4 ms·
> There's just so much complexity in even the 1.1 spec. Not sure if you meant to imply that, but "even" here suggests that 2.0 is an increase in complexity ove
by _delirium 10y ago
> There's just so much complexity in even the 1.1 spec.
Not sure if you meant to imply that, but "even" here suggests that 2.0 is an increase in complexity over 1.1, which I'm not sure is true. There is some new stuff, but also a lot of edge cases simplified and entire bodies of cruft ripped out (for example, XML DTDs and all associated baggage are gone).
- jancsika 10y agoYes, that's what I meant. Off the top of my head: 2.0 adds mesh gradients, a "bearing" command to path data, text that wraps (or possibly fills a cavity/shape, can't remember), manual z-ordering, and probably other new features that I didn't notice. However, it sounds like the browsers have essentially rejected a lot of those new features. If the idea is that they instead use the 2.0 spec only for the clarifications and cruft cleanup that you mention, that would reduce complexity and be a good thing.
- stuaxo 10y agoSome of the features, like mesh gradient have polyfills. Polyfills are the only way this chicken and egg problem will be solved, if widely used browser vendors will eventually implement the standards.
- jancsika 10y agoI'm only speculating, but the problem may be the complexity of the paint server interface. Using it requires FuncIRIs which-- as one commenter on another thread pointed out-- can cause name collisions with inline SVGs. You could of course abstract away that problem with javascript post-processing-- but then you have yet more complexity, this time for a problem that doesn't exist in the domain of CSS. That limits the expressivity of the feature. For example, I wouldn't be able to just play around with SVG mesh gradients inside about:blank in Firefox due to a deeper problem with resolving FuncIRIs. Whereas I can trivially create a CSS gradient there and experiment with them.