This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Comment from the i18n review of: http://dev.w3.org/html5/spec/ Comment 10 At http://www.w3.org/International/reviews/html5-bidi/ Editorial/substantive: S Tracked by: AL Location in reviewed document: undefined [http://dev.w3.org/html5/spec/spec.html#contents] Comment:This is a part of the proposals made by the "Additional Requirements for Bidi in HTML" W3C First Public Working Draft. For a full description of the use cases, please see http://www.w3.org/International/docs/html-bidi-requirements/#blocks-as-separators [http://www.w3.org/International/docs/html-bidi-requirements/#blocks-as-separators] . Here is the proposal made there: At one time, all browsers treated block elements that have been given display:inline in CSS as an ordinary inline element for bidi purposes, (i.e. gave no special treatment). One use case for using display:inline on block elements is getting an inline auto-numbered list with <ol style "display:inline">. To get bidi treatment of such use cases, HTML 4 explicitly specified (http://www.w3.org/TR/REC-html40/struct/dirlang.html#style-bidi): "When a block element that does not have a dir attribute is transformed to the style of an inline element by a style sheet, the resulting presentation should be equivalent, in terms of bidirectional formatting, to the formatting obtained by explicitly adding a dir attribute (assigned the inherited value) to the transformed element". The intent was to prevent the bidi ordering within such an element from being affected by the element's surroundings, as it would not be affected if it still had block display. To date, the only browser to implement this specification is Firefox. Unfortunately, this condition does not go far enough, since adding a dir attribute to an inline element does not prevent it from affecting the bidi ordering of its surroundings in ways that a separate block would not. A separate bug defining the ubi attribute specifies that the default ubi attribute value for a block element with display:inline shall be "ubi", isolating the element directionally from its surroundings. This is meant as an improvement on the condition mentioned above. Thus, the condition above should be removed from the HTML specification. A nice side-effect of this change is that when display:inline block element is explicitly given ubi=off, it will be displayed the way it had been before this condition was added to the HTML specification and the way it is currently displayed in all major browsers except Firefox. These changes do not present a problem for backward compatibility because the HTML 4 specification was never implemented in this respect by most browsers.
It's awkward to implement special cases where a computed CSS property value on particular elements has other side effects. It's not possible to express this in a stylesheet for instance, it would require hardcoded special cases. It would also be particularly strange for the value of a CSS property to implicitly change the value of a markup attribute, so this surely should not create a literal "ubi" attribute, just have the same effect. Since block-level elements with display: block already act as paragraphs, they already essentially have the effect of bidi-isolate. Perhaps one possible way to handle this is to give blocks recommended default rendering like this: div { display: block; unicode-bidi: isolate; } This would preserve bidi isolation if the element's display type is changed to inline, unless the author takes further steps to override unicode-bidi. It would have the additional side effect of leaving isolation enabled for display types other than "inline" or "block". I am not sure offhand whether or not that is desirable. I fear that this may be confusing to authors in any case, though. I think there is an expectation that <div style="display: inline"></div> renders exactly equivalent to <span>, under default styling. Perhaps this should be limited to list items, as that is the primary use case presented.
> I think there is an expectation that > <div style="display: inline"></div> > renders exactly equivalent to <span>, > under default styling. That expectation, reasonable as it sounds, did not prevent an explicit requirement in the HTML 4 spec that runs counter to it (http://www.w3.org/TR/REC-html40/struct/dirlang.html#style-bidi): "When a block element that does not have a dir attribute is transformed to the style of an inline element by a style sheet, the resulting presentation should be equivalent, in terms of bidirectional formatting, to the formatting obtained by explicitly adding a dir attribute (assigned the inherited value) to the transformed element". > Perhaps one possible way to handle this > is to give blocks recommended default > rendering like this: > > div { > display: block; > unicode-bidi: isolate; > } That sounds good, with one potential problem. I would prefer that the behavior be controllable through the ubi attribute, i.e. get no isolation for <div style="display:inline" ubi=off>, but I don't think that this will be the case for this mechanism. On the other hand, this is not a very strong preference. I think we can live with having to use <div style="display:inline;unicode-bidi:normal"> to get no isolation. So, this solution is acceptable to me (although others should feel free to speak up if they do not like it). Nevertheless, we still need to remove the language quoted above ("When a block element that does not have a dir attribute is transformed...") from the HTML5 spec (if it is there as it was in HTML 4).
Adding <allblockelementsselector> { unicode-bidi: isolate; } <allblockelementsselector>[ubi=off] { unicode-bidi: normal; } is pretty straightforward. You do need to specify that the default value of 'ubi' is different for block elements than for inline elements, however, since some implementations (e.g. IE) do put default values in the DOM such that they can be selected.
(In reply to comment #2) > > I think there is an expectation that > > <div style="display: inline"></div> > > renders exactly equivalent to <span>, > > under default styling. > > That expectation, reasonable as it sounds, did not prevent an explicit > requirement in the HTML 4 spec that runs counter to it > (http://www.w3.org/TR/REC-html40/struct/dirlang.html#style-bidi): > > "When a block element that does not have a dir attribute is transformed to the > style of an inline element by a style sheet, the resulting presentation should > be equivalent, in terms of bidirectional formatting, to the formatting obtained > by explicitly adding a dir attribute (assigned the inherited value) to the > transformed element". It seems most browsers don't implement that, though. And HTML5, which better matches implementation reality, and author expectations, does not have this requirement. > > > Perhaps one possible way to handle this > > is to give blocks recommended default > > rendering like this: > > > > div { > > display: block; > > unicode-bidi: isolate; > > } > > That sounds good, with one potential problem. I would prefer that the behavior > be controllable through the ubi attribute, i.e. get no isolation for <div > style="display:inline" ubi=off>, but I don't think that this will be the case > for this mechanism. If the ubi attribute is added, then surely it should be defined in terms of a mapping to the unicode-bidi CSS property. Whether it overrides a generic style rule depends on whether it is specified as a set of ordinary stylesheet rules (in which case it would) or a presentational hint (in which case it would not). > > On the other hand, this is not a very strong preference. I think we can live > with having to use <div style="display:inline;unicode-bidi:normal"> to get no > isolation. > > So, this solution is acceptable to me (although others should feel free to > speak up if they do not like it). > > Nevertheless, we still need to remove the language quoted above ("When a block > element that does not have a dir attribute is transformed...") from the HTML5 > spec (if it is there as it was in HTML 4). I don't believe it is there in HTML5.
> It seems most browsers don't implement that, though. Actually, Gecko has. And it does give better results for bidi cases, although isolation would be better. (Isolation was not a possibility when HTML4 was written; the closest you could get was to embed.) Since it will not break existing documents, and would prevent unexpected and rather confusing bidi-related breakage, I strongly recommend that the HTML5 spec port this requirement from HTML4 to HTML5.
(In reply to comment #2) > > I think there is an expectation that > > <div style="display: inline"></div> > > renders exactly equivalent to <span>, > > under default styling. > > That expectation, reasonable as it sounds, did not prevent an explicit > requirement in the HTML 4 spec that runs counter to it > (http://www.w3.org/TR/REC-html40/struct/dirlang.html#style-bidi): > > "When a block element that does not have a dir attribute is transformed to the > style of an inline element by a style sheet, the resulting presentation should > be equivalent, in terms of bidirectional formatting, to the formatting obtained > by explicitly adding a dir attribute (assigned the inherited value) to the > transformed element". I think it would be helpful for everybody to understand why this text was put in (I think it was mostly me who wrote it). The assumption was that <div>s would be displayed as blocks, but there might be styling variants that would take the *same* document and style some (or all) <div>s as inline. The main example was actually not <div>s, but lists. Now embeddings and such are inherited automatically on blocks, and so in the block styling, there would be an embedding, which then would suddenly vanish if the styling changed to inline. So the whole provision is not for a case like <div style="display: inline"></div> (why would you need that when you have <span> in the first place), but for a case like <link rel="stylesheet" type="text/css" href="blocks.css" title="Blocky" /> <link rel="alternate stylesheet" type="text/css" href="inline-blocks.css" title="Inliny" />
> Now embeddings and such are inherited automatically on blocks, and so in the > block styling, there would be an embedding To clarify what Martin's talking about, the effect of being a block, bidi-wise, is similar to that of being an embedding: the surrounding contents do not affect resolution within the element, and the 'direction' of the element determines the direction at its boundaries. (It has nothing to do with "inheriting embeddings" or anything like that.) Furthermore, any text reordering is confined within the boundaries of the element, which is an important similarity to the behavior of blocks. Both with isolation and with embedding, not only are the contents of the element isolated from the surrounding content, but, as with a block element, the contents of the element do not affect bidi resolution of the surrounding content. The difference between isolation and embedding is the effect of the element itself on the surrounding contents. For isolation, it's treated as neutral--effectively invisible. For embedding, it's treated as a strong character in the direction of the embedding.
(In reply to comment #3) > Adding > <allblockelementsselector> { > unicode-bidi: isolate; > } > > <allblockelementsselector>[ubi=off] { > unicode-bidi: normal; > } > is pretty straightforward. You do need to specify that the default value of > 'ubi' is different for block elements than for inline elements, however, since > some implementations (e.g. IE) do put default values in the DOM such that they > can be selected. Sounds great!
(In reply to comment #5) > > It seems most browsers don't implement that, though. > > Actually, Gecko has. And it does give better results for bidi cases, although > isolation would be better. (Isolation was not a possibility when HTML4 was > written; the closest you could get was to embed.) Since it will not break > existing documents, and would prevent unexpected and rather confusing > bidi-related breakage, I strongly recommend that the HTML5 spec port this > requirement from HTML4 to HTML5. I am not sure what you mean about porting the requirement. If we get the unicode-bidi:isolate to be applied by default to block elements (except for those with ubi=off) as proposed above, we do not need the embedding, and the HTML4 requirement for embedding should be left out of HTML5, as it apparently already is.
I'm happy to spec whatever browsers do. Previously I was told (by fantasai) to say 'unicode-bidi:embed' for all non-'inline' elements, to avoid the problem described above. Should I change this to 'unicode-bidi:isolate'? Would that resolve this bug?
(In reply to comment #10) > I'm happy to spec whatever browsers do. > > Previously I was told (by fantasai) to say 'unicode-bidi:embed' for all > non-'inline' elements, to avoid the problem described above. > > Should I change this to 'unicode-bidi:isolate'? Would that resolve this bug? I hope somebody can check the details, but to give some more historical background, when we were designing the bidi features in HTML (RFC 2070, taken over in HTML4) and CSS, we were not aware of the fact that bidi embeddings were as 'leaky' and 'promiscuous' as it later turned out they were. So it's very much possible that we would have choosen isolating behavior from the start if we knew about that.
(In reply to comment #11) > (In reply to comment #10) > > I'm happy to spec whatever browsers do. > > > > Previously I was told (by fantasai) to say 'unicode-bidi:embed' for all > > non-'inline' elements, to avoid the problem described above. > > > > Should I change this to 'unicode-bidi:isolate'? Would that resolve this bug? > > I hope somebody can check the details, but to give some more historical > background, when we were designing the bidi features in HTML (RFC 2070, taken > over in HTML4) and CSS, we were not aware of the fact that bidi embeddings were > as 'leaky' and 'promiscuous' as it later turned out they were. So it's very > much possible that we would have choosen isolating behavior from the start if > we knew about that. Making them all 'unicode-bidi:isolate' sounds right to me. Fantasai?
EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document: http://dev.w3.org/html5/decision-policy/decision-policy.html Status: Accepted Change Description: see diff given below Rationale: Ok, I've made all these elements have unicode-bidi:isolate instead.
Checked in as WHATWG revision r5635. Check-in comment: Update bidi algorithm CSS mappings to use new features. http://html5.org/tools/web-apps-tracker?from=5634&to=5635