Thank you. The company logos connecting to the influencers is a representation of the "bridge" that describes us. We've never heard the whitespace problem before but thank you for pointing it out!
Oh wow, I use WinMerge and they almost look identical on the screenshots. Honestly googled if they are not the same, or open source version of it - but does not seem so.
One reasons why some prefer multi tenancy via schemas instead of a tent ant column: Reading a column with the wrong tenant id happens easily, just forget the where in a query. Across schemas, this is much harder to get wrong as a schema has to be explicitly named in a query.
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.
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 (?)
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.
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.
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).
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.
Surely at the scale of Wikipedia that wouldn’t be a factor ?
considering the dominance of few browsers (chrome , safari on iOS) will most users notice any difference? The first one (with that UA) to the site with a new build will have they cache key warmed up ?
Mediawiki itself is built to support 10-year old phones (which is why the Moto G makes an appearance in the post - it's the official low-end Android benchmark) and older desktop operating systems. https://www.mediawiki.org/wiki/Compatibility#Browsers
Makes sense since the Moto G is also what Lighthouse and a lot of tools driven by it use. So PageSpeed Insights (pagespeed.web.dev), the Lighthouse developer in Chrome tab and even external services like https://totalwebtool.com all generally evaluate mobile performance using it to simulate a slower experience.
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.
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.)
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.
"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.
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.
Probably more useful for a nested menu. The default thing almost works out of the box. You need some css to set a proper cursor and style the clickable text properly.
I assume the author of the blog post just wanted to optimize the current situation, not completely change how these features work (which would most probably be a much more elaborate change).
Same for dropping jQuery - that will probably be a few weeks or months of work in a codebase the size of Wikipedia/Mediawiki.
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.
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.
> 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.
I found that in general, it was OK for pretty obvious things but sometimes it missed stuff such as: running a LIKE with wild card at the start, ie: "LIKE '%Luke%'". Running that wildcard in the start tends to make the optimizer do a full scan.
Otherwise, it did okay. Just ensure you give ChatGPT the schema as well for its best suggestion.
An experienced product person could maybe have helped with that *scnr