Live data from Hacker News

I'm betting on HTML

catskull.net

371–380 of 458 posts

Re: I'm betting on HTML

#371
post #358

Earlier quoted context omitted.

Actually, that sounds like one of the better startup ideas I've heard around AI. Automated accessibility compliance (or something close to it) would be very useful and definitely something people would pay money for. I fear LLMs are only about 80% up to the task, though, which is actually a very unpleasant place to be in that curve; sort of the moral equivalent of the uncanny valley. Whatever comes after LLMs though,…

80% sounds way to optimistic to me. The problem is that screen readers (and other assistive technology) have bugs and different behaviors, and some people use older versions of those tools with even more bugs and quirks. The only way to make sure that a website has a high level of accessibility is to perform manual testing in different environments. I don’t see how AI can solve this problem. And the people who perfor…

LLM could transform "bad HTML" into good HTML; add ARIA tags, add image captions, etc.

Re: I'm betting on HTML

#372

Earlier quoted context omitted.

80% sounds way to optimistic to me. The problem is that screen readers (and other assistive technology) have bugs and different behaviors, and some people use older versions of those tools with even more bugs and quirks. The only way to make sure that a website has a high level of accessibility is to perform manual testing in different environments. I don’t see how AI can solve this problem. And the people who perfor…

LLM could transform "bad HTML" into good HTML; add ARIA tags, add image captions, etc.

Unless it’s 100% reliable or near 100% reliable, you’d still need manual testing. Right now, automatic accessibility testing can’t even detect most accessibility issues. So we haven’t even reached the stage where all issues are detected by tools, and probably never will. Fixing all issues automatically is significantly harder than detecting them.

Re: I'm betting on HTML

#373
post #358

Earlier quoted context omitted.

Are you suggesting that AI will solve web accessibility, which is based on semantic HTML and ARIA? Because if not, humans will still be required to ensure that web content is accessible, and in that case semantic HTML remains important.

Actually, that sounds like one of the better startup ideas I've heard around AI. Automated accessibility compliance (or something close to it) would be very useful and definitely something people would pay money for. I fear LLMs are only about 80% up to the task, though, which is actually a very unpleasant place to be in that curve; sort of the moral equivalent of the uncanny valley. Whatever comes after LLMs though,…

The idea generalizes. Imagine an archiver which applies a transform to a site. Adding semantic markup - or censoring parts that someone finds offensive. If the original author agrees, they might offer an api so the transformation is linked to by the original. Or perhaps the transformer could make an agreement with/fool Google into linking to their version rather than the original. Perhaps because it's "safer".

Oh yes, a great startup idea.

Re: I'm betting on HTML

#374

Earlier quoted context omitted.

Look terrible? Didn't we have this debate a couple of decades ago about separation of semantics and presentation? Sorry, I should have let it slide.

I think what that person meant was if browser default styles made semantic HTML look more beautiful, it would probably reduce the incentive for lazy devs to make div soup. Like imagine if every browser preloaded a dozen attractive classless CSS frameworks for users and/or devs to choose from sort of like CSS Zen Garden. If all browsers had that, I think we'd get less div soup.

Three things I think:

(1) Unstyled HTML looks terrible.

(2) There's relatively few native components and the ones that exist are limited. Like not even what JQueryUI gave you 15 years ago limited. No cards, accordions, avatars, and other sorts of basic building blocks.

(3) No real support for common page layouts. Like a Dashboard or Hero marketing page sorts of things.

Re: I'm betting on HTML

#375
post #358

Earlier quoted context omitted.

Actually, that sounds like one of the better startup ideas I've heard around AI. Automated accessibility compliance (or something close to it) would be very useful and definitely something people would pay money for. I fear LLMs are only about 80% up to the task, though, which is actually a very unpleasant place to be in that curve; sort of the moral equivalent of the uncanny valley. Whatever comes after LLMs though,…

80% sounds way to optimistic to me. The problem is that screen readers (and other assistive technology) have bugs and different behaviors, and some people use older versions of those tools with even more bugs and quirks. The only way to make sure that a website has a high level of accessibility is to perform manual testing in different environments. I don’t see how AI can solve this problem. And the people who perfor…

My estimate of 80% included 6-12 months of serious development first, and a certain amount of budget for manual intervention for the first several dozen jobs. Certainly just flinging HTML at ChatGPT as it stands today would do nothing useful at all. Providing manual testing could easily be done as part of a higher service plan. Not only is there no rule that a startup using AI has to be just in the form of "throw it at the AI and then steadfastly refuse to do anything else", that's probably a pretty good way of filtering out the ones that will make it from the ones that won't.

Do assistive technologies have more "bugs" and "quirks" and "different behaviors" than natural text? I don't really think so. In fact I'd expect they have qualitatively fewer such things.

Semantic HTML would be important in this case... but it would be important as the output, not the input.

