241–250 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.
Earlier quoted context omitted.
I often use different light/dark settings between apps and my system. Just because I want system UIs to be dark, for example, doesn't mean I want to read long pages of white-on-black prose on your blog.
Then you still don't need a switch on every website. Just set the browser to display the light version and have it ignore the system setting.
Earlier quoted context omitted.
The pure-css effects I mentioned both don't use / .
Same caveat applies to the "checkbox hack" or any other pure CSS solution. You cannot create accessible versions of most complex controls like tabs without JavaScript. (That first example could be created semantically and accessibly with / though!)
Earlier quoted context omitted.
I've never met a designer who wasn't completely fine with my suggestions for more pragmatic solutions. Like just styling a default scrollbar instead of implementing my own scrollbar to make it exactly like the design. Using a default drop-down menu instead of rolling my own just so I can round the corners of the selects. The designers I've worked with are fine with these things. We have more important things to work…
I've never met a designer who cares how it gets done but I have hard time believing they were OK with the corners not being rounded as per the design. They may agree on shipping without the rounded corner, as long as the ticket to round that corner is registered. I suppose though that we have just had very different life experiences, as that is what the HN guidelines would require of us.
I have also met a lot of completely unreasonable designers that would insist on the most minimal things (even to the detriment of usability), and would act like assholes towards developers.
I have also had situations where developers would beg to work with a certain designer because their experience made development a breeze, even for complex layouts. Funny enough, the projects where this designer worked would always get done, and the visual result was always great.
Earlier quoted context omitted.
The committee is an unsolved puzzle as old as mankind. That's not to discourage you. If you do solve it it would remedy almost all of our problems. If the solution could be found instantly in 5 seconds someone would have solved it already. This one is going to take some actual thinking and modeling.
I know for sure that Apple, who has an important seat on the standard committee, holded back innovation for so long, it's not a matter of finding or not finding solutions. They're failing us for different interests
Apple isn't the problem.
Apple was the first to ship :has(), which developers wanted for 20 years but was thought to be essentially impossible to implement [1].
Apple pushed to get consensus on how to implement masonry layouts in CSS [2].
And they were first to ship the new specification in a browser you can use right now [3].
This dashboard shows Apple slightly ahead in terms of new CSS features being implemented and interoperable with Firefox and Chrome [4].
[1]: https://webkit.org/blog/13096/css-has-pseudo-class/
[2]: https://webkit.org/blog/16026/css-masonry-syntax/
[3]: https://webkit.org/blog/17660/introducing-css-grid-lanes/
Earlier quoted context omitted.
The major issue with this is that modern CSS is almost its own job, to the point we used to have Interface Developers at some place I’ve worked (HTML+CSS specialists). I did frontend for over a decade and eventually lost the train on CSS changes, I don’t even know what’s going on there anymore. It’s still awesome, but it’s becoming increasingly silly to ask someone to know modern HTML, CSS, JavaScript, Typescript, so…
When I started dabbling in web development, writing HTML and CSS was already its own job, and professional JavaScript developers basically did not exist. This was before TypeScript, before Node, before Ajax, before React or even jQuery. If anything has exploded in complexity in the intervening years, it's the JavaScript part of the equation. I agree that it's increasingly silly to ask someone to be an expert in all o…
Earlier quoted context omitted.
The pure-css effects I mentioned both don't use / .
Same caveat applies to the "checkbox hack" or any other pure CSS solution. You cannot create accessible versions of most complex controls like tabs without JavaScript. (That first example could be created semantically and accessibly with / though!)
rather than not working at all with js disabled
Earlier quoted context omitted.
@starting-style Has less than 90% browser support making it a non-starter for the time being at least.
It'll just degrade gracefully into not animating the element's entry, so unless the animation is somehow crucial you should still be fine to use it. If you really need to detect whether it's supported there are hacky methods: https://www.bram.us/2024/07/11/feature-detect-css-starting-s...
Earlier quoted context omitted.
I dont think anyone is arguing Google Earth should be pure HTML. But it is equally false you cant do Gmail with HTML only. There are things that HTML could do, and should be doing, that is not done or not yet possible simply due to hype and trend from browser vendors. We could continue to polish HTML + sprinkle of Javascript to its absolute maximum before hitting JS Apps. Right now this is far from the case.
Gmail with html only would not be a nice experience. Modern gmail is really bloated but it's actually one of the few web apps I have no problems with.