Web Compatibility

[jgraham]

Description

A focus area for small bugs that cause known site compatibility issues, or documented problems for authors creating libraries or sites, but which are not part of a larger feature that's appropriate for its own focus area.

Rationale

Observed compatibility bugs which cause breakage for users are often not missing features, but specific cases where existing browsers don't follow the spec for features that are implemented. On their own these would be hard to fit into the Interop process since a focus area for a single bug, however important, is hard to weigh as part of the metric. However having a single focus area for these issues seems to have worked well in 2022, with browsers going from ~20% to ~100%, and fixing several bugs that were known to cause problems for users, but had not previously got priority.

Specification

All included bugs will have a specification (although in some cases it may be that "success" is changing the specification, testcase, and "conforming" implementations to match what's actually required by compat).

Inclusions will be motivated by observed compat issues (e.g. in webcompat.com or author-reported issues that they've had to work around when developing libraries.

Tests

Since this is a somewhat miscellaneous selection of bugs, it's anticipated that tests may be added from other focus areas where the overall focus area doesn't get priority but there are a small number of observed pain points which do get priority. During the selection process participants can request removal of any tests that would cause them to object to the proposal.

Suggested bugs / rationale (tests to be added):

• Remove (or standardise?) overflow: overlay
  • https://bugs.chromium.org/p/chromium/issues/detail?id=55436
  • https://github.com/webcompat/knowledge-base/blob/main/data/overflow-overlay.yml
• Flexbox/abspos paint order
  • https://bugs.chromium.org/p/chromium/issues/detail?id=606208
• Decorating box semantics
  • Webcompat issue: https://bugzilla.mozilla.org/show_bug.cgi?id=1584348
  • https://bugs.webkit.org/show_bug.cgi?id=135353
  • https://bugs.chromium.org/p/chromium/issues/detail?id=1008951 (recently fixed)

[jgraham]

Note that this is not yet a complete set of bugs / tests and I expect more to be added before the start of the selection period.

[karlcow]

These are all small (paper cut) bugs

• failing in Chrome.
• working in both Firefox and Safari

It would be good to align the 3 browsers on the same behavior. It could be missing tests, it could be ambiguities in specs, or just simple bugs to fix, that would reduce paper cuts for Web developers.

• Animations with step-end keyframe timing functions and non-zero delay sometimes do not reach final keyframe
• fetch isn't defaulting to "no-store" cache mode when If-None-Match header is present
• deltaY on wheel events from Trackpad is different on retina screens vs regular screens
• Chromium ignores duplicated X-Content-Type-Options header
• Wrong elements get hover effect when you scroll during html5 drag and drop
• A fillStyle bug on Chrome canvas
• scrollIntoView({behavior:'smooth'}) cancelled by user scroll or another call in unrelated scrolling box
• scroll-margin-top not honor for component using and components under that use overflow-x: auto
• Padding in a child grid element affects the parent grid with minmax
• element === element.querySelector(selector) returns true – Element.querySelector() returns elements that are not descendants to the element when using an id as first part of an adjacent sibling combinator
• Text-emphasis should not be painted for control characters
• Text-emphasis is misplaced with letter-spacing
• text-transform capitlize behavior after dot (.)
• white-space: break-spaces wraps the text incorrectly

[gsnedders]

What's the status of #27? Does that make sense to include at this point?

[progers]

@karlcow , what approach did you use to generate the list of bugs in #187 (comment)?

[karlcow]

@progers So exactly what I said in the previous comment

• failing in Chrome.
• working in both Firefox and Safari

starting with the Interop List of Bugs opened on the Chromium project and checking which one mentioned the other browsers and selecting those where Firefox and Safari implementations were aligned. This is far to be perfect and the list could be a lot longer.

The why is maybe more interesting.

Webcompat issues are often created by the de facto implementation of the dominant market share browser. Both WebKit and Gecko teams can testify about this, where a bug is reported for a site breaking in Firefox or Safari, while they have the correct behavior, but the web developer assumed that the correct was Chrome's one, because the webdev worked exclusively with Chrome. The result is that other browsers have to implement quirks, site interventions or worse change the spec to align on chrome behavior.

So by fixing these paper cuts (if they are real bugs on Chrome side) would make it possible to avoid webcompat pressures on other engines and avoid confusion for web developers.

I hope it helps.

[bfgeek]

I think the above approach can likely be improved upon. Bugs are marked "interop" in the chromium bug tracking in a somewhat haphazard fashion. E.g. the above list includes bugs filed by chromium engineers noting a difference - but no evidence this affects a real world site (bugs filed by web developers have a higher probability however).

Examples of the specific issue being a repeat issue (e.g. references from the webcompat.com project) would be helpful to indicate that the bug is an issue (the overlay example is great for example).

[bfgeek]

Regarding crbug.com/1293302 specifically - we believe (from my understanding of the issue) is that the Blink behaviour is correct - and there are existing WPTs which are partially covering the issue (however they could be expanded):
https://wpt.fyi/results/css/css-grid/layout-algorithm/grid-flex-track-intrinsic-sizes-002.html

I'll double check with Ethan - but we'll likely WontFix this specific issue.

[jgraham]

From a gecko point of view "bug which got filed on blink but where the blink behaviour is now / was always correct" isn't a reason to remove the bug; it's a reason to ensure that it's fixed in gecko instead (it could, for example, be a case where we're operating on outdated assumptions about the correct behaviour). Of course it's even higher priority if we have evidence of widespread usage of the relevant feature, or active breakage. In this specific case I think the relevant gecko bug is https://bugzilla.mozilla.org/show_bug.cgi?id=1530097, which is indeed associated with a number of cases of breakage.

[gsnedders]

@jgraham what's your plan for this currently being "not yet a complete set of bugs"? how are we coming up with the list of compat bugs here?

[bfgeek]

@jgraham - This is why we'd like to expand the grid/flex areas for 2023. A (very) quick look through Gecko's bugs reveals the following issues:
https://bugzilla.mozilla.org/show_bug.cgi?id=1719273
https://bugzilla.mozilla.org/show_bug.cgi?id=1779799
https://bugzilla.mozilla.org/show_bug.cgi?id=1681354
https://bugzilla.mozilla.org/show_bug.cgi?id=1791398
I believe all of these issues have WPT in the css-grid/ associated with them.

Ian

[jgraham]

I will audit the proposed bugs, and which have wpt tests. In at least some cases there are ad-hoc tests and it would be reasonably easy to port them to wpt if that hasn't already happened.

For the grid and flex bugs (and similar cases), if there's a gecko bug and it has any webcompat links in the see-also, or has a webompat priority set I think it makes sense to include in this cateogry. And if there's other parts of the feature with browser-specific failures that also implies at least a compat hazard so I'm also broadly in favour of including those.

[chrishtr]

Also, @karlcow I'm not sure if there are failing WPT tests representing each of the issues you listed. Do you know?

[jgraham]

So an updated list of proposed bugs, some of which still need to have testcases exported to wpt:

• Remove (or standardise?) overflow: overlay
  • https://bugs.chromium.org/p/chromium/issues/detail?id=55436
  • https://github.com/webcompat/knowledge-base/blob/main/data/overflow-overlay.yml
  • Testcase at https://bug1521631.bmoattachments.org/attachment.cgi?id=9281215 can be converted to a reftest matching the decision to implement or remove.
• Flexbox/abspos paint order
  • https://bugs.chromium.org/p/chromium/issues/detail?id=606208
  • https://bugs.chromium.org/p/chromium/issues/attachmentText?aid=232309 can be turned into a wpt reftest
• Decorating box semantics
  • Webcompat issue: https://bugzilla.mozilla.org/show_bug.cgi?id=1584348
  • https://bugs.webkit.org/show_bug.cgi?id=135353
  • https://bugs.chromium.org/p/chromium/issues/detail?id=1008951 (recently fixed)
  • https://wpt.fyi/results/css/css-text-decor/text-decoration-subelements-002.html?label=experimental&label=master&aligned is the testcase from that bug, which now works on all experimental browsers
  • https://bugs.chromium.org/p/chromium/issues/detail?id=855589 (although in that case there is still discussion about the correct behaviour)
  • https://software.hixie.ch/utilities/js/live-dom-viewer/saved/10939 is a test from crbug 855589
  • https://bugzilla.mozilla.org/show_bug.cgi?id=1584348#c27 has another testcase that still shows a behavioural difference.
• Mouse events on disabled input elements
  • https://bugzilla.mozilla.org/show_bug.cgi?id=1653882
  • This was supposed to be in 2022, but afaik the test wasn't added.
  • Chrome just switched behaviour, but there's some chance that will be backed out over compat concerns, so this would be great to include in 2023 in case things don't go smoothly
  • https://wpt.fyi/results/html/semantics/disabled-elements/disabled-event-dispatch.tentative.html?label=master&label=experimental&aligned&view=subtest&q=html%2Fsemantics%2Fdisabled-elements%2Fdisabled-event-dispatch.tentative.html
• Increase sizes to accommodate spanning items crossing flexible tracks
  • https://bugzilla.mozilla.org/show_bug.cgi?id=1530097
  • https://wpt.fyi/results/css/css-grid/layout-algorithm/flex-and-intrinsic-sizes-002.html?label=experimental&label=master&aligned
  • https://www.software.hixie.ch/utilities/js/live-dom-viewer/?saved=10935 might be a Safari bug related to this (from https://bugs.chromium.org/p/chromium/issues/detail?id=1293302, but I can't verify).
• white-space: break-spaces
  • https://bugs.chromium.org/p/chromium/issues/detail?id=1261435
  • https://codepen.io/kizu/pen/mdMEOvw can be converted to a reftest with some care
  • Could also include https://bugzilla.mozilla.org/show_bug.cgi?id=1253840 which is tested at https://wpt.fyi/results/css/CSS2/text/text-align-white-space-003.xht?label=experimental&label=master&aligned&view=subtest (but where it seems like we probably need to adjust the test expectation, since Blink and WebKit are now aligned on the "wrong" behaviour).
• Chromium ignores duplicated X-Content-Type-Options header
  • https://bugs.chromium.org/p/chromium/issues/detail?id=1337723
  • https://bugzilla.mozilla.org/show_bug.cgi?id=1768069
  • https://wpt.fyi/results/fetch/nosniff/parsing-nosniff.window.html?label=experimental&label=master&aligned&view=subtest
• Firefox and Chrome differ on whether to honor a definite width on an image descendant of a grid
  • https://bugzilla.mozilla.org/show_bug.cgi?id=1681354
  • @bfgeek might find the relevant test; maybe the replaced-element tests at https://wpt.fyi/results/css/css-grid/grid-items?label=master&label=experimental&aligned&view=subtest&q=%2Fcss%2Fcss-grid%20%20firefox%3Afail%20chrome%3Apass

I've tried to look at all the suggestions for ones that are clearly causing real-world compat issues. @karlcow might have additional evidence of compat issues from the Chromium bugs (or indeed from WebKit bugs).

In terms of the general grid/flex/etc. carryover issues, I think it's unfortunate that we haven't had a clear plan for those before now. My ideal solution would have been to have specific proposals for each carry over, so they could be assessed along with other priorities, and then maybe merged into the compat bucket where appropriate. But we didn't have a clear process for that in time. The list above only includes the issues for which I could easily find compat problems. But I think we should have an additional discussion about how to handle carry-over in general.

[gsnedders]

Remove (or standardise?) overflow: overlay
https://bugs.chromium.org/p/chromium/issues/detail?id=55436

This seems like the wrong bug? https://bugs.chromium.org/p/chromium/issues/detail?id=1271942 and https://bugs.chromium.org/p/chromium/issues/detail?id=554361 (oh, maybe you lost the last digit?) seem more relevant.

And to note, the WebKit behaviour today is that it is a synonym of auto.

[karlcow]

I will look for more details. But what would be good to do probably for all of us is to have a list for 2024. Longterm Webcompat bugs have a nasty side effect as they can't be demonstrated or showed easily because 1. browsers change the standard behavior to avoid them, 2. implement quirks or 3. webdevs adjust their codepath with UA sniffing for sending different behaviors.

[bfgeek]

For the replaced/aspect-ratio issues (e.g. https://bugzilla.mozilla.org/show_bug.cgi?id=1681354, https://bugzilla.mozilla.org/show_bug.cgi?id=1719273 ) all of the failures in the css-grid/grid-items are relevant.
https://wpt.fyi/results/css/css-grid/grid-items?label=master&label=experimental&aligned&view=subtest&q=firefox%3Afail%20aspect-ratio%20or%20replaced-element
Additionally there are multiple alignment tests:
https://wpt.fyi/results/css/css-grid/alignment?label=master&label=experimental&aligned&view=subtest&q=firefox%3Afail%20aspect-ratio%20or%20replaced

We also find that because Firefox doesn't implement step 3 & step 4 of the grid sizing algorithm this compounds the replaced/aspect-ratio issues:
https://bugzilla.mozilla.org/show_bug.cgi?id=1300366 (note blocking https://bugzilla.mozilla.org/show_bug.cgi?id=1719273)
There are many test cases testing that implementations are running steps 3 & 4 when I disable these steps in our code the relevant tests are:
https://wpt.fyi/results/css/css-grid?label=master&label=experimental&aligned&view=subtest&q=grid-template-flexible-rerun-track-sizing.html%20or%20grid-percent-rows-spanned-shrinkwrap-001.html%20or%20flex-sizing-rows-min-max-height-001.html%20or%20grid-percentage-rows-indefinite-height-002.html%20or%20grid-percentage-rows-indefinite-height-001.html%20or%20grid-content-alignment-second-pass-002.html%20

For https://bugzilla.mozilla.org/show_bug.cgi?id=1779799 / https://bugzilla.mozilla.org/show_bug.cgi?id=1530097
At least the test below - but there are likely other relevant test-cases.
https://wpt.fyi/results/css/css-grid/layout-algorithm/flex-and-intrinsic-sizes-002.html?label=experimental&label=master&aligned

FWIW most of the Firefox failures in the css-grid directory are related web-compat issues that web developers are running into.

[andreubotella]

• white-space: break-spaces
  • https://bugs.chromium.org/p/chromium/issues/detail?id=1261435
  • https://codepen.io/kizu/pen/mdMEOvw can be converted to a reftest with some care

In Igalia we're starting to look into this issue, and we'll be fixing it at some point in the next year. The issue should probably be limited to the fact that Chromium counts an element boundary before a space as a line breaking opportunity, and you can reproduce this in a test case that doesn't require zoom. The fact that different zoom levels result in different line breaks even when the line width does not depend on the viewport size is a separate issue that should not count for Interop 2023.

However, as we were initially looking into this bug, we noticed that Webkit does seem to have this bug in some cases, although maybe not in all of the cases where Chromium has it, or it might have a separate but related bug. So should it still count for Interop 2023?

Edit: I had tested this bug in Webkit using Epiphany (Gnome Web), and apparently Safari doesn't have it.

[karlcow]

@jgraham for decoration box semantics
Probably this test makes it more obvious

https://software.hixie.ch/utilities/js/live-dom-viewer/saved/10939 is a test from crbug 855589

https://software.hixie.ch/utilities/js/live-dom-viewer/?saved=10982

[karlcow]

These are all small (paper cut) bugs

I'm reviewing my own suggestions and I think we can remove a bunch of them.
My reduced list

PROBABLY

• Animations with step-end keyframe timing functions and non-zero delay sometimes do not reach final keyframe . Needs WPT
• fetch isn't defaulting to "no-store" cache mode when If-None-Match header is present. Needs WPT
• Chromium ignores duplicated X-Content-Type-Options header. WPT OK
• element === element.querySelector(selector) returns true – Element.querySelector() returns elements that are not descendants to the element when using an id as first part of an adjacent sibling combinator. Needs WPT
• Text-emphasis should not be painted for control characters. WPT OK
• white-space: break-spaces wraps the text incorrectly. Needs WPT

MAYBE

• scroll-margin-top not honor for component using and components under that use overflow-x: auto. Needs WPT

For @jgraham list, still reviewing them, but:

• overflow: overlay will be a difficult one. https://cs.github.com/?q=%22overflow%3A+overlay+%22 doesn't return a lot of significant results. I wonder how many sites from the SeeAlso list in the bugzilla list have been fixed. And there's no obvious fix. If it is removed from Chrome and Safari, it is likely to create the same breakage than Firefox. Maybe this is acceptable. Safari could use Quirks, but that would leave Chrome without an easy solutions for removing it. Chrome doesn't have for now this flexibility. overflow: overlay on WebKit === overflow: auto
• Flexbox/abspos paint order seems reasonable and I can see how it could create very annoying issues in terms of webdevs.

To be continued.

[jgraham]

overflow: overlay will be a difficult one

I think it's acceptable if the outcome is that we standardise the Blink/WebKit behaviour and Firefox adopts that (although obviously that's not my preferred outcome). https://github.com/webcompat/knowledge-base/blob/main/data/overflow-overlay.yml has links to a lot of examples of this causing breakage in the wild.

https://bugs.chromium.org/p/chromium/issues/detail?id=811172 is another Blink/WebKit bug that has caused a number of compat problems.

[gsnedders]

So what is this proposal at this point? Is it just @jgraham's list of proposed bugs in #187 (comment), or is it a broader union of the listed bugs here?

[foolip]

I'm commenting on proposals for features that came up in State of CSS 2022 going by the list in #248. Obviously this focus area cannot be named directly, but it is notable that flexbox is still top of mind. A lot of that is due to flex gap not being available in older browser versions still in use, but also comments like "Flexbox seems to have some overflow bugs still. (min-width: 0; fix, anyone?)"

overflow: overlay is actually mentioned once directly as well.

[chrishtr]

@gsnedders I'm treating this proposal as tracking the union of @jgraham's issues and the ones from @karlcow.

[foolip]

text-transform capitalize behavior after dot (.)

Is this still on the table, given the discussion in w3c/csswg-drafts#8031? After internal review of the tests, this is one we're not sure about including.

[jgraham]

That's not in @karlcow's reduced list #187 (comment) so I consider it already removed. But in any case, removing it isn't a problem.

[nt1m]

Can all the testcases be exported to WPT? Makes it easier to assess the proposals generally.

[jgraham]

Per request we can also consider the overflow: overlay test removed since there's a pending spec issue there (see w3c/csswg-drafts#8063; hopefully we can all ship it as an alias of overflow:auto and get interop, but it doesn't need to be part of this issue).