This hypothetical startup could also pivot into developing a better screenreader pretty easily once they built this, but there would be a good few years where an AI chewing on the HTML and HTML templates in use by a server would be practical but you can't expect every assistive technology user to be using a 64GB GPU to run the model locally. Certainly that would factor into my pitch deck, though.

I'd give more credence to the "it has to be perfect to be useful at all" argument you're going with here if it weren't that I'm pretty sure every user of such technology is already encountering a whole bunch of suboptimal behavior on almost every site today.

Re: I'm betting on HTML

#377
post #332

Article's first sentence: "With the advent of large language model-based artificial intelligence, semantic HTML is more important now than ever." I think the sentence "With the advent of large language model-based artificial intelligence, semantic HTML is less important now than ever." is far more defensible. The semantic web has failed and what replaced it was Google spending a crap ton of money writing a variety of…

Are you suggesting that AI will solve web accessibility, which is based on semantic HTML and ARIA? Because if not, humans will still be required to ensure that web content is accessible, and in that case semantic HTML remains important.

If semantic HTML is important for accessibility and for software to be better able to parse information out of it, and AI solves the latter, semantic HTML is now less important because some of the use cases that needed it previously no longer need it. If you take "less important" as a moral/value statement instead of in terms of total utility provided, and assume that AI will have zero accessibility benefits, it will merely be as important as today, which is still at odds with the assertion of the original article that it would become more important. N.B. this seems doubtful, given how e.g. you can now past a bunch of code into an LLM and ask it questions quite naturally -- something I can easily see adapted to e.g. better navigating apps using only voice and screenreaders.

Re: I'm betting on HTML

#378

Earlier quoted context omitted.

LLM could transform "bad HTML" into good HTML; add ARIA tags, add image captions, etc.

Unless it’s 100% reliable or near 100% reliable, you’d still need manual testing. Right now, automatic accessibility testing can’t even detect most accessibility issues. So we haven’t even reached the stage where all issues are detected by tools, and probably never will. Fixing all issues automatically is significantly harder than detecting them.

Given how bad accessibility is, it seems like even something imperfect could be a big leap forward for a lot of sites.

Re: I'm betting on HTML

#379
post #169

Earlier quoted context omitted.

> 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…

So what are these great rebuttals? "Why not provide high-level powerful primitives out of the box?" So in practice most devs bypasses them and write their own high level primitives anyway, relying on the browser only for low level APIs. That's the point the article is making. Hixie is merely observing that this situation exists, has always existed and probably always will, so browser makers may as well embrace it. An…

> So what are these great rebuttals?

Those that you apparently read but didn't understand.

> the browser is a 30 year effort to do that and has always failed at it

And so the "we will not give you anything at all, implement everyting including all layouts, all widget all interoperability etc. from scratch" will work?

> browser implementations of even basic widgets aren't usable

Great article on the topic: "You can't capture the nuance of my form fields https://drewdevault.com/2021/06/27/You-cant-capture-the-nuan..."

The problem with the basic widgets is not that they are incomplete, but that they are not enough. Almost any attempt to re-build even the built-in widgets sucks and fails in numerous ways. Now Hixie wants to remove event that and pretend that building all that from scratch is "easier for developers".

> that's essentially what the Chrome WebUI PM says they plan to do: just talk to the authors of React and other frameworks, ask them what they need and do that i.e. give up on HTML tags like and

Here's what that PM said, verbatim:

--- start quote ---

No one needed and they needed and

Developers mostly don't want the assembly language of the web, they want their chosen frameworks to have excellent DX and the UX they produce to be fantastic. When we see frameworks as a core customer/partner for web APIs, things turn out a lot better.

--- end quote ---

How you read this as "give up on HTML tags" and "refocus on obscure features" is beyond me.

BTW, here's what Dan Abramov, on of the key developers of React, had to say a while back: https://dev.to/dan_abramov/comment/6kh1

--- start quote ---

React users would love to not have to npm install a date picker and bloat their bundles! If they need to "use the platform" then why doesn't that platform ship the features they actually ask for? Instead of a they get an . Features like service workers are touted as a solution to many problems in the web, but their ergonomics are so under-designed that people actually have to change domains to bust the cache from a broken build (I’m not making this up).

--- end quote

But sure, "give up on HTML tags like and , refocus on obscure features that make framework devs happy". Making the platform be only extreme primitives will definitely not make framework authors happy.

Re: I'm betting on HTML

#380
post #54

Earlier quoted context omitted.

> Section and article really don't add any value They are nice hints to assistive technologies and reader mode.

Yep that's totally fair! I'm not 100% sure if assistive technologies use section and article for any end user context like "jump to content", but they at least can be used to get more context than just another div Reader mode is one I don't think about enough. I could see that purposely hiding content outside of the article element.

Yeah, Reader mode is weird. I know it prioritises semantic tags like article, but since the behaviours are not standardised, I never know what will and will not work.
Post reply on HN