WebKit Isn’t Breaking the Web. You Are

http://www.webmonkey.com/2012/02/webkit-isnt-breaking-the-web-you-are/

by bootload • 14 years ago

89 63 14 years ago

shadowflit• 14 years ago

As an outsider looking in, it seems like the whole prefix thing is approaching the problem from the wrong direction.

Why do we have prefixes at all? Well, because developers want to start using new features before they've been fully standardized. Fine, understandable.

Browser developers make browser specific prefixes available, because you can't expect all browsers to roll out the same new features on the same day. Ok, that's one approach, but I can think of two others.

1) Don't wait for the entire standard to be formalized before expecting it to be implemented. A rolling standard approval process, if you will. It's basically what we have now where new features become available far ahead of the full standard, except prefixes won't be necessary because everyone will implement stuff on a rolling basis. That might be a little demanding of browser developers though, which leads to option 2...

2) Best effort evaluation iff you choose to use non-standardized features. Sort of how python lets you import from future, declare somewhere that you're using non-standardized features. After that, the browser switches to best effort mode, and just throws out any attributes it doesn't understand. When running in a dev environment mode, all these errors would show up, so you can see why things aren't behaving as intended if you're using an unimplemented feature.

jballanc9• 14 years ago

If only it were this simple. The problem is that not only are these implementations not formalized, but also there is often dispute over how they should be standardized. Border radius, for example, is "-webkit-border-bottom-right-radius" in Webkit but "-moz-border-radius-bottomright" in Firefox. If you look at competing ideas for standardizing things like gradients, you'll find even more disagreement. This is why prefixes are needed.

zalew4• 14 years ago

Wouldn't naming conventions solve the problem? f.ex. -{vendor}-{object}-{property}-{positions vertical-horizontal}-{additional}: {some-value-syntax-also}

In the end, everyone would just drop the prefix. Generating parsing it would be also way easier.

batista• 14 years ago

The problem is those are BS differences that in the end don't matter much.

border-bottom-right-radius vs border-radius-bottomright, please.

Either use some consistent way of naming as you do with other properties, or just pick a f*n name and use it.

If it was some real competing ideas on the RENDERING of the visual effect defined by the property, I could understand, but the mere name of css properties is not the place to be creative. Just discuss it for 1 hour with other vendors, come to a name and USE IT.

jballanc9• 14 years ago

The real problem with CSS is that it hasn't evolved. Solutions like SASS/SCSS or LESS resolve this issue quite neatly. Instead of needing to know or look up the peculiar browser-specific declarations for things like border-radius, you simply say "rounded(5px)".

zalew4• 14 years ago

All these solutions are only a wrapper around the real problem, which by all means in the end has to be solved.

jballanc9• 14 years ago

No, the real problem is that CSS (as it currently exists) has no means for abstraction. These approaches solve that.

Take an analogy: in the not too distant past, some microprocessors had divide instructions, others did not, but you didn't see people bracketing division instructions with platform-specific conditionals. For the most part no one cared because if you wrote "x / y" in your code, that was merely an abstraction that some compiler would break down into a series of shifts and adds or a divide, depending on the platform.

azakai4• 14 years ago

It's debatable whether WebKit did or didn't do anything wrong. If vendor prefixes appeared only in developer version of the browser, instead of stable releases, we wouldn't be in this situation - and developers would still get preview access to new browser features for testing, to prepare for when they become standardized.

Instead, the major WebKit browsers include vendor prefixed stuff in stable releases. Since WebKit won in mobile (and is on the way to winning overall), it isn't surprising we got to where we are now, with all other browsers planning to implement WebKit prefixed features.

kalleboo• 14 years ago

If WebKit didn't include vendor prefixes in stable releases, we'd still be here 6 years after they first implemented it putting PNG files in the corners of all our divs.

The problems are the standards aren't there. The standards organization is just way too slow.

TeeWEE3• 14 years ago

I totally agree. W3C is slow. But standards are like politics. You cannot blame W3C for 1 of the 10 parties not agreeing with the spec. And once we got it we are bound to it.

This is the reason native is always better then web. Once the technology is available one party will provide an api and it will be available in the next version of the OS.

Native is a free market approach, may the best man win. But propietary. Web is like socialism. Everybody gets the same but the whole system doesnt drive innovation.

masklinn4• 14 years ago

One of the problems is, vendor prefixes have both "beta" and "proprietary" meanings. And there's no way to disambiguate from the property's name.

And browser vendors will ship proprietary extensions, whether you like it or not.

magicalist• 14 years ago

Mobile Firefox includes vendor prefixes, and has from the beginning. All the new Web API stuff will be prefixed where appropriate. That's exactly what standard operating procedure calls for (whether right or wrong) and what mobile WebKit has mostly done (and we're really talking Apple here, at least for the first year or two and a bunch of major CSS spec drafts).