[jgraham]

Can all the testcases be exported to WPT? Makes it easier to assess the proposals generally.

Yes, but realistically I doubt we can do that by Thursday.

If there are concerns with specific tests once they're ported to wpt I think it would be possible to deal with that later.

[karlcow]

@jgraham Should we add https://bugzilla.mozilla.org/show_bug.cgi?id=1772305 to the webcompat focus area.

It creates this compat issue for Safari while doing the right thing.
webcompat/web-bugs#106690

[jgraham]

That seems reasonable to me c.f. @emilio and @foolip who would need to find someone from Google to look at this.

[chrishtr]

That seems reasonable to me c.f. @emilio and @foolip who would need to find someone from Google to look at this.

You're talking about this bug, right? Is that a bug in Gecko? Emilio's comment guesses that.

[jgraham]

Tests update for the areas I suggested:

• Remove (or standardise?) overflow: overlay
  • https://phabricator.services.mozilla.com/D166653
  • I'd forgotten that we agreed to remove this, and don't really remember what the reasoning was. But there's a test in case it allows us to re-add this one.
• Decorating box semantics
  • data:text/html,<h1 style="font:24px Arial"><a href="."><span style="vertical-align:middle">Link text with vertical-align:middle</span></a> and https://software.hixie.ch/utilities/js/live-dom-viewer/saved/10939 are cases that are still different, but it's possible the main issue here is fixed?
