Last modified: 2012-09-27 01:10:57 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T25015, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 23015 - Make vector skin standards compliant (CSS/HTML)
Make vector skin standards compliant (CSS/HTML)
Product: MediaWiki
Classification: Unclassified
Interface (Other open bugs)
All All
: Lowest minor with 1 vote (vote)
: ---
Assigned To: Trevor Parscal
: 23575 23610 28777 (view as bug list)
Depends on:
  Show dependency treegraph
Reported: 2010-03-31 02:51 UTC by Christian Thiele
Modified: 2012-09-27 01:10 UTC (History)
7 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Description Christian Thiele 2010-03-31 02:51:12 UTC
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...
Comment 1 Trevor Parscal 2010-03-31 04:19:22 UTC
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

Vector's CSS

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.
Comment 2 Christian Thiele 2010-03-31 04:59:50 UTC
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:

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

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.
Comment 3 Trevor Parscal 2010-03-31 06:53:39 UTC
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.
Comment 4 Roan Kattouw 2010-05-18 21:49:33 UTC
(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.
Comment 5 Roan Kattouw 2010-05-18 21:49:43 UTC
*** Bug 23575 has been marked as a duplicate of this bug. ***
Comment 6 Roan Kattouw 2010-05-21 15:51:29 UTC
*** Bug 23610 has been marked as a duplicate of this bug. ***
Comment 7 Ilmari Karonen 2010-06-10 23:44:03 UTC
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.
Comment 8 Aryeh Gregor (not reading bugmail, please e-mail directly) 2010-06-11 00:02:40 UTC
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.
Comment 9 Ilmari Karonen 2010-06-11 17:01:48 UTC
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.
Comment 10 Roan Kattouw 2010-07-22 20:01:18 UTC
*** Bug 24500 has been marked as a duplicate of this bug. ***
Comment 11 Bawolff (Brian Wolff) 2011-05-02 05:42:59 UTC
*** Bug 28777 has been marked as a duplicate of this bug. ***

Note You need to log in before you can comment on or make changes to this bug.