
Web Standards - maccman
http://dcurt.is/web-standards
======
tptacek
This is the result of a standards process running in reverse: _first_ the
specifications, _then_ the implementation. There was a time when the
"Internet" could if you squinted right be defined as "the collection of people
who make fun of that process and do the opposite"; their motto was (literally)
"loose consensus and working code".

First you get things working. Then you standardize on them.

Complain when the Webkit team refuses to implement standards. Have they shown
any unwillingness to support W3C standards once published? No? Then what's the
gripe? The browser vendors are doing _exactly what they're supposed to do_ :
come up with new things. If the W3C was doing its job, it would watch those
new things carefully and, when enough momentum existed, start ratifying them
as standards.

It's not enough to say, "you could have used the same argument to defend
Internet Explorer". To indict someone for "embrace & extend", you need both
halves of the behavior: creation of new features, _and unwillingness to
support subsequent standards for those features_.

~~~
haberman
It constantly amazes me how many people do not understand this. So many web
standards advocates will cry foul the moment any vendor tries something out
that has not already been standardized. Even Brendan Eich cried foul about
Dart even though JavaScript was out in the wild for a year before Netscape
even submitted it to a standards body.

Committees are not the right process for innovation. 10 years of overly
complicated and unneeded standards from W3C should have taught us this.

~~~
cageface
I'd go further than that. I think the era of the technology standard as a
formally specified, committee-managed, cross-platform entity is coming to an
end. What we're seeing instead is the emergence of open-source implementations
that are themselves the de-facto standard. This is particularly true of
languages. Look how Apple has managed to run circles around the C++ committee
in their single stewardship of Obj-C. Or think how ridiculous it sounds to
think of a "standard" definition of Python or Ruby.

~~~
fpgeek
If it is true that we have moved past the era of formal standards, we will
have lost something that is important. More important than most people
understand.

If a technology has only implementation, even an open source implementation,
that implementation will have all sorts of hidden assumptions and biases. No
one will know about or understand those assumptions and biases until the time
comes to use that technology in a new context.

In my work, I've dealt with multiple implementations of things like
simulators, models and even languages. The additional implementations usually
had some specific reason behind them (performance, alternative features,
supporting different execution environments, different mathematical properties
and so on). Nevertheless, the value of each alternative implementation (in
terms of surfacing hidden assumptions, finding bugs, illuminating more general
and flexible alternatives, etc.) went well beyond the specific reason that
implementation was made.

These considerations are even more important in the case of software that is
part of a large, chaotic, heterogeneous system like the Web. Imagine where the
mobile web would be today if there hadn't been a W3C and, at the turn of the
century, the Web really had been "what Internet Explorer renders" with no
attempt to document and codify anything else.

Or, to take your example of Objective C, how much does Objective C matter
_outside_ of Apple's ecosystem?

Contrast this with:

\- How much does JavaScript matter outside of Netscape's ecosystem?

\- How much does Java matters outside of Sun's?

\- Or, to take the granddaddy of examples, how much does C matter off of the
PDP-11 and outside of Bell Labs?

None of those languages would be anywhere near where they are today without
standards. On the other side of the coin, there is a reason languages like
Python, Ruby and Haskell have had (and, each to a varying extent, continue to
have) a "bus problem". Standards matter and even just the standardization
process itself matters. I wish more people understood that.

~~~
cageface
_How much does Objective C matter outside of Apple's ecosystem?_

It doesn't need to. Apple has demonstrated the agility of a wholly owned,
vertical stack. The pace of change has qualitatively changed since the days of
language standards set by plodding standards bodies.

~~~
fpgeek
It depends on what your ambitions are. I'd agree that it doesn't matter much
to Apple that Objective C isn't standardized (and not standardizing may be an
intentional part of Apple's business strategy by increasing porting and
switching costs).

But that also means that, no matter what its true potential is, Objective C
will never be more than what Apple makes of it. It won't be seriously used
outside of application areas Apple is interested in. It won't develop new
features Apple doesn't care about. And if Apple decides to go in a different
direction and/or runs into serious trouble, well that's it.

Apple has changed the world, but, unlike some other, standardized languages
including the ones above, Objective C never will. If we lose the full
potential of future great languages because they are limited by a single
company and/or a single implementation, we will all be poorer because of that.

