Staff software engineer at WMF
User Details
- User Since
- Nov 6 2014, 11:05 PM (398 w, 2 d)
- Availability
- Available
- IRC Nick
- jdlrobson
- LDAP User
- Unknown
- MediaWiki User
- Jdlrobson [ Global Accounts ]
Yesterday
This was caused by https://gerrit.wikimedia.org/r/c/mediawiki/skins/Vector/+/803976 which switched the h3 to a p in legacy Vector. ULS has some JavaScript that overrides this.
Lots of small patches and more work to be done. Making this our top priority next week.
Fri, Jun 24
Moving back to backlog for now due to other priorities.
I don't think so.
@JMcLeod_WMF this is an issue in the parser so I believe the content transform team are best to fix this. If not please let me know which team we should talk to.
We will take a look next week
https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(technical)&oldid=1094833127
In the meantime editors can workaround this by adding a rule to their user CSS (https://developer.mozilla.org/en-US/docs/Web/CSS/text-size-adjust)
Hoping to fix this for 1.39 release but can't promise that. I've updated documentation to be more clear on the state of this flag: https://www.mediawiki.org/wiki/Skin:Vector/2022#Configuration_parameters
Looking to merge this sometime next week.
Cc @bwang @Jdrewniak
T311170 should be fixed now so you can add the magic class to fix this one 🤞
Thu, Jun 23
Merged
Nice! Thanks for building this! It's cool to have this feature usable without having to install MobileFrontend!
It's also interesting there is an option that you can edit the JSON locally on MediaWiki:default-manifest.json although it would be nice to also define that in LocalSettings.php
This still does not explain why the title is there.
In practice, the content of title is shown as a tooltip on the desktop, and as text at the top of a menu that appears after a long-tap on phones and tablets.
Hey @Volker_E many of our articles contain tables, so if we're adding this to Codex I'm curious to hear about how we plan to keep design consistency between tables in articles and tables in Codex-based UIs and whether web team should collaborate with DST team to update those in parallel (I assume we don't want to load two sets of styles - one for Codex and one that's not Codex). We have a shared stylesheet for tables across all skins (except Minerva) that we could expand on: https://github.com/wikimedia/mediawiki/blob/master/resources/src/mediawiki.skinning/content.tables.less. Might also be a good time to bring Minerva in line and address the community feedback in T287997 that said they liked the table header hover effect.
We pushed a change this morning to tweak the viewport based on feedback. We removed the zoom and relaxed the 1200px width to 1000px
I409194accaf5592772fd70ee5b0005ca4199e282
I've documented the learnings in more detail here: https://phabricator.wikimedia.org/phame/post/view/286/should_vector_be_responsive/#4431
A learning point since I wrote this blog post.
I've had confirmation from 2 people who reported the issue that the issue is fixed.
@ppelberg we think deploying this is unblocked. I just wanted to confirm that you are okay with the plan in the task description before I execute it next week?
@bwang The collapsed TOC does yes, however since banners/site notices are sometimes a JS only feature and are rare ie. not shown on every page view all the time using JS could be an acceptable solution here that's worth considered.
Patch got merged 8 minutes ago, so will hopefully be on the beta cluster shortly.
Do you have $wgVectorResponsive = true in your LocalSettings.php? If so, this is not production ready yet (see T106463).
Banners are also JavaScript so we could do a banner height calculation to change the top calculation on the menu when a banner is present.
This seems to be intentionally added by @dmaza here: https://en.wikipedia.beta.wmflabs.org/w/index.php?title=MediaWiki%3ACommon.css&type=revision&diff=551070&oldid=548211
This feature is not deployed in production anywhere yet so this is not an unbreak now. I can only replicate on beta cluster but not with safe mode ( https://en.wikipedia.beta.wmflabs.org/wiki/Albert_Einstein?safemode=1). Will look into the gadget shortly.
Thank you!
@Bluehill395 I am also seeing that and that doesn't look expected thanks for pointing that out.
But, that also does not seem related to this particular issue. I'll raise this in T308689 as this feature is new and being actively developed.
We just synced a change that should improve this situation. Note you may need to apply ?action=purge to the URL if you are viewing anonymously.
The above patch gives the following result on iPad which is how it should be (with table of contents):
Will look to backport that tomorrow.