Vendor Tokens

Published 11 years, 10 months past

It may be that from the ashes of vendor prefixes will arise a new way forward.  As proposed by François Remy, vendor tokens would serve the same basic purpose as prefixes with a different syntactical approach, and with at east a couple of extra benefits.  Instead of prefixing properties, you’d instead add vendor tokens to the end of a single declaration, much as you do !important (which of course we never ever use, amirite?).

For example, you might write:

border-radius: 1em !webkit-draft !moz-draft !o-draft;

That’s it.  The prefixed alternative, of course, runs to multiple lines and has spawned a whole subindustry of framework plugins and mixins and what-all just to take the repetitive authoring burden off our shoulders.

I’ve been contemplating this proposal all morning, and perhaps not too surprisingly I’ve come down in favor of the idea.  I’m on record as being a fan of vendor prefixes, but what I was truly a fan of was the capabilities they offer.  The syntax was never a core interest for me, and the ugliness was pretty apparent.  Vendor tokens are less tortuous, and even make it much simpler to build in versioning, like so:

border-radius: 1em !webkit-draft-2 !moz-draft !o-draft;

Not that I’m saying this proposal will or even should get to that point, but the ability is there and it feels cleaner than trying to do the same thing with prefixes.  I feel they ought to drop the -draft part of the tokens; just saying !webkit !moz !o or possibly !x-webkit !x-moz !x-o should be sufficient.  I’m also not a fan of the bang, but then I never have been, and I figure any token marker would suffice.  As before, it’s not the syntax I care about so much as the capabilities.

There is a discussion ongoing at www-style, if you’re interested in adding your perspective or even just following along as various stakeholders thrash at the idea.  I’m cautiously optimistic.  It’s kind of a nice feeling!


Comments (8)

  1. I once mentioned, and I still think it might be appropriate, that since every vendor is proposing an implementation, or if you will, a candidate for the final release, the the single prefix ‘rc-‘ would be appropriate. Then every vendor’s browser would recognise this as what it was and undertake to render their particular release candidate.

    Now some would mention that not all vendors use the same order for parameters, but if they could go that far, it would make our lives a bit simpler.

  2. Poor ole Microsoft gets left in the cold. :-p

    Should the concept of vendor prefixes/tokens be extended to operating systems (in particular for mobile operating systems)? I don’t think I’m alone in having a feature like CSS transitions work on Android, but not on iOS (or vice versa).

  3. Actually, I left out !ms because they’ve been avoiding using prefixes. I just assumed that general policy would continue.

    I don’t know if platform prefixes would be a good idea or not, but they’d certainly be a lot easier to add and use than prefixes.

  4. Change the way a browser parses CSS in order to avoid the workaround code we have to use because we can’t change the way a browser parses CSS? Eh?

  5. Can’t say I’m much enthused as it looks like swapping one ugly for a different one.

  6. Yes, this is cleaner and easier to maintain than the current vendor prefix method. I would prefer not having the redundant “-draft” to keep it as succinct as possible.

  7. What do do when it’s a early adoption of a proposal that changes. I’m looking at you border-radius. -webkit-border-radius had a different shorthand implementation early on than -moz-border-radius. Same goes for background gradients. We would gang different implementations of an experimental implementation with this could we?

    What I DO like is that this would have avoided the whole situation where other vendors are picking up -webkit now. I assume the !webkit would be there just to say you’re passing it off to Webkit during the “experimental” phase, but if others wanted to pick it up, they simply could pick it up off the general property declaration. Is that how it would work?

  8. Never mind. I read the proposal. Same result though. I’m liking it.

    Advantage? Any browser which is not webkit but implemented border-radius in
    a way that is compatible with the “webkit draft” can support the
    declaration. This is different from vendor prefixes: other browsers don’t
    impersonnate webkit, they just acknowledge they support one specific
    property the way the webkit draft defines it. Browsers which are not
    compatible with that draft will just ignore the declaration. Browsers that
    change their implementation of a property are encouraged to iterate their
    “!vendor-draft” flag (using a version number, if appropriate).

Add Your Thoughts

Meyerweb dot com reserves the right to edit or remove any comment, especially when abusive or irrelevant to the topic at hand.

HTML allowed: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <em> <i> <q cite=""> <s> <strong> <pre class=""> <kbd>


if you’re satisfied with it.

Comment Preview