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

161–170 of 249 posts

Re: HTML Can Do That

#161

Post by jmpeax »

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.

Skill issue? I mean, I wonder if adding a skill to use these newer standards can push it over the edge from the crappy JS it was trained on.

Re: HTML Can Do That

#162

Post by extra88 »

doginasuit wrote: post #137
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…

> The only hard thing is still to position a popover near the element that triggers it, such as when you want to create a context menu that has to render above/below the button that triggered it. If you put something like this in your popover class, it will resolve to the button that called it when position-anchor is not set: top: anchor(bottom); I'm not sure how widely supported it is but I've been using it in Firef…

All current browsers support anchor positioning including popover buttons being the implicit anchor. However, the anchor positioning polyfill does not support this, it requires an explicit anchor-name.

Re: HTML Can Do That

#163

Post by extra88 »

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…

CSS now also has `reading-flow` to instruct the browser to change the reading order to match the visual order created by Flex or Grid. Unfortunately, not all browsers support it and it has some limitations.

Re: HTML Can Do That

#164

Post by extra88 »

waltbosz wrote: post #133

The color input looks different depending on your browser and OS. https://master.dev/blog/the-color-input-the-color-picker/ Firefox uses the native OS color picker, which in Windows 11 still looks unchanged from Windows 95.

That's fine, everything doesn't have to look the same everywhere. It does matter when there's functionality a site relies on but it's not available in one out more browser/OS combinations.

Re: HTML Can Do That

#165

Post by extra88 »

pseudosavant wrote: post #80
jdlshore wrote: post #4

The “hidden until found” feature surprised me. What’s the use case for something like that?

There is a common accessibility pattern where the first tab focusable item is a "Skip to content" link in the top left corner. The link is initially hidden until you tab to it. That is the only use case I could think of when checking it out.

That's not what it's for, that's solved by showing the link when it's focused.

My guess is there was a desire to make Find-in-page automatically expand elements and someone realized they could make it also work for custom disclosure widgets by giving the boolean attribute `hidden` an optional value.

Re: HTML Can Do That

#166

Post by preg_match »

tyre wrote: post #52
gunalx wrote: post #33

Earlier quoted context omitted.

Single page applications are one of the most anoying web patterns i know of. Please just let me have one page for each ting to do so i actually can bookmark it properly.

This is possible and, in my experience building them, the norm. SPAs have routers and update navigation state, including history for browser Back/Forward

Right but most of the time they don’t work. For example, LinkedIn, and instagram. I understand they have apps but… come on.

Re: HTML Can Do That

#169

Post by gulugawa »

dematz wrote: post #8

This comment by yurishimo should not be [dead], imo >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. It is true! HTML can…

The field can be enhanced with JavaScript to support filtering or typo mitigation.

Re: HTML Can Do That

#170

Post by cosmic_cheese »

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.

And related to that, native cell recycling for long lists would be nice, particularly with cases where the cells are on the heavy side.

Yes, it can be done with JS, but nothing is going to beat the browser engine for frequent DOM manipulation of that sort. It's also just one less dependency to have to pull in.

Post reply on HN