
Pre-fix the web: Webkit-only solutions hurts the open web - dave1010uk
http://codepo8.github.com/prefix-the-web/
======
dmethvin
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...](http://lists.w3.org/Archives/Public/www-
style/2012Feb/0313.html)

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.

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

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

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

I think you're misattributing malice here. This isn't a WebKit only issue,
this is a first-to-market issue. When some new css or js feature is proposed
and vendors implement it with the prefix, some developers rush to hack on it,
submit their demos to HN, and then forget about it weeks later. They don't
bother to go back and update the css later with other prefixes.

The same issue exists when WebKit isn't the first to market. WebKit doesn't
support calc() yet. Mozilla does. Plenty of abandoned webpages will never be
updated with other prefixes. But are these serious websites/businesses? Is
Facebook or Twitter sticking in -webkit and never bothering to go back?

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

Legacy content would still be broken because sparkle will likely be changed in
the process of standardization. IndexedDB has seen some dramatic changes in
the course of its development; all those sites that implemented an earlier
version will be broken when the standard is finalized. The vendor prefix sends
a warning to the developers.

Browser sniffing is a far bigger problem than vendor prefixes. Google is one
of the worst offenders, especially in mobile where they send UAs not equal to
iOS or Android to some poorer version.

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

------
jakubw
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-"_.

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

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

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

~~~
dmethvin
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_.

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

~~~
gcp
Well, WebKit is nice and all. At some point, it was not WebKit, but Gecko that
was the shit. Then early WebKit authors made something that was easier to
embed and had a license that was friendlier to corporate entities. Apple and
Google flocked to it, and improved it even more.

They could do this because they had a standard to work from. They didn't have
to source-reverse-engineer Gecko, because they could work from that standard,
that described how things worked. They didn't have to fork Gecko (nor would
they have wanted to because of the licensing), because they didn't need to do
things exactly the same way even where it made no sense. This standard came to
be because earlier browser vendors (including Microsoft/IE and Mozilla/Gecko)
understood that things would be a mess if they didn't cooperate. They'd been
there, and done that.

If you're now proposing to drop the actual standardization process and define
the Internet as "whatever WebKit renders", be aware that you're just killing
what made WebKit possible _in the first place_. You could fork WebKit, but
you'd still have to emulate it close enough to be bug-for-bug compatible.
That's not a way to get a real improvement or independent implementation.

And it wasn't how WebKit came to be, either.

For the companies that are heavily invested in WebKit (Apple, Google), it's a
wet dream: it ensures they can never be eclipsed by something even better.
Imagine if we had done that for Gecko (it's open source too, after all!):
Mozilla could have sat on their asses and wouldn't even really have to have
cared about improving it. Luckily people competed with rendering engines, so
both WebKit _and_ Gecko keep improving rapidly. And so do IE and Opera.

I can make similar analogies for things like C++, GCC and LLVM. Even if the
implementations are open source, having a standard that allows independent
ones is _tremendously_ important to prevent stagnation.

I'm not ready to allow C++ to be redefined as "whatever GCC compiles" any more
than I am ready to allow the Internet to be redefined as "whatever WebKit
renders". Even though yes, this does mean more work keeping things compatible
for me as a C++ programmer.

~~~
blibble
KHTML is as old as Gecko, and Webkit and Gecko are both LGPL.

the killer feature back in the early 2000's was the ability to render most of
the pages on the Internet as IE did, so saying that the engines were the
product of standards is categorically wrong.

the lack of adoption of Gecko outside of Mozilla is more to do with the fact
the source code is a mess, whereas Webkit is very clean and tidy, and as a
result very easy to hack on (years ago I _wanted_ to embed Gecko in a project,
and ended up using Webkit as it was actually possible to modify...).

~~~
pcwalton
The remarkable thing about Firefox is not how much it compromised on
implementing IE-specific features, but rather how much market share it gained
in spite of the fact that it _didn't_ compromise on implementing IE-specific
features. To name a few off the top of my head: ActiveX,
filter:progid:DXImageTransform, CSS "zoom" property, insertAdjacentElement(),
etc.

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

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

------
huxley
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...](https://wiki.mozilla.org/Platform/Layout/CSS_Compatibility#Data_on_vendor-
specific_prefixes)

~~~
starwed
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!

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

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

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

~~~
wwweston
It's absolutely true that those things aren't exclusive, but as somebody who
often uses two rare but capable user-agents (Lynx and the browser on an old
Nokia S40), I can testify that in practice, a significant number of websites
aren't being created with both in mind, and I think a significant number of
designers don't really understand what the lowest common denominator really
means.

It's very very easy to pay attention to only a handful of user agents, and
from what I can see, right now that's trending towards 2-3 desktop browsers +
"mobile" (which usually means "the iPhone and maybe one or two Android
devices").

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

~~~
dmethvin
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-".

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

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

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

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

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

~~~
angersock
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!

~~~
gcp
The problem of a standards body is that it requires everyone involved to have
an interest in having a common standard. When this is the case, they work
fine. When this is not the case, you're SOL.

Do you think Apple and Google have an interest in making mobile sites work on
Windows Phone, or phones with Opera Mini?

