- From: <bugzilla@jessica.w3.org>
- Date: Fri, 22 Oct 2010 21:22:12 +0000
- To: public-html-bugzilla@w3.org
http://www.w3.org/Bugs/Public/show_bug.cgi?id=10808
fantasai <fantasai.bugs@inkedblade.net> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |fantasai.bugs@inkedblade.ne
| |t
--- Comment #22 from fantasai <fantasai.bugs@inkedblade.net> 2010-10-22 21:22:04 UTC ---
(In reply to comment #18)
>
> (1) Should the scan be redone if the contents of the element change (e.g. due
> to DOM manipulation), rather than only doing it once?
Yes.
> (2) Should the scan consider CSS generated content (e.g. markers, :before
> content, text transforms, etc) instead of just looking at the raw text?
No.
> (3) Should the scan exclude text that is "display: none" and therefore is not
> rendered?
No.
> My answer to all three questions would be "yes", which is why I think this
> needs to be at the CSS layer, rather than just the HTML layer.
It should be an invariant in the design of bidi features that bidi resolution
does not depend on CSS. In other words, bidi should resolve exactly the same
whether the author-level style sheet has been enabled or disabled.
In reality, CSS block boundaries determine bidi boundaries, and so CSS will
have an effect on bidi resolution if the author is playing with unorthodox
display values and suchlike; however, the bidi dependence on CSS should be
minimized.
> direction: auto;
Aside from the point that full bidi resolution should be possible without
interpreting any CSS, there are several CSS features under consideration that
this would break:
- :rtl and :ltr selectors that map based on the markup-determined
directionality of the element
- logical properties such as margin-start and margin-end, which are
at the very least needed in the UA style sheet
The first requires a direction value to be resolved before selector matching,
and the second requires direction value to be resolved during the cascade.
Neither of these features is possible if bidi resolution is pushed into
the layout stages.
Wrt use cases:
The most important ability for HTML to have is a way of auto-detecting the
direction of user input and being able to faithfully replay that back into an
HTML-based UI. The simplest way to do this is to interoperate with the
plaintext bidi protocol, which is first-strong per paragraph of plaintext. This
means being able to indicate plaintext bidi handling of any input elements, and
plaintext bidi handling of any elements used to replay that input (or truly
plaintext input such as email).
There has been a lot of talk about doing something more intelligent than the
plaintext protocol, but bidi resolution is complicated and hard-to-understand,
and also an area where exact interop is important. It seems to me there's a lot
of research and discussion left to do in this area, and I'm personally not
convinced that trying to standardize something more intelligent than the
plaintext protocol is something we should attempt right now. I would vote for
addressing that in a separate bug, possibly on a later timeline.
--
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
Received on Friday, 22 October 2010 21:22:13 UTC