Hi Team, WebKit has 'Backslash-as-JPY' hack and it was removed from Blink. I noticed that we have 'WPT' test, which fail due to this hack: WPT Test Link: https://wpt.fyi/results/html/semantics/forms/the-option-element/option-text-backslash.html?label=master&label=experimental&aligned&q=option-text-backslash.html WPT Test Live Link: http://wpt.live/html/semantics/forms/the-option-element/option-text-backslash.html Blink Commit: https://src.chromium.org/viewvc/blink?view=revision&revision=159589 ^ Only doing partial merge of above to HTMLOptionElement (I also did for HTMLOptGroupElement). We pass the above testcase. ____ Changes in HTMLOptGroupElement.cpp (Line 121 onward): String HTMLOptGroupElement::groupLabelText() const { String itemText = attributeWithoutSynchronization(labelAttr); // In WinIE, leading and trailing whitespace is ignored in options and optgroups. We match this behavior. ______ Changes in HTMLOptionElement.cpp (Line 108 onward): String HTMLOptGroupElement::groupLabelText() const { String itemText = attributeWithoutSynchronization(labelAttr); // In WinIE, leading and trailing whitespace is ignored in options and optgroups. We match this behavior. ______ Just wanted to raise so we can track it.
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.
<rdar://problem/110000970>
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.