“The working group should not agree to freeze whatever syntax Chrome ships”

http://lists.w3.org/Archives/Public/www-style/2014Feb/0103.html

by cylo • 12 years ago

282 207 12 years ago

lists.w3.org

coldtea4• 12 years ago

Hah.

Remember when Blink was announced, how some people said "competing engines would be good for the web"?

And how the Blink team/Google paid lip service to improving the web going forward, better standards compliance, etc.

Firefox is ahead in some ways, too burneded by BS like a plugin ecosystem (focus on browsing damnit) and non-native UI skins, on the other.

IE is catching up but limping.

Webkit is not updating that fast anymore.

Opera, nobody but 10 people ever cared about. Besides, they're just Blink now.

Anybody holding their breaths for full ES6 support?

briandh2• 12 years ago

An awful lot of Firefox users happen to value its "BS" plugin ecosystem quite heavily.

coldtea4• 12 years ago

They might (though the vast majority just uses 2-3 plugins at most, ad block etc, that could as well be merged into core).

But this "awful lot of firefox users" is, in aggregate, awfully few judging from FF's sliding market share.

matthewmacleod• 12 years ago

This is a shallow misreading of the situation.

"competing engines would be good for the web"?

They will.

Firefox is ahead in some ways, too burneded by BS like a plugin ecosystem (focus on browsing damnit) and non-native UI skins, on the other.

Plugin systems are key to a good browsing experience; Chrome includes almost entirely the same feature set, so your argument is void; and, overall, there's no evidence that Firefox is particularly burdened by anything.

IE is catching up but limping.

IE caught up already, and I don't see any evidence that it's "limping"

Webkit is not updating that fast anymore.

Well, there are fewer contributors now. But it's kind of hard to draw any conclusions about how fast it's updating given how little time has passed since Blink forked.

Anybody holding their breaths for full ES6 support?

Yep, we're making good progress, and Firefox 29/Chrome 33 are doing better than ever. Still work to be done, but the ES6 spec isn't even finished yet, so that's to be expected.

In other words, chill out. Everything's looking pretty good, there are loads of excellent browsers available, and they're mostly getting better. It's not perfect, but what platform is?

lelandbatey• 12 years ago

If I may chime in on this:

    > IE is catching up but limping.
    IE caught up already, and I don't see any evidence that it's limping.

I actually kind of agree, and I'm surprising myself in saying that. Just from a consumers perspective, I found at least one place where IE offers something that I directly wanted to do that couldn't be done on any other browser.

I wanted to watch a HD Netflix on my laptop, but the Silverlight client had no hardware acceleration so it played terribly. Turns out, there is a hardware accelerated HTML5 version of Netflix that's only usable using IE since only IE has the necessary DRM.

I was quite surprised. Ignoring the potential ethical quagmire here, I thought it was interesting that there was something where IE gave me a better experience.

gress6• 12 years ago

This is misdirection. The allegation is that Google is using it's market power to subvert the standards process and subvert the open web it once championed now that it is powerful enough to do so.

coldtea4• 12 years ago

"competing engines would be good for the web"? They will.

Citation needed. Because, to support my argument, we just saw a "competing engine" starting to divert from the others. And not only in this case -- just the other day the Google team announced they'd drop CSS Regions too.

Would it be as easy for Google to do so, if they were still sharing Webkit code with all the other Webkit partners?

IE caught up already, and I don't see any evidence that it's "limping

Well, we still have to support IE10 (some also IE9). Everytime, every version gives something new, but holds something back that the latest other browser engines already have. E.g IE9 and WebGL.

Webkit is not updating that fast anymore. Well, there are fewer contributors now. But it's kind of hard to draw any conclusions about how fast it's updating given how little time has passed since Blink forked.

Nope, also before. Google had published commit stats in the time of the fork, and Apple had considerably slowed down commits for couple of years or so before that.

masklinn3• 12 years ago

Anybody holding their breaths for full ES6 support?

For which browser? Because currently, Gecko leads by a half marathon, and it's a marathon: http://kangax.github.io/es5-compat-table/es6/

chucknelson• 12 years ago

Any "insiders" have comments on this? Is this the Chrome team just trying to keep pushing forward, or are they technically sticking to the referenced compatibility guidelines they published?

I'm just wondering if there has been a lack of progress with Shadow DOM and their solution is just go-go-go to get things moving.

bzbarsky5• 12 years ago

From the shadow DOM spec author: https://groups.google.com/a/chromium.org/forum/#!msg/blink-d...

