Think you could help with answering my question here?
I'd like to better understand the dangers of changes like [changing icons].
- Why is it 2 weeks to be safe removing the old icons?
- In what circumstance can a page cached from the previous deployed version be served?
- How can the 2 icons edit vice-versa? (phab:T244444#6025519).
Hi! You referred to no Phabricator task in 1fd66a67edc, so I’m writing here. You provided no real explanation why the
:only-child rules are necessary, but their result can be seen here—the <ul> has no margin, so the bullet points get out of the box. Why are these rules worth it?
Thanks @Tacsipacsi, that is actually a bug. But not in Vector style, but in huwiki's https://hu.wikipedia.org/w/index.php?title=MediaWiki:Common.css.
padding property there and the styling is fine.
…and in Commons’ (see this example), and in enwiki’s, and so on. I think this is the point where you have the responsibility to fix the layout on these wikis, preferably without breaking any other layout (e.g. giving a huge padding to the box may break other cases, where there’s no list in the box). And your code breaks even on MediaWiki.org:
Here the bullet points get out of the red-bordered inner box, as
.messagebox :only-child may mean
div.messagebox > div > ul:only-child as well (actually something like this happens in the above Commons example, as the list is in a <div> within the table cell), not only
div.messagebox > ul:only-child (and it may mean many other things way down in the DOM tree)—using unqualified generic ancestor selectors is almost never a good idea!
I agree that unqualified generic selectors should be used carefully. Going to the Commons example, it's again a MediaWikiːCommon.css override, similar to huwiki. If removed the box overflow is goneː https://phabricator.wikimedia.org/F31553033
In the same way MediaWikiːCommon.css overrides should be used very sparelyǃ As they are a maintenance burden, they are hard to update with new findings on internationalization or accessibility. The reason for the
ːonly-child was excessive padding due to more generic selectors. Lists in messages are an edge case that we've been taken into account with our default padding, but the overrides are kicking them out of the box. Having the list bullets outside of the red box is not a breakage for me, it's acceptable or even recommended by some typographers, see https://betterwebtype.com/articles/2018/10/15/rhythm-in-web-typography/
To be precise: these are not overrides. These are consistent styles that have existed on-wiki and worked well for 14 years before appearing in MediaWiki core source code. (The huwiki and Commons versions are 1-2 years younger, simply because the first versions of their common.css’s are of that age.) So we got back to that you intervened in how these classes work after almost one and a half decade. (The red border was just an example. It’s still weird for me, even after reading the article, but I can accept some people like it that way. However, there are cases where it’s not a question that it’s simply wrong. For example hu:Sablon:Vitafejléc’s right pane fortunately has a paragraph above the list, otherwise it would look terrible with the bullet points appearing at the left pane’s right side.)
I'm not interested in a blame game, my work is focused on having consistent experience for users of all our projects. If you refer to https://phabricator.wikimedia.org/T127405 or https://phabricator.wikimedia.org/T228022 it's obvious that message box visual treatment was all over the place making it harder for user to orient.
ːonly-child selector targets to reduce whitespace in case block-level elements are the only children of the messagebox.
The „consistent“ styles haven't worked for 14 years, if we have a look at a mobile (iPhone 6/7/8) representation. https://phabricator.wikimedia.org/F31606008 Tables are not meant to be used for layouts, they mostly work well only under the assumption of a minimum width. And the new selector is only uncovering more table layout inflexibility.
I could imagine to add precision to the selector (like excluding table.messagebox) for a short-term solution, but it doesn't make the current layout any more future-proof. It only extends the semi-broken status quo.
Yes, that’s the first template of that I mentioned here that is actually really broken on mobile (but wouldn’t be very hard to fix the mobile layout, although working around your changes may take a bit more time). My subpage uses a plain <div>, which is as mobile-friendly as possible, while the Commons template uses a table, but with only a small icon, which causes a less-than-ideal, but still readable output (tested with the iPhone 6/7/8 user agent in Firefox’s responsive design mode). I don’t know what you mean by “uncovering more table layout inflexibility” (especially regarding my original example, which has not a single table), as the new selector simply messes up the current style. Doesn’t create a new consistent style, as it overrides only parts of the styles, while keeps other parts intact (I’m speaking about enwiki, huwiki and Commons, not mediawiki.org). Of course anything can break with such inconsistent changes. Excluding tables doesn’t fix the layout for non-table message boxes, so that’s not even a short-term solution.
Re:OOUI and stuff
Don't want to start an off-topic discussion on Phabricator (phab:T212808) so let us continue this discussion here (link on your page in Phabricator led me here).
To be quite honest, between May 2017 and November 2018 I didn't have admin rights (click), so I cannot tell myself. But there's been this discussion on plwiki, which hints that the problem with our local gadget was caused by the OOUI change and hasn't been really fixed ever since. To clarify: I am not claiming that that OOUI change caused the TypeError I mention in phab ticket, just that our local gadget stopped working.
And I am not a fan of OOUI at all. Wherever I could, I have disabled any sorts of fancy looking "improvements", which, for me personally are downgrades. I have disabled this on RecentChanges, Watchlist and Search. I would disable it anywhere else as well, but I unfortunately cannot. There should be an option in Preferences to turn off OOUI look and just use plain html forms, as it was before. I am one of those veteran editors; I've been here (in and out admittedly) for 15 years (10 on this account) and I got used to the "old look". As one of plwiki's technicans I am not against changes so to say, I am against changes that are completely unnecessary. OOUI forms are taking more space on the screen than their plain html "counterparts". These widgets are also taking some time to load, which really pisses me off.
All I ask for is, give me the ability to choose. Best wishes for this New Year, tufor
great talking to you to, buddy
Hi @Tufor, thanks for your honest input here. I've had a very busy week with the still ongoing OOUI v0.30.1 release and a lot of other things https://gerrit.wikimedia.org/r/q/owner:volker.e%2540wikimedia.org+status:merged I would like to better understand your take on the interface change. But need some more time for a better reply. Best, Volker
Vector, UI and more..
Hello, I have questions:
- Will you make an update of the Vector skin to remove the awful blue bar between sidebar and page content, the blue of the of the source editor, all non-flat icons, gradients and other ?
- Will the Design team make a graphic chart like the material design of Google ?
- Could the Design team propose new logos for sister projects with the blue red and green (Especially for Wikispecies' logo wich looks so old) ? ( I made some tries but it's missed)
trying to respond as clearly as possible and pointing out the different dependencies, but first of all explain what's the best process to raise those.
You might want to join Phabricator (We manage our projects, tasks and bugs on Phabricator.) and repost your questions as laid out on our site. There it gets more attention and usually the right respondents in comparison to a talk page like this.
Log in to Phabricator with your MediaWiki login credentials to be involved in the design quests. Please tag your tasks with "Design".
Regarding your questions:
- First I need to ask further: What would you expect from such a graphic chart to help your work?
- The Design team could propose new logos, but currently (again: limited resources) we don't have it planned as one of our priorities for the upcoming months. I will forward your logo page to the Communications team, so that they are aware of the critique and the work taken.
- I'll use the Phabricator. But it is not written if we can make concensus on it or not.
- For the graphic chart, it would be something really complete about all on-wiki content, pages formatting, template design, Mediawiki: messages design, ect.
- Thank you to show them my (horrible) work ! I think it's really important to bring the 3 colors to all the logos, especially for Wikipedia wich is the most-known project, because people could clearly identify Wikimedia's projects.
@Archi38, re: logo color, this issue has been discussed in the past, for example in the Wiktionary logo votes in ~2006. It was determined then, that having all the logos use the same color schemes, would be confusing; see example at w:de:Benutzer:Julian~dewiki#Test on logos. See also, these discussions (m:Discussion_on_the_logo_votes#The_Color_Complication and m:Talk:Wiktionary/logo/archive-vote-4#Changing_colors), in particular this comment: "the only thing we can do is to ensure that newly chosen logos harmonize [with] the others but don't look all the same". See also m:Logo#Logo_guidelines "It must be substantially different from the other project logos but still harmonize with the others.". HTH.
(Sidenote: There's a not-completely-serious compilation of these types of alternate logos, compiled at m:Red, green, and blue, which might amuse you. My volunteer account has added your designs, there.).
I still think that it would be better ^^. And thank you for adding them in red green and blue, I've already seen the page. Thank you for all !
Question about mw-ui-constructive and mw-ui-progressive buttons
Hi Volker, I noticed that phab:T110555 had been assigned to you, so I assumed you were the best person to ask this question to:
After the mw-ui-constructive (green) buttons had been turned to mw-ui-progressive (blue), I noticed that, when a button created with w:en:Template:Clickable button 2 (which uses the mw-ui classes) links to the page it is on, the mw-ui-progressive buttons are a darker shade of blue (which is normal); however, the mw-ui-constructive buttons are a darker shade of green with a blue border. Is this intentional? (See w:en:User:CabbagePotato/sandbox2 for a demonstration.)
Thanks for reaching out to me about this bug and for your demo. We've already received a message (from another user?) on https://phabricator.wikimedia.org/T110555#2142384 the Phabricator task. The problem seems that the while using an inline style declaration applying the wrong shade of green to the background, the template is protected and we therefore have currently no possibility to change the green.
There are no older topics