meyerweb.com

Skip to: site navigation/presentation
Skip to: Thoughts From Eric

Vendor Tokens

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!

Eight Responses»

    • #1
    • Comment
    • Tue 8 May 2012
    • 1739
    CW Petersen wrote in to say...

    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
    • Comment
    • Tue 8 May 2012
    • 1815
    Brian LePore wrote in to say...

    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
    • Comment
    • Tue 8 May 2012
    • 2102
    Eric Meyer wrote in to say...

    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
    • Comment
    • Wed 9 May 2012
    • 0512
    Schmoo wrote in to say...

    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
    • Comment
    • Wed 9 May 2012
    • 0659
    Pete B wrote in to say...

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

    • #6
    • Comment
    • Thu 10 May 2012
    • 1055
    wafsd wrote in to say...

    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
    • Comment
    • Thu 10 May 2012
    • 1835
    John Lascurettes wrote in to say...

    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
    • Comment
    • Thu 10 May 2012
    • 1837
    John Lascurettes wrote in to say...

    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).

Leave a Comment

Line and paragraph breaks automatic, e-mail address required but never displayed, HTML allowed: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>



Remember to encode character entities if you're posting markup examples! Management reserves the right to edit or remove any comment—especially those that are abusive, irrelevant to the topic at hand, or made by anonymous posters—although honestly, most edits are a matter of fixing mangled markup. Thus the note about encoding your entities. If you're satisfied with what you've written, then go ahead...


May 2012
SMTWTFS
April June
 12345
6789101112
13141516171819
20212223242526
2728293031  

Sidestep

Feeds

Extras