There's been a lack of progress in that it's taking a while, but there are a bunch of still-open unresolved issues... The problem with big complex features. ;)

Helianthus2• 12 years ago

They're commenting in this topic, and they seem clueless as to why anyone would object at all.

fidotron4• 12 years ago

This is because Google are trying to turn Chrome into an app platform to rival Cocoa, while almost every other web player (except Mozilla) has a vested interest in keeping the web a document viewer platform.

The recent arguments regarding Adobe's arbitrary region stuff were very enlightening on this.

jlongster2• 12 years ago

Mozilla has a vested interest in keeping the web a "document viewer platform"? Are you serious? Have you even heard of Firefox OS?

chrisrhoden• 12 years ago

while almost every other web player (except Mozilla)

RivieraKid5• 12 years ago

Exactly my thoughts. Web is a shitty app platform. And because it's a decentralized platform – the specification is developed separately from the implementations – it's moving forward too slowly.

Currently, the native platforms and the web is a mess imho. Tons of web standards, android, ios, linux, windows, osx, etc. Web and native platforms have different strenghts but there's no platform that combines them. I wish there was one solid, well-designed platform for both interactive documents and applications and for both mobile devices and desktops.

I'm (no longer) a fan of Google, but I'm beginning to think that if Google did this with Chrome, it would be a positive thing. Imagine the massive amount of programmer man-hours it would save.

pcwalton8• 12 years ago

I'm (no longer) a fan of Google, but I'm beginning to think that if Google did this with Chrome, it would be a positive thing.

Just so we're clear, you think that it would be a positive thing if Google unilaterally dictated Web standards by using its market power?

wwweston• 12 years ago

Tons of web standards, android, ios, linux, windows, osx, etc.

There was a time in the not too distant past that there was pretty much one dominant computing platform, and it wasn't exactly elysium.

I get the problems with web standards (right now I have a front end engineering job) and the multiplicity of platforms, but I'll take that over monopoly monoculture.

pcwalton8• 12 years ago

almost every other web player (except Mozilla) has a vested interest in keeping the web a document viewer platform.

How do you explain the fact that Mozilla representatives at the WG are also opposed to Google's move here then?

fidotron4• 12 years ago

Those are mere technical arguments.

Apple and MS, for example, have active interest in preventing Google's vision from happening.

kenferry2• 12 years ago

I think you're thinking of entities like "Apple" where it is more useful to think of "the people working on WebKit at Apple".

WebKit is what they do, all day, every day. They love the web, that's why they chose to go get a job working on it.

To say that the people working on WebKit don't want the web to succeed as an app platform is not something I have ever seen. Go hang out in #webkit on IRC and see what you think.

Edit: oh, right, so what IS going on? Exactly what it looks like: once you ship API, as Tab says, it DOES become very difficult to change due to compatibility requirements. That's why you do API review. People are saying, "why are you strong-arming this through?" It's not malicious.

I do also have sympathy for Tab. Progress on the web has a committee model, and committees suck. I don't know how they ever get anything done. Maybe it would be better if everything just fragmented, at least it'd move faster.

fidotron4• 12 years ago

Actions speak louder than words though.

Apple already have integrated and deployed the Adobe CSS regions stuff, Google say it's just not their priority this year and would have performance implications on mobile. This is the weasel way to say they don't care, much as Apple are here. The devs may feel otherwise, but they are beholden to their managers who will be well aware of the strategic implications of their work.

Google see Chrome as the best way to bust the iOS App Store, and as such Apple will mysteriously make the e-books in WebKit vision more compelling in the near future than the in browser app development one.

I'm not saying I agree with Google here (though more for tech reasons), just that we need to be clear that the web is experiencing a schism, and that there are certain subjects which it is hopeless to expect agreement on. This is one of them.

thrownaway2424• 12 years ago

What do you think Chrome people at Google do all day? Cold-call ads leads?

marcosscriven• 12 years ago

One thing that irritates me is that Apple still don't support WebGL in iOS Safari. Even on the desktop version it has to be manually switched on as a 'developer' tool. And it's clearly technically possible - iAds can use it!

gress6• 12 years ago

That's because they aren't satisfied that it's secure enough for the open web yet and they don't want to expose their users to risks they can't protect themselves from.

bryanlarsen• 12 years ago

Here's the reply: http://lists.w3.org/Archives/Public/www-style/2014Feb/0138.h...

