266863 2023-12-24 03:56:28 -0800 Consider lowercasing CSS keywords at source 2025-01-22 08:56:05 -0800 1 1 1 Unclassified WebKit CSS WebKit Nightly Build Unspecified Unspecified NEW InRadar P2 Normal --- 1 annevk sam karlcow ntim webkit-bug-importer oldest_to_newest 2001794 0 annevk 2023-12-24 03:56:28 -0800 It would probably be best if CSS keywords were lowercased in CSSValueKeywords.in rather than requiring them to be lowercased upon serialization (e.g., that's how we did currentcolor). This would allow for removing the lowercasing code introduced in bug 249438. 2001878 1 ntim 2023-12-25 00:03:06 -0800 That's probably fine, but there should be an assert somewhere to ensure everything is lowercase. 2002333 2 webkit-bug-importer 2023-12-31 03:57:12 -0800 <rdar://problem/120323932> 2088543 3 sam 2025-01-20 10:06:10 -0800 Pull request: https://github.com/WebKit/WebKit/pull/39295 2088570 4 sam 2025-01-20 14:15:25 -0800 Doing this makes the following tests fail: imported/w3c/web-platform-tests/css/css-transforms/animation/transform-interpolation-inline-value.html imported/w3c/web-platform-tests/css/css-transforms/parsing/transform-valid.html imported/w3c/web-platform-tests/css/css-transforms/transform-important.html transforms/2d/transform-value-types.html (see https://ews-build.s3-us-west-2.amazonaws.com/macOS-Ventura-Release-WK1-Tests-EWS/20cb8caf-31948/results.html). We should figure out if we think there is a compatibility concern here before proceeding. 2088574 5 karlcow 2025-01-20 15:24:11 -0800 Spec reference for translateX(), translateY(), scaleX(), scaleY(), skewX(), skewY() https://drafts.csswg.org/css-transforms/#two-d-transform-functions 2088576 6 karlcow 2025-01-20 15:41:55 -0800 https://codepen.io/webcompat/pen/xbKaLav uppercase and lowercase are working the same without issues. So the compat risk would be really on the side of other tools and JavaScript libraries expecting a match on the casing of these names. 2088579 7 karlcow 2025-01-20 16:00:00 -0800 if I manually change the test to be lowercase the error is about the canonical serialization. assert_equals("translateX(-4px)", "translatex(-4px)", "serialization should be canonical") 2088607 8 sam 2025-01-20 18:03:30 -0800 Yes, the only compat issue is of course sites that depend on the specific serialization. 2088608 9 sam 2025-01-20 18:04:34 -0800 The parser is agnostic to case for identifiers. This bug is only about serialization. 2088655 10 annevk 2025-01-21 02:12:00 -0800 I guess we should not do this unilaterally then. I was thinking in particular about the keywords bug 249438 was fixing, such as 'srgb' and 'optimizespeed'. Or do we also have cases where those need to be serialized as 'sRGB' and 'optimizeSpeed' and so there's no real canonical representation? 2088711 11 sam 2025-01-21 09:17:35 -0800 I think the only cases we know of where this is an issue is the transform ones. I think it's quite unlikely to be a real compat issue, and updating the tests makes sense (the cases of sites relying on specific capitalization of serialization seems quite unlikely). So, my proposal would be to just update the tests to match the spec, which is quite clear in saying identifiers should be serialized as all lowercase. I am happy to make this fix if no one objects. 2088741 12 annevk 2025-01-21 11:10:58 -0800 I see, I didn't realize. That sounds fine to me. I'll ping Elika just in case. 2088917 13 annevk 2025-01-22 00:03:42 -0800 Elika pointed out that this isn't really defined. I filed https://github.com/w3c/csswg-drafts/issues/11556 2089006 14 sam 2025-01-22 08:56:05 -0800 Oh, interesting! Thanks for filing!