Pre-fix the web: Webkit-only solutions hurts the open web

http://codepo8.github.com/prefix-the-web/

by dave1010uk • 14 years ago

81 57 14 years ago

codepo8.github.com

jakubw• 14 years ago

One way to quickly find code that uses -webkit- only CSS properties is to use the GitHub's code search with queries like: language: css +"-webkit-" -"-moz-".

___Calv_Dee___2• 14 years ago

While it's important to support cross-browser compatibility, it is equally important to deliver to the user the possible design experience. Unfortunately, this may come as a loss to the functionality of non-supporting browsers but I think in the end, it's worth it. Of course we should strive to enforce compatibility but not at the expense of creating a design of lesser-quality (as a result of being wrapped in cross-browser compatibility).

gcp4• 14 years ago

If the user visits your site with an unsupported browser (which in this case may actually perfectly support the features you want), (s)he's going to have a terrible experience and see a crappy design.

So I think you undermined your own argument completely.

___Calv_Dee___2• 14 years ago

I think I presented a trade-off rather than undermining my own argument although I didn't really clarify that I guess.

Essentially you either focus 100% to design and implementing the design via any available technologies (cross-compatible or not) or settle for 80% (20% loss of design and vision from effort in ensuring compatibility).

Ultimately it depends how passionate you are about your design. Personally I would rather have 5 people absolutely fall in love with and be moved by my design/interface/experience rather than 100 people being able to simply 'view' it.

politician3• 14 years ago

Is it possible to single out a specific browser to provide an enhanced experience? Yes. Is it possible to deliver a lowest common denominator experience to mobile browsers and IE? Yes. Are these options mutually exclusive? No.

Your perspectives are not incompatible.

dmethvin5• 14 years ago

Prefixing just did not work. We should push the standards bodies to drop that nonsense ASAP.

Making all of us blindly insert 5 or 6 duplicate declarations in every CSS rule is not a solution, and in fact circumvents the original purpose of prefixing--you're assuming that all vendors implement the feature identically, in which case why prefix at all?

The W3C meeting discussion on this was very depressing. Rather than trying to collaborate on standards that move the web forward, Webkit contributors want to get a leg up with proprietary extensions and make the others struggle to catch up.

   tantek: I think if you're working on open standards, you should propose
           your features before you implement them and discuss that here.
   smfr: We can't do that.
   sylvaing: We can't do that either.
   tantek: We're going to push you to do that sooner and sooner.
   jdaggett: If you're proposing something that's going to be put on a Web
             page, how is that proprietary?

http://lists.w3.org/Archives/Public/www-style/2012Feb/0313.h...

And we've just started this developer nightmare; right now it's mainly focused on CSS prefixing. Thanks to Apple refusing to share its touch patents, the W3C is stalled on touch event standards as well.

macspoofing• 14 years ago

>Making all of us blindly insert 5 or 6 duplicate declarations in every CSS rule is not a solution

No, it's not, but it isn't going away. Designers and Web Developers want to do more than current standards (and browser implementations) allow for.

rmc• 14 years ago

Making all of us blindly insert 5 or 6 duplicate declarations in every CSS rule is not a solution

A lot of the new CSS stuff doesn't require the vendor prefixes, since those vendors now support the prefix-less version. So you don't need to go "-webkit-border-radius: … -moz-border-radius: …", instead do "border-radius: …". We're at the stage where we need less CSS declarations.

The problem is that some sites only have "-webkit-border-radius:…". They should just drop the "-webkit-".

dmethvin5• 14 years ago

"A lot" isn't really true, here is some quantification:

https://wiki.mozilla.org/Platform/Layout/CSS_Compatibility

Long-standing ones like border-radius are unprefixed but most of the recent ones like transition are not.

And the overhanging problem for non-Webkit vendors is that all that legacy content out there prefixed with -webkit- isn't likely to be fixed until their next design iteration, if ever.

bonzoesc2• 14 years ago

Prefixing just did not work. We should push the standards bodies to drop that nonsense ASAP.

In case they don't implement the feature identically, which allows browser makers to experiment and find the right way to do it.

Prefixing isn't a function of the standards bodies, it's a function of browsers that want to implement stuff without worrying about peoples' experiments doing something stupid when the standards body picks the same property name but with different semantics.

edit: here's a scary thought, what if standards bodies picked Microsoft's version of CSS Transforms back in the '90s:

  #myObject {
     filter: progid:DXImageTransform.Microsoft.Matrix(sizingMethod='auto expand',
          M11=1.5320888862379554, M12=-1.2855752193730787,
          M21=1.2855752193730796, M22=1.5320888862379558);
  }

wwweston2• 14 years ago

"In case they don't implement the feature identically, which allows browser makers to experiment and find the right way to do it."

Maybe the right thing to do here is make the prefix optional. That is, let webkit/gecko/ie/etc recognize -webkit/-moz/-ms/-etc prefixes just in case you need to invoke a rule differently for a special snowflake case, but let the non-prefixed rule work when a prefixed rule hasn't been specified.