~~~
cageface
I used to think so but I've come around to the idea that the language is just
part of the platform. Learning the Apis and idioms is always more work than
learning a new syntax anyway.

~~~
fpgeek
I guess this is where we're actually parting ways. I agree that learning a
platform, its APIs and idioms is important, non-trivial work, but...

As you might guess from my username, I'm a fan of more than a few languages
where (at least I believe) the differences go well beyond syntax. That means I
want standards because I want to know what I can (or could) take with me to
another platform and what I can't.

------
sp332
_the developers of WebKit added the prefix -webkit to the experimental
stylesheet declarations. This ensured they worked only in WebKit._

No. This ensured that they didn't pollute the global namespace with
experimental, partially-implemented ideas. If Mozilla, Opera, and Webkit each
make e.g. "rounded-rect" declaration, and one browser takes the width as the
first argument while another takes the radius first, then we're screwed. At
least having "-moz-rounded-rect" and "-o-rouded-rect" means developers know
how their pages will behave in each browser. I agree that the W3C is
unacceptably slow, but that doesn't mean prefixes are a terrible idea.

~~~
kule
What I still don't understand is why the global namespace isn't used straight
away.

You could, for example, just use one line of css for border-radius for all
browsers. If one vendor does it differently you use their vendor specific
namespace to override it. Surely that makes more sense than having to do a
line of css for every vendor?

~~~
sp332
But if there's no standard, then how do you know which behavior to expect in
the "global" case and which ones should be vendor-specific? And if only one
browser experimentally implements a new feature, should you use the vendor-
specific namespace for it, or hope that all future implementations in other
browsers are the same?

~~~
kule
Just to clarify I'm not suggesting there should be no standard, there
definitely should be.

However for the initial implementation what's wrong with survival of the
fittest? The most popular way will win through, which would most likely become
standard. For those browsers that don't implement it in the same way you use
their vendor specific namespace instead.

Yes it's likely to be hairy when it's first being put to use if browsers have
slightly different implementations but no more so than using an experimental
tag in the first place.

The difference appears to me to be that for the next five+ years I could be
writing 8 lines of basically the same css for every instance of linear-
gradient (and that's assuming we don't get any new browser vendors in the
coming years) vs writing 2-4 lines with backwards compatibility or shock maybe
even 1 line if I didn't care about older browsers (e.g.
<http://www.colorzilla.com/gradient-editor/>).

------
ChuckMcM
Welcome to the 'standards' world. It sucks big time.

I've participated in standards in both POSIX working groups (network file
systems, network apis), IEEE working groups (PCI express Advanced Switching),
IETF working groups (RPC and XDR, heck I'm the 'owner' of port 111!), various
CAD standards groups, and a whole bunch of things that never even rose to a
level of relevance to get published.

If standards bodies are effective, they take away power from companies to
distort the playing field, if they are ineffective they allow folks to distort
independently. So large companies send representatives to standards bodies to
distort them in favor of their own company (Rambus is the canonical example)
and other companies send representatives to make them ineffective so that they
won't level the current field (Microsoft and XML is the canonical exemplar
there).

The bottom line is that Standards bodies whine that nobody lets them do their
job, and they tolerate members who actively prevent them from making progress.
I have long since given up feeling any sympathy for them whatsoever.

~~~
masklinn
> Welcome to the 'standards' world. It sucks big time.

Because a hegemony is so much better right? What fun that was last time
around.

------
mceachen
Dustin, I totally agree with you that the current system is whack. Glacial
adoption of W3C standards has a real cost on developers and users, and ends up
with rounded corners taking 16 lines of CSS, and gradient fills taking 8.

I don't think that we'll be better off just by making the current process "go
faster," though.

There needs to be _some_ proper vetting of features. You'd want to avoid the
tyranny of the monied interests. It can't just be Apple/Microsoft/Google
making the decisions about what goes in and what doesn't -- even though
they're going to shoulder the cost on the user-agent side to implement the
feature.

It might just be as simple as leaving the current ecosystem as it is, looking
at the adoption rate and success of a given construct, and folding those into
the "living" spec (without the prefix, of course) -- and just do this process
on a regular, fairly frequent interval, like every 6 months.