the money quote: "We feel the standard is sufficiently advanced, the remaining issues sufficiently small, and the benefit to authors sufficiently great to justify shipping sooner rather than later."

the Shadow DOM is pretty awesome, so I'll agree with the "benefit to authors sufficiently great" part. No comment on the rest.

mcphage• 12 years ago

This part of his reply annoyed me: "Attributing an ultimatum to my words is blatantly violating the Principle of Charity, especially since I've very explicitly clarified that I'm talking about the latter."

Given his words were "Whatever API gets shipped will be frozen almost immediately. If you want to suggest name changes, as we brainstormed a bit at the f2f, do so RIGHT NOW or forever hold your peace." ... I'm a proponent of the principle of charity, but I don't know how to read that as anything other than an ultimatum.

chc9• 12 years ago

This is the other way of reading it: He's essentially saying, "Once this is shipped, the cat will be out of the bag and we will not be able to put it back in, so if you need the cat for something, you should do it now." That's not what is traditionally meant by "ultimatum," because an ultimatum implies that you want someone to do something and will do something else to injure them if they fail to meet your demands.

munificent3• 12 years ago

By "be frozen" he didn't mean "Google will declare it to be unchangeable", he meant "users relying on it will prevent any of us from being able to change it." If it's an ultimatum, it's the users of the feature that are holding the gun, not Google.

Tab clarified what he meant in a response:

    By the way, I deeply apologize for the confusion revolving around my
    use of the term "freeze".  That term is used internally (within the
    Blink team) to indicate something that's no longer changeable (or at
    least is probably too difficult to change) *due to compat pain*.  I'm
    aware that there are other uses of the term, like "feature freeze",
    that imply a much more deliberate *decision* by somebody to stop
    making changes.
    
    I forgot about those additional meanings and was intending just the
    more popular internal meaning.  While I've certainly used that meaning
    in public, and have heard other people use it or other relatively
    close phrasings, I should have given more thought to the term and used
    something less likely to be confusing.

randallu3• 12 years ago

I disagree that the Shadow DOM is pretty awesome. I think scoping style is valuable, but building components that are exposed as new tags is not appealing given the vast complexity of the implementation and the limitations of tags.

Markup has a very weak type system (strings and children) which makes building complex UIs more painful than it has to be (this also stands for markup driven toolkits like angular and knockout -- where the equivalent of main() is HTML markup and mostly declarative). Markup isn't a real programming language, and it's very weak compared to a true declarative programming language.

JavaScript however is a real programming language with all of the constructs you need for building extensible systems. For building anything complex (which is where Shadow DOM should shine) you will need to use extensive JS, you will need your Shadow DOM components to expose rich interfaces to JS... At which point, why are you still trying to do mark-up first -- it's something that's more "in your way" than helpful.

caitp2• 12 years ago

While you're perfectly allowed to disagree, it sounds like what you're saying is this:

"Collections of div-soup activated by jQuery plugins are the way to write maintainable web applications that make sense"

It's not as though Javascript has no role whatsoever in custom elements, but really, there's a lot to be said about how this way of working will be a huge improvement over the current jQuery + div-soup status quo.

ebidel• 12 years ago

The Custom Elements[1] and Shadow DOM[2] specifications have little to do with each other. The former is useful for defining new elements in HTML, along with properties and methods. The latter can be used to encapsulate the style/dom of that element's internals. So each technology is useful by itself and can be used standalone. When used together, that's when magic happens :)

[1] http://w3c.github.io/webcomponents/spec/custom/ [2]: http://w3c.github.io/webcomponents/spec/shadow/

curveship2• 12 years ago

Thank you! I thought I was the only one who felt this way. I truly do not understand why Google feels that application composition should happen at the presentation layer rather than the code layer, particularly when the presentation layer is as weakly typed as HTML. This was tried and failed in the very first round of server-side web frameworks back in the mid-late 90s. More recently, the complexity of Angular's transclusion logic should have clued them in that this is an unwieldy idea.

I agree that some kind of style scoping construct would be a good addition, and far simpler than ShadowDOM. Simple namespacing would be a good start. It would be a more elegant solution to the kludgy class prefixing that has become common (".my-component-foo", ".my-component-bar", etc.)

malandrew4• 12 years ago

Yes, yes, a million times yes.

The biggest problem with this weak type system is obvious with CSS3 Matrix Transforms. CSS3 matrix transforms are the biggest bottleneck preventing fast updates to many DOM elements. Without fast updates of many elements across an entire page (window), pulling off the awesome smoothly animated effects found in modern desktop and mobile operating systems is pretty much impossible, especially in a system that implements immediate mode graphics over retain mode (DOM).

