Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

CSS Paint API: New possibilities in Chrome 65

developers.google.com

Post reply on HN
Print view View original

11–20 of 59 posts

Re: CSS Paint API: New possibilities in Chrome 65

#11

Post by zitterbewegung »

zawerf wrote: post #7

You'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 tha…

Embrace , extend and extinguish. Either that or developer ergonomics . Most likely the latter.

Re: CSS Paint API: New possibilities in Chrome 65

#12

Post by roblabla »

> 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 ?

Re: CSS Paint API: New possibilities in Chrome 65

#13

Post by ithkuil »

freddywang wrote: post #2

we 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);

with 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?

Re: CSS Paint API: New possibilities in Chrome 65

#14

Post by untog »

zawerf wrote: post #7

You'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 tha…

It 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.

Re: CSS Paint API: New possibilities in Chrome 65

#15

Post by vertex-four »

zawerf wrote: post #7

You'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 tha…

I 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.

Re: CSS Paint API: New possibilities in Chrome 65

#16

Post by lambda »

zawerf wrote: post #7

You'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 tha…

CSS Houdini is a multi-vendor effort to make more aspects of CSS layout scriptable rather than all having to be specified ahead of time.

https://ishoudinireadyyet.com/

This gives a much greater ability to iterate rapidly on new layout and styling details, polyfill for specifications that aren't widely implemented yet, and hook into some parts of the browser stack that you previously just had to use as is and trust that if you need a new feature, it would eventually be specified and/or implemented.

I think this article does the best job of explaining the whole effort:

https://www.smashingmagazine.com/2016/03/houdini-maybe-the-m...

Re: CSS Paint API: New possibilities in Chrome 65

#17

Post by zawerf »

zitterbewegung wrote: post #11
zawerf wrote: post #7

You'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 tha…

Embrace , extend and extinguish. Either that or developer ergonomics . Most likely the latter.

Developer 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.

Re: CSS Paint API: New possibilities in Chrome 65

#18

Post by untog »

spicyj wrote: post #10

Why isn't text rendering supported?

There are some odd threading issues with rendering text in OffscreenCanvas:

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.

Re: CSS Paint API: New possibilities in Chrome 65

#19

Post by tyingq »

roblabla wrote: post #12

> 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 ?

"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.

Re: CSS Paint API: New possibilities in Chrome 65

#20

Post by zawerf »

lambda wrote: post #16
zawerf wrote: post #7

You'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 tha…

CSS Houdini is a multi-vendor effort to make more aspects of CSS layout scriptable rather than all having to be specified ahead of time. https://ishoudinireadyyet.com/ This gives a much greater ability to iterate rapidly on new layout and styling details, polyfill for specifications that aren't widely implemented yet, and hook into some parts of the browser stack that you previously just had to use as is and trust th…

Within the context of Houdini, the Paint API is less weird to me now.

There are so many warts in CSS that I really wish I could customize. For example if I wanted to add a outside-aligned instead of center-aligned stroke to text, you can only accomplish it with lots of hacks: https://css-tricks.com/text-stroke-stuck-middle/ https://css-tricks.com/adding-stroke-to-web-text/. Using pseudoelements hidden behind, a circle of text-shadows, etc.

I wonder if there's anything in the Houdini project that will let me fix this. This paint api is useless to me since it doesn't give me the original contents of the dom being styled (so I would need to redraw the text, style it and layout it on my own). The solution I ended up with is using svg filters: https://www.smashingmagazine.com/2015/05/why-the-svg-filter-.... But a unified solution to customizing CSS without needing to call it a hack would be nice.

Post reply on HN