4 ms·

I'm not saying that this is the spec that pushes CSS into the code-territory. I'm not saying there is any one spec that does. I'm looking at the aggregate of CS

I'm not saying that this is the spec that pushes CSS into the code-territory. I'm not saying there is any one spec that does. I'm looking at the aggregate of CSS4 and am afraid that we are heading in that direction. See, for example, the crazy (and awesome, btw) things you can do in upcoming selectors such as matches[1] combined with a for[2], or the mind-bender that is the shadow dom[3]. [1] http://dev.w3.org/csswg/selectors4/#matches http://dev.w3.org/csswg/selectors4/#matches [2] http://dev.w3.org/csswg/selectors4/#idref-combinators http://dev.w3.org/csswg/selectors4/#idref-combinators [3] https://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/shadow/index.html https://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/shado...

debacle 15y ago
I think the more important reality is that TIMTOWTDI doesn't really belong in CSS, and that's what we're seeing happen more and more. Part of the problem is that CSS And rich internet applications can't really properly coexist - they do now, because that's part of how we work, but as time goes on the amount of lifting we're going to want to do with JavaScript is only going to continue to increase.
nitrogen 15y ago
Does W3C publish a rationale for each spec? I searched the Shadow DOM spec for the word "rationale" and found nothing, the abstract didn't say why the spec is useful, and the TOC didn't seem to list a justification section. Reading the Introduction section, I get the impression that Shadow DOM is supposed to help with creating widget-based UIs, but if we're at that point, why are we still using the text/document-focused DOM instead of creating a new abstraction that is better suited for UI (though the insertion point concept looks potentially useful)?
jerf 15y ago
I agree with you in principle about the abstraction issues in CSS, however I would submit that CSS constant's contribution to the problem is negative. It simplifies real-world CSS to have constants, and this has frankly been obvious for about 15 years now. As for the rest of CSS, I've really been rolling around to "just create a canonical JS binding and be done with it"; it's headed headlong into the Turing Tarpit and as long as it's going to end up there one might as well use a language designed to live in it.

debacle 15y ago

I think the more important reality is that TIMTOWTDI doesn't really belong in CSS, and that's what we're seeing happen more and more. Part of the problem is that CSS And rich internet applications can't really properly coexist - they do now, because that's part of how we work, but as time goes on the amount of lifting we're going to want to do with JavaScript is only going to continue to increase.

nitrogen 15y ago

Does W3C publish a rationale for each spec? I searched the Shadow DOM spec for the word "rationale" and found nothing, the abstract didn't say why the spec is useful, and the TOC didn't seem to list a justification section. Reading the Introduction section, I get the impression that Shadow DOM is supposed to help with creating widget-based UIs, but if we're at that point, why are we still using the text/document-focused DOM instead of creating a new abstraction that is better suited for UI (though the insertion point concept looks potentially useful)?

jerf 15y ago

I agree with you in principle about the abstraction issues in CSS, however I would submit that CSS constant's contribution to the problem is negative. It simplifies real-world CSS to have constants, and this has frankly been obvious for about 15 years now. As for the rest of CSS, I've really been rolling around to "just create a canonical JS binding and be done with it"; it's headed headlong into the Turing Tarpit and as long as it's going to end up there one might as well use a language designed to live in it.