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.
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.
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.
Your cat analogy still sounds like an ultimatum to me: threatening someone with not being able to work with the cat unless they acquiesce to their demand to work with the cat on a very short timeframe.
Here's how the email fits your definition of an ultimatum:
Demand: that the working group suggest changes to the proposal "RIGHT NOW."
Injury if they don't comply: Google will ship the API anyways and freeze it so the working group can't later change it without breaking compatibility with a major web browser.
> We've been working on Shadow DOM in the open for 2 years
There are references in the thread to a f2f that happened a week ago, but this implementation has been evolving for a Long time now. The most vocal respondents only seem to be concerned about the phrasing, and haven't indicated publicly that they have anything technically substantive to add to the discussion anyway.
Thanks - I did continue to read and looked into the spec bugs. I guess I didn't consider Boris, Dimitri, or Tab as being all that outspoken about the so called 'freeze' - one acknowledged the poor word choice, but that's about it.
No, that is not the form of an ultimatum. In an ultimatum, the threat will only come to pass if the target does not comply with the demand — it's an either-or situation, with the threat used as leverage to get what you really want. Google isn't saying, "Either suggest some stuff or we will ship the Shadow DOM API. We don't want that to happen, right?"
The message was of the form of an advisement rather than an ultimatum. It is similar to "Hey, everybody, I'm putting these cupcakes out. Get them fast because when they're gone, they're gone." I don't think anybody would hear that and say, "Hey, stop throwing around ultimatums." The "threat" is not a threat — it's a heads-up about something that is going to happen, so that people have a chance to respond adequately.
You can still say that Google was not considerate enough in what they did, but there is definitely a reading of the message that is not an ultimatum.
You're still confusing two constructions. There's no "or" in Google's message. They're doing to do what they're going to do, regardless of anyone else's actions. They're giving advance notice, but not an opportunity to change their plan.
It's the same distinction as between these two sentences:
"Give me your wallet or I'll drop this piano on you."
"I'm going to drop a piano, you might want to get out of the way."
The big difference here is "something is going to happen" vs. "something is going to happen to you". A threat or an ultimatum implies that you're the specific target of the action. An advertisement or notification implies that someone is going to take some action that may possibly affect you, but isn't specifically directed at you.
The boundaries get fuzzy when billion-dollar corporations get involved because they tend to wield a lot of power. However, most people would say that if you're a startup and a competing startup says "We're going to launch a new feature; better get ready", that's not an ultimatum. (As startups go, that's pretty damn polite.)
It reads as an advisement, but it really is an ultimatum. the analogy you provide about advisements is that something is going into effect which the adviser has no power over. However, Google does have the choice whether or not this goes through. It's not the weather, it's not a god, there are people that make decisions and they can be modified. That is where the ultimatum is, just disguised as an advisement.
You criticized the analogy and ignored the entire rest of the text which made my point entirely clear. Why do people do this?
OK, fine, here's another analogy: "I'm going to be leaving in 10 minutes, so if you have any questions, you'd better ask them now." The thing being "threatened" here is entirely in the speaker's control — he could opt not to leave. So is that an ultimatum? I don't think it would generally be viewed that way. Why? Because there is no threat being used as leverage to get something — the speaker (i.e. Google) isn't really making demands here, but rather stating what it's going to do. The thing being "threatened" will happen regardless; this is just an advisement that it will happen so that you can respond accordingly.
Put another way, the "threat" component of an ultimatum can't be unconditional. It is conditioned on noncompliance. AFAIK that's the defining characteristic of an ultimatum. It is possible to read this as being a conditioned threat, but it seems entirely reasonable to me to read it more in the spirit of "I'm going to do something, so here's your chance to get ready." It's entirely possible that Google doesn't care if it receives any further input (which is theoretically the "demand" in this ultimatum).
What's being threatened is that something will be shipped and frozen without review, input, or comment, if comment isn't made immediately - not that something is going to be shipped.
Exactly. Not shipping this feature hidden behind a flag is an ultimatum.
If the feature is hidden behind a flag, then only developers experimenting with the feature will turn it on an use it, but they will never venture to make a production app since they can't expect their users to also have that flag turned on.
If the flag is shipped in the on position, developers will take that as a sign to start shipping features using it to production.
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.
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."
And that's only a problem because Google decided to ship it now, RIGHT NOW instead of caring about the standards process and maybe holding off for a little bit.
Maybe, but "We want to ship now!" is a VERY different statement than "We want to lock in the API now and refuse to change it later!". I have a great deal of sympathy for the first one.
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.
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.)
Well, for one thing, div-soups are hard to read, create deeply nested DOMs, and lack semantics or transparency. If you're trying to preserve the nature of the web, which is transparent, indexable data, one where "View Source" actually has some use to you, then having a big ball of JS instantiate everything is very opaque.
The phrase "div-soup" makes me reach for my revolver. It seems to be a straw man that means "Either you're for Web Components or you're for the worst of web engineering."
- How does ShadowDOM (or Web Components more generally) make your DOM shallower? It's still the same box model. Deeply nested DOM structures are usually the result of engineers who don't understand the box model and so over-decorate their DOMs with more markup than is semantically or functionally necessary. Nothing in ShadowDOM (or, again, Web Components) changes this.
- Are custom elements really more transparent than divs? If "View Source" shows <div><div><div>...</div></div></div>, do you really gain much if it shows <custom-element-you've-never-heard-of-with-unknown-semantics><another-custom-element><and-another>...</etc></etc></etc>? Proponents of Web Components seem to imagine that once you can define your own elements, you'll magically become a better engineer, giving your elements nice, clear semantics and cleanly orthogonal functionality. If people didn't do that with the existing HTML, why will custom elements change them? At least with divs, I can be reasonably sure that I'm looking at a block element. Custom elements, I got nuthin'. They're not transparent. They're a black box.
- Finally (and more importantly), we already solved the "div-soup" problem. It was called XHTML. Custom elements in encapsulated namespaces! Composable libraries of semantically-meaningful markup! How's that working out today? It's not.
TL;DR: a common presentation DTD is the strength of the web, not its weakness. Attempts to endow web applications with stronger composition/encapsulation should not be directed at the DOM layer but at the CSS and JS layers above and below it.
1. Shadow DOM scopes down what CSS selectors can match, so deep structures can hide elements from expensive CSS rules.
2. Custom Elements promote a declarative approach to development, as opposed to having JS render everything.
3. XHTML was not the same as Shadow DOM/Custom Elements. XHTML allowed produce custom DSL variants of XHTML, but you still ended up having to implement them in native code as trying to polyfill SVG for example would be horrendously inefficient.
4. The weakness of the web is the lack of composeability due to lack of encapsulation. Shit leaks, and leaks all over the page. Some third party JS widget can be completely fucked up by CSS in your page and vice versa.
A further weakness is precisely the move to presentation style markup. Modern web apps are using the document almost as if it were a PostScript environment, and frankly, that sucks. We are seeing an explosion of "single page apps" that store their data in private data silos, and fetch them via XHRs, rendering into a div-soup.
The strength of the web was publishing information in a form that a URL represented the knowledge. Now the URL merely represents a <script> tag that then fires off network requires to download data and display after the fact. Search engines have had to deal with this new world by making crawlers effectively execute URLs. I find this to be a sad state of effects, because whether you agree or not, the effect is to diminish the transparency of information.
You give me an HTML page, and I can discover lots of content in the static DOM itself, and I can trace links from that document to other sources of information. You give me a SinglePageApp div-soup app that fetches most of its content via XHR? I can't do jack with that until I execute it. The URL-as-resource has become URL-as-executable-code.
Both are needed!
Javascript is great for portability of apps that would otherwise be done in a native environment (you wouldn't want to index these anyway). Isn't there a standard mime type to execute js directly in browsers? There should if not.
If you care about being searchable and having designs that are readable on a variety of devices, powerful and degradable markup is very useful.
Or search engines could use URLs with a custom browser that man-in-the-middles XHR and WebSockets to effectively crawl APIs, since the APIs theoretically are semantic by default.
execute url, index all XHR and websocket data, follow next link and repeat.
> If "View Source" shows <div><div><div>...</div></div></div>, do you really gain much if it shows <custom-element-you've-never-heard-of-with-unknown-semantics><another-custom-element><and-another>...</etc></etc></etc>?
You can extend the semantics of existing elements so you'd actually have <div is="custom-element-with-some-unknown-semantics-but-its-still-mostly-a-div">. Unextended tags are for when nothing in the existing HTML spec mirrors the base semantics you want.
Of course nothing stops people who did bad things before from doing bad things in the future, but it doesn't make tag soup worse.
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 :)
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.
I'm saying that DOM through its relationship to HTML has weaknesses that make it unsuitable for building application components out of. "jQuery-enabled div-soup" is an example of how mixing presentation with model and logic yields unmaintainable results.
I have been interested in React.js recently, since it provides an interface to create reusable components and to use them inside a rich programming language with full types. I think that's a better example of a competing idea.
My experience is with building single page apps from scratch, so maybe there's a common use-case (embedding a twitter widget, or a 3rd party comment system in a blog) that Shadow DOM and Custom Components will address that I'm not familiar with.
FB React is a good example because it's living more in the presentation layer. But Custom Elements offer some things that React doesn't (as far as I'm aware).
One is better encapsulation, another is a well defined styling system (although obviously this article shows that this is not a super simple problem to solve, I'm certain that a good way of doing this will be around before too long) --- finally, and the most important thing, is that it's just baked into the platform itself, so interop between different frameworks is less of a pain.
For instance, suppose you want to use a particular Ember component in your Angular app. You probably don't want to include the entire Ember environment, and you want it to play nicely with Angular's idea of data binding and local scopes. Can you even do this? If you can, how much effort does it take, and how much does it degrade the application?
So, we've got: interoperable components/widgets. Easily style-able widgets. Elements with some semantic purpose. Simplified documents. Reusable templates (which, once HTML imports are pref'd on by default, should be easily host-able on CDN hosts).
There are a lot of benefits to baking this into the platform, despite making the platform an even bigger, crazier mess than it already is. It should hopefully give us better (and better designed) tools to work with.
Granted, I'm not saying it's going to solve every (web) problem ever, nothing ever does.
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.
Yeah, the CSS OM is really horrible too. CSS Animations is another area where you end up feeding huge generated strings into the DOM -- in theory Web Animations is meant to improve this, though personally I feel like the API too high level and ends up being really large because of this :(.
In your example, I think it'd only be a small patch (for WebKit, where my experience is) to optimize "elem.style.transform = new WebKitCSSMatrix(a,b,c,d)" without intermediate stringification. Mozilla doesn't expose a CSSMatrix type unfortunately. I've done some similar things for other CSS properties in WebKit -- have you considered submitting a patch? I've found the WK guys super receptive to small optimizations which don't change observable behavior (i.e.: you can't tell if the WebKitCSSMatrix was stringified or not currently) like that.
We're not über familiar with the internals of the browser or how to go about submitting a patch that fixes this. We did talk to people at Mozilla about this, but we still have to follow up on that.
Do you contribute to this area of Webkit? I'd love to chat more about this with you. Email is in my profile. Use the famo.us one.
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.
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.