Marshalling matrix3d updates from numbers in an array of length 16 to a stringified array to apply it to an element, only to have the browser have to convert that stringified array back into an array of 16 numbers is insanity.

If you want performance, you need a more robust type system than just strings and children. I'm an engineer at Famo.us and we would absolutely love it if we could do something in javascript like element.set3DTransform(someLength16Array); We could simultaneously update thousands of DOM elements if arrays and typed arrays were supported instead of stringified.

chris_wot• 12 years ago

The following reply does not inspire confidence:

Sorry, this is my fault. These things were defined in the spec before, but we sliced them out for a separate spec, which I was supposed to write and haven't gotten finished yet.

http://lists.w3.org/Archives/Public/www-style/2014Feb/0113.h...

sw87• 12 years ago

Everyday a little bit closer, Google the new Microsoft. Not surprising.

chc9• 12 years ago

Were you not around during the dark days of IE? "Pushing for quick progress on standards" was not exactly a major complaint people had against them.

chadwickthebold• 12 years ago

I thought the issue was exactly that - that MS pushed for adoption of proto-standards before there was any sort of agreement on how they should actually be interpreted/implemented.

reuven• 12 years ago

Last week, I was giving a lecture on HTML5, starting with the origins of the Web, HTML, and the "browser wars." I indicated that the browser wars were an attempt by two companies (Netscape and Microsoft) to add tags without checking with anyone else, in the hopes of getting market share.

As I got to this point in the lecture, I paused, and realized for the first time that Google is often playing a similar game with Chrome.

Everyone agrees that standards are time-consuming, bureaucratic, and prone to all sorts of compromises. But the goal of standards isn't the speed of the process, but rather the inclusiveness of the process. (And yes, you can make a case for the W3C not being so inclusive...)

It's great that Google is interested in treating Chrome as a laboratory for new Web technologies, but I think that some added humility would be in order. It's one thing to say, "We think that this might work well, and are throwing it out there to see what will stick, keeping the good stuff and throwing out the bad." But instead, they seem to be saying, "We think that this is good enough for a standard, never mind the process." And that can't be good for the Web.

chc9• 12 years ago

That is how roughly all progress on the Web ever has happened. The existence of HTML5 is a testament to that — the W3C was lost in the woods for years and years trying to make XHTML 2 with nothing to show for it. Meanwhile, the browsers were coming up with their own ideas. So the WHATWG came along and specified what the browsers were already doing, as well as a few simple improvements. I think we can all agree HTML5 was a good thing. Well, if you think so, then you agree that progress coming from the browser implementers is often a good thing.

