This is helpful when development revolves around static environment.
Replacing JavaScript with Just HTML
81–90 of 296 posts
Re: Replacing JavaScript with Just HTML
#82Earlier quoted context omitted.
Animating accordions is almost always a bad idea because the content length can make it unbearable. In general I find animations on the web overused and unnecessary
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.
Re: Replacing JavaScript with Just HTML
#83The 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.
You can't actually control the open state properly from markup (the `open` attribute only sets the default state), which is why I haven't bothered with them.
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...
Re: Replacing JavaScript with Just HTML
#84I really try not using JavaScript unless absolutely needed. On my latest project, the whole site actually functions without JavaScript and is server side rendered. However, there's some small piece which I really needed JavaScript for couple reasons.
Basically, I have a site which collects the top STEAMD posts from places like HN, lobsters, tildes, slashdot, bear, reddit etc and displays them in chronological order. I wanted a way for users to block posts with certain keywords or from specific domains. I didn't want to do this server side for both performance reasons plus privacy reasons. I didn't want users to need signing up or something to block. I also didn't want to collect block lists for privacy reasons. So, I resorted to using JavaScript and local storage. All posts within the filter for the date are sent and JavaScript is used to block posts with keywords before displaying. So my server never knows what keywords are blocked.
Site for anyone curious:
Re: Replacing JavaScript with Just HTML
#85Earlier quoted context omitted.
Tabs, accordion, combobox. There is a whole lot more, these are just the ones I can remember now.
Yeah this is true at this point. A lot of more complex patterns require JS to be accessible to screen readers. We still should do more with HTML and CSS! And reach for leaner solutions than React everywhere. But be careful going for a pure CSS solution for things like tabs if you don’t understand the accessibility requirements. (I wish the HTML spec would move faster on these common patterns!)
https://www.w3.org/WAI/ARIA/apg/patterns/ is my go to for accessibility requirements of components.
And yes, being able to do all of these in pure HTML/CSS would be awesome. Though we are getting there with things like `details` and the newer `popover` features which should make things like rich tooltips, menu buttons, etc. a lot easier to implement. IIRC, there are also several anchor CSS properties to make positioning a lot simpler.
Re: Replacing JavaScript with Just HTML
#86Earlier 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.
Hey the email services has just proved you could offer better than Gmail experience with HTML + small dose of JS. Another example being the new FE on Github.
At the end of the day it isn't really the tech that is the problem. Is how people use the tech. And for thousands of different reasons keeping it simple has always provided better experience evaluated on the whole.
Re: Replacing JavaScript with Just HTML
#87Gimme a dark/light mode switch. CSS is allowed.
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
Re: Replacing JavaScript with Just HTML
#88Earlier quoted context omitted.
> But as much as I hate to admit it, it is very difficult to build something functional today with plain HTML and no/minimal JS. I would certainly agree that using a little JS can get you further than just HTML. But I think that a plain HTML page is far more pleasant to use (and thus, functional) than the JS monstrosities that dominate the Web today. There's a reason people use the NoScript addon: because a whole lot…
It's not an either/or. Modern Javascript is actually really nice to write and use, and you can write it in a tight, minimal way that doesn't bloat the page or slow it down.
>you can write it in a tight, minimal way that doesn't bloat the page or slow it down.
Yet most people don't.
There are some problems with the language itself but it's mostly from a users perspective that I find it frustrating.
Re: Replacing JavaScript with Just HTML
#89Earlier quoted context omitted.
like what?
Tabs, accordion, combobox. There is a whole lot more, these are just the ones I can remember now.
If we've concluded that's it's okay to have elements that change/morph, as we seem to with the introduction of things like details, a native tab-like element feels like a glaring omission. Tabs have been a long-standing UI pattern and forcing every site to implement their own is a nightmare for accessibility. (The page you're reading is maybe already in a browser tab.)
I wouldn't be surprised if it turned out less than half of the custom tab interfaces on the web failed from an accessibility standpoint. When considering ARIA guidance, I don't even think it's possible to build an accessible version in HTML alone.
Other people have recognized it's missing. Open UI has a draft spec for it[0] and CSS Tricks has an article from 2001 about Open UI's experiments with sections for tabs[1]. I have no idea what happened on this front, though.
[0] https://open-ui.org/components/tabs/
[1] https://css-tricks.com/newsletter/281-tabs-and-spicy-drama/
Re: Replacing JavaScript with Just HTML
#90Earlier quoted context omitted.
You can't actually control the open state properly from markup (the `open` attribute only sets the default state), which is why I haven't bothered with them.
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...
It's not about using it as an accordion, it's about controlling the open/closed state from other interactions.