Re: [whatwg/dom] Declarative Shadow DOM (#831)

@dfabulich 
Regarding the opt-in header, the cites source asked this, on twitter (and twitter ain't at all representative):
> Imagine a new exciting JS feature can only be used if the HTML is served with a particular response header. In terms of your professional projects:

It also excluded http-equiv, which makes it harder for adoption. Please consider that the majority of (every-day) javascript developers don't want to do have to do anything with server side languages or configuration or sometimes even html. This is far from representative data.

Wouldn't you think that those who would want to use server-side-rendering (aka are working at the layer of the web server already) to create shadow doms would not mind setting a flag over not having the feature at all?

> That could be worth it if we think the header is the right/best approach, but you'll recall my earlier argument that the using an opt-in HTTP header for the SSX issue would be a footgun

Then I simply don't share the footgun argument. Even given maximum XSS potential, it only exists if you opt-in to the feature. Any developer can create endless amounts of XSS and SQL injections. A walled garden appraoch with unlimited holes in the walls does not fix that.

So the question to me remains:
A) For client side / DOM using XSS as far as I understood @cure53 one of the most used sanitizer IS already fixed.
B) Given a header/meta-tag even a failure of string based server side sanitizers would not result in XSS happening due to the header missing. Wrong?

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/dom/issues/831#issuecomment-717886500