The problem in the browser wars was that they were trying to be incompatible, which is not really the case with Google. (Remember, Microsoft's model was not "Embrace, extend, evangelize.")

josteink6• 12 years ago

Last week, I was giving a lecture on HTML5... and realized for the first time that Google is often playing a similar game

I'm not going to be calling you names, but if you've been looking this has been obvious for at least a year now.

Chrome was released to enable all the bad stuff Google is doing now.

potch8• 12 years ago

The problem is the standards process exists to keep people from swinging their weight to force rushed/poorly thought-out technologies into a platform some already accuse of fragmentation and bloat. And to people who "But this is Google!" Throwing the process under the bus today because you think your favorite tech company can do no wrong screws everyone later when management changes. Management will change. The process is here to protect the web's interests regardless of whether any one actor's intent is good or not. If Google steamrolls everyone today, who will steamroll everyone tomorrow? The MPAA is on the W3C too.

camus2• 12 years ago

the problem is the web today is not what a proper application plateform should be. Developpers have waited long enough, we need more features and it takes way to long for the W3C to deliver.

At the same time, HTML5 was a coup orchestrated by the Whatwg on the future XHTML spec, It was a mistake in my opinion because the original W3C spec was way better as we would not have the discussion we are having today about web components and the shadow dom if the W3C spec had been chosen.

So I dont know. Is google way of doing things short-sided? or does it really solves some issues? Time will tell. but maybe the lean approach the Whatwg took wasnt that "future proof" after all.

macspoofing• 12 years ago

we need more features and it takes way to long for the W3C to deliver

We also need features that work across all major browsers.

potch8• 12 years ago

When the features don't work the same way in every browser, it hurts the platform. Poorly designed features are impossible to take back. (see also AppCache). Web Components is moving quickly, but there has to be an element of care. Shipping features before they're ready is driven by marketing and PR, not engineering maturity.

gress6• 12 years ago

If you want a proprietary platform controlled by a single vendor, code for iOS or Android.

johnward2• 12 years ago

So it's almost like the IE 6 days except that in this case the standards actually are influenced by Google instead of MS just doing whatever the hell it wanted. So slightly better but still not good. Plus if there is anyone I trust to do what is right for the user it's going to be Mozilla not Google.

ajross3• 12 years ago

That argument seems isomorphic to demanding that all software design and feature innovation happen within the W3C commitee process. Certainly that's not how most successful features have worked historically...

duaneb• 12 years ago

I don't think that people have double standards for Google, it's that the potential flaws aren't obvious.... Where's the competition and alternatives? We're stuck between making decisions too quickly and Google becoming the de facto standard.

EDIT: To be clear, I find Google's actions in this regard to be surprisingly impolitic and ill-conceived. Anyone who reads it should have alarm bells.

potch8• 12 years ago

Google should respect the desire of other parties to be given adequate time to review their proposals. Being told "you have to object NOW because we're going to ship" doesn't allow third parties to actually identify technical issues. It's like someone committing code without letting their peers review that code for flaws. It's a recipe for cementing flaws into the web platform. Intended or not, there is arrogance in the notion that external discussion of Google's proposal won't improve it.

ajross3• 12 years ago

The last example seems implausible: the MPAA doesn't ship a browser and can't control features by fiat.

I guess I'm not understanding the firestorm here (rather, I am, but in an uncharitable way as YET ANOTHER !@#?! Apple vs. Google proxy war on HN). Google developed a feature they like and want to ship it. They want it to be a standard. Apple (at least this one Apple person) doesn't want it standardized yet. Google is noting that they are going to want to ship this anyway ("threatening to ship it anyway" if you swing that way).

So what? Surely this kind of argument happens any time you have a proposed standard from a single vendor. What's special about Shadow DOM that it can't tolerate this kind of disagreement?

potch8• 12 years ago

You're right, the MPAA example is inapt.

As regards what makes Shadow DOM special? It's not special. The issue is that Google has made many public claims toward a Brand New Day of participation in standards with Blink. [1] Vendors and developers were beginning to have cautious optimism that upcoming standards wouldn't be as rushed and fragmanted as they were in the past. This action directly contradicts the previous goodwill.

[1] http://www.chromium.org/blink#new-features

pornel• 12 years ago

MPAA doesn't ship a browser and can't control features by fiat.

DRM extensions (EME) have shipped in Chrome and IE already (with whole W3C process steamrolled), so it seems that MPAA does control browser features — by proxy (Google Play/Xbox video store).

grayrest2• 12 years ago

So what? Surely this kind of argument happens any time you have a proposed standard from a single vendor.

The declarative nature of CSS means you have to set syntax in order to test things out while also making it bad to deprecate syntax (no meaningful conditionals). Attempted workarounds are things like the vendor prefixes disaster.

I was under the impression that post-split Blink was going to do the same thing Mozilla does and turn on unprefixed experimental features for Canary/Beta and flag them off in the release channel until things hit CR.

There isn't a lot of debate that the feature in question is desired but it seems like goog is jumping the gun. I'd guess it's because they have internal stakeholders (polymer, angular).

P.S. If anybody on the committee is reading and cares about a random guy on the internet's opinion: +1 ::shadow, ::shadow-all

bzbarsky5• 12 years ago

What's special is that recently browsers have been much better about not randomly shipping features unless there is some consensus from the other browsers. Instead, they've been implementing them behind runtime flags, getting specs written and agreed on, _then_ shipping.

As in, recently there have in fact not been these sort of arguments because browsers have somewhat cooperated to iron out issues before shipping.

Steko• 12 years ago

"Apple (at least this one Apple person) doesn't want it standardized yet."

Downthread it's clear that Mozilla and Adobe are also against it.

om2• 12 years ago

As the Apple person in question, my primary objection isn't about whether I "want it standardized yet". It's more that this hasn't even reached step 0 of the standards process (writing an "editor's draft", a document that writes stuff up in standardese but hasn't necessarily been documented by the WG yet) and Google is saying "we're shipping now and then will likely be unwilling to change it". Furthermore, it's not like there are only some edge cases to work out.

There are also substantive objections to the content of what is being shipped. Not only on the names (which Google invited comment on) but also on the intended semantics. It's pretty hard to usefully comment on the semantics without a draft spec and some time for discussion.

That's why most browser vendors try to make sure there is at least a draft, time for discussion, and rough consensus before shipping a feature enabled and unprefixed.

For what it's worth, Apple WebKit engineers agree with many Google Blink engineers about lots of standards topics, we actively collaborate on many things, and we actively support the goals of Web Components and of this particular styling feature, if not necessarily all the details. So your "proxy war" narrative is false.

However, I feel that Google is not being a good standards citizen in taking this particular action.

mattlutze• 12 years ago

It sounds like there's issue here where Google hasn't actually proposed a standard. They have an implementation which seems to at least not be completely documented, or not at all? I can't tell with just a little reading.

So, it's more than just an Apple v Google spat, the Google fellow is just saying "we don't want to take the time, so here accept what we ship or gtfo".

serge2k• 12 years ago

If Google ships and freezes syntax then it puts huge pressure to just go with it. This is not the right way to do things.

1qaz2wsx3edc• 12 years ago

This is a bit jaded, and I mean it light heartedly. But I'd be more inclined to listen to the W3 if they'd shoot down DRM. I no longer believe they have the web's interest at heart. Might as well let Google steamroll, if they're bound to steamroll things themselves.

anon1385• 12 years ago

But Google was one of the main driving forces behind the DRM proposal…

jessaustin• 12 years ago

The original announcement implied that name-change bikeshedding was the only thing holding up this wonderful feature. TFA counters that disagreements remain over "the syntax and the semantics". ISTM that this kind of difference of opinion is expected and nearly unavoidable, but doesn't portend especially dire consequences. The difference between "feature-switch" and "google-kicks-ass-hell-yeah-suck-it-wc3-feature-switch" was a PITA in the past, but now we have tools to abstract away the details. If web developers collectively decide that the pending Chrome feature is more broken than simply having obnoxious names would imply, then we'll just have to endure another round of this when Mozilla or whoever comes out with the next version.

mathattack• 12 years ago

Well, they just made Dimitri Glazkov famous.

gress6• 12 years ago

Why is anyone acting the least bit surprised here? Google built Chrome for one reason and one reason only. So that they could control the development of web technologies.

This is the tale of the scorpion and the frog playing itself out as usual.

http://en.wikipedia.org/wiki/The_Scorpion_and_the_Frog

donrhummy2• 12 years ago

Shadow DOM is a very, very bad idea.

http://glazkov.com/2011/01/14/what-the-heck-is-shadow-dom/

It kills cross-browser compatibility, kills standards (since they're unreachable, undocumented elements that can handle input, interaction and affect other elements.

badman_ting2• 12 years ago

It's starting to dawn on me what this will really be used for, and I can't say I'm stoked about it. But the article you've linked to seems pretty upbeat about the whole thing.

grayrest2• 12 years ago

Author of the article is the spec author.

donrhummy2• 12 years ago

I linked to an article that explains what it is and left it to you (the reader) to decide if it's good or bad. I believe it is a very bad thing.

ivan_gammel• 12 years ago

Even if it will become a standard, it may be complete evil. This concept is quite complicated for regular developer, so some day we'll see petabytes of cryptic, totally undebuggable markup. It should not be done in that way.

kevingadd3• 12 years ago

The Blink team seems dead-set on repeating the mistakes they made with the Web Audio API (shipping an immature, vendor-specific API to the web without third-party feedback and then forcing it through a standards process, etc). Pretty frustrating.

cromwellian9• 12 years ago

On the other hand, the Mozilla counter proposal, which was trying to do low-latency audio by using Javascript as a DSP was pretty awful. It's like saying you'll do 3D by handing a framebuffer to JS and doing rasterization in software.

"Forcing it through the standards process" sounds like the kind of rhetoric Republicans use when bills get passed they don't like.

kevingadd3• 12 years ago

Web Audio API has a similar mechanism for generating samples with JS and it's just as bad. In fact, Web Audio is worse for playback of JS-synthesized audio, not better. And lots of use cases demand playback of JS-synthesized audio: emulators, custom audio codecs, synths, etc.

The Mozilla API did one or two things and did them adequately; it did them by extending an existing API (the <audio> element). Use cases it didn't cover could have been handled with the introduction of new APIs or extensions to existing APIs.

The Web Audio API introduced an interconnected web of dozens of poorly tested, poorly specified components that covered some arbitrary subset of cases users care about. Most of the oversights still haven't been fixed and the spec is still full of unaddressed issues and deficiencies.

ndesaulniers3• 12 years ago

The O'Reilly book shipped with the old API! http://my.safaribooksonline.com/9781449332679#safari_reviews

lmm• 12 years ago

Funny how the biggest opponents of this kind of thing seem to also be the biggest fans of Javascript, which was developed by freezing whatever syntax Netscape came up with in three days. If this had been the process back in 1990 the web would never have got off the ground.

MDCore• 12 years ago

It sounds like you're trying to say that fans of JavaScript don't like freezing syntax but that that is disingenuous because JavaScript is the result of a frozen syntax thrown together in three days. Is that accurate so far? So... freezing something and throwing it out there is good? Or finding broad consensus is good? I can't tell which approach you're going for. Which "this" process are you referring to not having happened back in 1990?

ChuckMcM2• 12 years ago

So Google is taking their cues from the Internet Explorer playbook.

Having been in (and out) of standards wars at Sun and NetApp it really cries out how challenging doing "standard" stuff is. The original IETF standards process was really powerful at keeping out cruft, it included "fully documented" and "two or three interoperable implementations, of which source code must be available for at least two of them." The goal being that someone could sit down and write an implementation, and two there were at least two pre-existing implementations they could compare against for interoperability issues/questions and testing.

But standards break down when it comes to captured market share. If you're market share capture depends on your "value add", then you don't benefit if anyone can implement the same thing and you have to stay compatible with them.

MichaelGG• 12 years ago

When did the IETF process change? From looking at SIP (with all its combined RFCs, it's one of the largest standards), there's plenty of insane cruft. There's even an RFC that takes delight in coming up with crazy messages that are technically valid and suggestions on how implementations should try to guess the intent of the message. SIP goes back to the late 90s, so the process must have been corrupted by then.

ChuckMcM2• 12 years ago

Understand I've got some emotional baggage here[1] :-)

It changed when it became more relevant than ISO, I put it right at the end of the IP/ISO war, probably 1997, 1998. Basically up until that point the people who were motivated to subvert standards efforts pretty much ignored them, they had their own transport (OSI), their own mail services (X.400) their own directory services (X.500) and basically every else. IP and its "hacked together" stuff was pretty much universally considered "on its way out" by the "players."

When it became clear that IP wasn't on its way out, and in fact it was the burdensome and complex OSI standards that were going no where, the movers and shakers switched tactics, invade the IETF meetings (which did have an abusible community participation process) and drove the organization off a cliff in order to preserve their interests.

A really really good example of that was SIP and IPV6 both of which started out pretty reasonably, (because neither the phone companies nor the networking companies thought either was going to be relevant in the 7 layer OSI world) until whoops, that is where the action is so lets get in there and "fix" it.

[1] I sat in front of 500 engineers and explained out Sun was prepared to hand over any proprietary interest whatsoever in the RPC and XDR stacks (which had been "standards track" RFCs before that has a more explicit meaning, and so had sat there implemented by everyone but not officially 'standard') only to have Microsoft and the guy they had hoisted out of Apollo/HP, Paul Leach, invest thousands of dollars in derailing that offering, for no reason other than to try to resist anything compatible being out there. It was redonkulous in its pursuit of killing ONC/RPC at every venue. But like I said, that just made it personal for me.

cromwellian9• 12 years ago

The current div-soup approach with massive JS enhancement is what is a bad idea. It abuses the document model and makes information less transparent, less semantically meaningful, and makes it hard to share and reuse components between sites due to leakage. It also makes debugging and reading the DOM in an inspector far more messy.

Scoped CSS and Shadow DOM clear up the leakage problems and introduce proper encapsulation to the web beyond heavyweight IFRAMES. The templating system lets documents expose information in transparent ways again, rather than executing a big ball of JS just to get the DOM in a state that is meaningful.

Web Development has been fundamentally broken for ages. The basic ideas to fix it have been discussed for years. Every day delayed is a day for more native encroachment.

ndesaulniers3• 12 years ago

I was happy to see this from the link in the email:

Vendor Prefixes Historically, browsers have relied on vendor prefixes (e.g., -webkit-feature) to ship experimental features to web developers. This approach can be harmful to compatibility because web content comes to rely upon these vendor-prefixed names. Going forward, instead of enabling a feature by default with a vendor prefix, we will instead keep the (unprefixed) feature behind the “enable experimental web platform features” flag in about:flags until the feature is ready to be enabled by default. Mozilla has already embarked on a similar policy and the W3C CSS WG formed a rough consensus around a complementary policy.

I remember people getting worried that app developers might tell users to dig through their about:config equivalent to access the "full version" of this site. Glad that things are moving away from vendor prefixes. Kind of sad to see web audio still vendor prefixed (and the O'Reilly book shipped with the old API, lol!), but I assume that was implemented before the webkit/blink split.

erichocean2• 12 years ago

Going forward, instead of enabling a feature by default with a vendor prefix, we will instead keep the (unprefixed) feature behind the “enable experimental web platform features” flag in about:flags until the feature is ready to be enabled by default.

For the feature's we're talking about (JS methods and CSS stuff), doing so will mean that effectively no web authors use it. It's no different than requiring a plugin to view content. Anything hidden behind a feature flag might as well not exist, at least for those two categories.

For dev tools, stuff like that? Sure, feature flags are the way to go.

tiglionabbit• 12 years ago

Oh, it's about Hat and Cat. I first saw these at a talk on Shadow DOM and the future of the web by Rob Dodson.

http://robdodson.me/blog/2013/11/15/the-cat-and-the-hat-css-...

onethree• 12 years ago

"hi relevant standards authority, you're not working fast enough for our liking, so we're doing what we wan't and if you don't like it, too bad" if this was anyone but google, there'd be a shitstorm...

ollysb• 12 years ago

On another note, how great is it going to be to have components you can reuse between angular, ember, jquery and the likes? A web-components.com repository would be awesome!

josteink6• 12 years ago

And wouldn't it be awesome if multiple parties was able to read through a draft and make comments on it and provide constructive feedback before it was finalized and pushed into production on the web, to be supported for all eternity?

That way we could have a good implementation of this whole thing.

Sadly so far everything except the "rush this unfinished thing into production"-part is missing.

Obviously Google only see their own implementation, think "all is good" and don't give a rats ass about anyone else and their opinions, but here on HN we should have a wider perspective.

josteink6• 12 years ago

I've said it before and I'll say it again:

Chrome is the worst thing which has happened to the web because of what it allows Google to do.

MSIE ruined and fragmented the web with non-standards because it was in Microsoft's interest at the time to hinder a successfull adaptation of the web.

Google however is fundamentally a web-company and now they are using Chrome to shoehorn anything which fits their company onto the open web without a standards-comitee in sight, or accepting any sort of reasonable feedback.

This breeds monsters like HTTP2.0^W SPDY^W technogizzwizz kitchensink internet everything protocol.

This is much worse than anything MSIE ever did.

rkangel• 12 years ago

Forget the technical content, or the political point here - that thread is worth reading just as an excellent example of how to conduct a civilised discussion even in a situation with serious potential for strife.

Of particular note is how, even though it does get a bit stressed in the middle, everyone very carefully allows the discussion to calm down and restate their points with no emotional content.

bsaul2• 12 years ago

Reading about google shipping unpolished things too fast in chrome makes me smile, since i've just decided to stop using it as of yesterday, after realizing how bloated that software has become ( cpu & ram wise ). Wonder if that's a coincidence.

alimoeeny• 12 years ago

what do you use instead, which has better ram and cpu footprint?

bsaul2• 12 years ago

Well, actually chrome was consuming about 1 gig of ram (if you're counting all the "Chrome helpers" processes) and 2% constant CPU when i had absolutely no page opened. So pretty much anything else is better (i'm on safari right now and it feels extremely light). Note that it's not just me : https://productforums.google.com/forum/#!topic/chrome/y8VTVH...

youngtaff3• 12 years ago

Rather than link to a comment from someone at Apple part way down the thread and starting 'burn the witch' style threads on HN perhaps the OP should have started at the beginning - http://lists.w3.org/Archives/Public/www-style/2014Feb/0032.h... - and included the Blink thread that discusses Google's position and issues in more detail https://groups.google.com/a/chromium.org/forum/#!topic/blink... - read Adam Barth's comments if nothing else

RyanMcGreal• 12 years ago

A bit late to the party, but this seems relevant:

"[W]hy do we have an <img> element? Why not an <icon> element? Or an <include> element? Why not a hyperlink with an include attribute, or some combination of rel values? Why an <img> element? Quite simply, because Marc Andreessen shipped one, and shipping code wins."

http://diveintohtml5.info/past.html

CmonDev• 12 years ago

Nothing wrong with trying to do something different. Committees are too slow.

“The working group should not agree to freeze whatever syntax Chrome ships”

Related Stories