Intent to Ship: Rename `string` attr() type to `raw-string`

[Munira Tursunova]

Contact emails

moo...@google.com, and...@chromium.org

Explainer

None

Specification

https://drafts.csswg.org/css-values-5/#attr-notation

Summary

In https://github.com/w3c/csswg-drafts/issues/11645#issuecomment-2701601350 it was resolved to replace `string` attr() type with `raw-string`, see: https://drafts.csswg.org/css-values-5/#attr-notation. Change attr() syntax, so that `attr(data-foo string)` will now become `attr(data-foo raw-string)`.

Blink component

Blink>CSS

TAG review

None

TAG review status

Pending

Risks

Interoperability and Compatibility

Feature was launched recently in M133 and not supported in other browsers yet, so shouldn't be a high risk.

Gecko: No signal

WebKit: No signal

Web developers: No signals

Other signals:

WebView application risks

Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications?

None

Debuggability

This is minor syntax change, doesn't require additional support from DevTools

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, ChromeOS, Android, and Android WebView)?

Yes

Is this feature fully tested by web-platform-tests?

Yes

https://wpt.fyi/results/css/css-values/attr-all-types.html?label=master&label=experimental&aligned&q=css%2Fcss-values%2Fattr-all-types.html

Flag name on about://flags

CSSAttrRawString

Finch feature name

CSSAttrRawString

Requires code in //chrome?

False

Tracking bug

https://crbug.com/400981738

Estimated milestones

Shipping on desktop	136
Shipping on Android	136
Shipping on WebView	136

Anticipated spec changes

Open questions about a feature may be a source of future web compat or interop issues. Please list open issues (e.g. links to known github issues in the project for the feature specification) whose resolution may introduce web compat/interop risk (e.g., changing to naming or structure of the API in a non-backward-compatible way).

None

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5191129693421568?gate=5126282800791552

This intent message was generated by Chrome Platform Status.

[Mike Taylor]

On 3/11/25 5:48 AM, 'Munira Tursunova' via blink-dev wrote:

Contact emails

moo...@google.com, and...@chromium.org

Explainer

None

Specification

https://drafts.csswg.org/css-values-5/#attr-notation

Summary

In https://github.com/w3c/csswg-drafts/issues/11645#issuecomment-2701601350 it was resolved to replace `string` attr() type with `raw-string`, see: https://drafts.csswg.org/css-values-5/#attr-notation. Change attr() syntax, so that `attr(data-foo string)` will now become `attr(data-foo raw-string)`.

Blink component

Blink>CSS

TAG review

None

TAG review status

Pending

Risks

Interoperability and Compatibility

Feature was launched recently in M133 and not supported in other browsers yet, so shouldn't be a high risk.

Do we have any sense of current usage? And do we have a plan to communicate the change to developers?

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAAO7W_AkzsbO_zudgyt%3DYy6dBp2OKYcgSZZ2UHnUou0--o8Phg%40mail.gmail.com.

[Mike Taylor]

On 3/14/25 7:00 AM, Bramus Van Damme wrote:

On Thursday, March 13, 2025 at 7:09:03 PM UTC+1 Mike Taylor wrote:

On 3/11/25 5:48 AM, 'Munira Tursunova' via blink-dev wrote:

Contact emails moo...@google.com, and...@chromium.org

Explainer None

Specification https://drafts.csswg.org/css-values-5/#attr-notation

Summary

In https://github.com/w3c/csswg-drafts/issues/11645#issuecomment-2701601350 it was resolved to replace `string` attr() type with `raw-string`, see: https://drafts.csswg.org/css-values-5/#attr-notation. Change attr() syntax, so that `attr(data-foo string)` will now become `attr(data-foo raw-string)`.

Blink component Blink>CSS

TAG review None

TAG review status Pending

Risks

Interoperability and Compatibility

Feature was launched recently in M133 and not supported in other browsers yet, so shouldn't be a high risk.

Do we have any sense of current usage? And do we have a plan to communicate the change to developers?

Usage of `attr(data-x string)` seems pretty much inexistent because:

- This is Chrome-first and so far I’ve only seen a limited set of demos (that do not even use string).

- When a type is omitted - i.e. when using `attr(data-x)` – it behaves like `attr(data-x raw-string)`. The short for is what authors have been using so far.

That sounds promising, but do we have any UseCounter data?

As for communication I have prepared a PR to update MDN: https://github.com/mdn/content/pull/38580 which is awaiting review. The blog post + demos on developer.chrome.com (See https://developer.chrome.com/blog/advanced-attr) do not mention `attr(data-x string)` as the post points to MDN for docs. I can add an update banner to the post.

Thanks for that.

[Bramus Van Damme]

On Thursday, March 13, 2025 at 7:09:03 PM UTC+1 Mike Taylor wrote:

On 3/11/25 5:48 AM, 'Munira Tursunova' via blink-dev wrote:

Contact emails moo...@google.com, and...@chromium.org

Explainer None

Specification https://drafts.csswg.org/css-values-5/#attr-notation

Summary

