Last modified: 2008-04-16 10:58:21 UTC
There is invalid CSS in the Monobook main.css file, The online validation service gives the following for CSS 3: 1454 div.multipageimagenavbox Property -moz-border-radius doesn't exist : 6px Validating against CSS 2.1, gives: 1122 * > html #bodyContent, * > html #bodyContent pre Property overflow-x doesn't exist in CSS level 2.1 but exists in [css3] : auto 1446 div#searchTargetHide Value Error : background Too many values or values are not recognized : gainsboro 1454 div.multipageimagenavbox Property -moz-border-radius doesn't exist : 6px I'm not too aggrieved that MediaWiki is trying to push browsers towards the CSS 3 standard (though it's a bit ambitious and causes Opera to moan), but I am very disappointed that it is including proprietary browser extensions in a site-wide file. Things to fix: Remove -moz-border-radius Replace Gainsboro with #DCDCDC (Possibly remove Overflow-x: rule, I don't know anything about it)
I removed the non-standard color name in r33059. Actually, that was probably pointless. It's in CSS 3 and is universally supported. But honestly, I have no idea WTF color is "gainsboro", so the number is probably saner anyway. :) -moz-border-radius is not a proprietary property, it's an experimental implementation of a totally standard property. There's nothing at all wrong with using it. It's explicitly permitted by the standard and is good practice if it works correctly. The standard discourages use of vendor extensions, but that's probably intended to mean totally vendor-specific stuff, not experimental implementations of actual CSS properties -- provided the real CSS properties are used too. However, if we have it, we should really have an accompanying border-radius rule, like: border-radius: 6px; -moz-border-radius: 6px; I'm leaving this open because I'm not sure whether to remove -moz-border-radius or add a matching border-radius statement.
Re: -moz-border-radius 1) It actually IS proprietary property, since it is not part of any version of CSS and because of #3. But it should rather be called vendor-specific extension according to CSS specification. 2) However, it is valid CSS property, since the specification [1] says identifiers beginning with dash or underscore are reserved for vendor-specific extensions. It's known issue W3C CSS validator currently does not support vendor-specific extensions as valid properties. 3) It is not compatible with the CSS3 standard version since it does not have the same behavior as standard CSS3 border-radius property. 4) Speaking about vendor-specific extensions, we should also mention similar property for Webkit based browsers named -webkit-border-radius. However I would strongly discourage using of vendor-specific extensions and parts of CSS3 which are not widely supported yet in core stylesheets. Because the aim should be to have the page look as much similar as possible in any browser. Rounded corners and other CSS3 properties or vendor-specific extensions might be added eg. via Gadgets extension by adding specific stylesheet. [1] http://www.w3.org/TR/CSS21/syndata.html#vendor-keywords
(In reply to comment #2) > 1) It actually IS proprietary property, since it is not part of any version of > CSS and because of #3. But it should rather be called vendor-specific extension > according to CSS specification. It's not "proprietary" in the sense of being owned by anyone. It's only implemented by one vendor, and is therefore vendor-specific. > 3) It is not compatible with the CSS3 standard version since it does not have > the same behavior as standard CSS3 border-radius property. If that's the case, then the best thing might be to remove it. I have no opinion, can anyone give screenshots or something? > However I would strongly discourage using of vendor-specific extensions and > parts of CSS3 which are not widely supported yet in core stylesheets. Because > the aim should be to have the page look as much similar as possible in any > browser. Things already look significantly different in different browsers. Quite a few things have never worked in IE, for instance (media-specific external link icons, for instance). We shouldn't sacrifice visual quality or utility in one browser because others don't support some feature or other; we just need graceful degradation.
As discussed above, the issues outlined aren't actually bad CSS. I just ran the live enwiki through their validator, and the only errors that came up were due to either A) Known quirks in the program, such as not recognizing vendor-specific CSS B) CSS3 (if checking against 2. Checking against 3 removes the CSS3-related ones) No actual errors were found. http://jigsaw.w3.org/css-validator/validator?uri=http%3A%2F%2Fen.wikipedia.org%2Fwiki%2FMain_Page&profile=css3&usermedium=all&warning=2&lang=en
