6 ms·

The article mentions the functionality that the Javascript is used for: Expanding and collapsing sections, adding the media viewer on thumbnails shown in the pa

by janpio 3y ago

The article mentions the functionality that the Javascript is used for: Expanding and collapsing sections, adding the media viewer on thumbnails shown in the page. Both seems like reasonable use cases for interactivity that is (better) achieved using Javascript.

exabrial 3y ago
None of those things actually enhance the website. The only time people "use" them is by accident.
- muspimerol 3y ago
  Hard disagree, I use the hover-to-preview-article feature all the time. Sometimes I just want to peek at a page to see what it is instead of opening it.
- janpio 3y ago
  I don't think that is true. On Wikipedia's mobile view, collapsed sections are super useful (as the table of contents is not visible via the sidebar) and media viewer makes it possible to view details of an image/thumbnail without navigating away from the page.
  - iggldiggl 3y ago
    > collapsed sections are super useful (as the table of contents is not visible via the sidebar) Yes and no. On the hand some sort of table of contents is useful (but note that you could also just display it inline, the way it used to be done in previous desktop skins), on the other hand those collapsed sections break scroll position restoring when reloading the page after somebody (your browser or directly the OS) kicked it out of your RAM. This is because your (absolute) scroll position depends on which sections where expanded and which collapsed, and that information gets lost when the page reloads – all sections end up collapsed again and the scroll position your browser remembered no longer makes sense. (There is some sort of feature that tries to restore the section state, but a) it only works within the current session, but not if the OS low memory killer kicked the whole browser out of your phone's RAM and b) even when it does work, it runs too late in relation to the browser attempting to restore the previous scroll position.) So now that the mobile Wikipedia's full JavaScript no longer runs on e.g. older Firefoxes (e.g. one of the last pre-Webextension versions), the lack of a TOC is somewhat annoying, but other than that, somewhat ironically my browsing experience has become much, much better now that my browser can finally reliably restore my previous scroll position because now all sections are permanently expanded.
- shepherdjerred 3y ago
  Is Wikipedia really a significant offender here?
rickstanley 3y ago
CSS has come a long way, I would expect that these things would be ease to achieve with just CSS and HTML, for instance: media viewer -> dialog (I remember this being a HTML thing), collapsing sections -> details/summary (?) But I guess it's not there yet.
- ajkjk 3y ago
  There is always going to be a user interaction that is sufficiently complex as to require JS. Arbitrarily limiting to just CSS severely limits what you can do.
  - uoaei 3y ago
    Fairly certain that's literally the point of simplifying interfaces. Do what you need with what you have. Don't try to shove a racehorse into a VW Beetle.
    - blowski 3y ago
      As the old saying goes “simple as possible but no simpler”. There are likely some uses of JavaScript that make the UI simpler.
  - onion2k 3y ago
    It's not arbitrary though. It's a choice to save bandwidth shipping unnecessary javascript rather than making it easier to develop the website. At the scale of Wikipedia that isn't unreasonable.
    - ajkjk 3y ago
      It's not unnecessary if the feature is something you want? There's this pattern on HN: people value a feature as having 0 utility and then become annoyed that someone has paid time/performance/money for them. Well duh, if you discount the value of something to 0, it will always be a bad idea. But you're never going to understand why people are paying for it if you write off their values. At my last job there were countless pieces of UX to make things smoother, more responsive, better controlled by keyboard or voice reader, etc.. that required JS. It was not possible to make our site as good as possible with CSS, and it certainly wasn't worth the tradeoffs of loading a big faster (not that it couldn't have had it's loading time improved--just, cutting JS was a nonstarter).
Mystery-Machine 3y ago
"Better interactivity" is subjective. You could argue that faster is better. Expanding and collapsing sections can be achieved faster and with zero JavaScript (which also makes it work on browsers with disabled JS) with a hidden input[type="checkbox"]. Aa for the media viewer, it could be a great exercise to try and make it in a similar manner with input[type="checkbox"] for opening/closing media viewer and input[type="radio"] for switching to prev/next image. This one probably requires browsers to support the `:has` CSS selector. Also, if you want to further speed up your site, just like you said, the fastest way to speed up the site is to delete JavaScript, get rid of jQuery.
- 6510 3y ago
  https://developer.mozilla.org/en-US/docs/Web/HTML/Element/details https://developer.mozilla.org/en-US/docs/Web/HTML/Element/de... <details> is completely supported.
  - toast0 3y ago
    Oooh, that's lovely. I have a page with ~50 lines of javascript to do this, and it looks like I can make it zero lines of javascript instead.
    - 6510 3y ago
      One could use js to push the state into the url.
      - toast0 3y ago
        It's just opening and closing detail panes (personal recipie site), there's no reason to put the open/closed state in the url. But if I can do it with all html, that's better than a function to add / remove a css class and document.onclick = a function to find which recipie you clicked on and adjust the css class.
        6510 3y ago
