A LIST Apart: For People Who Make Websites

No. 309

Discuss: Prefix or Posthack

Pages

 1 2 3 >  Last »

1 Support -beta-* as a prefix for properties in draf

The solution seems simple, there are 3 kinds of properties in CSS:

1. Proposed (not present in any staandard)
2. Draft (in a draft standard)
3. Recommended (in a recommended standard)

Correspondingly, there should be 3 levels of support:

1. Implementation to vendor proposal (e.g. -moz-border-radius)
2. Implementation to draft standard (e.g. -beta-border-radius)
3. Implementation to recommended standard (e.g. border-radius)

Vendor prefixes already exist, and they’re as brittle as the article explains – and it’s right that they should be. Anyone who uses them knows they’re playing to the vendor’s whim. However, once there is agreement on how a particular property should work, this (draft) functionality should be made available in a consistent way.

The easiest way (in my opinion) is to agree on a reserved vendor prefix, beta or draft, and then each vendor can either map this to their vendor implementation (if it matches) or to a new implementation (which they would have to implement in any case, at least before the standard was agreed).

Of course, a beta prefixed property may still change its behaviour if the draft spec is revised, but then by using a beta prefix in your CSS you would understand that.

posted at 09:29 am on July 6, 2010 by kyangareth

2 Oops

Excuse the formatting, the preview window didn’t show my – hyphen-surrounded-text – with the strikethrough

posted at 09:32 am on July 6, 2010 by kyangareth

3

Great explanation of why beta prefix would be a step backward. I love your idea regarding the vendors being required to add a prefix for any new implementation, thus giving them time to work out bugs and get real feedback from developers and the Working Group.

Something I’ve been wondering, though, is should we always include the non-prefix version for future-proofing? Since we can’t predict whose implementation will become standardized couldn’t this lead to undesired results in the future?

posted at 09:40 am on July 6, 2010 by ryanswedal

4 A must read

Even big names in our industry questions the value of prefixes. I wrote a piece about this in March, but Eric Meyer says it so much better than I could.

I am also very glad to see that Eric addresses the fact that vendor prefixes never should be the last rules. Something that most authors seem to get wrong. (Incidentally, I’ve written about this as well)

posted at 09:50 am on July 6, 2010 by Lars Gunther

5 Not a big pain

If you’re ending up using vendor prefixes for rounded corners more than once in your CSS, then you’re probably doing something wrong.

Just create a class for rounded corners and apply it in your HTML document. ie:

.rc{ -webkit-border-radius: 5px; -khtml-border-radius: 5px; -moz-border-radius: 5px; border-radius: 5px;
}

This approach will let you modify all the rounded corners in your site in one place. Also using .rc in your markup will let you modify all the rounded cornered elements w/ JavaScript (for older browsers).

posted at 10:09 am on July 6, 2010 by gercheq

6

@gercheq
Wrong. More CSS is better than more markup. Reduces traffic and keeps presentational stuff out of your HTML.

@Topic
I’ve not read the entire article yet but this seems to be the first really absurd proposal to be published on ALA. More browser specific code and proprietary stuff? You must be kidding, Eric!

posted at 10:22 am on July 6, 2010 by Florian Schmitt

7 SASS

I’m a programmer who has to do CSS on occasion. I find that using meta-languages like SASS or Less make handling this ‘prefix explosion’ a lot easier.

I’ve created mixins for CSS3 functions where I only need to pass in a single line of code, e.g. +border_radius( 10px ), and the mixin handles all the browser-specific code necessary for that functionality. If anything should ever change, I change it once and all the rules change automatically.

This may be to “programmery”. I work with 4 designers and none of them are interested in learning meta-languages, even though for me, it cuts down on code-duplication, errors immensely.

http://sass-lang.com/

posted at 11:15 am on July 6, 2010 by bbttxu

8

Thanks for this post Eric, I was a little perplexed by Aaron’s article referring to the vendor prefixes as hacks and I think your article has more than rectified the confusion surrounding the use of them. Bruce Lawson also explains their use http://bit.ly/c1lMbu on his personal site.
@Florian – It is not absurd, if you read the article it explains it sublimely.

posted at 11:18 am on July 6, 2010 by lewismc

9 Using the unprefixed version

ryanswedal, I would say that in any case where the value syntaxes of all the vendor-prefixed properties yield the same results, add the unprefixed version at the end of the list. In a case where I have to write different values for different prefixed versions to get a consistent result but I was determined to use them anyway, I’d probably leave off the unprefixed property at the end because the inconsistencies in the prefixed properties means there’s a higher-than-usual chance of the specification having to change.

I absolutely recommend listing the unprefixed property last whenever you have it, of course. That leverages the cascade to future-proof your CSS as best you can.

posted at 11:35 am on July 6, 2010 by Eric Meyer

10 beta prefixing

kyangareth, as I explained in the article, I disagree that -beta- (or -w3c- or any other unified prefix) is a good idea. From an author’s point of view, it’s literally no better than not having any prefixes at all. From an implementor’s point of view it’s a little better than no prefixes, but not much; it becomes more difficult to quarantine the ill effects of a bad implementation.

posted at 11:39 am on July 6, 2010 by Eric Meyer

Pages

 1 2 3 >  Last »

Got something to say?

Discuss this article. We reserve the right to delete flames, trolls, and wood nymphs.

Create a new account or sign in below if you’d like to leave a comment.

Remember me

Forgot your password?

Subscribe to this article's comments: RSS (what’s this?)