The problem is that CSS continues to be a pain in the ass, even as it evolves. There is no other reason why something like tailwind should have the traction it has.
Replacing JavaScript with Just HTML
191–200 of 296 posts
Re: Replacing JavaScript with Just HTML
#192The 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 feature can also be implemented with pure css without JavaScript. Here is an example: https://docs.go101.org/std/pkg/io.html , just click all "+" signs to expand contents. We can also use pure css to implement tab panels. A demo: http://tmd.tapirgames.com/demos.html#section-demo-4 Modern css is powerful.
Note that pure HTML and CSS implementations of tabs using and fail to meet several important accessibility criteria [1].
While you can make something that visually appears to act as a set of tabs, building it accessibly unfortunately still requires JavaScript.
[1] https://adrianroselli.com/2019/04/details-summary-are-not-in...
Re: Replacing JavaScript with Just HTML
#193Earlier quoted context omitted.
If you specify the same name on each `details` element they behave like an accordion automatically [1], no need for JavaScript. If you set one of them to open that one will be initially open. [1] https://developer.mozilla.org/en-US/blog/html-details-exclus...
different things with the same name? O_O
It’s the name of the accordion and matches how radio buttons work. If you want to distinguish them, you’ll give them different ids.
Re: Replacing JavaScript with Just HTML
#194Earlier quoted context omitted.
Why would you build a switch instead of relying on the user’s system settings? The only reason I can imagine is that your dark/light mode is not usable/readable so it forces the user to switch
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.
Re: Replacing JavaScript with Just HTML
#195I'm so not impressed by the toggle implementation... How nice it could have been. Nesting the elements is a truly hideous choice. The summary is part of the details?? I thought they were opposites. Should we also put the headings in the from now on? Identifying a target should be done by id or by name. That it does use a name because js can't target it without makes it even more stupid. We already had labels for form…
> Nesting the elements is a truly hideous choice. The summary is part of the details?? I thought they were opposites. It gives them a semantic connection. Last I checked, HTML isn't really based on giving special meaning to combinations of sibling tags. A summary is part of the thing that conceptually requires detailing. > If you find 1000 websites using a toggle I doubt there is one using an ugly arrow like that. I…
Thanks for your thoughts.
>It gives them a semantic connection.
I understand the logic but I don't agree with it.
An element should be visible or not be visible. There shouldn't be a 3rd state. It is a new idea and it is bad. Try writing a polyfill.
Even if you insist it shouldn't be the only way to use it. There should at least be a so that the clickable thing can be put wherever one likes.
The goal is to make things convenient for the user not to sacrifice usability for some semantics.
But if it was a summary is not semantically part of the details.
I don't actually care about that, I just want to use it.
A summary should be allowed to have hyperlinks. I passionately hate clickable paragraphs but if you are going to do that at least change the pointer into a hand.
I could put the under the summary the way almost everyone does but then the name makes no sense.
>I think the default looks fine.
A summary (longer than a few words) starting with an arrow looks weird.
The arrow would be reasonable UI for fold out menus but those are not summaries.
I would want some margin on the left for the of the sub menu.
What I don't want is to also have padding on the parent(!) menu item. Seems like a very confused parent child relationship.
>> Maybe I'm dense but I also want my url to reflect the state of the page.
>If you scroll, should the fragment automatically update as you scroll past anchors? I think I'd find that quite annoying.
Depends, if the thing is infinite scrolling and the user needs to send a permalink it would be nice to update it.
If I have an accordion with say frequently asked questions it would be necessary to link to the items.
It often isn't needed but I can't really picture when it would be annoying.
Re: Replacing JavaScript with Just HTML
#196Earlier quoted context omitted.
That is no longer true! You can do it in CSS with a combination of `@starting-style` and `transition-behavior: allow-discrete`. [1] Another gotcha you'll run into is animating the height. A couple other new features (`interpolate-size: allow-keywords` and `::details-content`) will let you get around that. [2] Modern CSS is awesome. [1] https://developer.chrome.com/blog/entry-exit-animations [2] https://nerdy.dev/open…
I can't see how a bunch of esoteric incantations are better than just some straight-forward easy to understand and follow JavaScript.
We've gotten so far away from semantic documents so we could build "apps".
Data used to be first class. You would deliver everything in the HTML container and the style sheets or client could do whatever it wanted/needed with that data.
Native search, native copy, no clever javascript tricks to hide or remove information from the document.
The HTML data container should be immutable.
Re: Replacing JavaScript with Just HTML
#197I'm so not impressed by the toggle implementation... How nice it could have been. Nesting the elements is a truly hideous choice. The summary is part of the details?? I thought they were opposites. Should we also put the headings in the from now on? Identifying a target should be done by id or by name. That it does use a name because js can't target it without makes it even more stupid. We already had labels for form…
"I also want my url to reflect the state of the page... It would have been great if the toggle action was implemented as a simple attribute something like toggle='element name'"
Your wishlist (state in attributes, URLs reflecting page state, anything being toggleable via simple attributes) is basically describing an architecture I've been working on called DATAOS (DOM As The Authority On State).
The core idea: instead of JS owning state and syncing to DOM, flip it. State lives in HTML attributes. JS just listens for changes and reacts. Want toggle state in the URL? The DOM attribute is the state, so serializing to URL is trivial.
It won't fix being weirdly designed, but it's a pattern for building the kind of declarative, attribute-driven interactivity you're describing.
Free book and open source libraries if you are curious: https://dataos.software/book
Re: Replacing JavaScript with Just HTML
#198Earlier quoted context omitted.
I agree, but must also observe that I have never met a designer who was willing to admit without a knock-down drag-out fight that any animation they put in was not somehow crucial.
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.
Re: Replacing JavaScript with Just HTML
#199I don't want to be so negative, but we got details and popover after literally decades, and we still have datalist presented as a plausible option? Html is so underdeveloped and the first we all agree on that the first we'll pretend from committee real advancement
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
Re: Replacing JavaScript with Just HTML
#200The 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.
Fun fact: even works on github and similar sites with markdown-based input. You can post large inline logs in issues without cluttering the conversation.
I used this for a long time, and only now realized that I'm using html embedding, not some hidden markdown feature.