[HN Gopher] Hiding elements that require JavaScript without Java...
___________________________________________________________________
Hiding elements that require JavaScript without JavaScript
Author : mtlynch
Score : 58 points
Date : 2025-04-06 16:28 UTC (6 hours ago)
(HTM) web link (0xda.de)
(TXT) w3m dump (0xda.de)
| kaszus wrote:
| There is also CSS media now to detect if is enabled or not. It' s
| supported in last 2 versions of most popular browsers.
|
| https://developer.mozilla.org/en-US/docs/Web/CSS/@media/scri...
| gjsman-1000 wrote:
| By the time you are on the last 2 versions of popular browsers,
| you're at the point a developer can safely assume you have
| JavaScript, and can force you to use it.
| zamadatix wrote:
| The article is written around supporting "users who have
| JavaScript off", which is an option on all popular browsers.
| I.e. it's about better supporting users who don't want to use
| JavaScript, not about supporting e.g. Internet Explorer 1.0
| (though that could be helped by this kind of strategy too).
| gjsman-1000 wrote:
| Which in practice is an irrelevantly low number of people.
|
| Nowadays, unless you are serving developing markets,
| supporting legacy technology, or your website is truly just
| some basic static pages, it's a buzzword programmers use to
| flex on each other. That's about it.
|
| I personally find it annoying because I grew up as a junior
| right at the inflection point, when all the tutorials were
| still saying it was the right thing to do. That's a lot of
| work to do for something nobody - _and I mean literally
| nobody_ - in the real world cares about anymore. I would
| sooner brag about how my blog still works on Safari bundled
| with Snow Leopard.
| zamadatix wrote:
| Or it's something fun for a hacker to blog about
| polishing progressive enhancement on. You're free to
| choose your own takeaway of course. Part of the
| experience of being a junior is learning when which type
| of approach makes sense rather than expecting anything
| one reads to directly apply to how their next project
| should best be done, regardless if it's popular or
| unpopular. Not everything needs to be practical for most
| people to be worth writing about!
| sneak wrote:
| I am not nobody. Neither is Ed Snowden. Neither are the
| people who trained him, who regularly use javascript to
| exploit browsers.
|
| Many of us that know how security works on the modern web
| browse untrusted sites without JS enabled.
| userbinator wrote:
| This. The vast majority of browser exploits are in code
| related to the JS engine and its accompanying huge API
| surfaces, and even those rare ones which don't require it
| are often obfuscated/hidden using JS.
|
| Exploits aside, the amount of user-hostile irritating
| annoyances that just disappear without JS is also worth
| mentioning. Many years ago, I remember a site that was
| completely usable, yet continually begged me to "enable
| JavaScript for a better experience!", so I tried it and
| was immediately inundated with popups, moving flashing
| crap all over the page, and other things that I did NOT
| consider a "better experience". Never again.
| perching_aix wrote:
| You mean the _real world_ that can barely distinguish
| their browser from "Google"? Sounds like a very fair
| benchmark indeed.
|
| Did you know that HackerNews is 99% functional with JS
| turned off by the way? The only thing missing is the
| ability to collapse threads.
| lolinder wrote:
| It's still only available on about 90% of global browser
| traffic. If you're going out of your way to support noscript
| smoothly, you probably care about supporting more than just 90%
| of web traffic.
|
| https://caniuse.com/mdn-css_at-rules_media_scripting
| riedel wrote:
| I would guess even in absolute terms there will be more
| browsers with JavaScript disabled within the remaining 10%
| ffsm8 wrote:
| You think people that keep JS disabled will on average use
| older browsers?
|
| Idk, I honestly doubt that. In my experience the people
| using outdated browsers are on old mobile devices and some
| "special" enterprises micromanaging employee software
| installs
|
| And technologically illiterate apple users (because Safari
| doesn't Auto update like Chrome and Firefox)
| 0xdade wrote:
| Damn I didn't know this. I don't know how my search failed to
| turn this up, because I was literally googling how to
| accomplish it with media queries lol.
| microflash wrote:
| This is how `noscript` tags are hidden by UA styles.
|
| https://www.naiyerasif.com/post/2023/12/17/detect-scripting-...
| efortis wrote:
| Another option is using JavaScript to inject elements that need
| JS.
| bsza wrote:
| Doesn't need css, only adds placeholder divs to the "vanilla"
| html without unnecessarily downloading what would be inside.
| Simple and elegant, I like it.
| gjsman-1000 wrote:
| Outside of Hacker News or niche companies still supporting IE,
| progressive enhancement is completely dead.
|
| Even for my own projects, I don't care anymore; there's a warning
| to turn it on with a <noscript> tag, and the whole page is
| otherwise hidden.
|
| HN had the eulogy (with some kicking and screaming that it was
| premature) back in 2013.
| https://news.ycombinator.com/item?id=6316516
| jaredcwhite wrote:
| "Progressive enhancement is completely dead" is in fact
| something I only expect to see posted on Hacker News. _rolls
| eyes_
|
| Meanwhile, out on the open web, people build progressively
| enhanced solutions all the time.
| gjsman-1000 wrote:
| Sure, and I do too, when it makes sense and is simple enough.
| A marketing page with one form? Why not?
|
| But a CRUD-heavy app with forms and modals and many moving
| parts? Forget it. It's about as relevant as people using IE.
|
| 2 years ago, again on HN, someone asked if progressive
| enhancement "lost the war." In reality, it never showed up
| for battle on its own merits.
|
| https://news.ycombinator.com/item?id=37779408
| hinkley wrote:
| Not to mention anything that's been "dead" for a dozen years
| tends to be resurrected either by people who know or by
| people reinventing a wheel. We all live on a pendulum.
| rikroots wrote:
| Two places in particular where people need to think about
| progressive enhancement:
|
| + Low-powered or -specified devices don't like Javascript-
| heavy elements. For example, canvas elements - do people with
| steam-powered mobile phones really need to see that JS-heavy
| canvas animation? Wouldn't a static image do just as well for
| them? Same goes for intensely animated SVG scenes.
|
| + Apple News. JS is not a thing in AN. If you need to press a
| web article so it can be distributed via AN, be prepared to
| rip every shred of JS out of it - something that's a lot
| easier to do if your article has already been built with
| progressive enhancement in mind.
| simonw wrote:
| It's only dead among people who don't care about productively
| building fast loading, reliable websites.
|
| (Which apparently is most web developers these days. Sigh.)
| bshacklett wrote:
| Major props to the author for actually caring about this. JS
| seems like an assumption more than ever before. It's great to see
| that people understand that some of us don't want it.
|
| Very loosely related: why do so many websites use require
| Javascript to handle links? I'm so tired of trying to figure out
| how to open a given link in a new tab. :-(
| bombela wrote:
| and scrolling. and history.
|
| I am finding myself afraid of clicking any link, anchor, or
| button in the fear of losing the current position, word
| wrapping or the current form inputs.
|
| It's like I am being pavlov trained to be afraid of interacting
| with my computer.
| cosmic_cheese wrote:
| Mystery meat interaction is one of the worst parts of the
| modern web, and all too often it's found in places where
| there is little to no user benefit to be had for the tradeoff
| and a plain old HTML link or button would've sufficed. I wish
| more devs would give thought to this kind of thing.
| thefilmore wrote:
| You can use the hidden attribute.
|
| https://developer.mozilla.org/en-US/docs/Web/HTML/Global_att...
| jaredcwhite wrote:
| Another solution: wrap the feature in a custom element, use CSS
| :not(:defined) to hide the element, then in JS register the
| custom element so it's defined and the CSS no longer applies.
| winterbloom wrote:
| I don't get it, we should simply not support users that don't
| have JavaScript enabled. The vast majority of users/consumers
| will have it enabled
| gjsman-1000 wrote:
| Correct. As an HN commentator put it in 2023:
|
| "[Progressive enhancement] was just an idea by a few niche
| people who wanted to disable 1/3 to 2/3 of their browser's
| technology then demand that web-site operators/builders spend a
| lot of time and money on implementing for that sub-1%
| population. They didn't, and these people had no real
| leverage."
|
| https://news.ycombinator.com/item?id=37779408
| quotemstr wrote:
| For some people, it's about not breaking the web platform in
| ways that require JavaScript. For example, without JavaScript,
| links have predictable behavior. With it, you have link shaped
| buttons that can do anything and that often break when you try
| to do things the author didn't anticipate, like opening a link
| in a new tab.
| theandrewbailey wrote:
| We should simply not support developers that re-implement
| links, buttons, and text boxes entirely in Javascript. Such
| false elements lack inbuilt functionality (particularly with
| regards to accessibility), and are slower.
| perching_aix wrote:
| On the contrary, I don't get why (certain) sites - and people -
| absolutely insist on serving even the most basic things via
| copious amounts of JavaScript, and other adjacent technologies.
| Most website content is basic multimedia, text, images and
| video, and most use of JavaScript is either frivolous or is
| supporting user-hostile designs, such as infinite scroll.
|
| Reminds me to the WordPress / PHP scourge of the 2010s. "You
| don't understand, we _have to_ dynamically serve our site using
| PHP, and have an extensive CMS that we can barely use ourselves
| so we 'll will still constantly reach out to you about." And
| then the site is barely more than a brochure or a blog.
| userbinator wrote:
| Requiring JS (and _especially_ if you trendchase the latest
| "modern" crap) is essentially advocating for keeping Big
| Browser's monopoly and effective control intact.
| theandrewbailey wrote:
| > We'll simply create a single class, d-js-required to indicate
| that JavaScript needs to be enabled for us to display this
| element.
|
| You can run some JS to prove you're running JS. Can't you write
| in your site's CSS: .d-js-required {
| display: none; }
|
| and (in JS) remove that class on each element it's on?
| c0balt wrote:
| Wouldn't this lead to a delay of time to first content render?
| If you rely on display then a layout shift would also be an
| issue for JS-capable clients.
| charrondev wrote:
| Write that tiny of bit of JS inline in the head and put the
| class/attribute on the html element.
| 0xdade wrote:
| This is absolutely an option! It gets a little tricky to avoid
| shifting content around, since it's pretty typical to load
| styles in the head but load javascript either at the end of the
| DOM or with the defer tag, so the javascript would likely be
| running after the user has already seen the layout, and layout
| shifts could be clunky.
| grishka wrote:
| I did it the other way around. I put this at the start of <body>:
| <script>document.body.classList.add("hasJS");</script>
|
| And the corresponding CSS: .js{display: none;}
| .hasJS .js{display: block;}
| MrJohz wrote:
| This has the advantage compared to OP's solution that it will
| also work if JS doesn't load correctly (as opposed to if it is
| blocked/deliberately not loaded). You can add this line to the
| end of the main JS file that you're including on your page, and
| it will ensure that the JS "switch" will only get triggered if
| that file could be downloaded and parsed.
| duncans wrote:
| Reminds me of the Modernizr JS library from 2009 which would
| replace <html class="no-js"> with "js" for this purpose.
| https://github.com/Modernizr/Modernizr/blob/v1.1/modernizr.j...
| userbinator wrote:
| _And if not, you can just copy the link down below to share this
| page!_
|
| Or you could just copy it from the address bar?
| simonw wrote:
| I'm beginning to suspect that a substantial portion of users
| don't habitually do that, for two reasons:
|
| 1. They don't understand URLs. That's not too surprising to be
| honest, URLs are pretty complex things.
|
| 2. They've been burned enough times by crap SPAs that they
| don't instantly assume something they are looking at has a
| dependable URL they can copy and share.
|
| Thanks to 2 I've recently started rethinking a bunch of my own
| projects - I think I need to add explicit "share" buttons that
| copy URLs to people's clipboards for them.
| 0xdade wrote:
| The share button I have uses the navigator.share API if it's
| available, or tries to fall back to navigator.clipboard.
| Unfortunately I think I didn't do adequate testing to make
| sure the clipboard feature works in whatever edge cases you
| might have the clipboard API but not the Share API, so I'm
| pretty sure _that_ is broken.
|
| I really just put the URL at the end of the page with a
| `user-select: all;` to make it easy to copy _after_ you've
| read the content. It's also rendered server-side so even if I
| used utm or some other tracking things, the query params
| would automatically not be included in the server-rendered
| share link, just the permalink to the post.
|
| But to the original authors point, I also do find myself
| often just copying from the address bar and then manually
| deleting a bunch of the garbage at the end of URLs. Maybe
| that's why I thought it nice for a simple "copy this link"
| when JS is disabled.
| giantrobot wrote:
| Reasons to have JavaScript fallbacks in your pages:
|
| - Microbrowsers exist. They're the things that generate previews
| in messaging apps and social media.
|
| - Ad blockers. Because the advertising on the Web has become a
| complete dumpster fire even the FBI recommends ad blockers. They
| can break stupid JavaScript functionality. Partially loaded
| JavaScript can cause additional load on the back end with retries
| or missing completion conditions.
|
| - Crappy cellular. Cellular data remains unreliable and its
| reliability is not evenly distributed. A user can go from a great
| signal to shitty back to great through no fault of their own. You
| can't be guaranteed all your shitty JavaScript will even load.
|
| - Spiders. Spiders have varying amounts of support for
| JavaScript, not everything is some variation on Chrome.
___________________________________________________________________
(page generated 2025-04-06 23:01 UTC)