Re: [css3-writing-modes] direction vs. writing mode in markup vs. style

On Mon, Oct 25, 2010 at 12:11 AM, fantasai
<fantasai.lists@inkedblade.net> wrote:
> Breaking the thread because this is an important distinction that
> I think some people here are not getting.
>
> On 10/24/2010 09:29 AM, David Hyatt wrote:
>>
>> Another idea: just specify writing-mode in HTML instead and don't have
>> it be in CSS at all (except as a pseudo class you match on in order to
>> provide rules for that writing mode).  This is a little weird in that
>> we already have direction in CSS though.
>
> Two things:
>
> a) Base directionality is a content property, not a styling property.
>   The base directionality of an element is ultimately description of
>   the content inside it and provides data that is critical to its
>   correct layout no matter what styling (if any) is in use.
>
>   (The 'direction' property does not actually belong in CSS: it exists
>   in CSS in order to allow the HTML 'dir' attribute's functionality
>   for raw XML documents. This use case probably should have been
>   addressed with an xml:dir attribute rather than with CSS.)
>
>   No author of an HTML document should be setting or resetting the
>   base directionality of any elements via CSS: it should be set in
>   the HTML, where it can be processed by non-CSS UAs and when author
>   styles are disabled. [1]
>
> b) The vertical/horizontal mode setting is not a content property, but
>   a layout and stylistic one. It thus belongs in the styling layer,
>   and not in the markup.
>
> To me, any solution that scrambles this markup/style distinction is a
> non-starter. So if this doesn't make sense to you, let's talk about it.

Agreed 100%, fwiw.


> BTW, while I have your attention, the CSSWG's suggestion from the Oslo
> F2F to use HTML's alternate style mechanism to address vertical vs.
> horizontal styles has *already* been accepted by EPUB as the way forward
> for addressing alternate style requirements. So let's please focus the
> discussion on use cases that cannot be solved by this mechanism. [2]

Hm, okay.  That's definitely the solution that requires the least work
from us, so I guess it's cool if EPUB likes it.  This also seems to be
basically what Hakon was wanting, right?

I'm totally fine with this solution technically, I just thought it
wasn't great from an author perspective.  If EPUB thinks it's
sufficient, though, then I'm happy to go with it.


> Note also that EPUB has its own mechanism for handling unsupported
> features, so that use case, while also applicable to CSS in general
> and imo something we should address generally, is probably not urgent
> for us to solve for them.

Good to know.

~TJ

Received on Monday, 25 October 2010 17:53:40 UTC