Initial prototype of a `<toolbar>` element is coming along. Largely piggybacks off the focusgroup code so it's actually quite simple to do.
Lots to discuss and tweak before it's finished but got to start somewhere.
I personally think that camera and microphone is an easier sell because of the kinds of UI you get for those permissions and how they are often necessary to the flow.
Geolocation specifically is often not a requirement and generally stays out of your way until you ask. I could be completely wrong.
Yeah exactly, we already have the geolocation JS API, which you can use with any button you want. Yeah there's some rough edges with the permissions BUT also it's the status quo.
There's a nice carrot but there's no real stick for this, and it looks weird as heck on your site. Why bother migrating?
In my humble opinion this is an excercise in futility and pretty much no stick (that's web compatible anyway) is going to be strong enough for the carrot to be worth it...
You can hide the icon but not text which means this isn't going to work on most pages, maps all have small icon only buttons.
If you make another element go too close to it (/"overlap" it) it also ceases to work too. Imo the whole element should just visibility:hidden in those cases to make it super obvious you've done something not supported by this element. Though that might show how potentially silly this whole thing is
Ah yeah, basically all origin trials will also be available under that flag (or rarely in a dedicated one). Origin trials are useful for testing with your real users who can't/shouldn't go and change flags.
chromium.googlesource.com/chromium/src... it's this seems it is experimental though so should be under the general experimental web platform features flag.
I'm guessing it's maybe behind a separate flag so it's not exposed under experimental web platform features?
Nothing right now to my knowledge but it can definitely be proposed in OpenUI.
Isn't there some trick with CSS variables where you can use them as a state toggle?
Ahhh! Nice. Didn't realise that had been prototyped.
See now I'm wondering how you've done this demo... Grid isn't supported yet so how do you move both directions?
Either way that's an amazing abuse of this π
I asked about, and it doesn't currently handle that it specifically works with "real" focus but it's definitely a use case with interest.
There's two I'm aware of github.com/gfellerph/fo... and github.com/doeixd/scope...
I'm not sure how complete either of them are right now, I agree it would be good to get one that we rubber stamp from Open UI. We link to polyfills in other explainers so we could do the same for this one.
Open UI has been working on speccing out the focusgroup attribute: a declarative way to support roving focus & add keyboard nav to composite widgets like toolbars/menus
We'd love your feedback!
Learn more & see open questions: developer.chrome.com/blog/focusgr...
H/t to Edge folks for prototyping
just posted about our Tagged PDFs work here:
vignatti.com/posts/access...
Yeah idk maybe winter TC isn't the right place, though I don't think it's just the minimum common API that is under the umbrella (might be wrong).
But more of the existing APIs implemented in node and deno would be nice. Rather than packages that work differently with different APIs.
Definitely like the idea of exposing more of these commonly used APIs on 'server'. I've always wondered why say web usb isn't implemented anywhere, you have to pull in a separate package to do it.
My big concern would be the 8GB of RAM. Imo you're gonna be stretching that trying to do much more than just using the browser.
It feels like it's not cheap enough to justify itself to me, a Mac mini is more powerful and not much more expensive?
Ah install size okay. I'm so used to thinking about bundle size (though I appreciate not having MBs in my node modules!)
When you say it's 6.7kb I'm assuming that's the node version and in the browser it's very small?
I wonder if GitHub might search transitive deps via package locks too and that's why your spot checks seemed to fail you? Just guessing as to why that might happen.
I know the npm data on dependents might not itself be super useful, I have a types package that I know is used by Microsoft for some VSCode thing but that obviously doesn't show in the dependents on npm. GitHub does find it though.
Maybe @npmx.dev should surface this kind of information?
Prototype appearance base range input
appearance:base will save us one day... I need to be careful I don't break something while trying to implement it though.
Today in form controls are cursed, a range input with appearance none renders a thumb but no fill or track in all 3 major engines.
Igalia is proud to announce our Coding Experience program for 2026! Open to all new programmers, students and self-learners alike, applications are invited till the 3rd of April in one or more of five areas of Open Source development.
Apply now!
www.igalia.com/2026/02/27/I...
Though worth being aware that in browsers without setHTML this will mean you can't set HTML at all.
The CSP to disable unsafe sinks is `require-trusted-types-for 'script'; trusted-types 'none';`. This enables trusted types enforcement and that no policy names are allowed. So you're forced to use setHTML for setting HTML, it then also blocks eval and other forms of dynamic JavaScript execution.
