This is what happens when excitement overrules sane design principles. People seem to have all but forgotten about why we tried to separate HTML, CSS and JS. Now it seems to converge on the idea of everything being a JS library and JS being a structure of the Web, instead of HTML.
I don’t see it that way at all. The practical implication of the Houdini features (viewed in total, not just this piece of them), at least aspirationally, will be that it’s easier to factor custom design elements into their declarative parts and their procedural parts. There’s a lot of black-box complexity within CSS as it currently stands, and it makes sense to open that up so it can be extended and modified.
But then you lose predictability. It’s one thing for a browser to optimize CSS knowing exactly how it works, but as soon as you have to accommodate arbitrary imperative code from outside all optimization bets are usually off.
I take that point for sure, but it’s really a performance concern rather than a code health one, isn’t it? I defer to browser vendors as to whether Houdini will hurt performance unacceptably; I don’t feel qualified to have an opinion.
I’m a bit concerned about the XSS security implications as this allows even more scripting from even more places. I guess it is another reason to be very strict on the whitelists for any user content.
Realistically, CSS already has more security implications than anybody really wants to think about. Everyone should already be treating it as attack surface. This API does make things worse; it was previously difficult but possible to reason about the security implications of an isolated CSS snippet, and now it’s not possible without considering the entire page and all its scripts as well. Maybe that change will get more people to use the caution they already should have been…
I propose having several API releases with absolutely nothing in them so that browsers can catch up with the “extremely exciting” eye cancer already there. See caniuse browser scores for more. Also, I would like a pony.
If you would like to criticise this API or web APIs in general, could you please do it in some sort of constructive manner? I have no idea what your comment was about, other than that you seem angry about something.
What does this do better than the canvas element? And why is it specifically part of CSS?
The
houdiniproject aims to let you polyfill (future) CSS features rather than waiting for them to be implemented everywhere.Once
houdinisupport rolls out to all your target browsers, you won’t have to write a bunch of fallback CSS.This is what happens when excitement overrules sane design principles. People seem to have all but forgotten about why we tried to separate HTML, CSS and JS. Now it seems to converge on the idea of everything being a JS library and JS being a structure of the Web, instead of HTML.
I don’t see it that way at all. The practical implication of the Houdini features (viewed in total, not just this piece of them), at least aspirationally, will be that it’s easier to factor custom design elements into their declarative parts and their procedural parts. There’s a lot of black-box complexity within CSS as it currently stands, and it makes sense to open that up so it can be extended and modified.
But then you lose predictability. It’s one thing for a browser to optimize CSS knowing exactly how it works, but as soon as you have to accommodate arbitrary imperative code from outside all optimization bets are usually off.
I take that point for sure, but it’s really a performance concern rather than a code health one, isn’t it? I defer to browser vendors as to whether Houdini will hurt performance unacceptably; I don’t feel qualified to have an opinion.
I’m a bit concerned about the XSS security implications as this allows even more scripting from even more places. I guess it is another reason to be very strict on the whitelists for any user content.
Realistically, CSS already has more security implications than anybody really wants to think about. Everyone should already be treating it as attack surface. This API does make things worse; it was previously difficult but possible to reason about the security implications of an isolated CSS snippet, and now it’s not possible without considering the entire page and all its scripts as well. Maybe that change will get more people to use the caution they already should have been…
Glad to hear that a replacement for -
background: -webkit-canvas(...)is making it onto a standards track. https://webkit.org/blog/176/css-canvas-drawing/This is super-interesting, I can’t wait for support to roll out to more browsers.
I propose having several API releases with absolutely nothing in them so that browsers can catch up with the “extremely exciting” eye cancer already there. See caniuse browser scores for more. Also, I would like a pony.
If you would like to criticise this API or web APIs in general, could you please do it in some sort of constructive manner? I have no idea what your comment was about, other than that you seem angry about something.