Hacker News

> often think they're not baseline yet

I'm not an LLM, but that was my immediate thought - how new does a browser have to be to support these and which browsers am I excluding by using these features?

> 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. There is anchor positioning in CSS now but support is still limited and I find it hard to wrap my head around.

I was going to suggest anchor positioning. I found it difficult to wrap my head around too, but once it clicks it's pretty simple. As a bonus, you can use it to position many other things than just popovers.

I'm curious how many people are involved in the design of your app and what their concerns are.

Testing for accessibility and on mobile devices has a tendency to derail the best intentions. What tools are you using for those concerns? I'm not asking because I need advice. I'm asking because I want to know what you or your team did.

Thanks for the vouch! The rest of the article was indeed good but I find a lot of value in hacker news comments precisely because someone comes back to the comments and lays out why what I just read might need a different perspective. If you just want to see cool stuff that a browser can technically do, we are all capable of reading the Chrome dev blog, but we come to HN for a wider perspective. Someone telling a war story about how some little tidbit came back to bite them is also valuable (imo).

I mildly disagree. You still have to validate what the browser gives you. The user could have edited the "strong contract" using browser dev tools.

So, let the user type, then validate in javascript if you want instant feedback (by changing colors, say, to red / orange), but ideally don't fully block it from being seen by the server. And do the real validation on the server side. This is what I found to be fairly robust, while allowing mitigations if a bad rollout breaks something (delivering to clients is slower than updating something on the server side, most often).

I seem to recall there was a proposal to add such thing to <select>s

(iirc if you have [showdead] on you can click on the timestamp to the comment and will get a [vouch] option as a reverse-flag, fwiw. i see it and don't have showdead enabled, so enough people have re-vouched it!)

I got frustrated with sites that should just be documents bolting on a pile of javascript libraries, third-party requests etc so I made a standard for sites that are just documents, and wrote a checker for document-only pages. For SSL, the thing that actually changed the web was browsers flagging non-SSL - probably similar is needed here. https://certifiedweb10.org/ if you're interested.

Thank goodness you exist, the fingerprinters will be confused as to which one of the two of us went to their website!

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.

One thing you notice running NoScript is how prevalent Google is.

Even if a site doesn’t monetize with Google Ads, there’s a decent chance it’s pulling a script from ajax.googleapis.com, and Google still knows that you visited the site from the Referer of the script download.

This is part of how I judge how well made or how shitty a website is. If it requires scripts from a dozen third parties, then it usually sucks and one can easily recognize when not much effort has been put into making it.

Does HTMX work with NoScript? Doesn't it require JS?

oh my. Looks like NoScript is way better than what I've been using. Thanks!

https://noscript.net/

Alternatively: have the <time> element actually do something by hooking it up to the new Moment API and having it display the specified timestamp in the user's locale. That would at least provide an easy way to have the input format and the display format be the same.

But yes, there's also a very good argument to be made in favor of having such localized elements follow the content's `lang` attribute - potentially with a `lang="initial"` to reset it to "whatever the user has configured for their OS".

I'd be okay with regional date format for the user but it always submits as ISO 8601 date format.

Dealing with this right now. Got some people whose devices are set to display dates as dd/mm/yyyy and the janky pay submission form records it verbatim rather than translate to its internal mm/dd/yyyy format. If it's invalid date it will reject, but a guy submitted for August 4 and got denied for the system recording it as April 8. Spreadsheet MS Forms nonsense. Nobody cares.

This is… not obvious. It's only easy if you want the simplistic approach of sorting lexicographically or numerically. But in more complex tables, you will often encounter cases where the data representation for sorting is different from data representation for display.

Of course most JavaScript-based tables get this wrong, too.

I feel like there's so few times it would actually work how I want it that it seems like there's little point.

You want client side table sorting?

It's really easy to do this with server rendered HTML. Put a link with the sort param in the column headers and be done.

That's what javascript is supposed to be for. All of this is what javascript is supposed to be for.

HTML describes layout, CSS describes style, JS adds interactivity.

Want sortable tables? Get a jquery plugin and spend five minutes, done.

This was all solved a decade or more ago.

You can also control this behavior for almost any hidden element with the `hidden="until-found"` attribute

https://css-tricks.com/covering-hiddenuntil-found/

https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/...

Yeah I've seen a page that described a whole bunch of things you can do with CSS. So many animation options!

Looks like it's basically like a one way show-hidden mechanism, but the browser's built-in search will pop it open on matches.

So you could use it for additional notes, things like "view pricing terms" or "show exclusions" on product listings — stuff people need to read only when they need to read it — without it being hidden from them if they search for it.

It won't be an intended use case, but it might be a convenient place to put poisoned content for the “benefit” of scrapers…

Though humans will accidentally find it too, so using a details tag with appropriate summary as a warning would be more friendly than just hidden content. It'll still get opened, but the user at least has a way of closing it again afterwards.

Also before using it I'd want to check what old UAs including accessibility tools tend to do when they hit a value that they don't recognise for the hidden="" attribute - would what they don't recognise as a valid value result in defaulting to the content being hidden or visible/read/other?

Pretty cool! I’ve been using <details> for this. One example would be a collapsible tree hierarchy of our organization that you can CTRL+F and still find collapsed teams and people. Or an accordion, or anything collapsible, really.

I use it for tabbed content. That way search will reveal the tab and content on page search match.

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.

On a big page with lots of collapsed content, I want control+f to search it and find anything in the collapsed sections without having to manually expand them all before I hit control+f

One thing that comes to mind is JS-less image preview, clicking on an image thumbnail reveals the full preview.

Odd to both complain about adoption and out yourself as someone unwilling to move to a better solution because it’s less familiar. What do you expect the answer to be here?

With the exception of using divs for things that have a more appropriate element. Buttons for example - for the love of all that is holy - when I see an onclick handler and aria attributes on divs, I think, "couldn't you have restyled the button??"

Do I understand that first one correctly as datalist without allowing the user to submit a value not on the list?

As opposed to what? Not sure what the alternative you're picturing is.

You can animate it now. There's no default though which is a bit annoying. I wish we had made it animate open/closed smoothly.

https://austingil.com/animating-details-element-with-only-cs...

https://developer.mozilla.org/en-US/docs/Web/CSS/Reference/S...

It is! Add css animation to the ::details-content pseudo element

Exactly. Why reïmplement features in JS just because you can? Waste of effort and usually a worse user experience!

Wait, that wasn't what you meant?

It is commonly used in dashboards when you want a confirmation dialog

Very true, and ran into this one specifically myself when going down the "HTML can do this!" road. HTML can NOT, in fact, replace a good combobox with search input. Datalist has significant shortcomings. I wound up using a React island for this single input inside otherwise normal HTML, despite my own objections, because it really it just that much better than the native options.

There’s still browser/OS typo mitigation.

Wow, yeah - years later and I still get nothing in Firefox, and support is quite spotty in general (and clearly still buggy): https://caniuse.com/?search=datalist

Hard pass, that's essentially unusable.

That's the whole sanitize vs. validate argument debate that keeps coming up.

How you handle it is project-dependent. But if you're doing a real web site, not an SPA, you can show an error/help page, or re-load the current page with the error/help message.

> When we will pretend a drawing api we can call directly from webassembly?

Hopefully, never. There's enough ad-blocking arms race as it is.