hutzlibu 3y ago
"Both seems like reasonable use cases for interactivity that is (better) achieved using Javascript." Only if you want fancy animations. I sometimes do, but I think wikipedia can do without(and they don't) and use <details> https://developer.mozilla.org/en-US/docs/Web/HTML/Element/details https://developer.mozilla.org/en-US/docs/Web/HTML/Element/de... And media viewer I would naturally do with js as well, but I am certain you can also do it easily with CSS. (Many ways come to mind)
- extra88 3y ago
  I love details/summary and want them to succeed but current implementations have some issues. A big one is VoiceOver for iOS currently what they are or their state, something that's very straightforward and reliable when making a custom disclosure widget. Good article about some issues (with a link at the top to his previous article about them). https://www.scottohara.me/blog/2022/09/12/details-summary.html https://www.scottohara.me/blog/2022/09/12/details-summary.ht...
- Someone1234 3y ago
  Not supported on IE11[0] which Wikipedia supports[1] [0] https://caniuse.com/?search=details https://caniuse.com/?search=details [1] https://www.mediawiki.org/wiki/Compatibility#Browser_support_matrix https://www.mediawiki.org/wiki/Compatibility#Browser_support...
  - hutzlibu 3y ago
    That's a good, or rather bad point. I mean you could probably make a legacy version only, but itnis probably not worth the effort.
gwern 3y ago
The sections could be collapsed by CSS by default without render-blocking JS, and adding a media viewer to random media bits and pieces can definitely wait until later. So time-to-interactivity is unnecessarily hampered here.
- robertoandred 3y ago
  Except collapsing them by default makes them inaccessible to people/crawlers that aren't using JS.
  - gwern 3y ago
    Who is using mobile without JS? They are going to have many problems beyond collapses... Likewise, crawlers these days generally run with JS enabled in a browser/VM because so much breaks completely if JS is disabled. This is not a real problem, sorry, NoScript fans. (Anyway, if you are using CSS + the relevant semantic HTML elements, it can be more accessible, not less, because you are expressing priority and emphasis, so they can skip over collapsed stuff. Although I have my doubts whether screenreaders etc make any good use of it, given that they apparently still do not do basic things like stripping soft hyphens.)
l5870uoo9y 3y ago
And not to forget preview popups when hovering a link (thought it would be even if they implemented preview modals like https://gwern.net https://gwern.net).

by janpio 3y ago

exabrial 3y ago

None of those things actually enhance the website. The only time people "use" them is by accident.

muspimerol 3y ago
Hard disagree, I use the hover-to-preview-article feature all the time. Sometimes I just want to peek at a page to see what it is instead of opening it.
janpio 3y ago
I don't think that is true. On Wikipedia's mobile view, collapsed sections are super useful (as the table of contents is not visible via the sidebar) and media viewer makes it possible to view details of an image/thumbnail without navigating away from the page.
- iggldiggl 3y ago
  > collapsed sections are super useful (as the table of contents is not visible via the sidebar) Yes and no. On the hand some sort of table of contents is useful (but note that you could also just display it inline, the way it used to be done in previous desktop skins), on the other hand those collapsed sections break scroll position restoring when reloading the page after somebody (your browser or directly the OS) kicked it out of your RAM. This is because your (absolute) scroll position depends on which sections where expanded and which collapsed, and that information gets lost when the page reloads – all sections end up collapsed again and the scroll position your browser remembered no longer makes sense. (There is some sort of feature that tries to restore the section state, but a) it only works within the current session, but not if the OS low memory killer kicked the whole browser out of your phone's RAM and b) even when it does work, it runs too late in relation to the browser attempting to restore the previous scroll position.) So now that the mobile Wikipedia's full JavaScript no longer runs on e.g. older Firefoxes (e.g. one of the last pre-Webextension versions), the lack of a TOC is somewhat annoying, but other than that, somewhat ironically my browsing experience has become much, much better now that my browser can finally reliably restore my previous scroll position because now all sections are permanently expanded.
shepherdjerred 3y ago
Is Wikipedia really a significant offender here?

rickstanley 3y ago

CSS has come a long way, I would expect that these things would be ease to achieve with just CSS and HTML, for instance: media viewer -> dialog (I remember this being a HTML thing), collapsing sections -> details/summary (?) But I guess it's not there yet.

ajkjk 3y ago
There is always going to be a user interaction that is sufficiently complex as to require JS. Arbitrarily limiting to just CSS severely limits what you can do.
- uoaei 3y ago
  Fairly certain that's literally the point of simplifying interfaces. Do what you need with what you have. Don't try to shove a racehorse into a VW Beetle.
  - blowski 3y ago
    As the old saying goes “simple as possible but no simpler”. There are likely some uses of JavaScript that make the UI simpler.
- onion2k 3y ago
  It's not arbitrary though. It's a choice to save bandwidth shipping unnecessary javascript rather than making it easier to develop the website. At the scale of Wikipedia that isn't unreasonable.
  - ajkjk 3y ago
    It's not unnecessary if the feature is something you want? There's this pattern on HN: people value a feature as having 0 utility and then become annoyed that someone has paid time/performance/money for them. Well duh, if you discount the value of something to 0, it will always be a bad idea. But you're never going to understand why people are paying for it if you write off their values. At my last job there were countless pieces of UX to make things smoother, more responsive, better controlled by keyboard or voice reader, etc.. that required JS. It was not possible to make our site as good as possible with CSS, and it certainly wasn't worth the tradeoffs of loading a big faster (not that it couldn't have had it's loading time improved--just, cutting JS was a nonstarter).

Mystery-Machine 3y ago

"Better interactivity" is subjective. You could argue that faster is better. Expanding and collapsing sections can be achieved faster and with zero JavaScript (which also makes it work on browsers with disabled JS) with a hidden input[type="checkbox"]. Aa for the media viewer, it could be a great exercise to try and make it in a similar manner with input[type="checkbox"] for opening/closing media viewer and input[type="radio"] for switching to prev/next image. This one probably requires browsers to support the `:has` CSS selector. Also, if you want to further speed up your site, just like you said, the fastest way to speed up the site is to delete JavaScript, get rid of jQuery.

6510 3y ago
https://developer.mozilla.org/en-US/docs/Web/HTML/Element/details https://developer.mozilla.org/en-US/docs/Web/HTML/Element/de... <details> is completely supported.
- toast0 3y ago
  Oooh, that's lovely. I have a page with ~50 lines of javascript to do this, and it looks like I can make it zero lines of javascript instead.
  - 6510 3y ago
    One could use js to push the state into the url.
    - toast0 3y ago
      It's just opening and closing detail panes (personal recipie site), there's no reason to put the open/closed state in the url. But if I can do it with all html, that's better than a function to add / remove a css class and document.onclick = a function to find which recipie you clicked on and adjust the css class.
      - 6510 3y ago

hutzlibu 3y ago

"Both seems like reasonable use cases for interactivity that is (better) achieved using Javascript." Only if you want fancy animations. I sometimes do, but I think wikipedia can do without(and they don't) and use <details> https://developer.mozilla.org/en-US/docs/Web/HTML/Element/details https://developer.mozilla.org/en-US/docs/Web/HTML/Element/de... And media viewer I would naturally do with js as well, but I am certain you can also do it easily with CSS. (Many ways come to mind)

extra88 3y ago
I love details/summary and want them to succeed but current implementations have some issues. A big one is VoiceOver for iOS currently what they are or their state, something that's very straightforward and reliable when making a custom disclosure widget. Good article about some issues (with a link at the top to his previous article about them). https://www.scottohara.me/blog/2022/09/12/details-summary.html https://www.scottohara.me/blog/2022/09/12/details-summary.ht...
Someone1234 3y ago
Not supported on IE11[0] which Wikipedia supports[1] [0] https://caniuse.com/?search=details https://caniuse.com/?search=details [1] https://www.mediawiki.org/wiki/Compatibility#Browser_support_matrix https://www.mediawiki.org/wiki/Compatibility#Browser_support...
- hutzlibu 3y ago
  That's a good, or rather bad point. I mean you could probably make a legacy version only, but itnis probably not worth the effort.

gwern 3y ago

The sections could be collapsed by CSS by default without render-blocking JS, and adding a media viewer to random media bits and pieces can definitely wait until later. So time-to-interactivity is unnecessarily hampered here.

robertoandred 3y ago
Except collapsing them by default makes them inaccessible to people/crawlers that aren't using JS.
- gwern 3y ago
  Who is using mobile without JS? They are going to have many problems beyond collapses... Likewise, crawlers these days generally run with JS enabled in a browser/VM because so much breaks completely if JS is disabled. This is not a real problem, sorry, NoScript fans. (Anyway, if you are using CSS + the relevant semantic HTML elements, it can be more accessible, not less, because you are expressing priority and emphasis, so they can skip over collapsed stuff. Although I have my doubts whether screenreaders etc make any good use of it, given that they apparently still do not do basic things like stripping soft hyphens.)

l5870uoo9y 3y ago

And not to forget preview popups when hovering a link (thought it would be even if they implemented preview modals like https://gwern.net https://gwern.net).