Re: [CSS21] Are vendor-specific extensions invalid?

Patrick Garies wrote:
> 
> Christof Hoeke wrote:
>>  ... problem is that validating real-world stylesheets might contain
>>  properties which are available in most browsers (and are useful too)
>>  but which are not (yet) defined in CSS 2.1. I am not quite sure if
>>  that example still holds but display: inline-block is AFAIK not in
>>  CSS 2.1 but very useful (I am not even talking about vendor specific
>>  props like moz-opacioty etc).
> 
> |display: inline-block| has been in CSS2.1 for awhile now.

I did not check but I think there are quite a few properties working in 
browsers which are not in any spec yet (is opacity in 2.1 yet?). Anyway, 
there will be always new properties coming which are first implemented 
and then spec'ed (which is a good thing though as it uses CSS forward 
compatibility)

> Christof Hoeke wrote:
>>  IMHO a strict CSS 2.1 validator does help almost no one but the CSS
>>  2.1 maintainers ;)
> 
> The W3C’s CSS validator can also do checks against CSS3 and other 
> “profiles”. Flagging properties (as an error or otherwise) with a vendor 
> extension is still useful when the code is peer‐reviewed, at least, with 
> properties like |-moz-opacity| which are virtually obsolete (and should 
> be replaced with the CSS3 |opacity| property).

-moz-opacity was just an example

> As you proposed, flagging properties with a vendor extension as warnings 
> (or maybe informative notices) instead of errors might be a good idea 
> though. New profiles or an option could also be created (e.g., “CSS3 
> with Vendor Extensions” or an “Allow Vendor Extensions” check box). None 
> of this would help with properties that lack vendor extensions though.

vendor extensions allowed option is great.

> Christof Hoeke wrote:
>>  If I want to say to a customer "I use valid CSS 2.1" I am severely
>>  limited, most of the times I have to use invalid CSS 2.1.
> 
> I’m a bit curious as to which properties you “severely” need (aside from 
> ones that can be placed within conditional comments).

I don't want to start the discussion how to write x-browser CSS ;)
Just in short: Wether CSS hacks (just "valid" ones like e.g. c\olor) or 
conditional comments are used is another question. For my part I prefer 
a single CSS where I do not have to change the HTML and add more than 
one HTTP request for styles to my page. Still there are properties (like 
opacity you mentioned above) which are defined in CSS 3 (more or less as 
it is not a recommendation yet, is it?) but not in 2.1 (and adding more 
properties or values should probably rise the version number anyway.

> Christof Hoeke wrote:
>>  I guess a similar discussion takes place with HTML/XHTML. It just is
>>  not as difficult (anymore) as there are only very few elements not
>>  valid (but wellformed) like e.g. <embed> (which still may be replaced
>>  with valid constructs).
> 
> I know that there are well‐formedness checkers for XML (and, thus, 
> XHTML) out there (e.g., see <http://www.validome.org/xml/>). I don’t 
> think that I’ve ever seen an HTML 4.01 well‐formedness checker though.

see my other post how I would defined well-formed for CSS which is 
possible and reasobly I think


> Christof Hoeke wrote:
>>  I won't say the validator is not useful but it would be a greater
>>  help if it also could just check if my CSS is wellformed (or is this
>>  actually possible?).
> 
> I looked at the W3C’s CSS validator and it doesn’t look like it. I’m not 
> sure how useful it would be though since it wouldn’t test for 
> unrecognized declarations. I also don’t know that things like 
> Microsoft’s |filter| property or those that use their |expression()| 
> value would even pass a well‐formedness check.

I have not checked fully but I think they should be "well-formed" as 
they generally are just a FUNC token with content.


christof

Received on Monday, 28 July 2008 10:30:12 UTC