~~~
kaiuhl
I disagree about the proper vetting of features being a necessity. As long as
open-source rendering engines like Webkit or Gecko are pushing forward and
providing ideas _and_ implementations of those ideas, we can let web
developers vote with their websites.

Everyone understands that advanced features of CSS can't be relied upon—this
is now part of the collective front-end developer consciousness.

Get rid of the W3C and let Mozilla and the Webkit project define the web
moving forward; they've done a great job so far.

~~~
gioele
> Get rid of the W3C and let Mozilla and the Webkit project define the web
> moving forward; they've done a great job so far.

The standardization of required codecs for the `<video>` element is indeed a
wonderful accomplishment by the non-W3C HTML5 WHATWG.

Seriously, a third-party neutral organization will always be needed. Who will
you appeal to when the main companies start having different ideas about
something? Another thing that organizations like W3C or IETF do is to provide
some kind of shelter from patents and similar problems.

We can discuss about the efficacy of such shelters and about the ability to
mediate between different options, but the web is definitely under a better
situation than wireless telephony, a field where company-run consortiums
decide standards and "settle" disputes.

~~~
mappu
Speaking of `<video>`, i came across a site today that used <embed
src="foo.wav">. As long as video and audio formats are loosely specified, we
could've used the existing syntax and existing browser infrastructure (you
still can't disable HTML5 audio/video in Chrome[1] for e.g. data cap reasons)

__________________

1\. <http://crbug.com/50132>

~~~
lmm
The irony is that <embed> was never a standard (unlike <object>); if you
believe the W3C fans then you must be evil to use it. But it works, and has
always worked, better than any of the alternatives. I hear with html5 they've
given up and declared it part of the standard.

~~~
Hixie
The "they" that "gave up" is a different group of people than the "they" who
thought it was evil, by the way.

The current group working on the contemporary HTML living standard just
describes reality, by and large, so there was never really any doubt that
"embed" would be part of the standard when we started back in 2004.

------
sriramk
Somewhere in building 50 on Redmond campus, the IE team is wondering why
nobody ever said this in their defence when the exact same scenario was
playing out with IE (dominant browser, not available on all platforms, glacial
standards bodies, browser specific extensions, etc).

~~~
cgranade
This is a very different situation in quite a few ways. For one, IE was not
just a big browser, but was almost completely dominant. For another, many of
IE's browser-specific features were Windows-only by design, such as ActiveX.

Here, we have an open source rendering engine that clearly delineates browser-
specific features (each of which is well-documented). The use of a prefix
makes it possible to use the browser-specific features offered by WebKit
without sacrificing compatibility with other browsers, something Microsoft
actively resisted. For quite a while, it was very difficult, if not
impossible, to make sites that looked and felt right both in IE and in other
browsers.

Had Microsoft extended standards in a way that played nice with the rest of
the community, maybe they would have had someone saying something like this in
their defence. Instead, they used browser-specific features as a way of
undermining standards.

~~~
ootachi
NaCl is specific to individual processor architectures by design, much like
ActiveX was specific to Windows.

Prefixed WebKit features are certainly not consistently well-documented. CSS
animations, transforms, etc. had to be carefully reverse engineered by other
browsers.

~~~
jacobolus
CSS animations and transforms were released along with formal specs. The
Webkit developers read mailing lists, hang out on IRC, etc. If anyone thought
these were underspecified or ambiguous, they could easily ask for answers or
adjustments to the spec. It’s not like the Webkit folks were trying to hide
anything.

~~~
ootachi
The spec was not released alongside the implementation of animations and
transforms. It was released much later.

~~~
jacobolus
You’re right. CSS animations were announced and added to Webkit betas in
October 2007, and it took until the beginning of April 2008 for Apple to put
up their proposed formal spec. I’m not sure when they first hit a publicly
released version of Safari. Still, 6 months is pretty short in browser spec
time, and pretty much no one was using these features in the wild until much
later.

------
edd_dumbill
This is a somewhat ungrateful perspective, just after the Eolas patent case
was thrown out.