• Mouse events on disabled input elements
  • https://wpt.fyi/results/html/semantics/disabled-elements/disabled-event-dispatch.tentative.html?label=master&label=experimental&aligned&view=subtest&q=html%2Fsemantics%2Fdisabled-elements%2Fdisabled-event-dispatch.tentative.html
• white-space: break-spaces
  • Test line breaking of element boundaries with white-space: break-spaces wpt#37985
• Chromium ignores duplicated X-Content-Type-Options header
  • https://wpt.fyi/results/fetch/nosniff/parsing-nosniff.window.html?label=experimental&label=master&aligned&view=subtest

Move to flex/grid:

• Flexbox/abspos paint order
  • Add test for flexbox, abspos and order wpt#37903
• Firefox and Chrome differ on whether to honor a definite width on an image descendant of a grid
  • Seems like the issue is maybe already fixed? If it turns out there's a fix with a bug, we can add that.
• Increase sizes to accommodate spanning items crossing flexible tracks

• https://wpt.fyi/results/css/css-grid/layout-algorithm/flex-and-intrinsic-sizes-002.html?label=experimental&label=master&aligned
• https://www.software.hixie.ch/utilities/js/live-dom-viewer/?saved=10935 might be a Safari bug related to this (from https://bugs.chromium.org/p/chromium/issues/detail?id=1293302, but I can't verify).

