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 9 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: An element with display:block, except when it has been taken out of document flow with CSS such as float or position:absolute, but regardless of whether it is a block element or inline element, should be specified as introducing a UBA paragraph break between the content preceding and following it. This does not present a problem for backward compatibility because there has been no browser interoperability in this respect. If the display:block element has display:inline ancestors that have bidi properties (e.g. the dir attribute or the <bdo> element), these bidi properties should be applied to the anonymous block boxes created for these ancestors, in accordince with CSS specs for anonymous block boxes.
Since this is about the behavior of CSS display types, it should probably be defined in CSS, not in HTML. Non-HTML content set to CSS display: block should almost certainly have the same behavior.
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: Rejected Change Description: no spec change Rationale: This seems to be about CSS, not HTML.
(I'd send the bug to the CSSWG instead, but they don't use Bugzilla.)
This most certainly should also be included in the CSS spec, but this is not enough. As far as I understand, HTML is still supposed to be usable without CSS, and its spec is supposed to describe what to expect (minus presentation) from every HTML feature. Thus, for example, the spec of the dir attribute describes its effect (which is more than presentation) without limiting it to CSS terms. The HTML spec should therefore include a description of the effect that a block element will have on the bidi ordering of the inline content preceding and following it (which is more than presentation), with a note that this is actually dependent on the CSS display property - where it has been overridden from its default value.
If we're not talking about CSS, what is a "block element" or an "inline element"?
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: Did Not Understand Request Change Description: no spec change Rationale: see comment 5
(In reply to comment #5) > If we're not talking about CSS, what is a "block element" or an "inline > element"? Block elements are those that are displayed as blocks without a stylesheet or with the default stylesheet (and also with most other stylesheets) by browsers. Inline elements are those that are displayed inline without a stylesheet or with the default stylesheet (and also with most other stylesheets) by browsers. (this distinction is rather irrelevant for this bug, because the text says "regardless of whether it is a block element or inline element", but the information given here may be helpful in other contexts) As for background information, a quick Google search found e.g.: http://www.w3.org/TR/REC-html40/struct/global.html#h-7.5.3 http://htmlhelp.com/reference/html40/block.html http://htmlhelp.com/reference/html40/inline.html
(In reply to comment #7) > (In reply to comment #5) > > If we're not talking about CSS, what is a "block element" or an "inline > > element"? > > Block elements are those that are displayed as blocks without a stylesheet or > with the default stylesheet (and also with most other stylesheets) by browsers. > > Inline elements are those that are displayed inline without a stylesheet or > with the default stylesheet (and also with most other stylesheets) by browsers. > > (this distinction is rather irrelevant for this bug, because the text says > "regardless of whether it is a block element or inline element", but the > information given here may be helpful in other contexts) > > As for background information, a quick Google search found e.g.: > http://www.w3.org/TR/REC-html40/struct/global.html#h-7.5.3 > http://htmlhelp.com/reference/html40/block.html > http://htmlhelp.com/reference/html40/inline.html Those are all references to HTML 4.0. HTML 5 seems to be doing away with the concept of block and inline elements. It has a complicated graph of intersecting element types: <http://dev.w3.org/html5/spec/Overview.html#kinds-of-content>. It is possible to replace "block elements" with something like "flow elements that are not phrasing or sectioning elements", but the question remains whether there is a need to define the behavior of these elements in the absence of CSS given Ian's comment on another bug: 'HTML explicitly doesn't define rendering except by reference to CSS, which applies whether or not the browser actually implements CSS the spec says "User agents that use other presentation mechanisms can derive their expected behavior by translating from the CSS rules", where "expected to" is the normative equivalent of "must" in that section.'