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

> I can certainly fix this, but it has been something of a moving target over the last few years - from `attr(href)` to `attr(href, url)` to `attr(href url)` to `attr(href type(<url>))` to `string(attr(href type(<url>>)`

The original `attr(href)` still works! It pulls the attribute value as a string, nice and easy. Meanwhile, `string(attr(href type(<url>)))` isn't valid at all; `string()` doesn't take `<url>` values, just strings, idents, and numbers. We'd have to define the URL behavior (notably, whether it absolutizes, how it serializes, etc), and that is a separate project that we're not doing right now.

So the existing use-cases that print formatters have, of putting href attribute contents into ::after `content`/etc, still work in the same way they always did, with the same syntax they always did.

----------

Removing (for now) `attr(... type(<url>)` just means that you can't put an attribute value directly into a spot where CSS expects a URL, but that's already *intentionally* disallowed when getting the attr value as a string, to avoid exfiltration attacks.

I expect that when we *do* re-allow `attr(... type(<url>))`, it will hook more directly into the host language's knowledge of what attributes are *expected* to be fetchable URLs. If an element contains a URL attribute that the UA or user action can already trigger a request with (`<a href>`, `<img src>`, `<video poster>`, etc), then it's almost certainly not a security issue for CSS to trigger that exact same request in a slightly different spot on the page. The security concern is just taking an attribute value that the page *doesn't* expect to be part of a request, and allowing it to be appended to an attacker-chosen URL.

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


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

Received on Monday, 27 April 2026 23:19:06 UTC