Wikimedia Bugzilla is closed!

*** This bug has been confirmed by popular vote. ***

It not passing the validator is not a problem. The W3C validator is a tool to find possible problems. This is not a problem.

MediaWiki is built for browsers, not for validators. History has shown us time and time again that browsers are different than the W3C specification writes. Either intentionally or not.

This tag does not cause warnings in real browsers. It works fine with no problems whatsoever.

The reason it exists is because a placeholder marker is needed to mark where dynamic stylesheets need to be inserted into the document.

This marker doesn't have to be a <meta> tag, but it needs to be something. Something that doesn't do anything and is allowed in that position (i.e. not "moved" by real browsers, regardless of what the W3C says).

Any suggestions what kind of tag (or attributes) to use instead?

CC-ing @DanielFriesen for input as well.

It's not exactly a placeholder. And it's tricky to do. But one of the things I contemplated before was inserting an id, name, or class onto the stylesheet tag that comes before the spot we want to add dynamic stylesheets to. After that we'd probably do something like looking that node up on page load. And whenever a dynamic style is inserted we would record it so we know what element we now want to insert after. Or maybe recording the nextSibling onload and using insertBefore on that.

Or instead of a hacky id. We could give all stylesheets named ids. And inside a script tag register the id of the node we want to insert before or after. Then lookup that id when we first need to insert something.

(In reply to comment #3)
> It's not exactly a placeholder. And it's tricky to do. But one of the things I
> contemplated before was inserting an id, name, or class onto the stylesheet tag
> that comes before the spot we want to add dynamic stylesheets to. After that
> we'd probably do something like looking that node up on page load. And whenever
> a dynamic style is inserted we would record it so we know what element we now
> want to insert after.

That wouldn't work always since it is a marker used for both directions. Some stuff goes before, some stuff goes after.

And when the page is first loaded (depending on the site configuration and the logged-in user), it could be that neither exists yet or only one of the two kinds of stylesheets.

The marker is currently put between regular modules and site/user modules. The latter of which always needs to be cascade last. This works since browsers honor the order in the DOM as the cascading order (not the order in which things are inserted per se).

Using a stylesheet itself as a marker is smart, though we need to cover for all both scenarios (having a marker on a regular stylesheet or a site/user one). And then keep a reference to that and if the marker is of the other user-kind, insert before, and if a regular one insert after and update the marker reference.

If there's neither, it isn't a problem since then the first dynamic stylesheet becomes the marker and it goes from there.

This one is an easy fix: register the resourceloaderdynamicstyles keyword at the WHATWG Wiki.

http://wiki.whatwg.org/wiki/MetaExtensions

This should probably be done by a developer who can fill in the description data. To open an account, follow the instructions at the top of the page.

I'm in the process of asking for an account. Will corner Roan or Timo for a proper description.

I'm a bit confused why a marker is needed. Couldn't it just add a style tag to the bottom of the head element and add all of the styles there or could I not add a style tag with an id in the head that can be targetted?

(In reply to comment #7)
> I'm a bit confused why a marker is needed. Couldn't it just add a style tag
> to the bottom of the head element [..]

No, because (cascading) order matters: software > site > user.

Site and user resources are in the document from the beginning (inserted server-side). The marker is placed right before that point in the document, which is where any dynamically loaded modules are added.

See also comment 4 for why we can't put the ID on the last software resource.

We can't put the ID on the first site/user resource because some wikis don't have local overrides (in which case the tag isn't there), and many users don't have overrides (in which case that tag isn't there). So then one would still need a marker. The simplest solution is to have the marker there anyway.

A more elaborate solution would be to iterate through this stuff server side and generate and put the ID on the first site/user resource and if there are none, output an empty <style> tag and use that instead.

*** Bug 44003 has been marked as a duplicate of this bug. ***

(In reply to comment #2)
> It not passing the validator is not a problem. The W3C validator is a tool to
> find possible problems. This is not a problem.
> 
> MediaWiki is built for browsers, not for validators. History has shown us
> time
> and time again that browsers are different than the W3C specification writes.
> Either intentionally or not.

This comment tickled me the wrong way. I think this _is_ a problem.
A website that validates well is more future proof. If there is any website in the world that should be future proof it is Wikipedia which runs on MediaWiki.

I find validators an invaluable tool for
1) Finding and locating silly errors that might go amiss e.g. unclosed tags and preventing silly browser quirks that might result from them.
2) Promoting better professionalism amongst a young developer community. If a developer sees an align attribute for example they might decide to use that rather than styling.

Any errors that show up in a validator run the risk of masking more serious errors.

Note that also a page that parses better loads quicker - http://ejohn.org/blog/javascript-performance-stack/

I think MediaWiki's failure to validate is one of many "broken windows" I see in the MediaWiki software that should be addressed.

I've got access to the wiki, and requested information to put on the wiki from Roan and Timo by email. Neither has haven't provided the information needed as far as I know, so I've given up after that.

This is the needed info:
1. Brief description
2. Link to specification

I've made a simple spec at https://www.mediawiki.org/wiki/ResourceLoader/ResourceLoaderDynamicStyles_specification , and I'm trying to request access to the whatwg wiki now.

Registered at http://wiki.whatwg.org/wiki/MetaExtensions

This part now validates, though there are other issues (being worked on at bug 62885).