Bug 327332 – REGRESSION (319622@main): dropping margin-trim: inline breaks Tailwind v4 sites (chatgpt.com controls offset)

• Status: RESOLVED
• Resolution: FIXED
• Component: CSS

[Karl Dubost]

Created attachment 481771 [details]
minimal-testcase.html

Since 319622@main (bug 322106), margin-trim no longer accepts inline, inline-start or inline-end, following the css-box-4 grammar change (w3c/csswg-drafts#13731):

https://drafts.csswg.org/css-box-4/#margin-trim
Value: none | block | [ block-start || block-end ]

Tailwind v4 cannot write a supports query for @property, so it detects Safari older than 16.4 with this condition, and sets fallback values for its --tw-* custom properties when it matches:

@supports ((-webkit-hyphens: none) and (not (margin-trim: inline))) or ((-moz-orient: inline) and (not (color: rgb(from red r g b))))

https://github.com/tailwindlabs/tailwindcss/blob/main/packages/tailwindcss/src/ast.ts

WebKit now matches it, so current Safari Technology Preview is treated as Safari 16.3. 

On chatgpt.com the fallback rule (* { --tw-translate-y: 0 }) sits in a later cascade layer than the utilities, so every -translate-y-1/2 is lost and the composer mode toggle pill is drawn half its height too low. Shipping Safari 26 still parses margin-trim: inline and is not affected.

Test case: attached minimal-testcase.html

Expected: CSS.supports('margin-trim', 'inline') is true as in shipping Safari, the red bar is centered in the grey box, translate is "0px -50%".
Actual: CSS.supports('margin-trim', 'inline') is false, the red bar hangs below the grey box, translate is "0px".

Firefox and Chrome do not match the condition and render it centered.

Tailwind v4 output is on a very large number of sites, and the CSS already deployed will not change. WebKit likely needs to keep accepting the inline keywords (with no layout effect) and the CSSWG needs to know the grammar change is not web compatible.

Attachments: minimal-testcase.html, reduced-testcase.html (from chatgpt.com).

[Karl Dubost]

<rdar://189766320>

[Karl Dubost]

1. Chromium removed the inline values too (crrev.com/c/8256869) and has shipped margin-trim
2. Firefox parses block values only, but neither matches the condition. 

Chrome has no -webkit-hyphens and Firefox supports rgb(from). 
Only WebKit is misdetected.

[Karl Dubost]

I opened https://github.com/tailwindlabs/tailwindcss/issues/20568

[Karl Dubost]

* tailwinds CSS is not working through CDN once deployed. So we cannot create a quirk on tailwind CDN. 
* Fixing with a quirk on chatgpt.com  would not solve for other websites.
* Maybe we could try to match the full rule from tailwind as a marker for the quirk "@supports ((-webkit-hyphens: none) and (not (margin-trim: inline))) or ((-moz-orient: inline) and (not (color: rgb(from red r g b))))" but this makes it very fragile too. 
* dropping -webkit-hyphens from WebKit could fix every Tailwind v4. That said it might break other things in return, or maybe it could be just about -webkit-hyphens: none

WebKit added unprefixed hyphens on 2023-05-27 (9f181fb3edaf, bug 243670), so Safari 17.
but all websites which still contain -webkit-hyphens: auto would automatically break, creating another series of webcompat issues and all websites having JavaScript using element.style.webkitHyphens would break.

hyphens in 
* Gecko has only a -moz- alias
* Blink has no alias at all
* WebKit it's an alias, defined in CSSProperties.json next to -epub-hyphens

[Karl Dubost]

We could maybe create  a static helper in CSSSupportsParser.cpp

static bool collectTailwindFeatures(CSSParserTokenRange range, OptionSet<TailwindFeature>& features) {


 }


Then use it as 

// Quirks.cpp — may the fix run on this page? Yes, unless site-specific hacks are off.
bool Quirks::needsTailwindPropertyFallbackQuirk() const
{
    return needsQuirks();
}

// CSSSupportsParser.cpp — is this @supports condition Tailwind's?
bool CSSSupportsParser::isTailwindPropertyFallbackCondition(CSSParserTokenRange range)
{
    OptionSet<TailwindFeature> features;
    if (!collectTailwindFeatures(range, features))
        return false;
    return features == OptionSet { TailwindFeature::WebKitHyphensNone, TailwindFeature::MarginTrimInline,
        TailwindFeature::MozOrientInline, TailwindFeature::ColorRelativeRGB };
}

And where the two meet, in CSSParser::consumeSupportsRule:

if (supported == CSSSupportsParser::Supported && m_context.tailwindPropertyFallbackQuirkEnabled
    && CSSSupportsParser::isTailwindPropertyFallbackCondition(prelude))
    supported = CSSSupportsParser::Unsupported;


But I wonder about the performance cost of doing this. It would happen everytime @supports is being used in a CSS when parsing.

[Sammy Gill]

*** Bug 329584 has been marked as a duplicate of this bug. ***

[Sammy Gill]

Pull request: https://github.com/WebKit/WebKit/pull/79066

[EWS]

Committed 325333@main (285584d52fd3): <https://commits.webkit.org/325333@main>

Reviewed commits have been landed. Closing PR #79066 and removing active labels.

[EWS]

Committed 321067.673@safari-7626-branch (c713d922f947): <https://commits.webkit.org/321067.673@safari-7626-branch>

Reviewed commits have been landed. Closing PR #7621 and removing active labels.