W3C home > Mailing lists > Public > www-style@w3.org > December 2014

Re: [css-writing-modes][css-scoping] unicode-bidi in Shadow DOM, and possibly other properties?

From: Koji Ishii <kojiishi@gmail.com>
Date: Mon, 22 Dec 2014 16:35:11 +0900
Message-ID: <CAN9ydbXdCeU0u3_-_Odvtb4MKkW_HMMsAT14dhi_Qy2GbVTrog@mail.gmail.com>
To: Simon Pieters <simonp@opera.com>
Cc: www-style list <www-style@w3.org>, public-i18n-bidi@w3.org
On Thu, Dec 18, 2014 at 3:38 PM, Simon Pieters <simonp@opera.com> wrote:
>> What's more interesting to me is that this section uses dir="i", which
>> is not defined in either HTML spec[3][4].
> No, it doesn't. It uses the selector [dir=ltr i] where the i means
> case-insensitive match for the attribute value "ltr".
> http://dev.w3.org/csswg/selectors4/#attribute-case

Ah, ok, I was too much looking for dir=isolate and forgot that, thank you.

> I'm not an expert in either Shadow DOM or bidi, but...
> I think if you want to match HTML elements like <div>, it should be
> unicode-bidi: isolate; except when the document's encoding is ISO-8859-8 in
> which case it should be unicode-bidi: bidi-override;. As a UA-level style
> rule.
> If you want to match HTML elements like <span> or unknown elements, don't
> set unicode-bidi.
> What should happen with <span is=foo-bar>?
> I don't think you want to just override the computed value of the host
> element. What if the author has set it to something else?

Thank you for the great suggestion. I was under an assumption that
Shadow DOM needs to enforce encapsulations, but your suggestions
brought me two questions I'd want to run with Shadow DOM experts:

1. If Shadow hosts are inline, do we want its bidi state isolated or
not from the parent tree?

2. Your suggestion makes sense, but then it'd be author's
responsibility to set it correctly for custom elements. Are we ok with
this, or do something in custom elements?

I don't have answers to these questions right now, I'll look into
further. Thank you for your thoughts!

Received on Monday, 22 December 2014 07:35:38 UTC

This archive was generated by hypermail 2.4.0 : Monday, 23 January 2023 02:14:46 UTC