[css-values] attr()'s url type seems wrong

[annevk]

Per https://drafts.csswg.org/css-values-4/#attr-types the value of the attribute is literally forwarded to CSS, without taking into account how that attribute would be parsed (which requires passing in a base URL and encoding to the URL parser). This means that if you have

foo="bar"

in your document at / and your CSS is in /css/meh it'll link to /bar in your document and /css/bar in your CSS.

[tabatkins]

Hm, this is a very good point. I think I agree with you.

What's the right DOM concepts to pull in here?

Agenda+ to make sure this sounds good for the rest of the WG.

[annevk]

For base URL it would be https://html.spec.whatwg.org/multipage/urls-and-fetching.html#document-base-url.

For encoding I'm having a harder time pinning down ideal rules. Largely we want new places to use UTF-8, but most (X)HTML elements will not. The field is https://dom.spec.whatwg.org/#concept-document-encoding. Whatever we do here this should get a lot of detailed tests and probably security review.

To get to the document from an element you would use https://dom.spec.whatwg.org/#concept-node-document.

[css-meeting-bot]

The CSS Working Group just discussed [css-values] attr()'s url type seems wrong, and agreed to the following:

• RESOLVED: Specify we use host document behavior for URL types in attr()

The full IRC log of that discussion

<dael> Topic: [css-values] attr()'s url type seems wrong
<dael> github: https://github.com//issues/5079
<dael> TabAtkins: Ana reviewed changes to attr and noticed I have it defined as attr with URL type it takes string and spans into URL function using css resolution rules for relative urls
<dael> TabAtkins: Unfortunate because if have a href and pull it out it resolves different from if click a and if you pull it into css.
<dbaron> s/Ana/Anne/
<dael> TabAtkins: They're not concordant resolution mech
<dael> TabAtkins: Suggestion is when using url-type we should use same reoslution rules as HTML uses.
<dael> TabAtkins: Reasonable to me. Exact working needs to be worked out with Anne.
<dael> TabAtkins: As long as no one objects to that I'm happy to have it work
<dael> fantasai: Update L3 as well?
<dael> TabAtkins: Only to whatever version the new advanced attr function is in
<dael> fantasai: Right, yeah
<dael> fantasai: Also values 4 hasn't been published in long time
<dael> TabAtkins: Sure. Separate issue.
<dael> astearns: Other comments?
<fantasai> +1 to the change
<faceless2_> +1 from me, it's a good idea.
<bkardell_> +1
<dael> astearns: Prop: When attr function is using URL type use same resolution rules as HTML
<dael> fantasai: I think take resolution rules for the element from which took attr
<dael> TabAtkins: Yes, but only one language that deinfes which is HTML
<dael> fantasai: [missed]
<dael> TabAtkins: Yeah, generic HTML doc doesn't define either
<fantasai> s/[missed]/If you apply CSS to a generic XML document, then HTML doesn't define that/
<dael> s/HTML/XML
<dael> fantasai: You shoudl write spec so it works for whatever languages
<dael> TabAtkins: As long as not a huge pain of cross doc references sure. If it is a pain I'll write it how it's readable. We'll figure out details. Want to make sure general plan is right
<dael> astearns: Objections to specify we use host document behavior for URL types in attr()
<dael> RESOLVED: Specify we use host document behavior for URL types in attr()

[andruud]

@annevk With the new security restrictions which prevent any attr-tainted value from being used as a URL, does this change still make sense?

As the spec is right now, attr(href type(<url>)) is allowed, but attempts at using that in anything that would trigger a load of that URL will make it invalid at computed-value time. The only case where this still matters is when you serialize something like --x: attr(href, type(<url>)).