I am VERY pissed at this time. just to let you know. Every "trivial" option you present requires EDITING ALL TEMPLATES YET AGAIN! When it was introdiced, I edited them all to get RID of all the hacks. Now I have to put them all back?

Using <indiocator> on the host page is aNOT possible, because that would lead to nesting the tags, giving errors.

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.