@Jdlrobson I'm waiting for TemplateStyles to be deployed, but it has a major blocker in that it does not support media queries (see T135788), on which the new main page relies heavily. Other then that, I just have to ensure 100% consensus from the community :)

A line break (\n) after each list item should provide a clean output allowing breaks.

It applies to all skins. But can we decide on a unified selector please?

In T483#2316983, @MZMcBride wrote:

I'm hoping to find some time to play around with TemplateStyles this week. I'm curious whether features such as url() will be totally banned or only banned for non-Wikimedia domains. If we're going to disallow certain kinds of CSS (i.e., if we're only going to allow a subset of CSS), we'll want to make sure that the documentation and user interface both make this clear early and often to prevent headaches and frustration.

To clarify, even if this is the older task, the code responsible for this bug is no longer present since Category view switched to CSS cloumns.

If we're not touching the colors set in the other skins, they will override this, and the colors set in enwiki's common.css will have to remain.

This would remove the ability for dynamic styling (unless parser functions work inside <TemplateStyles>, but that is a coding nightmare), so that is a definite no for me. As @Nbdd0121 says, this is a super-breaking change, and wihtout a good rationale. Both inline and <style> have their uses, and neither has the full set of features that the other lacks.

@fredw, the current release version (45) still uses the internal font stack, which is why I find it odd we override it in the first place. But if the internal stack is removed, we may as well leave it.

I think scoping to #mw-content-text should be enough. Any tempate appearing outside actual content is usually protected anyway.

In T483#2215393, @Entlinkt wrote:

It should probably be avoided that templates can leak styles into that area.

OK, let me explain my exact goals again...

Yes, lets move all CSS inline to the templates... I think not. Why shouldn't the loading of Mobile.css be fixed instead?

Where is the max-width coming from?

@MaxSem That breaks up the list, which creates accessability issues on its own. The better choice is to use column-break CSS. But browser support is fragmanted.

From what I can see, the content is evenly spaced on both sides inside the quotes. Adding the margin would break that symmetry, which would look bad in ohter situations. Spacing also depends on client font metrics. Plus this adds micro-managing CSS bloat; we should not fall into these "1px"-trap because something looks off. Suggest WONTFIX.

I don't agree with removing Linux Libertine; I want Georgia removed. But anyway...

I'll remove it. When will it be deployed?

I get this (blocking) error on any page on enwiki with an .ogg file on it. Chrome does not like somthing about the embedded player (that replaces the native player).

Yeah, I removed that, as it !forced any clears to none, which interfered with some templates.

Wikipedia:Typography links to some archived font surveys that break down the installed fonts for each of the three popular platforms (Windows, Mac, Linux). Some will regard those as outdated, but it provides a good base non the less.

Your guess is as good as mine. I found the code once, but now I searched the entire core and I can't find it anymore...

That would be a terrible hack that defeats the purpose of using clumns in the first place.

I don't think that is sufficient reason to remove focussing all together.

I made some small modifications to the Dutch script, but I like having it closer to the MW implementation. I'll move the 'Create account' to the right, but I'm not sure what to do with the user page link: remove it or link it? Thoughts?

This is a local problem. Normally, unvisited pages on your watchlist are bolded. On enwiki, this is changed to a green bullet. Recently, changes to the ResourceLoader forced me to move the CSS associated with the watchlist to a gadget, to ensure the correct loading order.

If a gadget doesn't work and other scripts are affected, I'm sure such admins will be taken to task pretty quick.

I hope this trend is not pushing towards other (generic) classes, such as thumbs. Those are used by templates, and this may apply to galleries as well.

@Volker_E, You mean the font stack? Last revision is here, it then moved to a separate CSS page before it was killed off. Now, Common.js only loads two common Unicode fonts, and only on XP.

We should not specify fonts that are marginally installed by default. Some time back, enwiki had a font stack for unicode fonts that included 30(!) fonts. It grew over the years because each time some glyph didn't work, another font was added. I ended up removing it as it started to interfere with the browser's glyph fallback. So let's not fall into that trap, lest we end up with 30 fonts.

Glad you understand. We shouldn't use @supports for initial, there would be no end to it and we'd end up with duplicate rulesets everywhere. Just avoid initial where ever you can.

@mxn, IE does support @supports in the nighlies, but not initial. So this creates a problem is they decide to implement text-decoration-style.

Oh dear, we just moved the problem from Firefox to Internet Explorer; IE does not support initial (and probably never will), but it will someday support text-decoration-style, which will cause the same problem we're trying to solve here. And it already supports @supports in the nightlies, where it will throw an unneeded CSS error in the console.

Now site and user are loaded twice. @Krinkle calls this 'harmless', but it is extremely annoying having to dig through duplicate properties, not knowing where they come from. I also experience occasional load order issues and discrepancies between bedug and live loads.

In T99369#1481983, @fredw wrote:

Yes, Mathoid (which is nothing more than server-side MathJax for those who missed that...)

What @DavidEppstein said...

This comes as quite a shock... I was so glad to get rid of those awful PNGs. But it is not much of a suprise that it was unmaintainable due to the way MathJax was integrated.

I don't think it is too hard using inline CSS; it is the most straightforward approach. Personally, I would choose [| and |] as column markers, with | (and |-) as optional column break points. That should not create a conflict with existing markup. HTML-wise, they should translate to somthing like:

I chose those values as they inherently include their own 1.5x and 2x versions (not al of them need to be listed in preferences though). The cleanup is due anyway. I once suggested an expiring mechanism for (existing) thumbs that have been stale for 90 days, but it requires a daily task to run.

