Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

I'm betting on HTML

catskull.net

Post reply on HN
Print view View original

161–170 of 458 posts

Re: I'm betting on HTML

#161

Post by mixmastamyk »

klardotsh wrote: post #86
Gigachad wrote: post #56

Earlier quoted context omitted.

In general the issue with these built in components is that you can't theme them. And they stick out like a sore thumb when you get a windows 7 style component in the middle of a modern looking app. They also have basically no extensibility so when you inevitably need to do something half complex, you have to scrap it and start again with JS. So you may as well have just started with JS which just works, gives you fu…

Unfortunately this is a case where we'll have to agree to disagree. Half the time with Electron apps I wish I could disable CSS completely and just use my system theme because it sucks less than whatever the designer came up with for that app (the definition of "sucks less" falls into many axes that vary per application and context; no point in digressing far into that), so what you described would be a feature, not…

SKINZ all over againz!

Re: I'm betting on HTML

#162

Post by zelphirkalt »

jillesvangurp wrote: post #78

The point of walled garden is that they are very tempting to stay inside off for users. Their power comes from most users not resisting that temptation. Becoming the equivalent of a digital hermit and living in a hole in the ground outside these walls, which is what I would characterize this as, is not going to result on a lot of people stepping outside those walls. If you've ever watched Life of Brian, you'll have a…

Sometimes though, that dusty hole in the middle of nowhere seems to be the most progressive in terms of using standards, when the person sitting in it adopts new HTML elements, immediately having accessibility, while their JS-based rivals still struggle with restoring the functionality of the back button and adding routes in their SPA to get back something resembling normal linking behavior. In a way that is a much deeper dusty hole in the ground to dig for oneself.

Anyway, it is questionable, how much progress there is in moving into walled gardens and throwing multi megabyte websites at visitors, when we can have the same functionality with less.

Re: I'm betting on HTML

#163

Post by rezonant »

kevinstubbs wrote: post #116
wruza wrote: post #95

Earlier quoted context omitted.

ChatGPT (and its future offspring) can navigate regular websites the same way humans do It seems to be at least a not-yet-true claim, but let’s ignore that for now. It’s interesting if LLMs actually could do this. As I understand it, LLMs are trained on texts and source code among other things. But lacking… let’s name it a reasoning apparatus, can they really look at a DOM tree and tell what it is/does? It’s not a te…

> can they really look at a DOM tree and tell what it is/does Yes, if you encode the DOM as a list of options for ChatGPT to choose from. In fact I developed a proof of concept of this for a client. https://jarvys.ai/ although they seem to have pivoted from automating just the browser to automating all software.

Well if the DOM is all unstructured divs with no semantic information, can a human even tell what it means without applying the structural styling on the page?

A good example would be a misguided approach at making a bunch of labels with values that are aligned. Someone told this poor developer that is bad, so they figure hey, let's use CSS to lay it out. They make a dictionary of the key/value pairs and iterate over all the keys in the first column into the first div and then output all the values in the second div.

div - label 1 - label 2

div - value 1 - value 2

If there's 100 key/values it's going to be hard for a human to figure out which value is for the 76th item, and LLMs have proven to be very bad at indexing problems like that so I wouldn't expect it to be a better story there.

(Not saying this wouldn't work in some cases, just couldn't be a general solution given the crap out there)

Re: I'm betting on HTML

#164

Post by bob1029 »

p-e-w wrote: post #26

HTML is the solution to walled-garden lock-in? What? Those walled gardens already use HTML, including some of the semantic elements mentioned (plus ARIA semantic attributes, which are much more sophisticated). > ChatGPT-like interfaces are likely the future of human data access. And the whole point of artificial intelligence systems is that they don't require specialized "machine-readable" annotations in order to pro…

This seems reductive to me.

There's "HTML" and then there's the kind of website where the final DOM isn't known until the user has already been attempting to read it for 10 seconds. There is a substantial difference in the % of browser capabilities that need to be exercised between the extremes of use.

Complexity of implementation is what ultimately separates the good from the bad. Any tool can be operated skillfully or poorly. An apprentice with a circular saw and a fully charged battery can do a hell of a lot of damage. A master may elect to use no tool at all and simply bang on the side of the thing (I.e. push back on the business).

The latest websites I have built are some of my most compatible ever. I don't use web sockets anymore. I don't depend on JavaScript to have piecemeal conversation with the server. You can actually use ~80% of the product with JavaScript entirely disabled. How are the engineering choices demonstrated here not exactly the solution for walled garden lock-in?

Re: I'm betting on HTML

#165

Post by SPBS »

ugh I was so excited to see pure HTML modals were a thing with only to find out there's no way of triggering them without JavaScript. Using pure HTML you can only dismiss them, not trigger them.

https://github.com/whatwg/html/issues/3567

> dialog elements are a great addition and I'm glad they're getting implemented, but a key part of their functionality relies on JavaScript: to open a you need to use JavaScript to set the open attribute.