MatthewPhillips3• 14 years ago

You only need to use prefixes on experimental not-yet-standard features. When the feature is standardized the prefixes are dropped.

If you want to only support standardized features then only support standardized features. That's a decision for individual developers to make. What you are proposing is to strip developers of the ability to test out non-standard features.

huxley2• 14 years ago

Agreed. I'm concerned that this backlash will also slow the adoption of CSS3 features back to the glacial pace we saw with CSS2.x

dmethvin5• 14 years ago

> When the feature is standardized the prefixes are dropped.

More accurately, when the feature is standardized most browsers recognize both the the prefixed and unprefixed versions. This is still a significant competitive advantage for Webkit since there will be a lot of legacy content out there that uses only the -webkit prefixed name. This situation is an incentive for Webkit contributors Apple and Google to delay disclosure and standardization of these features as long as possible, and the W3C discussion above indicates they are doing just that.

> What you are proposing is to strip developers of the ability to test out non-standard features.

If it's only the developers we're inconveniencing, then sure let's have the W3C dictate that prefixed features are available in preview/beta/canary builds but disabled in builds intended for non-developer release. That would create some healthy pressure to get things standardized quickly, eh?

> If you want to only support standardized features then only support standardized features.

Once something is available to the public, developers will use it and often with good reason. That's where prefixes are most destructive. If Chrome comes out with a -webkit-sparkle property tomorrow, advocates of prefixes would have you add -moz-sparkle, -o-sparkle, -ms-sparkle, and plain old sparkle immediately just in case it becomes a standard. Nuts! It would be better for non-Webkit browsers if we just started with plain old sparkle so that legacy content would not be forever broken to them.

chc• 14 years ago

If we allowed the W3C to become a bottleneck like you propose rather than a seal of approval like it is in practice, we wouldn't have CSS transitions in any browser this decade, we wouldn't have AJAX, we wouldn't have canvas, etc. It would be really nice if things could work the way you want, but history has shown time and again that if progress in Web standards is going to proceed at a reasonable pace, it is almost always implemented as a proof-of-concept and then standardized once its utility is recognized. This back-and-forth between shipping code and the standards bodies has evolved as part of the process.