But not so consistent with other projects like Gerrit.

I think we should build on multiples of 120 and 160. That should result in the following common cached image sizes: 120, 160, 180, 240, 320, 360, 480, 640, 720, 960, 1280, 1440, 1920... with 240 as the default.

I ment if the Wikimedia logo should be black and white?

I'm saying we could use existing code for that, for example: https://www.mediawiki.org/wiki/Extension:CSS and https://www.mediawiki.org/wiki/Extension:NewPageCSS

We already have several extensions that can load page-bound CSS. Why are these not used?

Good! Now we have an actual example of an obsolete attribute being removed from a browser. That will kill any argument claiming "but these attributes still work and will be supported forever!".

I'll have a shot at it. Does it have to be black-and-white?

Locally as in enwiki? I would also oppose that, as I do see other elements shrinking, such as the search box. So a universal box-sizing:border-box is ill-conceived. There is nothing in the way to choose border-box for certain elements, but it makes no sense whatsoever to apply it to all elements; they have been designed with content-box in mind after all.

You may want to reword your proposal, because I somehow still have the idea that you want to apply the first snippet somewhere, and I would certainly oppose that.

Sorry, I am wrong to asume the first snippet is not already in Vector? If not, why put a patch in core to fix a local CSS issue?

Where can I see the bug in action?

Common.js still loads edit.js and watchlist.js through importScript; edit.js because of a seemingly longstanding bug T10912, and extra buttons for the old edit toolbar; and watchlist.js to add butons to dismiss watchlist messages.

In T104067#1408332, @He7d3r wrote:

I would prefer T70466: Add parser test for multiline <pre> or <syntaxhighlight> elements inside a dd element created by ":", to suport better the usage of these elements inside of lists.

It has alwasy broken inside a list item wihtout the enclose=div option (which was a hack in itself). We should make it a good habit of no longer using it inside a wikilist item. Other then that, wether it is Tidy or the parser getting confused (I'd have to test using ExpandTemplates), the extension should always treat it as a new block context.

Then I was partly wrong, and it still presents a problem.

Also, as @Krinkle hase pointed out in the patch, divs cannot have focus and thus cannot be navigated using the keyboard. That hurts accessability more then the purported middle-click would.

It is clear that the design team knows nothing about the technical aspects of web typography. All the issues raised here are real, especially the non-Latin use of fonts (and Georgia in particular). But perhaps I expect too much when trying to explain something that transcends outside the expertise of designers.

Let me rephrase that: Declining a task should only be done if the request is eihter unreasonable, hard to implement or going against core design priciples. Neither of those apply, so no single dev can decline.

Reopening... @Krinkle, you do not have the authority do decline this request, and I will not leave this alone until users have some control over ordering, wihtout having to revert to indicator name-hacking.

Those are the less distinct corrections. The core of the Typography Refresh--the actual fonts--would all be reverted to just "sans-serif".

To allow...?

I'm just about ready to fully support reverting back to sans-serif for the headers. There has been plenty of feedback from readers on mediawiki.org, and all of them are blissfully ignored. That is what happens when you stand by a change dispite its shortcomings.

Not convinced this needs action. It will also break any script interacting with the menu... again.

I once already suggested throwing out Georgia as being diproportionate to the other fonts. See https://www.mediawiki.org/wiki/Talk:Typography_refresh#Header_fontstack. I also suggested ohter fontstacks that are very similair in design and metrics. But ditching Georgia is the main argument in all of them.

That did not clear the problem for me, so caching issue is server-side.

Very possible. But these deploy/cahcing issues seem to become a weekly occurence.

I thought the point of all CSS loading at top by default is that there is no point in loading CSS at the bottom. I can think of no scenario where CSS is not needed at page load. The only possible advantage is that content comes sooner, but you also risk style flashes.

How can it be a regression? It's a new feature with a new bug?

@Jdforrester-WMF, I don't think there has been any case studies done with regards to indicator use, and I think you have no idea how indicators are used in real wiki-life. I am talking from experience and as the one how implemented it on enwiki, I get all the complaints regarding sorting.

Then discuss... I have put my arguments forward in that auto-sorting gives more trouble then advantages, and that sorting can easily be achieved localy instead.

Because I'd like to have this cleared before it gets released.

Any HTML5 will not degrade gracefully on IE8; while it safely ignores the tag, any associated CSS wil also be ignored.

Any HTML5 will not degrade gracefully on IE8; while it safely ignores the tag, any associated CSS wil also be ignored.

Final patch pending. Once merged, this can be closed.

Chrome bug to monitor: https://code.google.com/p/chromium/issues/detail?id=439820 (EDIT:) which is now marked as "fixed".

I think the shortest path is, as @EoRdE6 points out, is to allow users to supress redirects, but only when moving from their own user space. What were the reasons this was shot down?

This will lead to option-bloat. If there is a user option to disable this particular interface element, what about all the other elements that some editors don't want to see? There would be no end in sight. Therefor declined.

Perhaps supress the creation of a redirect by default when moving a draft.

Again, no editor is directly using <indicator>, but uses templates, which there are a few hundreds of, and I am not about to go through them all again to add a name parameter, which has other disadvantages, like breaking id naming.

In T94307#1287739, @Nemo_bis wrote:

I don't understand the seemingly strong push for this request: what's so hard about making indicators have names which sort in the way you want, whatever it is?