Jul 30 2021
Citizen skin (which Alistair works on) does something quite interesting which might be worth considering - the image expands on hover which I think is a much better indication that the image can be interacted with:
Wikiwand also has an alternative solution by overlaying a magnifying icon on hover. However, both solution suffer from the issue that there is lower discoverability because it the image has to be hovered first. I think the core research question would be how does the magnifying icon change the click rate of the thumbnail, and how might we convey the interaction more clearly.
Might not be completely related but would it be possible to have an easy way for skin authors to get the content of the ToC and disable the default? In that way skin authors don't have to rely on CSS hacks or JS tricks to duplicate or move the ToC outside of the article.
I'm unsure about removing the background since it can cause issues with transparent images. There can be a default solid background which is the same color as the lazyloading placeholder color (base80/90?), so that the UI is unified with other UI components like the search suggestions, Minerva, and the mobile apps.
Jul 28 2021
Cherry-picked patch to latest stable and LTS
Jun 27 2021
Jun 15 2021
Jun 10 2021
Jun 4 2021
Jun 2 2021
May 30 2021
May 27 2021
May 26 2021
For some reason, after clicking preview in VE, it loads core styles (maybe skinning interface but I'm not sure) inline in the head element. Because it is loaded in a <style/>element in <head/>, it overrides any styles with the same specificity and breaks any skins that styles any content element.
May 21 2021
Yeah I think this should be a core hook, not a skin hook.
Yes it should be a core hook that is accessible by both skins and extensions.
May 20 2021
Would there be a possibility to provide a hook in core to override the site tagline so that the same feature can be used by other extensions and skins?
Currently there is no clean way to reproduce the said feature from MF without hardcoding it in the skin like Minerva does.
May 19 2021
May 7 2021
Apr 26 2021
Apr 22 2021
Thanks for everyone's help! Cherry-picked the patch for REL1_35.
Mar 27 2021
Speaking from experience as a dark skin author, just using @media (prefers-color-scheme: dark) only allow users to manually toggle dark mode though the browser/OS settings. The more useful way is to detect the client's media query flag and adjust the site though JS.
Mar 25 2021
Submitted a patch based on the NoCaptchaReCaptcha implementation. The config flags are also refactored to not use global variables.
Mar 23 2021
Mar 22 2021
I found it weird that mediawiki.cookie does not honor $wgCookieSecure, as $wgCookieSecure should not be set to true in a mix HTTP/HTTPS configuration anyways. Besides since the introduction of $wgForceHTTPS, mediawiki.cookie should be able to set secure cookies.
Mar 20 2021
Mar 17 2021
Mar 16 2021
The extension was originally set up in Wikimedia Gerrit, but the Gerrit repo has ceased development and move to GitHub (T277589).
Mar 11 2021
Patch merged into core
Mar 9 2021
Reopen due to still being an issue on 1.35
Mar 7 2021
Cherry-picked the core fix to 1.35 instead:
Mar 4 2021
Feb 20 2021
@Ammarpad Would the patch be backported to 1.35 in the form of either core or the extension?
1.35 is the LTS version and the extension is widely used on many wikis.
Jan 30 2021
Why? Can't we just make it an absolutely-positioned thing on all skins, at the bottom of the page, like most of the Internet? Also keeping the banner at the top of the page on desktop skins is not optimal, as it obscures vital UI components such as the search box or the site's name on skins like Timeless and Vector.
Oct 15 2020
Oct 13 2020
Aug 20 2020
Patch merged to 1.35 in T250851
Aug 12 2020
Aug 11 2020
@Legoktm I cherry-picked the patches required and merged them into a single one.
I am not sure if it is the right way to do it so please let me know if any changes needed to be made.
Relevant discussion and cherry-picked patch are in T250851,
Aug 9 2020
Can this be backported to 1.35? T233677 removed the ability to stop mediawiki.searchSuggest from being loaded and there is no alternatives to do so in 1.35.
Aug 6 2020
Jun 30 2020
Jun 19 2020
Jun 18 2020
Jun 16 2020
Jun 12 2020
@abi_ Thanks for adding the project!
I added the project information to Translatewiki, and commit access is granted too.
Please let me know if there's anything I can do to help.
Apr 13 2020
@Isarra the portal implementation could theoretically replace the current jQuery autocomplete in the core as a drop-in replacement. One of the major benefit of the new search suggestions (OOUI, Portal, etc.) is that it has rich suggestions with images and descriptions. With both PageImage and TextExtract as default extensions, it might be a decent starting point to replace the jQuery solution.
Feb 15 2020
Seems to be a misconfiguration issue on my end.
The issue was resolved after a reinstall of Parsoid, now everything works fine.
Feb 14 2020
The Parsoid output is as follow:
madmin@scw-u18lts:/home/www-data/public_html$ grep -C5 parsoid LocalSettings.php # 'redisServer' => '127.0.0.1:6379',
Feb 7 2020
I have to learn about those performance measurements. Could you give some links?
As @Volker_E mentioned, WMF decided to not provide web fonts for large scale projects for now as the trade off on performance and UX is not worth the investment. When a website uses a webfont, the client needs to make a HTTP request then download the font, it is an additional delay on the critical rendering path. Take Roboto as an example, the WOFF2 (most compressed format) for Roboto Regular (400) with basic latin is 16KB. Plus the latency introduced in the HTTP request, it could easily be 2-3 seconds load delay on a slow 3G network. Page load time can be solved with font-display:swap or lazyload, but that will introduce other UX issues such as font popping when web font is loaded. For a site like Wikipedia that serves a lot of people with slower and capped connections, the negative performance impact is significant.
Feb 6 2020
@Volker_E if web fonts are out of the picture for now, I suggest that we should focus on updating the hierarchy on the current Vector skin first to match with the style guide to improve readability. However, it might introduce a lot of problems with existing templates or layout hack uses on WMF sites.
@AronManning The typography that the style guide suggested is not adopted at all by Vector, I suggest that instead of focusing on font choices first, we need to focus on adopting the hierarchy (size, styles, weight, etc.) defined in the style guide as it is more suited for modern day screens. Adopting the hierarchy first will improve the readability issues across different platforms, and also builds a foundation for studying other font choices.
Just curious, is there a particular reason to deviate from the fonts used in the style guide? It would make more sense to adopt the Wikimedia styles that is also used on Minerva and native apps instead of picking other fonts for UI standardizations and many reasons.
Feb 5 2020
@matmarex thanks for looking into it and the praise! Not sure if the following information helps but we don't have RESTBase on the wiki.
Also another weird behavior is that templates placed inside the <tabber> tags (from Extension:Tabber) seems to be not affected.
Feb 4 2020
@Ryasmeen instead of inserting a template, it was simply visual editing a page that already has a template in there.
@Ryasmeen it is on a non-WMF wiki, here's an example page containing templates using TemplateStyles: https://scwdev.czen.me/Defender
Since it is a dev site, registration is locked and edits are permission only. However, I hope that the following screenshot would help:
Jan 30 2020
@Ryasmeen templates with TemplateStyles transclusion means using a template that uses TemplateStyles, aka having <templatestyles src="Template:Foo/style.css">.