Code common to all skins, and not specific to Vector, was moved to MediaWiki:Common.css. If you want to propose a change to the sitewide CSS that is not specific to a particular skin, please do so at
MediaWiki talk:Common.css rather than here.
All the stylesheets are documented at the
catalogue of CSS classes. Please add any new classes into that catalogue.
@
Edokter: With
Special:Diff/642208825, a bunch of stuff is getting picked up that shouldn't be. For example, there's a huge gap between the page/talk/read/edit tabs and the page title h1 now, because .mw-bodyh1{margin-top:1em;} is now matching it. These rules need to be made more specific.
Jackmcbarn (
talk) 21:30, 12 January 2015 (UTC)reply
Thanks for spotting that. Now fixed. -- [[
User:Edokter]] {{
talk}} 22:06, 12 January 2015 (UTC)reply
Proposal for .topicon
After having seen (previously) the French Wikipedia utilize a .topicon system that allows for topicons to be dynamically placed using Javascript and CSS, I'd like to propose that we implement something similar on the English-language Wikipedia. I'm not entirely sure where to go with this since it would affect all topicons, including (but not limited to)
{{Good article}},
{{Featured article}}, and
{{pp}}. For me, the problem lies in aesthetics and organization. Many times, an article with multiple top icons may look disjoined. (See, for instance,
Atomic bombings of Hiroshima and Nagasaki. Note the gap in the middle where the audio icon is, visible in an article like
California Gold Rush. Other spoken articles, such as
Project Gutenberg, showcase the speaker icon with considerable white space to the right where the good article or featured article icon usually rests.
I found a very simple code which I've implemented on my own custom Vector.js and Vector.css pages which rests the icons neatly directly to the right of the first heading. The Javascript code searches for the .topicon class and moves the code to either above or below the first heading (depending on importance of order) and the CSS steps in to make the icon float to the right. The result is a system of top icons that is flawlessly positioned in the top-right corner and adjusts automatically to the display of multiple top icons. If someone can help me figure out how to even begin discussions or proposals in implementing this, I would greatly appreciate your help!
You're basically re-inventing the wheel. We now have
Page status indicators, which does exactly what you want. I am currently taking inventory of all topicons in order to convert them. -- [[
User:Edokter]] {{
talk}} 12:34, 18 March 2015 (UTC)reply
Hi
Edokter, thank you for your response! If there's any way I can help, please feel free to let me know. Cheers,
The Obento Musubi (
talk·contribs) 19:26, 18 March 2015 (UTC)reply
This will make the size of the search field a lot smaller and thus more optimal at smaller width screens, while at the same time making it larger if there is the space available for it. It falls back safely to the default width if viewport units are not yet available on your platform. I think it could be a welcome addition. —
TheDJ (
talk •
contribs) 12:45, 1 July 2015 (UTC)reply
Should maybe phab this one for upstream? I agree that increasing the size of the bar would be nice in the context of desktop screens. --
Izno (
talk) 14:11, 1 July 2015 (UTC)reply
Interesting. Lose the animation though; the elasticity is jarring and could bump the tabs temporarely into the content area (when resizing to just the right spot). -- [[
User:Edokter]] {{
talk}} 14:15, 1 July 2015 (UTC)reply
OK, I was looking in the W3C Recommendations, not the Candidate Recommendations. Current version is
only three weeks old. --
Redrose64 (
talk) 16:54, 1 July 2015 (UTC)reply
Yes but not in a W3C Recommendation, so it's not set in stone. The link you gave at 15:30, 1 July 2015 goes to an Editor's Draft which can change on a near-daily basis. That July 2005 doc is not a CR but a Working Draft, a little more stable than an Editor's Draft, but still not certain to make it
through the stages of Candidate Recommendation → Proposed Recommendation → W3C Recommendation. As an example, there were some features of HTML5 (such as the
Interactive elements) that were included in the Candidate Recommendation of 4 February 2014 but omitted from that of 29 April 2014 (they weren't in the W3C Recommendation of 28 October 2014 either). We really should not rely on anything that hasn't made it all the way through to W3C Recommendation, since not only might it not ultimately be included, browser vendors are under no obligation to provide it. --
Redrose64 (
talk) 17:40, 1 July 2015 (UTC)reply
My point is that the definition of the unit in question has been included in the documents and moreover stable for 10 years, regardless of the status of the documents in whole. I'm not sure I disagree that we should avoid using documents which aren't W3C recommendations, but unless you've seen someone voice an issue with this on a mailing list or a ticket on the W3C side, an objection based solely on the unit without a suggested replacement, it's not helpful to suggest we shouldn't use those units. --
Izno (
talk) 18:15, 1 July 2015 (UTC)reply
If
your browser doesn't support it, then the fallback is still safe and you simply won't notice any change. There are many parts of CSS that are still in draft status, but in wide use. Many more than people assume actually. The entire
transition spec and large parts of media queries are a draft for instance. Yet they are nearly universally implemented by browser vendors. —
TheDJ (
talk •
contribs) 21:13, 1 July 2015 (UTC)reply
i didn't put this in phab yet, because i figured it would be fine and simple to test out on en.wp before we mainline it. —
TheDJ (
talk •
contribs) 21:14, 1 July 2015 (UTC)reply
@
TheDJ: From a product perspective, I say go for it. The Discovery Department has logging in place that should be able to measure the impact of this change. Please ping me when the change goes live, so we can analyse the before and after. --
Dan Garry, Wikimedia Foundation (
talk) 04:45, 2 July 2015 (UTC)reply
This
edit request has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.
OK, so let's try a version without transition then. Please add the following: —
TheDJ (
talk •
contribs) 13:12, 14 July 2015 (UTC)reply
@
Izno,
TheDJ,
Deskana (WMF), and
Mr. Stradivarius: The preference he's talking about is the "Widen the search box in the Vector skin" checkbox in the Gadgets tab on
Special:Preferences. The preference, when enabled, causes the search box to be wide all the time, not just on wide screens. Disabling the preference causes this just-implemented logic to kick in as expected.
Gparyani (
talk) 17:26, 14 July 2015 (UTC)reply
I'm fairly sure this change is screwing up the layout in Safari using Vector. The login screen (
Special:UserLogin) looks fine, but on article pages and elsewhere where
MediaWiki:Vector.css is loaded, the search box now hangs off of the page by about 40px, maybe? It's causing a horizontal scrollbar. --
MZMcBride (
talk) 15:35, 20 July 2015 (UTC)reply
Screenshot of the issue:
testwiki:File:Vector-safari-layout-bug-2015-07-20.png. This is with Safari version 7.0.6 (9537.78.2). I don't typically use Vector or Safari, so I don't really care about this issue, but depending on the prevalence, a temporary revert might be prudent here. --
MZMcBride (
talk) 15:46, 20 July 2015 (UTC)reply
I use Safari myself every single day. I haven't seen this issue however. There also have been no other reports yet. I'll keep a close eye on it though. Thanks for the report. —
TheDJ (
talk •
contribs) 18:38, 20 July 2015 (UTC)reply
For what it's worth, Safari using iOS 7.something (on my phone) exhibited the same issue. I finally upgraded to iOS 8 this week and Safari using iOS 8 seems fine. I imagine this is just an aged bug in Safari that got fixed. I'm just slow to upgrade. :-) --
MZMcBride (
talk) 02:22, 29 July 2015 (UTC)reply
The next step is to implement it on the preferences and user login pages and also on other wikis.
GeoffreyT2000 (
talk) 03:02, 28 July 2015 (UTC)reply
.contentSub can contain messages like "Redirected from ...", so yes, it is hidden with a prupose. -- [[
User:Edokter]] {{
talk}} 18:10, 7 November 2015 (UTC)reply
OK. If you actually came via a redirect then "Redirected from ..." doesn't seem so bad to display. The html for a redirect like
Mainpage says <div id="contentSub"><span class="mw-redirectedfrom"> (Redirected from <a href="https://en.wikipedia.org/?title=Mainpage&redirect=no" title="Mainpage">Mainpage</a>)</span></div>. Maybe mw-redirectedfrom could be used to remove it but I don't know whether there are other potential unwanted messages in .contentSub.
PrimeHunter (
talk) 22:04, 7 November 2015 (UTC)reply
Protected edit request on 14 November 2015
This
edit request has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.
The h3 currently takes a size of 116% or thereabouts. I would guess this was changed in the same set of changes for the typography refresh (namely, the h1 with serif). We can override the h4 in this file if we want (to 108%?--that looks good to me) --
Izno (
talk) 22:03, 8 April 2016 (UTC)reply
That was indeed a deliberate design decision as part of the Typography Refresh, mainly because H5 and H6 are hardly used, and to make the difference between H3 and H4 more noticable. There is an open ticket on Phabricator for this. -- [[
User:Edokter]] {{
talk}} 10:24, 9 April 2016 (UTC)reply
I would suggest that, if we don't decide to override the heading sizes (back to those specified individually on lines 127, 131, and 135), then we should either:
remove H5 from the list of heading levels offered in the Advanced editor, or
make the Advanced editor's Heading dropdown previews render using the active skin's styles, so that editors (at least those using Vector and using the Advanced editor) who might be planning to add an H5 to an article will have an opportunity to notice that it will be indistinguishable from both its parent H4 and the next H4, if any, and thus, perhaps, be discouraged from using the H5.
This
edit request has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.
Please remove the following fragment from this page:
/* Menu over FR box */div.vectorMenudiv{z-index:2;}
This code actually does nothing, because it's overridden by a more specific CSS selector from the Vector skins's code div.vectorMenudiv.menu, which sets z-index:1;. And it doesn't seem to be necessary – the dropdown menu already correctly appears on top of the FlaggedRevs (PendingChanges) notice, e.g. on
Economy of China right now (if that's reviewed, you can find another example on
Special:PendingChanges):
https://phabricator.wikimedia.org/F8884523Matma Rextalk 16:22, 28 July 2017 (UTC)reply
Not done no explanation of why this is needed or demonstration of any testing has been done. @
Fromanderson: if you want to personalize your Vector experience, you can do so at
User:Fromanderson/vector.css. —
xaosfluxTalk 02:02, 12 November 2019 (UTC)reply
@
Xaosflux: I think the editor is too new to make the subpage in question, which is why there's an edit protected request. --
Izno (
talk) 03:08, 12 November 2019 (UTC)reply
@
Izno: brand-new editors should still be able to create their own personal subpages. —
xaosfluxTalk 04:13, 12 November 2019 (UTC)reply
Interface-protected edit request on 5 April 2020
This
edit request has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.
This edit can be undone now (@
MusikAnimal:). Both
Twinkle and MoreMenu have been fixed long back. There are no other gadgets AFAIK which require this.
SD0001 (
talk) 07:33, 5 April 2020 (UTC)reply
`.mw-body .mw-indicators` rule should be removed (on hold!)
This
edit request has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.
There's an
upcoming change, already
visible on beta, that cares about a small, but useful change in DOM for screenreader users. It puts the indicators underneath first heading in DOM, to expose things like featured article or good article in sequence of the article title.
Visually nothing will change, except that this override in enwiki is obsolete and would push the indicators unnecessarily down.
Please remove the override with rollout this coming Thursday, 2020-04-09.
Volker E. (WMF) (
talk) 01:00, 8 April 2020 (UTC)reply
@
Volker E. (WMF): This sheet applies to all skins. Did you test the deployed skins besides Vector? --
Izno (
talk) 02:18, 8 April 2020 (UTC)reply
@
Izno: In further testing (details on task) we realized that an extra round of changes is needed before rolling the change out to all wikis. Please ignore for now and leave the code as is. Thanks! --
Volker E. (WMF) (
talk) 02:28, 8 April 2020 (UTC)reply
And this is vector.css which I screwed up on woooo. :D
--
Izno (
talk) 02:29, 8 April 2020 (UTC)reply
/* Make "From Wikipedia, the free encyclopedia" a bit smaller */#siteSub{font-size:92%;}
, to
/* Make "From Wikipedia, the free encyclopedia" a bit smaller and in italics */#siteSub{font-size:92%;font-style:italic;}
It will make the text italic and it will look better.
Cupcake547Let's chat! 22:31, 7 April 2021 (UTC).reply
See
MOS:ITALICS for an explanation of when italics are used on the English Wikipedia. Is there guidance there that supports this request? –
Jonesey95 (
talk) 23:56, 7 April 2021 (UTC)reply
@
Jonesey95: Yes I read the guidance and there is support. On the "Use of italics that are specific to Wikipedia" subsection it says: One-line notes that are placed at the top of articles or sections (most often to assist disambiguation or provide cross-references) are hatnotes. One-line notes may also be placed at the top of sections to cross-reference or point to additional information that is not directly linked in the text. Both of these are in italics and indented to distinguish them from the text of the article proper. The Disambiguation and redirection templates and Wikipedia page-section templates automatically provide the required italic formatting, and this is exactly that. Thanks,
Cupcake547Let's chat! 23:46, 8 April 2021 (UTC).reply
You'll need a well advertised discussion with a strong consensus to modify text that appears on every page. –
Jonesey95 (
talk) 01:42, 9 April 2021 (UTC)reply
Interface-protected edit request on 26 April 2021
This
edit request has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.
The rule to hide #contentSub2 should be limited to the
Main Page since it has no effect on other pages and it causes problems with the
Shortdesc helper gadget.
Replace
/* Don't display some stuff on the main page */.page-Main_Page#deleteconfirm,.page-Main_Page#t-cite,.page-Main_Page#footer-info-lastmod,.action-view.page-Main_Page#siteSub,.action-view.page-Main_Page#contentSub,.action-view.page-Main_Page.firstHeading{display:none!important;}
with
/* Don't display some stuff on the main page */.page-Main_Page#deleteconfirm,.page-Main_Page#t-cite,.page-Main_Page#footer-info-lastmod,.action-view.page-Main_Page#siteSub,.action-view.page-Main_Page#contentSub,.action-view.page-Main_Page#contentSub2,.action-view.page-Main_Page.firstHeading{display:none!important;}
and remove
/* Cancel out the custom margin applied to this element to avoid effectively having double the amount of content padding-top as expected on [[Main Page]]. */#contentSub2:empty{display:none;}
WMF has moved more things around. Let me go find it.
Izno (
talk) 13:39, 1 May 2021 (UTC)reply
Found, fixed.
Izno (
talk) 13:48, 1 May 2021 (UTC)reply
Interface-protected edit request on 1 February 2022
The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
Interface-protected edit request on 13 July 2022
This
edit request has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.
Change .mw-body .mw-indicators { to body.skin-vector-legacy .mw-indicators {.
The 2022 Vector already adds padding by itself, by adding additional padding, we are pushing indicators down further then needed. See for instance the featured article star on
Tyler Skaggs. —
TheDJ (
talk •
contribs) 18:38, 13 July 2022 (UTC)reply
This fixes an issue where links cause the desktop view on mobile to expand the viewport to the point where the right empty whitespace kicks in. This should be a fine temp fix. —
TheDJ (
talk •
contribs) 20:19, 18 January 2023 (UTC)reply
Done I don't love this, added for now. —
xaosfluxTalk 01:33, 19 January 2023 (UTC)reply
Yes, because that was the wrong place for it. This is the right place, where the change will only affect the Vector skin(s). ‑‑
Neveselbert (
talk·contribs·email) 18:12, 24 January 2023 (UTC)reply
Can you point to an example page where this problem is presenting? —
xaosfluxTalk 18:12, 24 January 2023 (UTC)reply
@
Neveselbert please be more specific, clicking Special:ListFiles doesn't seem to be causing a problem, can you point to a link that actually demonstrates the problem you are presenting? —
xaosfluxTalk 19:46, 24 January 2023 (UTC)reply
Not done for now: please establish a
consensus for this alteration before using the {{
Edit interface-protected}} template. At this point, you need to establish a consensus that this should be changed in any local MediaWiki space page and not upstream.
Izno (
talk) 02:46, 25 January 2023 (UTC)reply
Also the page linked above looks fine to me, even in
mobile view —
xaosfluxTalk 15:13, 25 January 2023 (UTC)reply
@
Neveselbert was able to get it to show, seems to be after about 720px wide in legacy vector -- why can't this be fixed upstream though? —
xaosfluxTalk 18:08, 25 January 2023 (UTC)reply
Not done for now: please establish a
consensus for this alteration before using the {{
Edit interface-protected}} template. Moreover, why do you think this adjustment needs to be made? If you would like to make it for yourself, you may go to
Special:MyPage/vector.css.
Izno (
talk) 04:10, 31 August 2023 (UTC)reply
Now that the coordinates ID appears exclusively in indicators, the coordinates stuff needs cleaning. In Vector.css, remove and replace
lines 11 to 43 with
body.skin-vector-legacy#coordinates{position:absolute;top:3.5em;right:0;line-height:1.6;text-align:right;font-size:92%;white-space:nowrap;float:right;margin:0;padding:0;text-indent:0;text-transform:none;}/* correct position for VE */body.skin-vector-legacy.ve-ce-surface#coordinates{margin-right:2em;margin-top:-1em;}
These are the only rules that apply according to console.
In Vector-2022.css, remove and replace
lines 6 to 18 with
Similar story regarding applicable rules, once we remove the positioning inherited from old Vector by adding the class that applies only there. I've also removed a few other rules that I cannot conceive of needing in Vector 22.
This change also supports
phab:T331679/
phab:T357580. It may cause some not-quite optimal appearance which will go away on purge/null edit and/or user cache refresh.
Moving this to TemplateStyles can be a separate discussion for later but is (really, has been) possible also if we want.
Izno (
talk) 18:06, 9 March 2024 (UTC)reply
@
Izno for v22: so we no longer need the hack that is in there now because of the change - but we need a different css hack? Is there upstream work being done to not require this hack? —
xaosfluxTalk 13:52, 21 March 2024 (UTC)reply
The upstream rules need to be generic across all wiki and all possible indicators. Some local overrides are to be expected in my view.. —
TheDJ (
talk •
contribs) 14:25, 21 March 2024 (UTC)reply
@
Xaosflux, I don't understand why you're framing this as a question of hacks vice... non-hacks. What gave you the impression the new change is a hack? I am for the minute trying to at least restore us to less rather than more CSS now that we have done the work we needed to do a while ago. :)
Izno (
talk) 02:15, 22 March 2024 (UTC)reply
FYI, I think…we also used the indicator prefixes in the selectors, because we discovered a few coordinate-like templates that did not yet use indicators. It might be these are all fixed now (and if they are not, they should be, probably only one way to find out.) —
TheDJ (
talk •
contribs) 14:31, 21 March 2024 (UTC)reply
@
TheDJ, yeah, I am pretty sure I nixed these already.
Izno (
talk) 02:08, 22 March 2024 (UTC)reply
@
Xaosflux, both changes needed to be made, in the order I suggested. Why did you not do so?
Izno (
talk) 02:16, 22 March 2024 (UTC)reply
Attempting to minimize disruption, I perhaps missed something - thought v22 was no longer loading legacy-vector? —
xaosfluxTalk 09:23, 22 March 2024 (UTC)reply
@
Xaosflux Not yet it's not, that's why at least body.skin-vector-legacy needed to be added.
Izno (
talk) 17:18, 23 March 2024 (UTC)reply
Thanks, I plan to retry this - but haven't had a period where I'm able to watch it for to 5-15mins it takes to go live yet. —
xaosfluxTalk 17:55, 23 March 2024 (UTC)reply
Code common to all skins, and not specific to Vector, was moved to MediaWiki:Common.css. If you want to propose a change to the sitewide CSS that is not specific to a particular skin, please do so at
MediaWiki talk:Common.css rather than here.
All the stylesheets are documented at the
catalogue of CSS classes. Please add any new classes into that catalogue.
@
Edokter: With
Special:Diff/642208825, a bunch of stuff is getting picked up that shouldn't be. For example, there's a huge gap between the page/talk/read/edit tabs and the page title h1 now, because .mw-bodyh1{margin-top:1em;} is now matching it. These rules need to be made more specific.
Jackmcbarn (
talk) 21:30, 12 January 2015 (UTC)reply
Thanks for spotting that. Now fixed. -- [[
User:Edokter]] {{
talk}} 22:06, 12 January 2015 (UTC)reply
Proposal for .topicon
After having seen (previously) the French Wikipedia utilize a .topicon system that allows for topicons to be dynamically placed using Javascript and CSS, I'd like to propose that we implement something similar on the English-language Wikipedia. I'm not entirely sure where to go with this since it would affect all topicons, including (but not limited to)
{{Good article}},
{{Featured article}}, and
{{pp}}. For me, the problem lies in aesthetics and organization. Many times, an article with multiple top icons may look disjoined. (See, for instance,
Atomic bombings of Hiroshima and Nagasaki. Note the gap in the middle where the audio icon is, visible in an article like
California Gold Rush. Other spoken articles, such as
Project Gutenberg, showcase the speaker icon with considerable white space to the right where the good article or featured article icon usually rests.
I found a very simple code which I've implemented on my own custom Vector.js and Vector.css pages which rests the icons neatly directly to the right of the first heading. The Javascript code searches for the .topicon class and moves the code to either above or below the first heading (depending on importance of order) and the CSS steps in to make the icon float to the right. The result is a system of top icons that is flawlessly positioned in the top-right corner and adjusts automatically to the display of multiple top icons. If someone can help me figure out how to even begin discussions or proposals in implementing this, I would greatly appreciate your help!
You're basically re-inventing the wheel. We now have
Page status indicators, which does exactly what you want. I am currently taking inventory of all topicons in order to convert them. -- [[
User:Edokter]] {{
talk}} 12:34, 18 March 2015 (UTC)reply
Hi
Edokter, thank you for your response! If there's any way I can help, please feel free to let me know. Cheers,
The Obento Musubi (
talk·contribs) 19:26, 18 March 2015 (UTC)reply
This will make the size of the search field a lot smaller and thus more optimal at smaller width screens, while at the same time making it larger if there is the space available for it. It falls back safely to the default width if viewport units are not yet available on your platform. I think it could be a welcome addition. —
TheDJ (
talk •
contribs) 12:45, 1 July 2015 (UTC)reply
Should maybe phab this one for upstream? I agree that increasing the size of the bar would be nice in the context of desktop screens. --
Izno (
talk) 14:11, 1 July 2015 (UTC)reply
Interesting. Lose the animation though; the elasticity is jarring and could bump the tabs temporarely into the content area (when resizing to just the right spot). -- [[
User:Edokter]] {{
talk}} 14:15, 1 July 2015 (UTC)reply
OK, I was looking in the W3C Recommendations, not the Candidate Recommendations. Current version is
only three weeks old. --
Redrose64 (
talk) 16:54, 1 July 2015 (UTC)reply
Yes but not in a W3C Recommendation, so it's not set in stone. The link you gave at 15:30, 1 July 2015 goes to an Editor's Draft which can change on a near-daily basis. That July 2005 doc is not a CR but a Working Draft, a little more stable than an Editor's Draft, but still not certain to make it
through the stages of Candidate Recommendation → Proposed Recommendation → W3C Recommendation. As an example, there were some features of HTML5 (such as the
Interactive elements) that were included in the Candidate Recommendation of 4 February 2014 but omitted from that of 29 April 2014 (they weren't in the W3C Recommendation of 28 October 2014 either). We really should not rely on anything that hasn't made it all the way through to W3C Recommendation, since not only might it not ultimately be included, browser vendors are under no obligation to provide it. --
Redrose64 (
talk) 17:40, 1 July 2015 (UTC)reply
My point is that the definition of the unit in question has been included in the documents and moreover stable for 10 years, regardless of the status of the documents in whole. I'm not sure I disagree that we should avoid using documents which aren't W3C recommendations, but unless you've seen someone voice an issue with this on a mailing list or a ticket on the W3C side, an objection based solely on the unit without a suggested replacement, it's not helpful to suggest we shouldn't use those units. --
Izno (
talk) 18:15, 1 July 2015 (UTC)reply
If
your browser doesn't support it, then the fallback is still safe and you simply won't notice any change. There are many parts of CSS that are still in draft status, but in wide use. Many more than people assume actually. The entire
transition spec and large parts of media queries are a draft for instance. Yet they are nearly universally implemented by browser vendors. —
TheDJ (
talk •
contribs) 21:13, 1 July 2015 (UTC)reply
i didn't put this in phab yet, because i figured it would be fine and simple to test out on en.wp before we mainline it. —
TheDJ (
talk •
contribs) 21:14, 1 July 2015 (UTC)reply
@
TheDJ: From a product perspective, I say go for it. The Discovery Department has logging in place that should be able to measure the impact of this change. Please ping me when the change goes live, so we can analyse the before and after. --
Dan Garry, Wikimedia Foundation (
talk) 04:45, 2 July 2015 (UTC)reply
This
edit request has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.
OK, so let's try a version without transition then. Please add the following: —
TheDJ (
talk •
contribs) 13:12, 14 July 2015 (UTC)reply
@
Izno,
TheDJ,
Deskana (WMF), and
Mr. Stradivarius: The preference he's talking about is the "Widen the search box in the Vector skin" checkbox in the Gadgets tab on
Special:Preferences. The preference, when enabled, causes the search box to be wide all the time, not just on wide screens. Disabling the preference causes this just-implemented logic to kick in as expected.
Gparyani (
talk) 17:26, 14 July 2015 (UTC)reply
I'm fairly sure this change is screwing up the layout in Safari using Vector. The login screen (
Special:UserLogin) looks fine, but on article pages and elsewhere where
MediaWiki:Vector.css is loaded, the search box now hangs off of the page by about 40px, maybe? It's causing a horizontal scrollbar. --
MZMcBride (
talk) 15:35, 20 July 2015 (UTC)reply
Screenshot of the issue:
testwiki:File:Vector-safari-layout-bug-2015-07-20.png. This is with Safari version 7.0.6 (9537.78.2). I don't typically use Vector or Safari, so I don't really care about this issue, but depending on the prevalence, a temporary revert might be prudent here. --
MZMcBride (
talk) 15:46, 20 July 2015 (UTC)reply
I use Safari myself every single day. I haven't seen this issue however. There also have been no other reports yet. I'll keep a close eye on it though. Thanks for the report. —
TheDJ (
talk •
contribs) 18:38, 20 July 2015 (UTC)reply
For what it's worth, Safari using iOS 7.something (on my phone) exhibited the same issue. I finally upgraded to iOS 8 this week and Safari using iOS 8 seems fine. I imagine this is just an aged bug in Safari that got fixed. I'm just slow to upgrade. :-) --
MZMcBride (
talk) 02:22, 29 July 2015 (UTC)reply
The next step is to implement it on the preferences and user login pages and also on other wikis.
GeoffreyT2000 (
talk) 03:02, 28 July 2015 (UTC)reply
.contentSub can contain messages like "Redirected from ...", so yes, it is hidden with a prupose. -- [[
User:Edokter]] {{
talk}} 18:10, 7 November 2015 (UTC)reply
OK. If you actually came via a redirect then "Redirected from ..." doesn't seem so bad to display. The html for a redirect like
Mainpage says <div id="contentSub"><span class="mw-redirectedfrom"> (Redirected from <a href="https://en.wikipedia.org/?title=Mainpage&redirect=no" title="Mainpage">Mainpage</a>)</span></div>. Maybe mw-redirectedfrom could be used to remove it but I don't know whether there are other potential unwanted messages in .contentSub.
PrimeHunter (
talk) 22:04, 7 November 2015 (UTC)reply
Protected edit request on 14 November 2015
This
edit request has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.
The h3 currently takes a size of 116% or thereabouts. I would guess this was changed in the same set of changes for the typography refresh (namely, the h1 with serif). We can override the h4 in this file if we want (to 108%?--that looks good to me) --
Izno (
talk) 22:03, 8 April 2016 (UTC)reply
That was indeed a deliberate design decision as part of the Typography Refresh, mainly because H5 and H6 are hardly used, and to make the difference between H3 and H4 more noticable. There is an open ticket on Phabricator for this. -- [[
User:Edokter]] {{
talk}} 10:24, 9 April 2016 (UTC)reply
I would suggest that, if we don't decide to override the heading sizes (back to those specified individually on lines 127, 131, and 135), then we should either:
remove H5 from the list of heading levels offered in the Advanced editor, or
make the Advanced editor's Heading dropdown previews render using the active skin's styles, so that editors (at least those using Vector and using the Advanced editor) who might be planning to add an H5 to an article will have an opportunity to notice that it will be indistinguishable from both its parent H4 and the next H4, if any, and thus, perhaps, be discouraged from using the H5.
This
edit request has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.
Please remove the following fragment from this page:
/* Menu over FR box */div.vectorMenudiv{z-index:2;}
This code actually does nothing, because it's overridden by a more specific CSS selector from the Vector skins's code div.vectorMenudiv.menu, which sets z-index:1;. And it doesn't seem to be necessary – the dropdown menu already correctly appears on top of the FlaggedRevs (PendingChanges) notice, e.g. on
Economy of China right now (if that's reviewed, you can find another example on
Special:PendingChanges):
https://phabricator.wikimedia.org/F8884523Matma Rextalk 16:22, 28 July 2017 (UTC)reply
Not done no explanation of why this is needed or demonstration of any testing has been done. @
Fromanderson: if you want to personalize your Vector experience, you can do so at
User:Fromanderson/vector.css. —
xaosfluxTalk 02:02, 12 November 2019 (UTC)reply
@
Xaosflux: I think the editor is too new to make the subpage in question, which is why there's an edit protected request. --
Izno (
talk) 03:08, 12 November 2019 (UTC)reply
@
Izno: brand-new editors should still be able to create their own personal subpages. —
xaosfluxTalk 04:13, 12 November 2019 (UTC)reply
Interface-protected edit request on 5 April 2020
This
edit request has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.
This edit can be undone now (@
MusikAnimal:). Both
Twinkle and MoreMenu have been fixed long back. There are no other gadgets AFAIK which require this.
SD0001 (
talk) 07:33, 5 April 2020 (UTC)reply
`.mw-body .mw-indicators` rule should be removed (on hold!)
This
edit request has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.
There's an
upcoming change, already
visible on beta, that cares about a small, but useful change in DOM for screenreader users. It puts the indicators underneath first heading in DOM, to expose things like featured article or good article in sequence of the article title.
Visually nothing will change, except that this override in enwiki is obsolete and would push the indicators unnecessarily down.
Please remove the override with rollout this coming Thursday, 2020-04-09.
Volker E. (WMF) (
talk) 01:00, 8 April 2020 (UTC)reply
@
Volker E. (WMF): This sheet applies to all skins. Did you test the deployed skins besides Vector? --
Izno (
talk) 02:18, 8 April 2020 (UTC)reply
@
Izno: In further testing (details on task) we realized that an extra round of changes is needed before rolling the change out to all wikis. Please ignore for now and leave the code as is. Thanks! --
Volker E. (WMF) (
talk) 02:28, 8 April 2020 (UTC)reply
And this is vector.css which I screwed up on woooo. :D
--
Izno (
talk) 02:29, 8 April 2020 (UTC)reply
/* Make "From Wikipedia, the free encyclopedia" a bit smaller */#siteSub{font-size:92%;}
, to
/* Make "From Wikipedia, the free encyclopedia" a bit smaller and in italics */#siteSub{font-size:92%;font-style:italic;}
It will make the text italic and it will look better.
Cupcake547Let's chat! 22:31, 7 April 2021 (UTC).reply
See
MOS:ITALICS for an explanation of when italics are used on the English Wikipedia. Is there guidance there that supports this request? –
Jonesey95 (
talk) 23:56, 7 April 2021 (UTC)reply
@
Jonesey95: Yes I read the guidance and there is support. On the "Use of italics that are specific to Wikipedia" subsection it says: One-line notes that are placed at the top of articles or sections (most often to assist disambiguation or provide cross-references) are hatnotes. One-line notes may also be placed at the top of sections to cross-reference or point to additional information that is not directly linked in the text. Both of these are in italics and indented to distinguish them from the text of the article proper. The Disambiguation and redirection templates and Wikipedia page-section templates automatically provide the required italic formatting, and this is exactly that. Thanks,
Cupcake547Let's chat! 23:46, 8 April 2021 (UTC).reply
You'll need a well advertised discussion with a strong consensus to modify text that appears on every page. –
Jonesey95 (
talk) 01:42, 9 April 2021 (UTC)reply
Interface-protected edit request on 26 April 2021
This
edit request has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.
The rule to hide #contentSub2 should be limited to the
Main Page since it has no effect on other pages and it causes problems with the
Shortdesc helper gadget.
Replace
/* Don't display some stuff on the main page */.page-Main_Page#deleteconfirm,.page-Main_Page#t-cite,.page-Main_Page#footer-info-lastmod,.action-view.page-Main_Page#siteSub,.action-view.page-Main_Page#contentSub,.action-view.page-Main_Page.firstHeading{display:none!important;}
with
/* Don't display some stuff on the main page */.page-Main_Page#deleteconfirm,.page-Main_Page#t-cite,.page-Main_Page#footer-info-lastmod,.action-view.page-Main_Page#siteSub,.action-view.page-Main_Page#contentSub,.action-view.page-Main_Page#contentSub2,.action-view.page-Main_Page.firstHeading{display:none!important;}
and remove
/* Cancel out the custom margin applied to this element to avoid effectively having double the amount of content padding-top as expected on [[Main Page]]. */#contentSub2:empty{display:none;}
WMF has moved more things around. Let me go find it.
Izno (
talk) 13:39, 1 May 2021 (UTC)reply
Found, fixed.
Izno (
talk) 13:48, 1 May 2021 (UTC)reply
Interface-protected edit request on 1 February 2022
The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
Interface-protected edit request on 13 July 2022
This
edit request has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.
Change .mw-body .mw-indicators { to body.skin-vector-legacy .mw-indicators {.
The 2022 Vector already adds padding by itself, by adding additional padding, we are pushing indicators down further then needed. See for instance the featured article star on
Tyler Skaggs. —
TheDJ (
talk •
contribs) 18:38, 13 July 2022 (UTC)reply
This fixes an issue where links cause the desktop view on mobile to expand the viewport to the point where the right empty whitespace kicks in. This should be a fine temp fix. —
TheDJ (
talk •
contribs) 20:19, 18 January 2023 (UTC)reply
Done I don't love this, added for now. —
xaosfluxTalk 01:33, 19 January 2023 (UTC)reply
Yes, because that was the wrong place for it. This is the right place, where the change will only affect the Vector skin(s). ‑‑
Neveselbert (
talk·contribs·email) 18:12, 24 January 2023 (UTC)reply
Can you point to an example page where this problem is presenting? —
xaosfluxTalk 18:12, 24 January 2023 (UTC)reply
@
Neveselbert please be more specific, clicking Special:ListFiles doesn't seem to be causing a problem, can you point to a link that actually demonstrates the problem you are presenting? —
xaosfluxTalk 19:46, 24 January 2023 (UTC)reply
Not done for now: please establish a
consensus for this alteration before using the {{
Edit interface-protected}} template. At this point, you need to establish a consensus that this should be changed in any local MediaWiki space page and not upstream.
Izno (
talk) 02:46, 25 January 2023 (UTC)reply
Also the page linked above looks fine to me, even in
mobile view —
xaosfluxTalk 15:13, 25 January 2023 (UTC)reply
@
Neveselbert was able to get it to show, seems to be after about 720px wide in legacy vector -- why can't this be fixed upstream though? —
xaosfluxTalk 18:08, 25 January 2023 (UTC)reply
Not done for now: please establish a
consensus for this alteration before using the {{
Edit interface-protected}} template. Moreover, why do you think this adjustment needs to be made? If you would like to make it for yourself, you may go to
Special:MyPage/vector.css.
Izno (
talk) 04:10, 31 August 2023 (UTC)reply
Now that the coordinates ID appears exclusively in indicators, the coordinates stuff needs cleaning. In Vector.css, remove and replace
lines 11 to 43 with
body.skin-vector-legacy#coordinates{position:absolute;top:3.5em;right:0;line-height:1.6;text-align:right;font-size:92%;white-space:nowrap;float:right;margin:0;padding:0;text-indent:0;text-transform:none;}/* correct position for VE */body.skin-vector-legacy.ve-ce-surface#coordinates{margin-right:2em;margin-top:-1em;}
These are the only rules that apply according to console.
In Vector-2022.css, remove and replace
lines 6 to 18 with
Similar story regarding applicable rules, once we remove the positioning inherited from old Vector by adding the class that applies only there. I've also removed a few other rules that I cannot conceive of needing in Vector 22.
This change also supports
phab:T331679/
phab:T357580. It may cause some not-quite optimal appearance which will go away on purge/null edit and/or user cache refresh.
Moving this to TemplateStyles can be a separate discussion for later but is (really, has been) possible also if we want.
Izno (
talk) 18:06, 9 March 2024 (UTC)reply
@
Izno for v22: so we no longer need the hack that is in there now because of the change - but we need a different css hack? Is there upstream work being done to not require this hack? —
xaosfluxTalk 13:52, 21 March 2024 (UTC)reply
The upstream rules need to be generic across all wiki and all possible indicators. Some local overrides are to be expected in my view.. —
TheDJ (
talk •
contribs) 14:25, 21 March 2024 (UTC)reply
@
Xaosflux, I don't understand why you're framing this as a question of hacks vice... non-hacks. What gave you the impression the new change is a hack? I am for the minute trying to at least restore us to less rather than more CSS now that we have done the work we needed to do a while ago. :)
Izno (
talk) 02:15, 22 March 2024 (UTC)reply
FYI, I think…we also used the indicator prefixes in the selectors, because we discovered a few coordinate-like templates that did not yet use indicators. It might be these are all fixed now (and if they are not, they should be, probably only one way to find out.) —
TheDJ (
talk •
contribs) 14:31, 21 March 2024 (UTC)reply
@
TheDJ, yeah, I am pretty sure I nixed these already.
Izno (
talk) 02:08, 22 March 2024 (UTC)reply
@
Xaosflux, both changes needed to be made, in the order I suggested. Why did you not do so?
Izno (
talk) 02:16, 22 March 2024 (UTC)reply
Attempting to minimize disruption, I perhaps missed something - thought v22 was no longer loading legacy-vector? —
xaosfluxTalk 09:23, 22 March 2024 (UTC)reply
@
Xaosflux Not yet it's not, that's why at least body.skin-vector-legacy needed to be added.
Izno (
talk) 17:18, 23 March 2024 (UTC)reply
Thanks, I plan to retry this - but haven't had a period where I'm able to watch it for to 5-15mins it takes to go live yet. —
xaosfluxTalk 17:55, 23 March 2024 (UTC)reply