Yes, the W3C process takes about half the lifespan of many HN readers. Yup,
it's not ideal.

But it's the only game in town and it's been going on so long because it
works. Because it successfully brought Microsoft into the fold and
conversation at a time where, had they decided, they could have broken
everything.

It's worth exercising a little perspective. Can you think of any endeavor that
has so successfully united vendors to create something as broad and
interoperable as the web, over such a relatively small period of history? The
W3C has been fundamental to this.

\- What has the W3C ever done for us?

\-- Well, HTML.

\- Oh yeah, they gave us that. Yeah. That's true.

\-- And CSS you could view source and copy.

\--- Yeah, you remember how scared we all were of Microsoft Blackbird?

\- All right, I'll grant you that HTML and CSS are two things the W3C have
done...

(you get the idea.)

~~~
gkoberger
W3C isn't the only game in town. There's the WHATWG because of W3C's
shortcomings.

------
potch
My complaint is not that -webkit CSS extensions are bad. I love how fast the
browsers move. It's that people aren't careful to make sure they use all the
prefixes when they're available. It's an education problem, but people using
CSS preprocessors such as LESS and SASS have no real excuse.

~~~
tjogin
That wouldn't be a problem if the non-vendored variants of the CSS attributes
didn't take so god damn long to become proper standards.

The problem is not the webkit vendor attributes, the problem is that proper
standards aren't able to keep up.

HTML5 is _still_ not a proper W3C standard (or "recommendation"), it's still
just a working draft, and was last updated in May of 2011. It's been six
years. So far.

~~~
voyou
I don't really understand this objection. Sure, HTML 5 isn't officially a
standard, but neither is -webkit-whatever; in both cases, you can use
whichever non-standard you like, subject to browser support. The advantage of
the W3C draft is that it is a non-standard that the browser makers are all
working towards.

~~~
tjogin
The objection is that the standardization process is too slow. Not a little
bit too slow, but so glacially slow it's almost indistinguishable from
abandonment. So, progress of key web technologies needs to be put into
vendors's hands.

CSS border-radius is _still_ not a W3C recommendation. It's been a draft for
_nine and a half years_. So far. It was last updated one year ago.

With a standardization process that broken, vendors need to take things into
their own hands, and them doing so, especially webkit doing so, has been an
astounding success, IMHO.

~~~
voyou
Yes, but _why does it matter_ that the standardization process is slow? What
is the practical relevance of something moving from "Candidate Recommendation"
to "Recommendation" status? Why are draft standards any worse than vendor
extensions?

~~~
tjogin
Prefixed attributes bring features to developers while they are still
experimental, which means we don't have to wait a decade before trying them
out.

------
3pt14159
Aside: Please don't have a flashing beacon thing where I'm trying to read. I
get visually distracted very, very easily.

~~~
mortenjorck
I'm going to have to agree that's a usability gaffe. Peripheral animation that
isn't in service of a notification or something else that actually requires
the user's attention is, quite literally, only a distraction.

~~~
aidos
It's worse than that actually - hold your mouse over it and you give the
author "Kudos." I find that particularly offensive /rant

------
lwhi
To me, the article comes across as a bit of an uninformed rant.

> I hope it does kill the W3C and CSS Working Group standardization process.

To this, I have to ask "Mr Curtis - are you _CRAZY_?"(!)

Do you not realise that it's taken over 12 years to say good bye to IE6. Have
you not had the pleasure of battling with the ramifications of a browser that
doesn't play by the rules?

\--

There are some understandable reasons for not making use of vendor prefixes.

The article that Dustin Curtis links to makes some valid points about the
dangers of continuing to use vendor prefixes. A similar line of thinking is
presented here [1]

The alternative to using vendor tags isn't to stop using the features - it's
to simply drop the vendor prefixes and use the property names from the (non-
ratified) CSS specifications before they're fully approved.

For all it's failings, the W3C does a grand job. Negotiations take time. Best
we don't throw our toys out of the pram.

\--

