Summary: | HTMLOptionElement text is impacted by 'Backslash-as-JPY' hack | ||
---|---|---|---|
Product: | WebKit | Reporter: | Ahmad Saleem <ahmad.saleem792> |
Component: | Forms | Assignee: | Nobody <webkit-unassigned> |
Status: | NEW --- | ||
Severity: | Normal | CC: | akeerthi, annevk, ap, cdumez, karlcow, mike, rniwa, webkit-bug-importer, wenson_hsieh |
Priority: | P2 | Keywords: | BrowserCompat, InRadar, WPTImpact |
Version: | Safari Technology Preview | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
See Also: | https://bugs.webkit.org/show_bug.cgi?id=233439 |
Description
Ahmad Saleem
2023-05-23 05:32:00 PDT
I'd be very cautious about putting too much weight on Blink decisions in this area. Presumably Chrome on Windows effectively still has it through the behavior of Microsoft fonts. We'll need to evaluate the user impact ourselves. (In reply to Alexey Proskuryakov from comment #1) > I'd be very cautious about putting too much weight on Blink decisions in > this area. Presumably Chrome on Windows effectively still has it through the > behavior of Microsoft fonts. > > We'll need to evaluate the user impact ourselves. Just test on work laptop with windows and Chrome Stable, still pass this test, which might suggest that they are not following Microsoft’s font behavior. The font behavior is happening behind the scenes, so the test would pass, but the character visible to the user would be different between Windows and Mac Chrome. IIRC one also needs to be running Windows in Japanese to see the difference. (In reply to Alexey Proskuryakov from comment #3) > The font behavior is happening behind the scenes, so the test would pass, > but the character visible to the user would be different between Windows and > Mac Chrome. IIRC one also needs to be running Windows in Japanese to see the > difference. Fair point.. I don't have laptop machine to change / experiment with Japanese language. Can we ask someone from Sony team from win-cairo team to experiment on this testcase with Chrome? and see if this fails. Alexey, but wouldn't this create an inconsistency with other macOS/iOS applications? This assumes the website was either made on Windows with such a font and legacy encoding or made on macOS/iOS using Safari. And while it might visually work for that case, it seems that we end up creating a different node tree which I'd argue is even more surprising behavior and more likely to create real interoperability issues. The choice as I understand it is between everything being consistently wrong vs. getting the most common scenario (looking at the webpage) right, while the rest remains the same. Although I don't remember if we also do this correction when copying to the pasteboard - if we do, that covers pretty much all scenarios except for cross-platform tests. So I feel like the choice to preserve status quo is obvious as long as we believe that this is still somewhat common on the web. Alexey pointed to https://github.com/w3c/csswg-drafts/issues/6848 which should probably be resolved before we do anything here. Given that it's an open issue we could meanwhile rename the tests to include .tentative to make it clear they are testing something that is not yet decided upon. |