In other words, you didn't actually say what actions may or may not have been wrong.

azakai4• 14 years ago

Including vendor prefixes in a release build, I said, is arguably wrong. I'm not arguing that it is - I honestly don't know which is better, as not including them has downsides too.

And, as you said, other browsers do this too (but less recently), it isn't a WebKit-specific thing. The only difference is that WebKit won on mobile and has become the dominant web rendering engine there, between Android and iOS (and Blackberry, WebOS, etc. etc., pretty much everyone uses WebKit on mobile).

The only solution to this would be to not have a single implementation dominate the market. But that has already happened on mobile, the question is now how to live with that. (And there is risk on desktop too.)

cheald3• 14 years ago

The problem isn't Webkit, or even web developers targeting webkit. The problem is that we have a de facto standard for rounded corners on the web, and it's still not an accepted standard. The W3C designs and approves CSS draft specs on a schedule that makes IE development cycles look speedy. The web moves faster than that now.

The first CSS3 draft for the backgrounds and borders module was published in 2001. ELEVEN YEARS LATER it's still not a finalized standard. And the problem is developers?

I've been using -moz and -webkit and -o vendor prefixes for years now, with virtually no variation or change. Why don't we have a standardized border-radius yet? By the time the W3C actually settles on a standard, the industry will be twelve draft specs ahead of them in production for all practical purposes.

I really, really dislike the idea of non-webkit vendors implementing support for webkit prefixes. Stick to your own prefixes. Don't break the rules to make up for lazy or bad developers. That's a huge part of why IE was such a pain in our collective asses for so many years. When you coddle lazy or bad developers, you end up breeding an entire crop of developers who end up creating terrible legacy systems that will plague us for years to come. Just say no. If you have to do something, go ahead and implement the draft spec.

Developers: Use Sass or LESS or similar. Start worrying about presentation and stop worrying about implementation. Until the W3C gets its act together, use tools that help you do the right thing with the least amount of effort. Everyone wins.

yuhong• 14 years ago

CSS3 Background and Borders is a candidate recommendation, which means in most recent browsers it can already be used unprefixed.

cheald3• 14 years ago

And it reached that Candidate Recommendation status nearly one year ago, only ten years after it was first introduced.

I'm picking on border-radius because it's an easy target, but the fact remains that large pieces of CSS3 remain in "working draft" statuses. Microsoft went all cowboy and gunked up the web with their "standards be damned, we'll do it live" approach to IE, and since then, other browser vendors have been extremely spec compliant in an attempt to avoid the same sort of mess that IE got us into, but they're hogtied by a standards body that takes longer to work out border-radius than it takes for most web companies to be born, flourish, and die.

azakai4• 14 years ago

> I really, really dislike the idea of non-webkit vendors implementing support for webkit prefixes. Stick to your own prefixes. Don't break the rules to make up for lazy or bad developers.

I sympathize with the sentiment. But you are asking all the non-WebKit browsers to not render the mobile web properly.

Like it or not, WebKit won on mobile. People wrote tons of websites that only render correctly on the iOS and Android browsers.

Other browsers can't change that by not implementing the WebKit prefixes. In fact without implementing them, they make it harder for themselves to gain market share - the only thing that can prevent a single implementation like IE or WebKit from becoming a de-facto standard.

Other browsers can evangelize - go around and ask website makers to write to standards, not to what currently works in WebKit. They are already doing that as much as they can. It isn't making much of a difference.

cageface• 14 years ago

The web is at enough of a disadvantage WRT native apps as it is. If you disallow the kinds of enhancements that depend on a more intimate relationship with the browser, like -webkit prefixes, you put them that much further behind.

zobzu2• 14 years ago

exactly, and that is why webkit (but not only - aka the extensions) are the problem.

if the browser has a large market share people will use it 'wrong' aka not just for experimentation.

its like waving with free candy and blaming people for taking it.

dave1010uk2• 14 years ago

I'm not sure what you mean by "WebKit won on mobile" (maybe you mean in US) but you may be interested to know that the most popular mobile browser is Opera [1]. WebKit still has a majority when you combine iPhone, Android and Nokias but I wouldn't say it's won. The race for the mobile web isn't over yet.

[1] http://www.quirksmode.org/blog/archives/2012/01/browser_stat...

masklinn4• 14 years ago

> But you are asking all the non-WebKit browsers to not render the mobile web properly.

I don't think that's a fair caracterisation. It's perfectly proper to render a mobile site as you're told do, which is what browsers correctly do right now.

TeeWEE3• 14 years ago

The problem to begin with is that browser makers where adding their own baked prefixes. They where not following the spec and opened the door for designers to use them.

