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

HTML Can Do That

chrisburnell.com

Post reply on HN
Print view View original

151–160 of 249 posts

Re: HTML Can Do That

#151

Post by actionfromafar »

Wowfunhappy wrote: post #148
dajonker wrote: post #89

Popover, dialog, invoker commands, our entire production app uses these everywhere and it works really well! The fact that dialogs and popovers are rendered on the "top layer" and that nested popovers are also automatically stacked on top of each other and have 'cascading close' shows how well these standards were designed. The only hard thing is still to position a popover near the element that triggers it, such as…

> LLMs are also terrible at these new standards. If they even know about them, they often think they're not baseline yet and they have almost zero training data compared to the giant mountain of weird JS and CSS that people had to use before the introduction of these standards. I really wonder if AI coding is just going to lock us into 2024-ish era languages and libraries forever.

At least one thing to hold the torrent of churn back just a little. Silver linings..

Re: HTML Can Do That

#152

Post by zephen »

krapp wrote: post #110
zephen wrote: post #108

Earlier quoted context omitted.

> HTML describes layout News to me.

That's understandable, because almost no one actually works with HTML directly anymore, but it's true. HTML contains tags like for headers, for paragraphs, for line breaks for prerendered text, and for ordered and unordered lists, for tables as well as , , , , , , , and to both explicitly and implicitly describe the layout of an HTML document. In fact, "HTML" itself is an acronym (HyperText Markup Language) in which…

Thanks for the downvote, but you're wrong.

> explicitly and implicitly describe the layout of an HTML document.

No, this doesn't happen.

> In fact, "HTML" itself is an acronym (HyperText Markup Language)

Duh.

> in which the "Markup" describes the function of HTML to "mark up" text in a similar way that editors once did in the print industry, describing which parts of the text should be bold, italicized, etc. or divided up and in what way.

Which has fuck-all to do with the layout.

Re: HTML Can Do That

#153

Post by sublinear »

Wowfunhappy wrote: post #148
dajonker wrote: post #89

Popover, dialog, invoker commands, our entire production app uses these everywhere and it works really well! The fact that dialogs and popovers are rendered on the "top layer" and that nested popovers are also automatically stacked on top of each other and have 'cascading close' shows how well these standards were designed. The only hard thing is still to position a popover near the element that triggers it, such as…

> LLMs are also terrible at these new standards. If they even know about them, they often think they're not baseline yet and they have almost zero training data compared to the giant mountain of weird JS and CSS that people had to use before the introduction of these standards. I really wonder if AI coding is just going to lock us into 2024-ish era languages and libraries forever.

Yes. The maintenance costs of these models are very high. Something's gotta give soon.

It's exactly like trying to acquire a bootleg of a movie, but all you can afford is a single blurry jpeg taken from the back row of a theater.

What's worse is you're an alien who wants to understand life on Earth by watching this single movie. That's how far away we are from AGI.

Re: HTML Can Do That

#154

Post by krapp »

zephen wrote: post #152
krapp wrote: post #110

Earlier quoted context omitted.

That's understandable, because almost no one actually works with HTML directly anymore, but it's true. HTML contains tags like for headers, for paragraphs, for line breaks for prerendered text, and for ordered and unordered lists, for tables as well as , , , , , , , and to both explicitly and implicitly describe the layout of an HTML document. In fact, "HTML" itself is an acronym (HyperText Markup Language) in which…

Thanks for the downvote, but you're wrong. > explicitly and implicitly describe the layout of an HTML document. No, this doesn't happen. > In fact, "HTML" itself is an acronym (HyperText Markup Language) Duh. > in which the "Markup" describes the function of HTML to "mark up" text in a similar way that editors once did in the print industry, describing which parts of the text should be bold, italicized, etc. or divid…

[flagged]

Re: HTML Can Do That

#155

Post by michaelchisari »

jamescun wrote: post #5