[jgraham]

Still need to identify / add tests from #187 (comment) and https://bugzilla.mozilla.org/show_bug.cgi?id=1772305 (cc @karlcow)

[bfgeek]

What about issues mentioned in #187 (comment) ?

[jgraham]

@bfgeek I thought those tests were being added to grid / flexbox focus areas. I agree they're important and shouldn't be lost.

[bfgeek]

I thought those tests were being added to grid / flexbox focus areas. I agree they're important and shouldn't be lost.

Should:

• Flexbox/abspos paint order
• Increase sizes to accommodate spanning items crossing flexible tracks

Also be dropped from this particular area as they are already in the grid/flexbox focus areas?

[bfgeek]

(Just after consistency about how we think of these)

[andreubotella]

• white-space: break-spaces
  • Add a test for white-space: break-spaces wpt#37905
  • https://wpt.fyi/results/css/CSS2/text/text-align-white-space-003.xht?label=experimental&label=master&aligned&view=subtest (might need to change test).

I'm currently looking into fixing this in Blink, and working on a more comprehensive WPT test. Note that the Chromium bug isn't just about white-space: break-spaces, but about how it interacts with element boundaries when line breaking.

Also, I don't think https://wpt.fyi/results/css/CSS2/text/text-align-white-space-003.xht is related to this issue at all, since this is about whether text-align: justify does anything when the line has no collapsible white space, which is not a requirement (keyword "may") in the spec:

