141–150 of 296 posts
The details / summary thing absolutely kills me. There’s basically nothing you can’t do with them. Hiding and replacing markers is easy. But every component library just pretends they don’t exist. It even saves you the effort of all the aria control and expanded tags: these tags don’t need them.
The details / summary thing absolutely kills me. There’s basically nothing you can’t do with them. Hiding and replacing markers is easy. But every component library just pretends they don’t exist. It even saves you the effort of all the aria control and expanded tags: these tags don’t need them.
It’s odd and frustrating that such an essential tag is not defined to be accessible, afaik.
I didn't know about , but how are you supposed to use it with a non-trivial amount of items in the list? I don't see how this can be a replacement for javascript/XHR based autocomplete.
Don't use it, it totally blows. For another oddity to not use, check out the multiple select: https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/... Expecting users to press modifiers when clicking on these is so funny.
I mean… 5 year olds can figure out shift-click in Minecraft.
The details / summary thing absolutely kills me. There’s basically nothing you can’t do with them. Hiding and replacing markers is easy. But every component library just pretends they don’t exist. It even saves you the effort of all the aria control and expanded tags: these tags don’t need them.
Last I checked that without JavaScript details / summary has accessibility issues. That is, you need JS to add aria-open or similar. It’s odd and frustrating that such an essential tag is not defined to be accessible, afaik.
Every question/exercise is centred around how well you know React hooks, effect, memoization, modern css-in-js etc. Given I've been working with Astro recently, in one interview I talked about DOM APIs and I can see the interviewer raise an eyebrow. In later stage, even I that passed the exercises, still didn't get the job.
I don't want it to be this way, but HTML has nothing approaching even one tenth the ambition of XSLT and XForms.
If HTML were proposed today, you would be laughed out of the room.
Earlier quoted context omitted.
Seriously. As a user I can count on zero hands the number of times I’ve said “Oh great, I’m sure glad this UI is animated!” - and likewise zero times have I missed it when animation isn’t used. Animation is a way to light small units of your users’ precious time on fire, for zero benefit.
Animations are also a way to explain causal relationships between interactions and their results, and to help build mental models of software behaviour.
Earlier quoted context omitted.
I’m not sure this is correct. The DOM class HTMLDetailsElement has the `open` property, which you can use to read/write the details element’s state. If you’re using setAttribute/getAttribute just switch to the property. https://developer.mozilla.org/en-US/docs/Web/API/HTMLDetails...
Having to use the property on the element instance, rather than the actual HTML attribute, is exactly the kind of wrapper code I want to avoid if I'm using a built-in.
`open` works just like checked for a checkbox input. You can set the initial state in HTML and CSS can respond to changes in the attribute if a user clicks it. Markup won't have programmatic control over the attribute by design, that's always done in JS by modifying the element instance.