I'm that minutia in your statistics that is still rocking NoScript in 2026, enabling JavaScript on a site-by-site basis, but this is increasingly difficult with the modern web. Hopefully these and others modern HTML features gain adoption, along with realizing perhaps a Single Page Application isn't necessary in most instances. I don't often have to write frontend code, but when I do, there is very little in terms of…

The View Transition API makes this even more viable.

https://developer.mozilla.org/en-US/docs/Web/API/View_Transi...

https://view-transitions.chrome.dev

Best part about it is how gracefully it degrades.

Re: HTML Can Do That

#156

Post by alwillis »

dajonker wrote: post #89

Popover, dialog, invoker commands, our entire production app uses these everywhere and it works really well! The fact that dialogs and popovers are rendered on the "top layer" and that nested popovers are also automatically stacked on top of each other and have 'cascading close' shows how well these standards were designed. The only hard thing is still to position a popover near the element that triggers it, such as…

> LLMs are also terrible at these new standards. If they even know about them, they often think they're not baseline yet…

It doesn’t have to be that way.

You could create a Skill [1] that tells the agent to use modern css; the newer models like Opus 5 are probably much better with modern css.

Google released a set of skills at I/O called Modern Web Guidance [2] that steer coding agents to use modern css and best practices.

[1]: https://www.skills.sh/paulirish/dotfiles/modern-css

[2]: https://developer.chrome.com/docs/modern-web-guidance/get-st...

Re: HTML Can Do That

#157

Post by theandrewbailey »

yurishimo wrote: post #2

Just a heads up but datalist is not really a great solution if you need a strong contract. The user can still type whatever they want into the field and there is no fuzzy filtering or typo mitigation. Once you add those requirements, a library that gives you a more fully featured combobox is likely going to make a lot of sense in your project.

Not having fuzzy filtering could be OK if you could filter the datalist and force it to display anyway. (There is no way to force it to display.) I gave up and used or instead.

Re: HTML Can Do That

#159

Post by zephen »

krapp wrote: post #154
zephen wrote: post #152

Earlier quoted context omitted.

Thanks for the downvote, but you're wrong. > explicitly and implicitly describe the layout of an HTML document. No, this doesn't happen. > In fact, "HTML" itself is an acronym (HyperText Markup Language) Duh. > in which the "Markup" describes the function of HTML to "mark up" text in a similar way that editors once did in the print industry, describing which parts of the text should be bold, italicized, etc. or divid…

[flagged]

> And all you're responding with is invective.

This statement is mendacious, at best. I have explained that HTML has fuck-all to do with layout. I can explain it to you, but I can't understand it for you.

Here, check out what the W3C has to say about it:

> Because HTML conveys meaning, rather than presentation, the same page can also be used by a small browser on a mobile phone, without any change to the page. ... But it goes further than just differences in screen size: the same page could equally be used by a blind user using a browser based around speech synthesis, which instead of displaying the page on a screen, reads the page to the user, e.g. using headphones. Instead of large text for the headings, the speech browser might use a different volume or a slower voice.

(Emphasis in the original.)

https://html.spec.whatwg.org/multipage/dom.html#semantics-2

Also, check out the ACID series of specifications which require and always use CSS, because otherwise, there is no mandate on how a browser should display stuff.

And, just for completeness, here are a couple of quotes from Tim Berners-Lee:

> HTML should convey the structure of a hypertext document, but not details of its presentation. This was the only way to get it to display reasonably on any of a very wide variety of different screens and sizes of paper.

> The separation of presentation from structure is a fundamental principle of the Web. HTML documents represent the logical structure of the document; style sheets provide formatting instructions.

Now, I will grant you during the browser wars of the 90s when everybody was trying to get ahead, some layout elements were stupidly added to HTML, and copied by other browsers. But these came nowhere near close to being definitive layout descriptions, and since at least 1997, the W3C has advocated for separating content into HTML, and presentation into CSS.

Post reply on HN