If an element’s white space is not collapsible, then the UA is not required to adjust its text for the purpose of justification and may instead treat the text as having no justification opportunities.

[jgraham]

@andreubotella how soon do you expect to have tests in wpt? If not in the next coupld of weeks, could we start by merging and tagging the test I ported and then replacing it once your tests are landed?

[jgraham]

@bfgeek I don't mind moving those into flexbox/grid tests instead of here.

[jgraham]

Karl's test list (will update as tests are found/added):

• Animations with step-end keyframe timing functions and non-zero delay sometimes do not reach final keyframe .
  • Add test for Chromium animation bug with delay and step-end transition wpt#37937
• fetch isn't defaulting to "no-store" cache mode when If-None-Match header is present.
  • Test Cache-Control and Pragma headers when If-None-Match is set wpt#37986
• element === element.querySelector(selector) returns true – Element.querySelector() returns elements that are not descendants to the element when using an id as first part of an adjacent sibling combinator.
  • https://wpt.fyi/results/dom/nodes/ParentNode-querySelector-scope.html?label=master&label=experimental&aligned&view=subtest&q=dom%2Fnodes%2FParentNode-querySelector-scope.html
• Text-emphasis should not be painted for control characters.
  • https://wpt.fyi/results/css/css-text-decor/text-emphasis-style-property-010Cf.html?label=master&label=experimental&aligned&view=subtest&q=css%2Fcss-text-decor%2Ftext-emphasis-style-property
  • https://wpt.fyi/results/css/css-text-decor/text-emphasis-style-property-010Cn.html?label=master&label=experimental&aligned&view=subtest&q=css%2Fcss-text-decor%2Ftext-emphasis-style-property

