When a block element is set to display:inline, it is desirable for it to behave bidi-wise as it would if it were display:inline-block. Under CSS2.1, there was no way to accomplish this, and unicode-bidi:embed was used for lack of a better choice. Now that we have unicode-bidi:isolate, it should be the default instead, as the HTML5 spec (http://dev.w3.org/html5/spec/Overview.html#non-replaced-elements) says it should be.
Created attachment 102778 [details] test case
Created attachment 102780 [details] test case
This is going to make the bidi-isolate code even more performance-critical than it already is. :( Oh well.
Please note that unicode-bidi:isolate should not have any effect (and thus can be completely ignored) on elements that already constitute separate bidi paragraphs, e.g. elements with display other than inline, or that have float, or that have absolute position, etc. The default is meant for the case when a "block" element like div gets assigned display:inline. This should be a fairly rare case.
I suspect this may be as simple as adding the CSS from the HTML5 spec into html.css in WebCore: http://www.whatwg.org/specs/web-apps/current-work/multipage/rendering.html#bidirectional-text http://trac.webkit.org/browser/trunk/Source/WebCore/css/html.css The important piece is of course the LayoutTests which get landed with any change.
The change needs to be effective for "block" elements whether or not they have a dir attribute. Rules like div {display:block; unicode-bidi:isolate;} are not sufficient because the generic [dir] {unicode-bidi:embed;} is considered more specific and overrides them for elements with a dir attribute. See http://www.w3.org/Bugs/Public/show_bug.cgi?id=14850.
*** Bug 74988 has been marked as a duplicate of this bug. ***
Please note that this change was made in Chrome and Mozilla years ago.
(In reply to Aharon (Vladimir) Lanin from comment #8) > Please note that this change was made in Chrome and Mozilla years ago. It was in Mozilla... In Chrome I've just revived an old patch that was never merged. https://chromium-review.googlesource.com/c/chromium/src/+/1081302
Sorry, I got confused between https://bugs.chromium.org/p/chromium/issues/detail?id=296863 and https://bugs.chromium.org/p/chromium/issues/detail?id=391260. The latter, which is much more important than the former, was indeed fixed in 2016. Note, however, that the corresponding WebKit bug, https://bugs.webkit.org/show_bug.cgi?id=134630, is still NEW. That's the more important one.
(In reply to Aharon (Vladimir) Lanin from comment #10) > Sorry, I got confused between > https://bugs.chromium.org/p/chromium/issues/detail?id=296863 and > https://bugs.chromium.org/p/chromium/issues/detail?id=391260. The latter, > which is much more important than the former, was indeed fixed in 2016. > > Note, however, that the corresponding WebKit bug, > https://bugs.webkit.org/show_bug.cgi?id=134630, is still NEW. That's the > more important one. Thanks! Good to know.
New discussion in WhatWG: https://github.com/whatwg/html/issues/5594
(In reply to Noam Rosenthal from comment #11) > (In reply to Aharon (Vladimir) Lanin from comment #10) > > Sorry, I got confused between > > https://bugs.chromium.org/p/chromium/issues/detail?id=296863 and > > https://bugs.chromium.org/p/chromium/issues/detail?id=391260. The latter, > > which is much more important than the former, was indeed fixed in 2016. > > > > Note, however, that the corresponding WebKit bug, > > https://bugs.webkit.org/show_bug.cgi?id=134630, is still NEW. That's the > > more important one. > https://bugs.webkit.org/show_bug.cgi?id=134630 has been resolved. Waiting for consensus on https://github.com/whatwg/html/issues/5594 before tackling this one.
Created attachment 401438 [details] Patch
(In reply to Noam Rosenthal from comment #14) > Created attachment 401438 [details] > Patch Uploaded a patch so that EWS can find all kinds of platform-specific failing tests.
Created attachment 401523 [details] Patch
This patch modifies the imported WPT tests. Please ensure that any changes on the tests (not coming from a WPT import) are exported to WPT. Please see https://trac.webkit.org/wiki/WPTExportProcess
Comment on attachment 401523 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=401523&action=review > Source/WebCore/css/html.css:1279 > -bdi, output { > +address, blockquote, center, div, figure, figcaption, footer, form, header, hr, > +legend, listing, main, p, plaintext, pre, summary, xmp, article, aside, h1, h2, > +h3, h4, h5, h6, hgroup, nav, section, table, caption, colgroup, col, thead, > +tbody, tfoot, tr, td, th, dir, dd, dl, dt, menu, ol, ul, li, bdi, output { > unicode-bidi: isolate; > } Why not put "unicode-bidi: isolate" right after each "display: block", since the rule is that they go together? If we did that we could see that it’s done correctly. When done this way, to verify it’s correct we have to carefully scan this list to notice that nothing extra is included and nothing is left out, which seems impractical.
(In reply to Darin Adler from comment #18) > Comment on attachment 401523 [details] > Patch > > View in context: > https://bugs.webkit.org/attachment.cgi?id=401523&action=review > > > Source/WebCore/css/html.css:1279 > > -bdi, output { > > +address, blockquote, center, div, figure, figcaption, footer, form, header, hr, > > +legend, listing, main, p, plaintext, pre, summary, xmp, article, aside, h1, h2, > > +h3, h4, h5, h6, hgroup, nav, section, table, caption, colgroup, col, thead, > > +tbody, tfoot, tr, td, th, dir, dd, dl, dt, menu, ol, ul, li, bdi, output { > > unicode-bidi: isolate; > > } > > Why not put "unicode-bidi: isolate" right after each "display: block", since > the rule is that they go together? If we did that we could see that it’s > done correctly. When done this way, to verify it’s correct we have to > carefully scan this list to notice that nothing extra is included and > nothing is left out, which seems impractical. It's copied directly from https://html.spec.whatwg.org/multipage/rendering.html#bidi-rendering, I thought it would be easier to keep them in sync-ish and track later if we keep them similar.
Bump, this really worths the hassle and great that this amount of work is done.
Created attachment 460261 [details] Safari 15.5 matches other browsers I am unable to reproduce this bug in Safari 15.5 on macOS 12.4 by using attached test case and both lines look identical as required by expected result but I am not clear from the code perspective whether it is done correctly or not but from the output, it is rendering same across all browsers as shown in the attached screenshot. Thanks!
(In reply to Ahmad Saleem from comment #21) > Created attachment 460261 [details] > Safari 15.5 matches other browsers > > I am unable to reproduce this bug in Safari 15.5 on macOS 12.4 by using > attached test case and both lines look identical as required by expected > result but I am not clear from the code perspective whether it is done > correctly or not but from the output, it is rendering same across all > browsers as shown in the attached screenshot. Thanks! Code-wise, basically this https://searchfox.org/mozilla-central/source/layout/style/res/html.css#39-92 should be copied to https://searchfox.org/mozilla-central/source/layout/style/res/html.css#39-92 and layout tests WebKit has in the repository should be updated. A test case, data:text/html;charset=utf8,شی<div style="display:%20inline">(ظطز) should get Firefox's result (not even Chrome result)
<rdar://problem/96912726>
We match Chrome, but apparently Firefox is right but Chrome is wrong? @Myles: Can you confirm what we should do here?
The test case from 2011 was fixed by https://bugs.webkit.org/show_bug.cgi?id=134630. This bug is about the test case Ebrahim described in https://bugs.webkit.org/show_bug.cgi?id=65617#c22.
*** Bug 267887 has been marked as a duplicate of this bug. ***
For the record, I’m OK with copying the rule from the specification, despite my suggestion that maintenance would be easier if these were paired with "display: block". So that comment should not block this. Since Myles isn’t working on the project any more, who can move this forward?
(In reply to Darin Adler from comment #27) > For the record, I’m OK with copying the rule from the specification, despite > my suggestion that maintenance would be easier if these were paired with > "display: block". So that comment should not block this. Since Myles isn’t > working on the project any more, who can move this forward? Happy to give it a try. I will try to do changes from Noam and give credit and will do draft PR and then fix all remaining test cases (as best as I can). :-)
Just to update - I have this draft PR ready will all tests rebased but now we have WPT tests, so I will sync and then rebase my PR and then it would be ready for review (need to update - commit log as well for PR): Draft PR - https://github.com/WebKit/WebKit/pull/23084