Make vector skin standards compliant (CSS/HTML)
Closed, DeclinedPublic
Actions

Assigned To

Authored By

	APPER
	Mar 31 2010, 2:51 AM

Description

Standards compliance is one of the most important things for a free project. Monobook was compliant, vector not - so this is step backwords :/

When monobook introduced in 2004 there where few standard compliant pages - this got better and now that even IE gets more standards compliant, we will have an erroneous page? Not good!

HTML seems to be okay. There is only one issue and it seems to be related with flagged reversions, because it's only on de.wikipedia and not en.wikipedia. There you'll find the div with id "p-variants", which contains an empty ul element, which is not allowed.

But there are a lot of CSS errors, which floods my error console. Mostly this is because of browser specific CSS. I really don't know why these are necessary. The site has to work without these, so they are only for "better look". I don't see this is required. If a browser doesn't support alpha transparency via opacity - is it really needed to use filter then?

But which is the funniest thing of all is, that you ONLY use browser specific CSS: -moz-border-radius: sure, border-radius: nowhere. Why -ms-box-sizing but not box-sizing? I don't really understand this.

Another thing is the use of "cursor:ew-resize;". This is marked as "features at risk" in the standard, because it doesn't make much sense and could be dropped in future (the CSS3 validator doesn't know it). Why don't you use "cursor:e-resize;"? The browsers supporting "ew-resize" handle it the same like "e-resize" but there are browsers not supporting "ew-resize" but "e-resize" (IE and Opera).

I think you never validated the CSS? Please try this and have a look, if you are at least also using the standard compliant variant. For example all border-radius-things doesn't work at the moment in Opera and IE9 because of this - but both have much better (more complete) implementations of this than Firefox, which is supported via -moz-border-radius...

Version: unspecified
Severity: minor

Details

Reference: bz23015

Related Objects

Duplicates Merged Here: T25610: Empty portlets in Vector make invalid XHTML markup
T25575: Vector is invalid XHTML (empty UL elements)
T30777: Vector skin causes all Wikipedia pages to fail W3C validation
T26500: Do not output empty portlets

Event Timeline

• bzimport raised the priority of this task from to Lowest.Nov 21 2014, 11:06 PM

• bzimport added a project: MediaWiki-User-Interface.

• bzimport set Reference to bz23015.

APPER created this task.Mar 31 2010, 2:51 AM

Vector's CSS does not use any of the rules you are mentioning. Rules like "-moz-border-radius", "cursor:e-resize" and "-ms-box-sizing" are being used by jQuery UI, so perhaps you should take your plight up with them.

As for validation - fair enough, Vector has some errors, but Monobook does too.

Monobook's CSS
http://jigsaw.w3.org/css-validator/validator?uri=http%3A%2F%2Fbits.wikimedia.org%2Fskins-1.5%2Fmonobook%2Fmain.css%3F257z45&profile=css21&usermedium=all&warning=1&lang=en

Vector's CSS
http://jigsaw.w3.org/css-validator/validator?uri=http%3A%2F%2Fbits.wikimedia.org%2Fskins-1.5%2Fvector%2Fmain-ltr.css%3F257z45&profile=css21&usermedium=all&warning=1&lang=en

I think it's reasonable to suggest that these errors be investigated, but your approach here seems to be intended to start a fight rather than suggest a patch.

Furthermore, Vector accomplishes significant cross browser compatibility, even down to IE 5.5 - and it does it with a single CSS file being sent to the client which is smaller than Monobook's main.css file which then must be supplemented with additional CSS files on various browsers - making Vector lighter weight in both size and request load. The CSS is more modular, the layout is more consistent (read not broken) in right-to-left mode, and it looks exactly the same on all browsers, which Monobook does not.

I will leave this open until Vector's main-[ltr|rtl].css files pass validation without errors.

Thank you for your reply.

The one error in monobook's css is because you checked against CSS 2.1 - it's CSS 3. It's without errors if you check it against CSS 3:

http://jigsaw.w3.org/css-validator/validator?uri=http%3A%2F%2Fbits.wikimedia.org%2Fskins-1.5%2Fmonobook%2Fmain.css%3F257z45&profile=css3&usermedium=all&warning=1

But you are right: in the main-ltr.css are only three errors, all because of -moz-any-link, which is okay, I think.

I was aware of the errors in the jquery library and didn't meant them. I meant the file
http://bits.wikimedia.org/w/extensions/UsabilityInitiative/css/combined.min.css?77a

This comes with vector - but seems not to be part of the skin. So what's the correct Product/Component for this here in bugzilla?

And of course the HTML error: The empty <ul> element. I just realized, that this is only the fact, if you are logged in (and maybe you need the right "sighter"). I think this is a vector issue.

I committed r64426 just now, which corrects the empty <ul> issue. Thankyou for reporting that - I've heard about it before but never got around to taking any action on it.

combined.min.css is not part of the skin, but it is used by some of the skin-related extension called Vector and the editing related extension WikiEditor. You are seeing CSS which is used together with jQuery UI in there, and the use of jQuery UI here has to do specifically with our editing tools making use of jQuery UI's Dialog and Draggable modules.

The proper extension to report this sort of thing to would thus be the UsabilityInitiative extension, which contains both the Vector and WikiEditor extensions.

(In reply to comment #3)

I committed r64426 just now, which corrects the empty <ul> issue. Thankyou for
reporting that - I've heard about it before but never got around to taking any
action on it.

Reverted, broke CollapsibleTabs. See also discussion at bug 23575 for why this is invalid XHTML 1 but valid HTML 5.

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

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

If we really want to serve valid XHTML 1 without breaking lots of scripts that assume that the <ul>s are there, I suppose we could always insert a dummy <li style="display:none"> there. It would feel rather silly, but then again, it's a silly requirement.

ayg wrote:

We could either fix the script that broke (which should be just a few lines), or forget about XHTML 1 Transitional. Either way is fine with me.

It's not just one script, though. There are at least two (CollapsibleTabs and addPortletLink), and I know of several site/user scripts that would probably also be affected. We could do it if we had to (one reason why I originally introduced addPortletLink was to make such fixes easier by encouraging script authors to use it instead of rolling their own) but I'd rather not do it just to comply with a pointless requirement in an old standard that no-one actually relies on.