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?
Topic on User talk:Volker E. (WMF)
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.
Remove the 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:
- a
- b
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.
The ː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.