
CSS Paint API: New possibilities in Chrome 65 - syrusakbary
https://developers.google.com/web/updates/2018/01/paintapi
======
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 ?

~~~
Ajedi32
From a purely technical perspective I agree. There's no reason this has to be
behind HTTPS.

I don't think this was done for technical reasons though. Rather, it's an
attempt to drive further adoption of HTTPS with the ultimate goal of phasing
plain HTTP out of mainstream use entirely.

For websites on LAN you can either install your own root cert on client
devices, or assign the site a public domain name (even if the site itself
isn't accessible from the public internet) and get a publicly-trusted cert
that way.

~~~
hungerstrike
> install your own root cert on client devices...

That’s a pain in the ass just to test a local website.

~~~
Ajedi32
If you're just testing on localhost, there should be no need for a cert. As
the article says, localhost is treated the same as https here. In the future,
I expect all features that require a secure context will start treating
localhost as secure, if they don't already.

~~~
hungerstrike
I usually have 2 or 3 devices that I need to test a website on, so no -
localhost alone doesn't help at all. For example: I run the website on my
workstation and I want to test it on my iOS and Android devices.

With this recommendation, I have to generate a certificate and install it
everywhere just to test simple functionality.

Since Google recommended the ".test" domain for internal testing that's what I
use. In the past I had used ".dev" (now owned by Google) and ".local" (now
used by Apple for bonjour networking) to setup test domains on my LAN. So,
Google should allow these features through for ".test" at least.

Honestly, they should make it a flag that developers can toggle at the very,
very least.

~~~
Ajedi32
\--unsafely-treat-insecure-origin-as-
secure="[http://example.com"](http://example.com")

[https://www.chromium.org/Home/chromium-
security/deprecating-...](https://www.chromium.org/Home/chromium-
security/deprecating-powerful-features-on-insecure-origins)

Or just use a self-signed cert and click though the security warning.

~~~
hungerstrike
The first recommendation doesn't work on iOS or Android.

The second, well, who knows if it will work today or tomorrow. And, it's still
a pain in the ass.

------
bsimpson
I'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/e5d2a4b7826bf5962fad1...](https://gist.github.com/appsforartists/e5d2a4b7826bf5962fad142bcd255465)

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.

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

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

~~~
bsimpson
I 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/e5d2a4b7826bf5962fad1...](https://gist.github.com/appsforartists/e5d2a4b7826bf5962fad142bcd255465)

------
zawerf
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 that does this)?

~~~
lambda
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/](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...](https://www.smashingmagazine.com/2016/03/houdini-maybe-the-most-
exciting-development-in-css-youve-never-heard-of/)

~~~
zawerf
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/text-stroke-
stuck-middle/) [https://css-tricks.com/adding-stroke-to-web-
text/](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-...](https://www.smashingmagazine.com/2015/05/why-the-svg-filter-is-
awesome/). But a unified solution to customizing CSS without needing to call
it a hack would be nice.

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

~~~
bfgeek
We 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).

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

~~~
dassurma
Author 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
Thanks for the info. Love your youtube videos by the way :)

------
markdog12
The second demo doesn't work for me, I think it's missing demo2.js?

[https://googlechromelabs.github.io/houdini-samples/paint-
wor...](https://googlechromelabs.github.io/houdini-samples/paint-
worklet/parameter-checkerboard/)

~~~
dassurma
... my bad. Last minute corrections made it worse. Will get it fixed ASAP.

------
spicyj
Why isn't text rendering supported?

~~~
untog
There 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.

------
tzahola
Another day, another wart on the modern web stack.

~~~
dang
Maybe so, but this is by now a cliché. Please don't post unsubstantive
comments to HN threads.

------
anfilt
Quit 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.

~~~
agentS
I am sorry that you are sick of the HTTPS everywhere movement.

But forcing your sites to use HTTPS will also prevent your users from
unwittingly participating in DDOS attacks on other sites (e.g.
[https://en.wikipedia.org/wiki/Great_Cannon](https://en.wikipedia.org/wiki/Great_Cannon)).
Consider it herd immunity.

Also, to respond to some of your other anti-HTTPS comments:

regarding overhead: people are also working hard to minimize the amount of
overhead inherent to TLS. For instance, TLS 1.3 will establish an encrypted
connection in a single roundtrip, and is capable of resuming encrypted
connections in zero roundtrips with application opt-in (see
[https://blog.cloudflare.com/tls-1-3-overview-and-q-
and-a/](https://blog.cloudflare.com/tls-1-3-overview-and-q-and-a/)). The
encryption itself has fairly ubiquitous support in hardware, making most of
them ridiculously fast.

regarding CAs: with HTTP you are implicitly relying on the honesty of people
in the network path. With HTTPS you are implicitly relying on the honesty of
the intersection of a) people in the network path, b) people who control a CA.
This is strictly fewer people than with HTTP. People are also working hard to
solidify our faith in the set (b), by requiring Certificate Transparency for
all new certificates, thereby ensuring that misbehaving CAs can be detected,
and drastically raising the cost of mounting a CA-based attack.

You say "What if I for what ever reason don't want to use HTTPs", I you'll
have to layout some of those reasons explicitly. You'll probably find that
people are working on all of them.

In general, the default expectation on the web should be encrypted and
authenticated (i.e. only both endpoints can read/write the data). Once we live
in that future, asking for the ability to allow plaintext network traffic will
seem a lot like asking modern programming languages to explicitly allow buffer
overflows. The language designer would be justified in saying "No", and
ignoring you. The considerate language designer might ask "why would you want
that", and try to address your real need. But they would still never actually
give you what you ask for. This may be "taking away choice" in the same sense
that mandating airbags is "taking away choice", but people shrug and accept it
because the baseline has moved.

~~~
anfilt
The biggest problem is Java Script. Netscape made huge mistake when they added
that to their browser. If we wanted to download code on the fly it should have
been a separate format from HTML. HTML is supposed to be a document. Sadly,
that boat sailed decades ago. I really wish the standards committee would quit
adding basically hacks to what was supposed to be a bunch documents. Then
create a separate format more conducive to that goal.

I suppose you could that creating a secure web context is kinda of way of
doing that. Separating documents from more interactive content. However,
freaking HTML is a horrible way to structure such a system.

Also the CA is single point of failure. A MITM only affects the users along
that routing path. CA failure can affect the entire web...

I agree default is fine, but the user should be able to change those defaults.
I could always compile a version for Firefox or Chromium that does. However,
that's kinda ridiculous that I don't see any thing for instance in
about:config Firefox.

\--Speaking of programing languages-- Honestly, I don't see any language
succeeding that only allows code with run time checks running. It's why rust
has the unsafe keyword. To override those checks. The reason there are lots of
hardware devices where the data from said device will vary in size, and there
is no way the compiler will know how all these devices work. The unsafe
keyword allows Rust to be a system programming language. Heck even C requires
you to revert to ASM at times for working with hardware. The generated code
may not meet some strict requirements set by the hardware or you need to setup
the environment so C code can run.

Honestly, the biggest problem I see with programming languages is that too
many of them try to be general purpose. Domain specific languages are great.
If the language is designed well for the problem space it can lead to well
written concise and understandable code. If your problem domain is working
with hardware you need raw pointers, memory access and accurate timing. If you
problem domain is altering images you probably want easy to use vector
operations, handling of regions ect...

