11 ms·
CSS Paint API: New possibilities in Chrome 65
- freddywang 9y agowe already had this all the way back in 2008. It's called webkit css canvas! Iconapp.io is using that heavily! background: -webkit-canvas(mycanvas);
- ithkuil 9y agowith the CSS Paint API you instantiate a new canvas like object for every time your reference the painter, while this was referencing one specific instance of a canvas, right?
- bsimpson 9y agoI don't know the internals of either. In a Paint Worklet, the canvas is generated for you, and your painter is automatically called every time an input property changes. In -webkit-canvas, you manually instantiate the canvas and manually repaint it. It's the difference between reactive and procedural programming (even though the actual painter is procedural in either case). Here's a gist I threw together showing how to use the same paint function with either API: https://gist.github.com/appsforartists/e5d2a4b7826bf5962fad142bcd255465 https://gist.github.com/appsforartists/e5d2a4b7826bf5962fad1...
- freddywang 9y agoYes, the only downside is that you have to procedurally instantiate a canvas. You get to control when the render event should happen though. With CSS Paint API, it feels like declaring webgl shader.
- matmo 9y agoI always find it interesting that Chrome is charging ahead full steam on experimental API's like this while most other browsers have given no intent to implement them yet. Did Chrome come up with Houdini? Are they being brave or pushy here?
- foob 9y agoIt's a joint W3C Technical Architecture Group and CSS Working Group initiative, you can find a lot of details in this post from the Opera developer blog [1]. [1] https://dev.opera.com/articles/houdini/ https://dev.opera.com/articles/houdini/
- mintplant 9y ago> Did Chrome come up with Houdini? Most certainly not. I know people at Mozilla who've been working on Houdini-related features for a while now (cf. https://wiki.mozilla.org/CSS/Houdini https://wiki.mozilla.org/CSS/Houdini). Chrome is just the first to release here.
- deleted 9y ago[deleted]
- dassurma 9y agoAuthor here :) Houdini is a task force that consists of people from Apple, Mozilla, Microsoft, Chrome, even IBM and Samsung. It’s by no means a Chrome-only thing or us being pushy. Servo has an experimental implementation, but it’s the part of Servo that hasn’t been merged into FF. All participating browser vendors have given very positive signals about CSS Paint API. Check http://ishoudinireadyyet.com/ http://ishoudinireadyyet.com/ to stay up to date :)
- matmo 9y agoThanks for the info. Love your youtube videos by the way :)
- tzahola 9y agoAnother day, another wart on the modern web stack.
- zawerf 9y agoYou've always been able to use a canvas normally and then create a url to it using toDataUrl. Alternatively toBlob then createObjectURL which I think might be more performant than data url which requires encoding/decoding base64. So I guess the main thing added is convenience? Am I missing something here? Adding CSS that requires corresponding JS code is also new territory isn't it (I can't think of anything else that does this)?
- zitterbewegung 9y agoEmbrace , extend and extinguish. Either that or developer ergonomics . Most likely the latter.
- zawerf 9y agoDeveloper ergonomics is good. I still remember days where you had to use images for shadows and round corners. Now it's just one line of CSS. But here it doesn't feel very ergonomic. You still need to write that JS code! Reading into it some more I think the only benefit it adds is state management (rerender on parameter change) but I don't really don't want/need CSS doing that for me.
- untog 9y agoIt says that it'll re-run the code on resize, which is a lot easier than using a canvas manually then listening for window.onresize or something. And I suppose supplying the parameters in CSS instead of via a separate JS call is nice? Also, the mention of rendering off-thread in the future is pretty great, and not possible with current methods.
- vertex-four 9y agoI believe this could avoid at least one copy of the canvas's buffer from the graphics card to the CPU and back again - which might be useful for animation performance? Also, yeah, it's a more "obvious" way of doing this - instead of rendering to an offscreen canvas and converting that to an image, just render to the right place in the first place.
- lambda 9y ago
- markdog12 9y agoThe second demo doesn't work for me, I think it's missing demo2.js? https://googlechromelabs.github.io/houdini-samples/paint-worklet/parameter-checkerboard/ https://googlechromelabs.github.io/houdini-samples/paint-wor...
- dassurma 9y ago... my bad. Last minute corrections made it worse. Will get it fixed ASAP.
- spicyj 9y agoWhy isn't text rendering supported?
- untog 9y agoThere are some odd threading issues with rendering text in OffscreenCanvas: https://bugzilla.mozilla.org/show_bug.cgi?id=801176#c29 https://bugzilla.mozilla.org/show_bug.cgi?id=801176#c29 Given the post's mention of running this stuff off-thread in the future, I suspect it's related to that.
- roblabla 9y ago> Note: As with almost all new APIs, CSS Paint API is only available over HTTPS (or localhost). This feels ridiculous. I understand why certain features would be gated behind https (camera access, stuff like that). But this feature doesn't look dangerous at all. I don't always want to deploy https. What about local websites (not localhost, but LAN) ? Am I not allowed to use those APIs then ?
- tyingq 9y ago"Https only" ensures Google's future (via AdSense, Double click, Chrome, Android, and Analytics) as the only sort of MITM that sees what mostly everyone is doing. While the https movement has benefits, don't misunderstand Google's interest as altruism. Good cause, murky motivation.
- seanwilson 9y agoOr maybe Google and Mozilla actually want to make the web more secure? Not everything has to be a conspiracy.
- anfilt 9y agoI would hardly call it secure. There have been too many failures with certificate authorities. The whole system is dependent on that weak point. Also do you keep track of the certificates issued to every website you visit? Then if you visit the website notice the certificate has changed. Do you check if it's a legitmate change ect.. If you don't keep track of certificates how do you even know you are not being MITM. You trust the certificate authority to handle that. However, certificate authorities clearly have signed or given out bad certificates. Further, it only takes one bad certificate authority to compromise the entire system. If the browsers really cared they would make sure that all login mechanism use something like J-PAKE or a private Key. That way if certificate authority was compromised the attacker would also have to know either your password or private key. Further, not everything requires an encrypted session. It just adds overhead for no good reason. If you worried about MITM injecting a zero day. It would help if the web standards did not keep getting more and more complicated increasing the attack surface. All you need there is just a simple signed hash of the page. Some things might not even need that. --EDIT-- I went on a bit of ramble there. If we want to be Mr. Conspiracy. I would say google likes adding more and more features because it makes it harder for competing browsers to exist. Not only that let's consider HTTP 2.0. The standard does require TLS, but Firefox and Google will not talk to HTTP 2.0 web-server without TLS. The large market share of Chrome for instance makes you unable to decide to run a plain text HTTP 2.0 web-server even though TLS is optional according to the standard. Even though Chrome is not the standard as specified by the standard document. I am forced to comply with how chrome and firefox are doing things. The effectively can make their own standards since there are so few browsers. The would be my Mr. Conspiracy reason why google would want to require TLS. Becuase let's face building a secure Crypto stack the meets all the requirements for TLS is not easy. So that just increases the barrier to entry.
- anfilt 9y agoQuit bloating the web... Also I am sick the HTTPs everywhere movement. What if I for what ever reason don't want to use HTTPs. We have so few browsers, that basically what they do is the defacto standard.
- jaredlunde 9y agoWat
- anfilt 9y agoTry to implement the rendering engine of a web-browser. The standards keep growing. A much simpler model could have been drafted for web content. Instead we keep hacking onto HTML adding things like CSS, JS. Then we keep adding on to those add-ons. Clearly, people are building things that are not documents. So why do we keep adding hacks to this document model? Further, when you you Google, Mozzila, ect... saying you can't you use a feature without HTTPs the effectively make HTTPs part the standard even though it's not written in the standard. For instance let say I wanted to run HTTP 2.0 web server. The HTTP 2.0 standard does not require encryption. However, because none of the browsers vendors support HTTP 2.0 without TLS. I must setup TLS to make my server accessible. It's not part of the standard, but the big browser providers effectively make it part of the standard. I don't have a problem with crypto. I just hate the browsers forcing it to be basically part of the standards. When it should be optional.
- gruez 9y agothe problem is that if it's optional, lazy/ignorant developers will never implement it, even for sites that actually need it (pretty much any sites that handle login). requiring tls for new features is just another nudge that browser developers have put in place to encourage tls adoption.
- anfilt 9y agoHowever, me as user despite bad web developers should be able to access the site if I want to. For instance in Firefox. I can't even go into about:config and enable plain text HTTP 2.0. They are trying to make choices for me.
- Aaron1011 9y ago> As of now, text rendering methods are missing and for security reasons you cannot read back pixels from the canvas. Does anyone have an idea as to what those reasons might be? I've heard of JavaScript access to certain CSS features being limited (e.g. getComputedStyle()), but I'm not sure what the benefit is here. Is there any way that user information could be leaked through a paint worklet context?
- gruez 9y agocanvas/font fingerprinting
- anfilt 9y agoFinger printing the user is the main reason why.
- bfgeek 9y agoWe made a mistake in the article there. (There aren't any security issues with pixel read-back here) I'll ping Surma on Monday to get it fixed. The primary reason we did this is to ensure there wasn't a performance cliff if you did read-back pixels. With the current API surface you can record all of the canvas commands, and play them back when you need to raster. Additionally it doesn't leak how many pixels we are actually rastering to. (hope this helps).
- bsimpson 9y agoI've written some prototypes using Paint Worklet that run in both Safari and Chrome. Safari has an experimental API called -webkit-canvas that's very similar to Paint Worklet. You can use it to write code that runs in either engine pretty easily. I've just thrown together a gist outlining how to do so: https://gist.github.com/appsforartists/e5d2a4b7826bf5962fad142bcd255465 https://gist.github.com/appsforartists/e5d2a4b7826bf5962fad1... It's not quite a polyfill, because -webkit-canvas doesn't automatically repaint when you change an input property. Otherwise, it would be pretty simple to write one. I may write a proper tutorial at some point. Hopefully this gives other interested folks a push in the right direction, in the mean time.