In https://github.com/w3c/csswg-drafts/issues/11645#issuecomment-2701601350 it was resolved to replace `string` attr() type with `raw-string`, see: https://drafts.csswg.org/css-values-5/#attr-notation. Change attr() syntax, so that `attr(data-foo string)` will now become `attr(data-foo raw-string)`.

Blink component Blink>CSS

TAG review None

TAG review status Pending

Risks

Interoperability and Compatibility

Feature was launched recently in M133 and not supported in other browsers yet, so shouldn't be a high risk.

Do we have any sense of current usage? And do we have a plan to communicate the change to developers?

Usage of `attr(data-x string)` seems pretty much inexistent because:

- This is Chrome-first and so far I’ve only seen a limited set of demos (that do not even use string).

- When a type is omitted - i.e. when using `attr(data-x)` – it behaves like `attr(data-x raw-string)`. The short for is what authors have been using so far.

As for communication I have prepared a PR to update MDN: https://github.com/mdn/content/pull/38580 which is awaiting review. The blog post + demos on developer.chrome.com (See https://developer.chrome.com/blog/advanced-attr) do not mention `attr(data-x string)` as the post points to MDN for docs. I can add an update banner to the post.

 

[Munira Tursunova]

Thank you, Bramus and Mike.

 

That sounds promising, but do we have any UseCounter data?

 

No, but there is some data gathered from http archive: 'string' type in attr(). I found 15 websites that might cause a potential breakage, so the overall percentage of breakages is under 0,000088%.

[Mike Taylor]

Thank you for looking into that. Do you have any sense of the relative impact of the breakage for each site, i.e., does some text look funny (low) vs the page is unusable due to broken layout or missing content (high)?

Is there someone on your team that might be able to attempt outreach to get these sites to update?

[Alex Russell]

Why would we change this? We backed the original intent with the usual conditions: once the concrete is poured, it's done. I'm not inclined to approve.

Best,

Alex

[Munira Tursunova]

Do you have any sense of the relative impact of the breakage for each site, i.e., does some text look funny (low) vs the page is unusable due to broken layout or missing content (high)?

I assume theoretically there might be missing content, so high.

Is there someone on your team that might be able to attempt outreach to get these sites to update?

Bramus kindly agreed to help with this.

Why would we change this? We backed the original intent with the usual conditions: once the concrete is poured, it's done. I'm not inclined to approve.

There was a spec change initially raised by Apple after shipping in Blink. I guess we can mention that we wouldn't ship that in Chrome in the CSSWG issue, but I'm not sure if Apple will also ship `string` instead of `raw-string`, which may cause interoperability issues.

[Tab Atkins Jr.]

On Mon, Mar 17, 2025 at 11:21 AM Alex Russell <sligh...@chromium.org> wrote:
> Why would we change this? We backed the original intent with the usual conditions: once the concrete is poured, it's done. I'm not inclined to approve.

That is not, as a general rule, how API owner approval is interpreted,
or (as far as I know) intended. It also drastically conflicts with
usual practice, which has substantial weight of precedent behind it -
while we of course balance the cost of any changes with the benefits,
we are generally *open* to changes requested by other implementors,
particularly when we're the first to advance an API.

In this particular case, the cost is virtually nil - it's a brand new
API with minimal usage, and it's a change to a *default* keyword that
would rarely be written explicitly anyway. (We only have it at all,
rather than just relying on a keyword being absent, due to my own API
design preferences, and the fact that it aids us with a small
back-compat issue.) The benefit of "make other implementors happier
with the API" definitely outweighs the costs here, by any reasonable
metric.

But even in more controversial/costly cases, I strongly contest the
principle you're trying to establish here. We *do* make changes, even
ones with compat pain, as part of our unofficial contract with other
implementors, to make it more palatable to everyone when we push ahead
faster than other implementors are comfortable with or capable of
matching. It's always a judgement call, but it leans *much* further
toward acceptance than "once Blink API owners approve, the concrete is
poured" does.

~TJ

[Munira Tursunova]

Checked the websites with potential breakages, don't observe any breakages. 

The only website with visual differences is https://css3test.com/#css-values-5, but it  "checks which CSS3 features the browser recognizes, not whether they are implemented correctly." (pasted from the website) and links to CSS Values 5 attr() spec: https://www.w3.org/TR/css-values-5/#attr-notation, so should be updated accordingly.

Updated the doc with the findings. 

[Vladimir Levin]

Thank you for checking.

LGTM1

--

You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAAO7W_CFxpEZk%2BsdK3b8pfOX%3DPo0bdXxNnHWYvB8j2TeiqEVDw%40mail.gmail.com.

[Chris Harrelson]

LGTM2

To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADsXd2Mk4BGq%2BTkCt_af2YK9HbWQ_2O1gZZvjmQ6%3D2XVObG0%3Dw%40mail.gmail.com.

[Mike Taylor]

LGTM3 - thanks!

[Alex Russell]

I see there are 3 LGTMs now, and I'm not going to block, but I want to be extremely clear that this is not precedent and that folks who have asked for this change should take note that I might block future changes of this sort if we see this kind of thing become a habit from the CSS WG.

Best,

Alex

[Bramus Van Damme]

To close the loop: the PR to update MDN got approved just now and should be deployed later today.