> It'd be great if there was a way to make a or a elements capable of opening dialogs.

> Precident already exists for page interactivity baked into HTML - for example can already scroll the page, and elements are capable of hiding elements behind interactivity, so I think it stands to reason elements could be opened by other page elements.

Re: I'm betting on HTML

#166

Post by broodbucket »

teekert wrote: post #150

Yeah do we need that disclaimer? If I (non native English speaker) write a blog post it will be shit English and won’t read “smoothly”. Then ChatGPT makes it nice and smooth. I check if my intentions are left unaltered and then post. For professional stuff I used to ask my American colleague, now I don’t have to bother her anymore.

I don't see it as confessing their sins, more like "FYI, I used X tool to help me with Y" like you'd see "Page generated by Z" in a footer except in a header since it's related to the content itself. Unless you're writing an assignment for an English class I don't think anyone would feel lied to if they found out you had help from an AI translator.

Re: I'm betting on HTML

#167

Post by jayjader »

rado wrote: post #61
Gigachad wrote: post #56

Earlier quoted context omitted.

In general the issue with these built in components is that you can't theme them. And they stick out like a sore thumb when you get a windows 7 style component in the middle of a modern looking app. They also have basically no extensibility so when you inevitably need to do something half complex, you have to scrap it and start again with JS. So you may as well have just started with JS which just works, gives you fu…

, , etc can be themed

requires some vendor-specific prefixes last time I tried theming it using CSS (unless you're using "theme" to mean host system/window mananger/browser - wide theme). There is no common subset (that I am aware of) of CSS properties shared amongst browsers that can be leveraged to even decently change the element's appearance. So I'm not sure that it is the best example.

I agree that many of the list _are_ themable enough to warrant investing the effort to wrangle their particular interfaces over reinventing them entirely with s.

Re: I'm betting on HTML

#168

Post by feitingen »

bob1029 wrote: post #164
p-e-w wrote: post #26

HTML is the solution to walled-garden lock-in? What? Those walled gardens already use HTML, including some of the semantic elements mentioned (plus ARIA semantic attributes, which are much more sophisticated). > ChatGPT-like interfaces are likely the future of human data access. And the whole point of artificial intelligence systems is that they don't require specialized "machine-readable" annotations in order to pro…

This seems reductive to me. There's "HTML" and then there's the kind of website where the final DOM isn't known until the user has already been attempting to read it for 10 seconds. There is a substantial difference in the % of browser capabilities that need to be exercised between the extremes of use. Complexity of implementation is what ultimately separates the good from the bad. Any tool can be operated skillfully…

Lots of websites already present a machine friendly site to google-bot and some other spiders.

I don't see why they can't offer the same to other bots and only serve the Javascript-heavy pages to humans.

Re: I'm betting on HTML

#169

Post by troupo »

rapnie wrote: post #143

Ian 'Hixie' Hickson gave his view on the future of the web in January this year in a public Google doc titled "Towards a modern Web stack" [0]. On its HN submission (referencing the wrong URL, so I resubmitted [1]) he defends against criticism [2] Quoting from the doc here's the stack: - WebAssembly (also known as Wasm) provides a portable compilation target for programming languages beyond JavaScript; it is being ac…

> On its HN submission (referencing the wrong URL) he defends against criticism [1]

And it's a very weak defence. There are great rebuttals to whatever he writes in there.

I mean, he rants that HTML failed, and then literally proposes "By providing low-level primitives instead, applications could ship with their own implementations of high-level concepts like layout, widgets, and gestures, enabling a much richer set of interactions and custom experiences with much less effort on the part of the developer."

Has he tried to implement any of those from scratch using only low-level primitives? How is it "much less effort on the developer"?

In general it just reads like a justification for Flutter:

"This API alone is not useful for application developers, since it provides no high-level primitives. However, as with other platforms, powerful frameworks will be developed to target this set of APIs. A proof of concept already exists in Flutter"

Why not provide high-level powerful primitives out of the box? Oh, then Flutter wouldn't have a reason to exist.

---

As a side note: WebHID is a Chrome-only non-standard. They literally dumped a non-spec onto other browser vendors, shipped it to prod, and then "updated" the spec later: https://github.com/mozilla/standards-positions/issues/459

Re: I'm betting on HTML

#170

Post by Kiro »

SPBS wrote: post #165

ugh I was so excited to see pure HTML modals were a thing with only to find out there's no way of triggering them without JavaScript. Using pure HTML you can only dismiss them, not trigger them. https://github.com/whatwg/html/issues/3567 > dialog elements are a great addition and I'm glad they're getting implemented, but a key part of their functionality relies on JavaScript: to open a you need to use JavaScript to s…

I don't see the higher purpose of "HTML only" if that means we need to extend HTML with scripting capabilities. In that case I rather just use JavaScript.
Post reply on HN