My opinion is that final browser builds should not support these prefixes. Its too easy to say that developers are breaking the web. Actually browser makers are. Webkit is the new IE6. Cool features but they are extending the standard with their own baked goodies.

zobzu2• 14 years ago

might be voted down, but that's pretty insightful. just remove the inflamatory "webkit is the new IE6" and its actually very accurate.

jan_g• 14 years ago

I don't think it's accurate at all. Browser vendors aren't 'extending the standard with their own baked goodies', but are merely prefixing those CSS properties that aren't yet finalized, but are part of the standardization process. There's no parallel with IE6 at all, in my opinion.

ugh• 14 years ago

Not following the spec? Using prefixes is following the spec. That’s how it’s supposed to work.

marizmelo2• 14 years ago

Why do we have those prefixes in the first place? Ok, ok, test new functionalities is a good thing, but create bad practices among developers it is not.

All the problems with IE began when they (M word) started their with own implementation of javascript, CSS, and even HTML (automatic close for tags is not ok people, developers need to learn).

It is not your (browser vendors) responsibility to define your own interpretation of the standards. We have organizations that take care of this for you. All the problems involving incompatibilities began with browser vendors trying to "simplify" developers life giving their own version of the "standard".

If a new functionality is not part of the standards yet it must be a reason. Why not respect that and avoid all sort of complications?

Why the rush?

Force organizations to release early pieces of work will generate bad industry standards.

Do not like the way how one standard is defined?

You will have to swallow. - by brazilian team couch Zagallo

Yaggo4• 14 years ago

> It is not your (browser vendors) responsibility to define your own interpretation of the standards. We have organizations that take care of this for you.

You realize that browser vendors are members of W3C and thus essentially creating the standards [for their commercial interests]? For example, the browsers have CSS transforms today because Apple proposed them back in 2007. (Wow, that's half a decade ago; time passes fast.)

> Why the rush?

Because without the "rush" by browser vendors we would be writing XHTML 2.1.14 without any fancy HTML5 stuff.

cheald3• 14 years ago

And CSS transforms are still in the "working draft" stage. It's been a half-decade and they aren't a full part of the standard yet.

That's why "the rush".

marizmelo2• 14 years ago

Creating confusion among developers just because you want to release "fancy HTML5 stuff" doesn't seem to me as a good idea.

Why not first implement these new features on your own browser as "developer version only", and prove that they work and do benefit users and the web in general? I believe that is the way you establish credibility and acceptance of a particular feature.

I am not against the release of all these amazing things, but I am against the way they are currently doing it.

If the proposed features do not have defined and W3C-agreed set of names and properties associated with those features, they should not be released to end users.

I don't want to see something like "only for IE" in applications and websites anymore. The problem is still small for now, but it can become huge if this bad practice doesn't stop.

lhm• 14 years ago

Is there someone gathering statistics on css prefix usage in the wild? I think it would be interesting to see some real data on this.

rplnt3• 14 years ago

Will wide -webkit prefix support stop sites like google.com from sniffing and blocking users? Probably not. And that is even bigger problem than forgetting to add some vendor specific prefixes. Worst thing about it is that it's all "politics". Want people to use your browser? Block other browsers and they will eventually switch. Microsoft did this, now Google does this. It's just that this time no one seems to care.

Yaggo4• 14 years ago

Dev^H^H^HPeople are lazy. Preprocessor tools exist but installing and running them is always extra work unless 100% integrated into workflow.

What if there was one common "-experimental-" or "-x-" prefix instead of multiple vendor prefixes? Browsers would parse them all and throw away the ones they don't support/undestand.

lmm3• 14 years ago

If you do that then if two browsers implement a new property incompatibly it becomes impossible to write a site that works in both (see gradients, where the "function call" syntax is different in different browsers).

Yaggo4• 14 years ago

The browser can still ignore a property if its value cannot be fully parsed (e.g. invalid gradient syntax).

Zarel• 14 years ago

What about one common prefix in addition to vendor prefixes?

Then you could write "-x-border-radius: 2px" in the majority of times where the property was compatible, but you'd still be able to write "-webkit-border-radius: 2px 4px; -moz-border-radius: 4px 2px" where it's implemented differently.

willvarfar• 14 years ago

This talks exclusively about webkit in a mobile world; webkit is also Chrome, and so has taken over the desktop world too.

The success of an engine lauded for its cleanliness and conciseness and architecture (khtml) over the sprawling mess of engines that preceded it.

Flenser• 14 years ago

Won't webkit drop the prefix once things are standardised and then sites will either be broken or have to drop the prefix to o, thereby working in all browsers?

lmm3• 14 years ago

No. Apple isn't going to break existing sites out of purism. Webkit will be supporting -webkit- for decades, and so will everyone else, just as with every nonstandard tag that's ever existed.

WebKit Isn’t Breaking the Web. You Are

Related Stories