Re: [csswg-drafts] [css-values] attr()'s url type seems wrong (#5079)

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

* `RESOLVED: Make type(<url>) invalid in the attr() function (for now).`

<details><summary>The full IRC log of that discussion</summary>
&lt;fantasai> annevk: attr() started supporting types allowing to parse attributes according to specified CSS types<br>
&lt;fantasai> annevk: Some issues here.<br>
&lt;fantasai> annevk: One was about passing the base URL along. Some discussion about that, forget the outcome.<br>
&lt;fantasai> astearns: Munira suggested making the type invalid<br>
&lt;fantasai> annevk: That is my preferred solution as well<br>
&lt;emilio> q+<br>
&lt;fantasai> annevk: Resolving as document stylesheet maybe works. But if you resolve and serialize, it ends up as all ASCII, which is all Western-centric. Not what you want to print.<br>
&lt;fantasai> annevk: like domain name would become pyunicode<br>
&lt;fantasai> annevk: If you want it as a formatting feature, you'd need to add a converter function<br>
&lt;fantasai> annevk: which we haven't exposed previously, and has security implications<br>
&lt;fantasai> annevk: Browsers have not yet converged on a single algorithm for that operation<br>
&lt;astearns> ack emilio<br>
&lt;fantasai> emilio: Multiple base URL is not an issue.<br>
&lt;fantasai> emilio: That said, I don't disagree with making it invalid.<br>
&lt;fantasai> annevk: So you'd parse it for each document separately?<br>
&lt;fantasai> emilio: attr() is substituted at computed value time, so you need to have the element and the document<br>
&lt;fantasai> annevk: So when you compute the value, you parse the attribute value<br>
&lt;fantasai> emilio: Yes<br>
&lt;fantasai> emilio: You can optimize some cases but basically yes<br>
&lt;fantasai> annevk: So you go into CSSOM, you get attr()<br>
&lt;fantasai> emilio: The stylesheet has a base URL of its own, but it's not the base URI we're talking about here.<br>
&lt;fantasai> annevk: Does the CSSOM have an object representing attr() you can query?<br>
&lt;fantasai> emilio: Maybe with typed OM<br>
&lt;fantasai> emilio: But you don't know which element you're applying the function to<br>
&lt;fantasai> emilio: It's likely that idk about typed OM internals much<br>
&lt;fantasai> emilio: but I imagine it presents as a function value with a keyword inside<br>
&lt;fantasai> emilio: Might be a string or whatever<br>
&lt;fantasai> emilio: But it's tangential. You can share a stylesheet across multiple docs without an issue<br>
&lt;fantasai> astearns: Problem is that making invalid breaks print formatters<br>
&lt;fantasai> annevk: Yeah, some want to do things like print URL of the link. But then you run into the i18n problem. Only works well for ASCII inputs, and that doesn't feel responsible to standardize<br>
&lt;emilio> scribe+<br>
&lt;astearns> ack fantasai<br>
&lt;emilio> fantasai: was it the case that the existing formatters use a different syntax? In which case making type(&lt;url>) invalid wouldn't change anything?<br>
&lt;emilio> ... presumably they are stuck on whatever syntax they support<br>
&lt;emilio> ... seems we could try to standardize what they support but dropping type() from the spec shouldn't change it<br>
&lt;emilio> ... but agreed we shouldn't break their existing content<br>
&lt;emilio> ... that'd be bad<br>
&lt;fantasai> annevk: Unclear if they support the current syntax<br>
&lt;fantasai> astearns: Could take a resolution that `type(&lt;url>)` is invalid, hoping print formatters are not using that syntax yet?<br>
&lt;fantasai> TabAtkins: I'm happy with that.<br>
&lt;fantasai> TabAtkins: We can also put an allowance for e.g. non-security-sensitive uses such as printing<br>
&lt;fantasai> annevk: Not so much security, but i18n concern<br>
&lt;fantasai> annevk: If the idea of this function is to display the URL, then we should have a good way of displaying<br>
&lt;fantasai> annevk: If we just echo the value, then it will work for Western docs but fall apart everywhere else<br>
&lt;fantasai> annevk: In which case I'd rather avoid<br>
&lt;fantasai> annevk: making something that works for a subset of the world<br>
&lt;fantasai> astearns: By making invalid now, not blocking a future where we figure out how to make it work well for i18n<br>
&lt;fantasai> annevk: Yes. We should probably get there eventually. Just not a priority to figure out for anyone atm<br>
&lt;fantasai> astearns: Ok, let's take a resolution and see how Mike responds to it.<br>
&lt;fantasai> PROPOSED: Make type(&lt;url>) invalid in the attr() function (for now).<br>
&lt;TabAtkins> +1<br>
&lt;fantasai> RESOLVED: Make type(&lt;url>) invalid in the attr() function (for now).<br>
&lt;TabAtkins> scribe+<br>
</details>


-- 
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/5079#issuecomment-3329306728 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Wednesday, 24 September 2025 15:19:16 UTC