And contrary to your claim that prefixes are just applied blindly, some CSS features have indeed been implemented differently by different browsers — gradients and the flexible box model, to name just a couple. Prefixing is the only reliable way to get the feature before the W3C actually produces a standard with it 10-15 years down the road (I wish that was hyperbole, but it isn't — just look at how long they plugged away at XHTML 2 with no end in sight before everybody got tired of waiting and started implementing HTML5). The point of prefixes is to ensure that the W3C are never faced with a choice between standardizing a CSS feature against their will and breaking the Web.

Although I don't like the bloat from an ideological standpoint, in practice this is the best way we've come up with. But to make reading, writing and maintenance easier, I generally like using a CSS metalanguage with a library like SASS+Compass or Stylus+Nib. That way, you can just write, say, "transition: color .5s linear" and it'll get translated into the appropriate cross-browser code.

ugh• 14 years ago

The alternative – no prefixes – is even more horrible. That would be chaos and disaster.

Webkit’s might is the problem here. Dropping prefixes without having some alternative solution in place is definitely not the solution. That’s why it’s a hard problem.

blibble3• 14 years ago

the comparison between IE6 and Webkit is unfair: Webkit is completely open-source and under active development, whereas IE6 was propriety and dead.

as a pragmatist I don't see it as an bad thing if Webkit becomes close to 100% of the browser market...

dmethvin5• 14 years ago

Because, hey, monopoly and monoculture, what could possibly go wrong?

If Webkit's codebase defines the "standard" then the decision-making process is no longer open, even if the source code (eventually) is. It is controlled by a small number of people, primarily at Google and Apple, who have their existing products and product plans to consider when adding features and changing behavior.

Think about what that means if you are trying to compete with those two. Forget trying to create a competing code base, they control like 90% of the existing mobile web. But even if you adopt Webkit you're at a huge disadvantage because they're months ahead--you can't just fork the code and go your own way, you also have to adopt whatever they include later because it's the standard.

blibble3• 14 years ago

as a pragmatist, I really don't care.

the W3C is completely ineffective.

I kinda wish Gecko and Trident would die, as it would make my life a lot easier (no more silly compatibility libraries, testing in 5 different engines, etc).

what's stopping Mozilla from forking Webkit? remember that Webkit itself was a fork of KHTML...

khuey3• 14 years ago

And what happens when somebody discovers a zero-day security flaw in Webkit then? Even benign monoculture is bad for the web.

batista3• 14 years ago

So what? Then the exploit will work with 100% of browsers instead of, say, 40% as it is now.

Not that much of a difference...

cbs• 14 years ago

IE6 was propriety and dead.

I don't think either propriety vs opensource or dead vs active development are important to the overall question of "is standardizing on a single implementation a bad idea?"

Yes, the fact it had dropped out of active development made it worse to standardize on, but it was already a bad idea.

The same goes for open source. Yes, it can be forked to get away from something bad, but if only one browser/engine becomes standardized on by users and developers, then that engine's team has complete control over what the web becomes regardless of competing implementations are doing.

It creates a HUGE hurdle to pull the web in another direction. People weren't "stuck" with IE6 because it wasn't opensource, they were stuck because the distributor wasn't releasing new versions that also did what the competing products wanted supported.

mileszs• 14 years ago

Internet Explorer 6 was released in 2001. I realize this is not central to the article, but "A lot of products were made in the end 90s that only worked in Internet Explorer 6" bothered me. Perhaps it simply made me feel old, but I'd like to think its some sort of noble sense of historical correctness.

sp332• 14 years ago

Can't we just convince devs to not use prefixed code? That stuff is experimental, it is guaranteed to break in the future. I know it's hard, but wait for the standard to be standardized, or realize that every time you type "-webkit-" you're making a commitment to fixing your site at some point in the future.

khuey3• 14 years ago

Except it's not guaranteed to break, because vendors aren't consistent about dropping prefixes.

condiment• 14 years ago

I don't understand the argument against having to revisit the site and fix it in the future.

Web design takes place from the standpoint of what is possible to accomplish with the most-supported features. From that starting point, vendor prefixes only allow developers to improve their product for users of more modern browsers, and in doing so, place a vote of support for the rapid completion of the prefixed feature.

If you decline to use "-webkit-", you put your website at a disadvantage compared to others that do use the prefix, and you still have to return to the site at some point in the future in order to implement the feature once it's widely supported.

I suppose there's an argument to be made for saving a little bit of hassle in the present time, but that's highly situational and since CSS is so easy I don't think it holds muster.

eli2• 14 years ago

OK, so it breaks and my corners go back to not being properly rounded. I can live with that.

jorisw• 14 years ago

So where are all these sites with only -webkit- prefixed CSS? I don't know any.

gcp4• 14 years ago

Try impersonating the UA of a mobile device. This is where the competition nowadays happens.

tomjen32• 14 years ago

The entire prefix thing is just silly. Do whatever the standard say it should do and be done with it.

eli2• 14 years ago

So... one should never use features that aren't already in the standard?

Sure, that's one approach. But what if you want one of those features?

EGreg• 14 years ago

The browser makers should always be compatible with the standard, the new features shouldn't break the expectations of web page creators which they get after reading the standard. http://www.quirksmode.org/

angersock• 14 years ago

Spoken like someone who probably has never had to deal with vendor extensions to OpenGL... :(

Try to fix your standards body and get them to move faster!

tomjen32• 14 years ago

Honestly I put in css which _does the very same thing_ for each of the major browsers and then once more with no prefix.

So standardize it already. It is a defactor standard, so why haven't the standard organizations made it yet?

politician3• 14 years ago

Can't we just have type="text/css' and type="text/css+webkit"? Wouldn't utilizing MIME types solve this problem for all parties? W3C can continue to be ineffective without vendors subverting its control. Vendors get a namespace in which to stick their ill-thought experiments. Developers get to isolate vendor-specific CSS away from the standard stuff.

edit: clarification, hopefully

dmethvin5• 14 years ago

If the browsers available to the general public support vendor-specific sheets, the problem won't be solved at all. At some point Firefox and IE will see that there are a lot of pages out there on the web written with "text/css+webkit" and start to interpret them in order to compete. This is the same problem they are faced with today through "-webkit-".

politician3• 14 years ago

Are you saying that Firefox interprets -webkit- styles? If that's the case then there is no way of solving this problem because the browsers are subverting what is essentially a dependency injection process.

ori_b• 14 years ago

The problem is that using prefix-less names means that it needs to be standardized before any experimentation can be done.

Standards that get ratified before any experimental implementations exist tend to be horrible.

huxley2• 14 years ago

According to Mozilla's own research[1]:

  how many sites in your mobile Webkit browser crawl use at least one of 'transition', 'transition-timing-function', 'transition-duration', 'transition-property', 'transition-delay' (ignoring prefixes)?
  1245 / 30087 = 4.13%

  how many use them only with -webkit prefixes (no -moz or unprefixed versions of the properties)?
  336 / 30087 = 1.12%

  how many use them only with -webkit prefixes and unprefixed (no -moz versions of the properties)?
  365 / 30087 = 1.21%

Is it really that serious an issue if it only crops up in 1.12% of mobile sites (where webkit has the overwhelming marketshare).

[1] https://wiki.mozilla.org/Platform/Layout/CSS_Compatibility#D...

starwed• 14 years ago

For a long time, reddit's mobile interface was broken in anything other than webkit, entirely because of a single -webkit CSS rule they were using to display the voting arrows.

If just a few really popular sites have broken mobile sites because of this, that's a big problem!

halayli• 14 years ago

The point behind prefix was to support experimental CSS features and the prefix gets dropped once it's out. This is not Webkit specific, other browsers do the same. It's a pretty bad idea indeed, but I am not sure why you are pointing at webkit only.

Pre-fix the web: Webkit-only solutions hurts the open web

Related Stories