

WebKit Isn’t Breaking the Web. You Are - bootload
http://www.webmonkey.com/2012/02/webkit-isnt-breaking-the-web-you-are/

======
cheald
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.

~~~
azakai
> 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.

~~~
dave1010uk
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...](http://www.quirksmode.org/blog/archives/2012/01/browser_stats_f_2.html)

~~~
sambeau
Opera is _not_ the most popular mobile browser.

If you look at the graph he links to they compare Opera to Android, iPhone,
iPod Touch separately despite all being Webkit based. Add them up and you have
around 43% well more than the 18% shown for Opera.

If you look at the table you linked to Android plus Mobile Safari also gives
44%. Opera has 22%.

~~~
dave1010uk
Using these stats, Opera is the most popular mobile _browser_ but WebKit is
the most popular mobile browser rendering engine / framework. Whilst WebKit
being > 50% of rendering engines definitely counts for something, my point is
that non-WebKit browsers account for a very significant chunk of the mobile
web.

From PPK again:
[http://www.quirksmode.org/blog/archives/2009/10/there_is_no_...](http://www.quirksmode.org/blog/archives/2009/10/there_is_no_web.html)

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

~~~
jballanc
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.

~~~
zalew
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.

~~~
joahua
The idea behind vendor prefixes is that they are implementations of ideas
before conventions have been established. When two vendors implement something
simultaneously but pre-spec, it's hard to tell which one will end up being
canonical.

Your general convention is probably good, but in 5 years time when n
parameters have ended up in your {additional} parameter, people will ask why
that, too, doesn't follow a convention. The answer is definitionally that the
convention doesn't exist yet, and the vendor prefix is a step on the way to
establishing one.

~~~
zalew
I don't know if it's really a big deal to set up a general convention, and
when new features appear, just discuss it with W3C and/or other vendors, and
use it. These are the minor kinds of problems that can be solved in theory
with a few emails and in practice with a 2 months thread on a discussion board
(but still better than a mess)

~~~
jballanc
But it isn't a mess. Finalized names are selected as _part_ of the
standardization process. That's exactly what TFA was saying: the
standardization process works, but web developers are being exceptionally
lazy.

What you're asking for is that the browser engineers should wait until part of
the standardization process is done (the naming) before they start on
implementation, only to potentially have to rewrite things once a finalized
name is selected. Not going to happen.

~~~
throwaway64
a process that takes 11 years and counting to finalize the properties of a
rounded border isnt a mess, its a disaster.

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

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

~~~
jballanc
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.

~~~
zalew
If less & co would automatically abstract css vendor-specific features just
like Jquery abstracts javascript DOM access methods, you'd be right, but as
far as I can see on the main page <http://lesscss.org/> you still have to
declare it by hand, so it doesn't work that way. Using less doesn't make
styling widely compatible out of the box. Looks like what we need is less-like
frameworks to evolve into cross-platform abstraction layers.

~~~
tghw
With projects like Compass (<http://compass-style.org>) for SASS/SCSS, those
abstraction layers are there. When we made WebPutty (<http://webputty.net>)
with SCSS support, one of the first and most common questions we got was "can
I use Compass", so we added it. It's pretty much the standard for
abstractions.

Less is not quite there yet, but things like Twitter Bootstrap are well on
their way to becoming similar standard abstractions.

~~~
masklinn
> With projects like Compass (<http://compass-style.org>) for SASS/SCSS, those
> abstraction layers are there.

That's nonsense, those "abstraction layers" are inserted statically during
deployment, they don't improve as browsers improve. When Google or Apple adds
a proprietary -webkit- property which may never get standardized, Compass has
no way to make that property available to all browsers _in sites built at the
time the property was solely proprietary_ as browsers gradually implement it
(and it gets standardized) over the next years.

~~~
jballanc
Code that you compiled on a machine 10 years ago is rather unlikely to still
run on whatever machine you're using now. That's the way things go. Still,
this is CSS's problem, not Compass's. If CSS had better abstraction abilities
built in, then you could point your page to a reference set of abstractions
that could be updated as browsers improve.

~~~
masklinn
> Code that you compiled on a machine 10 years ago is rather unlikely to still
> run on whatever machine you're using now.

1\. That's not even true, you should try out windows once in a while

2\. We're not talking about local programs.

> That's the way things go.

No it's not, that's not even a cop-out that's complete, utter and absolute
bullshit. Pages from the very origin of the internet back in 1992 still work
perfectly fine today:
[http://www.w3.org/History/19921103-hypertext/hypertext/WWW/T...](http://www.w3.org/History/19921103-hypertext/hypertext/WWW/TheProject.html)

 _You_ making things which break is not "the way things go", it's you being
incompetent, don't try to pass the blame to somebody else...

> If CSS had better abstraction abilities built in, then you could point your
> page to a reference set of abstractions that could be updated as browsers
> improve.

as you're doing here. So now to fix _your own personal incompetence_ there
needs to be a centralized authority set which will magically fix your crap as
time goes on? How about doing things correctly to start with?

~~~
jballanc
_Pages from the very origin of the internet back in 1992 still work perfectly
fine today_

Yeah, but none of my <marquee> tags work. Which is funny, because that was
also a non-standard, browser-specific feature. If that element had been
standardized, but as <marquis>, then those pages would still break.

 _How about doing things correctly to start with?_

I thought that's what we were advocating? Using vendor specific prefixes is
the same as using a non-standard tag: it will likely break, and will almost
definitely not work on multiple platforms. That doesn't seem to me, though, to
be an argument against them.

If you want to complain that the standardization process is too slow, and thus
people are used to continue using vendor-prefixed tags longer than they
should, I'll be right beside you yelling about it. But the solution, it seems
to me, isn't to "break" or abolish vendor prefixes. If you want to speed up
the standardization process, do what the WHATWG did.

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

~~~
TeeWEE
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.

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

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

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

~~~
lmm
Yes, my point is at the moment I can set -moz-gradient and -webkit-gradient
(or whatever the actual property name is) using the different syntax for each,
and have my page work in both.

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

~~~
zobzu
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
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.

~~~
TeeWEE
IE6 sucks now. But when it came out it was one of the advanced browsers out
there. And it was the first browser to support shadows and opacity.

\- Shadows with: filter: Shadow(Color=#999999, Direction=135, Strength=5); \-
Opacity: filter: progid:DXImageTransform.Microsoft.AlphaImageLoader
(src='image_name.png', sizingMethod='scale');

It even has support for javascript in css: left:
expression(15+((e=document.documentElement.scrollLeft)?e:document.body.scrollLeft)+'px');

And I remember you could even give your scrollbars colors.

How is this different from webkit shipping browser with cool new features now?
Similar to microsoft right? They also wanted to show how cool their browser
was back then. If Microsoft never shipped IE6 with these extensions we would
have a lot less issues a few years ago.

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

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

------
willvarfar
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
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?

~~~
lmm
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.

------
marizmelo
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

~~~
Yaggo
> 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.

~~~
marizmelo
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.

~~~
Yaggo
> 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?

Because of the real world needs. For example, Apple has been agressively
pushing HTML5 features because they needed to offer alternative for Flash.
(CSS effects, <video>, etc.)