[bfgeek]

I don't mind moving those into flexbox/grid tests instead of here.
@jgraham sg - to be clear I don't mind either way - just consistency. The two tests for those are already part of the flex/grid test suites.

[andreubotella]

@andreubotella how soon do you expect to have tests in wpt? If not in the next coupld of weeks, could we start by merging and tagging the test I ported and then replacing it once your tests are landed?

I already opened a PR: web-platform-tests/wpt#37985

[johannesodland]

I know it might be too late, but I'll post this combat issue here and leave it up to you to decide if it can be included in interop 2023 or not.

There are some interop issues on ::first-letter when it comes to including punctuation and whitespace. This prevents some international authors and users from using ::first-letter in their sites, as it will not match their typographic conventions. It's a small issue, but it excludes many authors and users from using the pseudo element.

The spec includes punctuation and whitespace before and after the initial letter, as defined in css-pseudo-4. Browsers are not interoperable and supports punctuation and whitespace to a varying degree:

Safari:
Whitespace: supported
Punctuation: partial support

Chrome:
Whitespace: not supported
Punctuation: partial support

Firefox:
Whitespace: not supported
Punctuation: partial support

There is a crude test in WPT. It currently fails for all browsers:
https://wpt.fyi/results/css/css-pseudo/first-letter-punctuation-and-space.html?label=master&label=experimental&aligned

There are open issues in all browsers here:
https://bugs.chromium.org/p/chromium/issues/detail?id=1163175
https://bugs.webkit.org/show_bug.cgi?id=179815
https://bugzilla.mozilla.org/show_bug.cgi?id=602459

[jgraham]

I know it might be too late, but I'll post this combat issue here and leave it up to you to decide if it can be included in interop 2023 or not.

Unfortunately the proposal period for Interop 2023 is indeed over.

You are of course welcome (and encouraged!) to propose ::first-letter for a future round of Interop. However, based on the description so far it doesn't sound like it would be part of a Web Compatibility focus area; this is usually for browser differences in existing features that are breaking sites in the wild. Features that are poorly supported across browsers typically get their own top-level proposal.

[foolip]

Thank you for proposing Web Compatibility for inclusion in Interop 2023.

We are pleased to let you know that this proposal was accepted as the Web Compat 2023 focus area. You can follow the progress of this Focus Area on the Interop 2023 dashboard.

For an overview of our process, see the proposal selection summary. Thank you for contributing to Interop 2023!

Posted on behalf of the Interop team.