[1]
[http://www.quirksmode.org/blog/archives/2010/03/css_vendor_p...](http://www.quirksmode.org/blog/archives/2010/03/css_vendor_pref.html).

~~~
tptacek
I think you're misinformed by what "the rules" are.

W3C standards are not, in fact, an innovation speed limit. Vendors are free to
implement whatever they'd like.

The only way a vendor should be encumbered by the W3C is that if they choose
to implement a feature, they should _also_ support the W3C incarnation of that
feature. That's it, full stop.

The problem with IE6 isn't that it did extra things. It's that it did a
variety of things (some extra, some not) _badly_ , and then Microsoft _refused
to bring it into compliance_. That's not a problem we have with Webkit. So
what are you saying when you try to tar Webkit with the IE brush? How familiar
are you with the development process behind Webkit?

~~~
lwhi
If you read the article referenced, you'd realise that web-kit isn't being
picked on. The concept of using vendor-prefixes is being questioned.

I'm not tarring webkit with an IE brush. I'm stating that without the W3C or
similar body to set standards, we would in a far worse situation.

The article spectacularly misses the point.

~~~
tptacek
Do you have something to say about vendor prefixes? That's what we're talking
about. I'm not particularly concerned about what particular blue ribbons we
affix to the W3C. They're great. Now what?

~~~
lwhi
These links [1][2] provide some reasoning behind not using vendor extensions.
The second is referenced in the article we're commenting on. I find it
difficult to understand why much vitriol needs to be expended.

[1]
[http://www.quirksmode.org/blog/archives/2010/03/css_vendor_p...](http://www.quirksmode.org/blog/archives/2010/03/css_vendor_pref.html)

[2]
[http://www.glazman.org/weblog/dotclear/index.php?post/2012/0...](http://www.glazman.org/weblog/dotclear/index.php?post/2012/02/09/CALL-
FOR-ACTION:-THE-OPEN-WEB-NEEDS-YOU-NOW)

~~~
chc
That QuirksMode article you posted includes an update acknowledging that it's
wrong. I think the stance in the newer post it links to is more reasonable,
though I'm still not sure it's all the way there.

~~~
lwhi
The article provides a summary of potential problems with vendor prefixes,
which still stands.

The author acknowledged that his suggested solution was wrong. See the redux
[1] (which is actually mentioned in the article) for alternative solutions.

My main concern is that the dcurt.is article misses the point entirely.

[1]
[http://www.quirksmode.org/blog/archives/2010/03/css_vendor_p...](http://www.quirksmode.org/blog/archives/2010/03/css_vendor_pref_1.html)

------
MeanderingCode
Way to go, dcurtis, ranting about web standards and webkit's greatness while
your website doesn't render sanely on my android devices' webkit browsers.

~~~
bithive123
That's unfair, it says right at the top of the page that he's a superhero not
a web developer.

------
mattbeck
This seems to be a fairly standard gripe from the W3C. "Listen to us, because
if you don't the sky will fall!"

They are making themselves increasingly irrelevant because they exist
primarily to restrict and limit rather than to expand and innovate.

Partly that's the nature of the beast, standards are after all rules.

The problem is that the rules need a clear and timely mechanism to evolve.
Clearly the W3C is the wrong answer to that problem.

I remember well what things were like in the days of horrible tag soup trying
to support internet explorer and netscape, and that sucked too.

Standards are good, having a single rule set for everyone to test against is
good.

The W3C though, yeah they suck hard.

Way past time to move to a usage-based standards adoption mechanism. Let
people innovate, if that change sees wide support adopt it as a standard.

------
jseims
Does anyone have any insight as to _why_ the W3C has taken over 10 years to
converge on the spec for rounded corners? Any info more than just
"bureaucracy"?

~~~
th0ma5
you really do have to properly vet these things. i didn't realize the work
involved either until i started following the rdfa spec. beyond the
bureaucracy (which is actually pretty good, like a software development
process) there are unintended use cases and side effects, and the concept
needs to be as complete as possible and not self-contradictory. there must
also be prior art to be researched and understood and incorporated wherever
possible as to not throw out good ideas with an off-the-cuff implementation.
second, it is actually done sort of slowly, and with your input if you want,
and you can start to use a lot of the core features of drafts, just like a
beta program.

------
pygorex
Browser developers are going to innovate new features. A standards body
doesn't drive innovation. Innovation is not a top-down process. A standards
body exists to ensure some level of interoperability between browsers.

What Prefixgate shows is that a W3C standard is not a rigid set of laws like
the 10 commandments. Rather a W3C standard is like a peace treaty - all
adherents agree to respect certain protocols and behave in certain ways, buy
are free to pass whatever laws they want within their own boundaries. Assuming
that these proprietary laws do not conflict with existing treaty stipulations.

Peace treaties give us access to the best of both worlds: vendors are free to
innovate as they see fit, yet they still commit themselves to some level of
interoperability. Innovations influence the standard and the standard ensures
that all vendors adopt the best innovations at some point.

The comparisons between IE of old and Webkit are incorrect. Microsoft has a
history of implementing standards incorrectly
(<http://www.quirksmode.org/css/quirksmode.html>) and bullying standards
bodies ([http://techrights.org/2011/09/06/michel-levy-comes-out-
swing...](http://techrights.org/2011/09/06/michel-levy-comes-out-swinging/)).
When it comes to standards _Microsoft does not act in good faith._

~~~
pbhjpbhj
> _Innovation is not a top-down process._

I don't see why it can't be. For example, going back 10 years the W3C could
have said we're standardising a series of layout definition attributes (or
multiple backgrounds, or colour fades, or bordering styles, or animation modes
or whatever) and then waited for those to be implemented by the browsers. I
don't see why the standards bodies can't anticipate a need that hasn't yet
been coded for and implement a preliminary standard definition for browser
writers to use.

It probably wouldn't work in practice because it appears to rely on the
standards body moving faster than the browser makers which is a laughable
suggestion as things stand now.

As I, probably shortsightedly, see things now it's the javascript (jquery,
mootools, etc.) writers who're best placed to speak to the next iteration of
web standards as they are actively filling the holes that are missing in the
current iteration of HTML+CSS (and associate tech).

~~~
wvenable
> For example, going back 10 years the W3C could have said we're standardising
> a series of layout definition attributes

So 10 years ago, before the iPhone and the iPad and the entire mobile web? You
really expect that standards body _10 years ago_ would have anticipated the
need for multi-touch events, for example?

~~~
pbhjpbhj
I didn't say that all innovation is exclusively top-down. I just said that I
couldn't see why it couldn't happen. For example when a client gives you a
design brief for a system that's a limited type of top-down innovation.

W3C do appear to create some standards before there is a working
implementation too.

------
JoshTriplett
I find it funny that that rant holds up as an example the magic bit of CSS
animation on the right which treats a brief hover over it as a "kudo".

------
jerfelix
I'm glad that the webkit-specific features were prefixed. I just wish they
would have chosen a prefix that was a wake-up call to anyone relying on them.

Perhaps a prefix like "this-feature-will-be-deprecated-in-2013-".

Slightly off-topic, but in a similar manner, when we struggled with users
permanently deleting records, ignoring the warning that they were permanently
deleting records, and calling us to retrieve the irretrievable, we changed the
confirmation box from "click OK" to "type the word 'irreversible". This cut
the calls to near zero.

------
lifthrasiir
It is correct that W3C certainly lacks the ability to coordinate different
vendors. But is it good to abandon the _coordination_ process altogether? No,
the problem here is a standardization process and not a coordination process.
You at least have to coordinate vendors to maintain the very baseline, no
matter Web standard is means or not. (If you don't agree on this, you'd be
better looking at the past...) Someone should really bring up the better
alternative than Web standard, and not only criticize it.

------
georgemcbay
"Despite having representatives from all of the major browser developers, the
Working Group has not been able come up with a solution."

IMO there's no "despite" about that, "Due to" would be more appropriate.

Design by committee sucks even under the best of circumstances. When the
committee is made up of very different companies each trying to use the web as
a chip to bolster different parts of their businesses, of course the process
is going to be broken. It probably can't not be broken.

~~~
nerfhammer
I don't see how deciding the syntax for a gradient fill might affect one
business concern vs another

~~~
georgemcbay
Actually there are very real ways in which this sort of thing can impact one
vs another. eg. Adobe may push for a format that natively supports the double
sided color filling rules they use in Flash to make it easier for them to
produce Flash->HTML5 conversion frameworks without a lot of code rewriting
while other parties may not have this as a concern.

That aside, you picked a ridiculously low-hanging fruit of a concern. Consider
something larger, like JavaScript and the fate of ECMAScript 4 due to the very
situation I'm talking about. But even the minor bikeshedding concerns can be
used as political levers one way or another regardless of how (in)significant
one implementation is compared to another.

~~~
nerfhammer
There ought to be at least some things that literally none of the participants
in w3c etc have any conflict of interest about and therefore would be able to
decide quickly on. The debate over the <video> tag for example may never be
decided on. But I have trouble thinking of any counter-examples.

------
Finster
Ohhhh, so it's okay when webkit does it... just not IE.

------
meow
I think the reason for this kind of slow evolution is lack of generic
properties (like --surprise-- internet explorer's filters ) which lets
developers push the boundaries on their own with in a reasonable limit. For
example, support for border-radius, linear gradient, box shadow, text shadow
etc all deal with rendering of elements at various levels. If there is a
generic property which lets us control rendering and positioning of elements
to a limited extent, the current evolution and standardization processes will
be much less of a problem (I'm not saying internet explorer's filters are the
way to go. But you have to give them credit for putting such a generic
property in developer's hands).

------
zobzu
the guy proposes to kill standardization bodies, and that web engines should
do w/e the hell they like, regardless of standards.

coming from what appears to be a webkit dev, that's pretty bad.

standardization bodies should certainly be deeply fixed - but this kind of
reply is wrong.

------
pippy
>The reason the -webkit prefix was necessary is simple: the W3C and the CSS
Working Group are ineffective, failed organizations.

This is a bit too far. The -webkit prefix was a gesture of courtesy. What if
other browsers implement it differently, and the spec changes? then older
webkit browsers will render it incorrectly.

The solution is simple: code to the standards, then target the fringe
browsers. It doesn't matter if it's webkit or IE, this is a future proof,
cross compatible solution that will solve both problems.

------
dedward
Let's broaden the picture a bit here and look at the internet as a whole.
There are no standards - there are suggestions (RFCs), lots of open stuff
(open source, free, whatever), and some closed stuff, and then there's what
really happens.

It turns out that IPv4 and DNS worked pretty well, though of course the
internet at-large only uses a portion of those "standards". We didn't need an
organization to tell us every last little detail and how it would work and
"approve" it before we use it. People found out what worked, documented it,
and it became the de-facto standard. We've never waited on the various
internet "governing" bodies while keeping our own progress at bay. THere's
absolutely no reason to.

Know why everyone (more or less) obeys the allocations issued by ARIN? Because
we recognize someone has to manage that limited resource pool, and they do an
okay job of it. We're all free, more or less, to set up networks in whatever
way we want, with whatever IP space we want - we just can't expect cooperation
from our neighbours without some discussion and agreement so we don't stomp on
each other's space - so we look to ARIN and their brethren to manage this. If
they ceased to do so efficiently, they'd be replaced.

The W3C has no power to force a developer or vendor to implement a given
feature or not, and nobody really cares whether or not something is
"officially" compliant. Most web pages are not fully compliant... yet the web,
built by kids and adults and everything in between grew up and here we are,
talking on HN.

It'd be great if people could agree when we end up with overlapping features
from different vendors...... it makes it hard for the developers right? That
should be obvious to all. But we've switched browsers over the years, and will
again, and whichever ones actually do what people need them to do, as well as
keep developers happy, will prosper - w3c has little to do with it as far as I
can see.

Same for DNS (gripes aside - let's be realistic).

We implemented IPv4 and it works great, but does the internet at large obey
the type of service bits which are part of that standard? heck no. It's a big,
evolving, organic thing.

The web - same deal. Know what makes a standard? Something people adopt and
continue using. Usage defines the standards - nobody is compelled to do
anything just because it's a "standard" according to some group.

------
BillPosters
Front end Developers seem to disagree a lot. Some embrace the webkit prefix
and sprinkle it all through their CSS. Others prefer not to resort to old
fashioned site building techniques and instead aim to get the functionality
working everywhere in one hit without coding like it's 1996.

------
starfox
I fully agree with this. CSS set the web back years with it's inability to
handle simple layout. The W3C organization is run by representatives of major
corporations, and the standards take years to roll out.

------
bradgessler
W3C is a web standard, on paper.

<http://www.webkit.org/coding/lgpl-license.html>

WebKit is living, breathing, open standard that anybody can fork and
contribute to.

Code talks, paper walks.

~~~
fpgeek
Code is crucially important. That is why good standards bodies require
implementations. Nevertheless, that doesn't make an implementation a standard
(unless you are satisfied by under-specified, poorly documented, fragile, de
facto "standards"). That you don't seem to care about (or possibly don't
understand) the distinction suggests you are part of the problem.

NevWebKit is an implementation, not a standard. That you

------
eslaught
Why doesn't the standards body ask webkit to deprecate and begin to phase out
any -webkit-* CSS selectors which have been fully standardized? That seems
like an effective way to force people to use the standards once they actually
exist.

Complaining about people using -webkit-* before the standards exist is
obviously unreasonable, considering the implications of populating the global
namespace with conflicting versions of the same feature.

~~~
bzbarsky
The standards body has asked WebKit to do that, in fact.

Apple flat-our refused to ever remove -webkit prefixes that they have once
shipped.

Note that no one is complaining about the mere existence of the prefixes; the
problem is:

1) The way they're being used by web developers. 2) The fact that some of
these properties are not standards-track, with Apple actively refusing to
allow them to be standardized.

------
dreamdu5t
... dcurt.is is an abuse of the TLD standards...

------
readme
Great points. I'm going to automatically concur on the grounds that I don't
think bureaucracies that produce nothing should have a say in the production
of anything.

------
huggyface
The aggressive dismissal of the concerns are unwarranted and a bit ignorant.
The concern is not, per se, vendor extensions -- such a mechanism exists for a
reason -- but rather that many _users_ of those extensions have lazily taken
to only bothering with webkit extensions. Most of the time for no reason other
than an IE-only like "suck it" attitude (many demos front-paged here on HN
only work in single browser, despite often needing just trivial changes to
work elsewhere).

Dismiss the W3C and the purpose for standards at your peril. Webkit and its
offshoots have the ability to innovate on the edge _because_ that body and its
impact kept the web open.

EDIT: It's worth noting, with sober consideration, that _exactly the same
argument was made to support Internet Explorer_ during the ugliest days of the
web. This could have been cribbed verbatim from something a Microsoft advocate
would have said in the late 90s.

~~~
kaiuhl
You miss the fact that Gecko and Webkit are open source projects. There will
never be the case where something like ActiveX can exist with these projects.

~~~
recoiledsnake
Okay, so you now you have edited the source code and compiled a binary, is
your recommendation that the binary be downloadable and installable by the
user from the website?

Open source is one thing, but if you're not able to convince Google and Apple
to ship your changes, you've hit a wall. FF implementing support for the
WebKit extensions is what will break the web back into the IE-dominant era.

~~~
mbrubeck
Note that, to get the web _out_ of the IE-domininant era, it was first
necessary for Firefox to implement IE extensions like document.all and
innerHTML.

Having a competing browser is useless if it won't work with the content that
people want to use.

------
ronreiter
Relax. Just relax. The web browsers are automatically updating themselves for
a reason.

------
gavanwoolery
I am going to go out on a limb and say: fuck standards.

Make a powerful, but extremely simple (as in: small instruction set) virtual
machine and protocol. That way anyone can make their own standards.

~~~
jarek
Sir, do you understand the World Wide Web?

~~~
gavanwoolery
Apparently not - what am I misunderstanding?

~~~
jarek
More-or-less assured interoperability and complexity of content creation stand
out as two of the larger issues. Episodes of the web's history when
organizations did create their own standards might be another one.

------
jmsduran
Kudos to the author of the article. I read the referenced article on
glazman.org, and once "glazou" described -webkit-* as having "hardware market
dominance", I could not stop LOL'ing until I finished reading his blog post.
Seriously?!

I second that the web is constantly evolving, whether or not it benefits the
ego-fat cats at Google, Apple, or Mozilla. Get used to it and adapt, at least
that's what I remember hearing in a Google Tech Talk back in 2008, does anyone
still tune in to those?

