[thelist] [css-d] Vendor prefixes and validation

Barney Carroll barney.carroll at gmail.com
Tue Dec 21 10:33:58 CST 2010


>
> Alan,
>>
>> Vendor prefixes are traditionally used to implement proprietary or
>> experimental features.
>>
>
> Yes, I acknowledge that but this transitional approach has held back web
> designers and developers for years.


Subjectively disagree. I think the prefix mechanism is very useful for
separating "as far as we're concerned this is fully-functional and ready for
the wild" from "still in dev — please experiment but only if you know you're
experimenting".


> The idea is that bleeding-edge tech won't be
>> triggered by valid CSS — it must be triggered intentionally with custom
>> CSS.
>>
>
> I don't quite follow what you are saying here.


Yeah that doesn't read too clearly — sorry. What I mean is, as far as
practically possible, the front-ender should be able to code CSS as per the
spec without getting any beta functionality leaping out of their creations
as new browser releases come about. If they're aware that the technology is
still in development, they can bite the bullet and use the prefixed
properties.


> We now have all implementations supporting all the CSS3 properties that I
> demo'd . I would please appreciate a check in FF4 beta if anyone has it.
>

Awesome stuff. If it works, that's the vendor's decision — knock it out of
beta, and bind the functionality to the non-prefixed CSS properties.


> It's time now to drop the prefixes. Now if you wish to debate this, then
> please feel most welcome to subscribe to the CSS WG list. Not that you will
> stop anything.


:(


> Yes it does. Check the latest drafts [1]
>

Draft means beta in my book. Vendor prefix. This goes back to my subjective
disagreement as to what the whole point of a division between dev/release
code syntaxes.


> About that slash "/". I was the one that proposed it to the CSS WG list
> since it was only parsed by I think Opera 9.0 (and earlier) and IE5.5. I
> proposed it as a means to introduce a fall back background-color but during
> my time away from the WG list, it developed into it current use.


Interesting!


>  The same goes for WebKit&  Gecko's different syntax choices for
>> border-radius — because you are specifically invoking different
>> implementations, the ability to use vendor prefixes comes in really handy:
>> you feed this code which isn't quite as it was intended to the
>> implementation that you know can handle it.
>>
>
> I dare say that you are not aware of border-radius spec from the latest
> draft [3] which also makes use of the "/"
>

No, I wasn't actually. I don't read the drafts too often, and in any case I
treat them as drafts — proposals to be developed; not final. Do you
understand what I mean about premature adoption of drafts, differing syntax
and implementation, and the benefit of having -moz-border-radius and
-webkit-border-radius, since neither implementation gels well into a single
syntax I can reliably use with a single non-prefixed property?


Regards,
Barney Carroll

barney.carroll at gmail.com
07594 506 381


More information about the thelist mailing list