The CSS declaration block bit in the draft doesn't make sense about webappsec-referrer-policy

[jeisinger]

What about just making this the last step - any remaining case of declaration block should be an inline style ..

[bzbarsky]

What about presentation attributes, which get mapped into CSS styles but are not really associated with either stylesheets or declaration blocks? Or maybe they are; Gecko creates declaration blocks for SVG presentation attributes and SMIL-animated stuff (but not HTML presentation attributes).

[jeisinger]

I created a PR here: #92 - wdyt?

[jeisinger]

actually, not sure why we need to restrict this to inline styles.

In the end, if the request doesn't come from a stylesheet, it comes from some declaration block, and if that block doesn't have an owner node, there's not much we can do.

But if it has one, why not use the referrer information from that node?

[bzbarsky]

In the end, if the request doesn't come from a stylesheet, it comes from some declaration block

This is not necessarily true. See above about presentation attributes...

[jeisinger]

if I'm reading the spec correctly, e.g., https://html.spec.whatwg.org/#the-page:attr-background says that the corresponding style property should be set, which would put it into an declaration block, no?

What about just adding a forth case: Otherwise: set the referrer policy to "never"

[bzbarsky]

says that the corresponding style property should be set

It's used as a specified value in the cascade, is what it says.

which would put it into an declaration block

No, because a declaration block is a CSSOM concept. There is no declaration block associated with mapped attributes, necessarily. One could implement them in terms of one internally, of course, but nothing anywhere requires that.

The right way to solve this, in general, is for CSS to actually define a processing model for URIs that captures the right referrer information. That is, any specified url() value would include not just the URL string but also the relevant referrer and referrer policy. That's what UAs have to do in practice to implement this, no?

If the CSS working group is not cooperating in doing this, then you probably need to explicitly define how this works for the various sources of specified value information. Those include stylesheets, inline styles, and presentation attributes. I think that's it (in the sense that the various SVG/SMIL stuff comes down to being presentation attributes and I'm pretty sure the SMIL source and target have to have the same referrer and referrer policy so you don't have to worry about them being mismatched... I think).

[jeisinger]

I don't think having url() specify the referrer is desirable.

Since we're already in the business of defining CSS for CSS, I could just require that every CSS declaration used in HTML & SVG that is not part of a stylesheet is part of a CSS declaration block that in turn has an owner node

[bzbarsky]

I don't think having url() specify the referrer is desirable.

I'm not saying that there would be a refferrer string in the url() syntactic construct.

I'm saying that the url() syntactic construct would lead to the creation of a thing that, in addition to the url string, contains the information needed to load it properly (i.e. referrer and referrer policy, or something they can be gotten from).

I could just require that every CSS declaration used in HTML & SVG that is not part of a stylesheet

Mapped attributes don't necessarily correspond to declarations either. They really do just correspond to a specified value.

Have you talked to the CSSWG about this stuff?

[jeisinger]

I did (last time at TPAC) but without success :/
Let me try to ask them more specific questions

[annevk]

@jeisinger let me state here what I suggested on IRC. File an issue at https://github.com/w3c/csswg-drafts/issues/new and link it with this one. Then, if we don't hear back, we can start pinging some individuals (or we can do that right away).