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

141–150 of 249 posts

Re: HTML Can Do That

#141

Post by ndriscoll »

dansalvato wrote: post #131
hk__2 wrote: post #20

Related to this, I’d love that HTML natively support sortable tables. This is a common need but every single time I have to reimplement it.

I had always thought that table sorting seems like the perfect job for HTML, given its data-driven nature, and the possibility of implementing sort information into the attributes of table cell elements. But thinking about it: Is there a precedent for HTML to be able to include information that instructs the device to present the DOM out of order? Maybe it's out of scope for HTML to have information about presentatio…

XSL has sorting, so kind of, depending on which document you're referring to when you say DOM.

Re: HTML Can Do That

#142

Post by ndriscoll »

krapp wrote: post #123
hk__2 wrote: post #118

Earlier quoted context omitted.

> Want sortable tables? Get a jquery plugin and spend five minutes, done. I want sortable tables without having to rely on a third-party plugin to a third-party library. HTML describes content, not just layout. It would be a `sortable` attribute on the table, just like you already have attributes that have nothing to do with layout such as `autocomplete` or `aria-*`.

Everyone already complains that browsers are too bloated and now you want to have every browser support sortable tables when a single, simple JS file would work?

The overwhelming majority of web pages are static documents, and it's a document format, so basic document primitives make sense. Same with something like line charts or pie charts. Bloat is things like USB APIs that present obnoxious security surfaces.

Re: HTML Can Do That

#144

Post by pavlov »

HTML in 2026 is starting to do most of what native desktop GUI frameworks did in 1996…

Well, honestly “most” is an exaggeration, when I think of what NeXT/Apple AppKit was offering around the turn of the millennium already.

It was a tremendous setback for front-end that Web 2.0 put everybody on the very lowest common denominator of UI frameworks, and then we spent decades just poorly rebuilding checkboxes and menu buttons.

Microsoft played a significant role here because they overreached around 2001, thinking their overwhelming desktop dominance will allow them to single-handedly decide the evolution of the internet’s UI layer. So they deprecated Internet Explorer (the browser with 95% marketshare) and put all their engineering bets on proprietary solutions like XAML as the HTML replacement.

Re: HTML Can Do That

#145

Post by abanana »

peesem wrote: post #97

once again, i will ask: why do people care so much about only having one element open at a time? let me see what i want to see!

Yes, absolutely, and UX experts such as those at the Nielsen-Norman group have for years been advising against auto-closing the already-opened options when opening another. For good reason - user frustration in their research.

If I clicked it to open it, then if I want to close it, I'll click it again. Don't hide content I might still be reading!

Re: HTML Can Do That

#146

Post by seanclayton »

t1234s wrote: post #132

HTML did since inception but that didn't stop people from trying to reinvent it using and a bunch of JS. All these great built in features, especially typeahead, wont be mainstream until they can be excessively styled.

> All these great built in features, especially typeahead, wont be mainstream until they can be excessively styled.

https://developer.chrome.com/blog/a-customizable-select

Re: HTML Can Do That

#147

Post by abanana »

mabini wrote: post #45

[flagged]

Although I've used that phrase myself in the past, I've come to hate it. Somebody will post it on every HN thread where any form of suggestion has been made.

If it's part of a paragraph of insightful commentary, it's meaningful. On its own it's not, it appears as though the poster chose to copy-and-paste a cliché instead of bothering to tell us what their specific disagreement even is (perfectly reasonable sarcasm from the sibling comment notwithstanding).

Re: HTML Can Do That

#148

Post by Wowfunhappy »

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.

Re: HTML Can Do That

#149

Post by abanana »

bellowsgulch wrote: post #36

The older I get, the less I want to use new browser features that have already been somehow possible with existing ones that typically have been around for literal decades. Adopting them makes a future with multiple browser engines more labor intensive and unlikely as the number of standards targets one is required to support grows and it becomes a game of asking yourself what sites you want your browser to support.…

You started that off by raising an interesting point. Pity you had to ruin it by telling us you're exceptionally thoughtful and profound, and that those who disagree, suck!

It's true, the amount of work that would be needed nowadays has made the idea of building a new browser engine almost impossible (I don't know how the Ladybird devs are getting on). It's a reason to encourage people to support Firefox on desktop, since just about everything else is based on the other browser engine. I still miss Opera's Presto - we don't want to lose another one, or there'll be no competition at all.

But as we've already crossed that threshold where the workload is preventing new engines from being built: choosing not to use new features, after they've been added to all the existing browser engines, isn't going to help that situation in any way.

Re: HTML Can Do That

#150

Post by hyperhello »

esprehn wrote: post #124
hyperhello wrote: post #82

Earlier quoted context omitted.

I mean the action and target attributes don’t seem to appear anywhere else but the popover api. I’m in favor of HTML dialogs, I just don’t see the point in the trend of making everything into this declarative nightmare it’s becoming when we have onclick=dialog.show() without even quotes.

Script attributes are very often disabled for security reasons. The declarative actions API is currently only used for popover, but it's been discussed for over a decade to allow SSR of rich content that's interactive before script loading. See also https://developer.chrome.com/blog/command-and-commandfor For a long time I also pushed back on these interactive APIs because script is a better primitive and every site…

What I guess this all leads to is that we’re trying to create some kind of DSA that doesn’t have the possibility to hang or crash the way imperative programs must have the ability to if they are to be effective. So it seems like web design is an avalanche of sort of silly css prefixes and selectors and attributes that refer to object ids and everything, when what we might have said instead is that if a script takes more than one second wall clock or something equivalent adjusted to standard then it gets rolled back like a transaction.
Post reply on HN