RE: [css3-writing-modes] a third option for implementing logical properties

> First, I don't like the "logical" keyword. What we are indicating is the
> reference. And there's nothing particularly logical about using the
> writing-mode as the referece. So, I suggest one of these instead:
> 
>   margin: script 1em 0px;         /* my favorite */
>   margin: writing-mode 1em 0px;
>   margin: beas 1em 0px;           /* before-end-after-start */

Does "beas" just a keyword, or per-character-indicator? I mean, can I also say

margin: e 1em;

I just thought if that's what you meant, we can also get rid of all margin-before/end/after/start properties as well to reduce the number of properties.


> Second, we should also think of how this can be expanded to the
> inside/outside use case. There we could say:
> 
>   margin: spread 1em 0px;
>   margin: tobi 1em 0px;           /* top-outside-bottom-inside */
> 
> ('before' and 'bottom' both start with a 'b', unfortunately)

I like this approach too. You're right that we need to resolve inside/outside in near future, and single syntax to resolve both issues looks great.


> Third, what are we keying off? That is, what does the UA consult when trying
> to find out how to resolve these abstracted values? There are several
> options:
> 
>   - the computed value of 'writing-mode' for the element
> 
>   - some document-wide setting that reflects the major writing
>     direction of the document, e.g., the computed value of
>     'writing-mode' for the root element
> 
> For inside/outside, the most natural value to key off from the which page
> the content is on. This cannot be resolved on a per-element basis (as
> elements can be paginated).

CSS3 paged media defines that page progression is defined from the value of writing-mode of the root element, and I think even/odd page rules for page-break-after should follow that. I think the same method works here too.


> I'm slightly worried about having a binary switch for "full support"
> or not. One can see clients that support ltr and rtl, but not vertical layout.
> Or some other matrix. Why not use media queries and query the dominant
> direction of the document, e.g.:
> 
>   body { border-radius: 1em 2em }
>   @media (dir: vertical-lr) {
>     body { margin: border-radius: 2em 1em }
>   }

I agree with this. There might be some browsers that supports vertical-rl but not vertical-rl. Your solution seems to cover these cases perfectly.


>  > No property other than these basic box model properties would be  >
> "logicalized"
> 
> I support this. It's managable. It seems managable.

All what we're discussing is not just for backward compatibility. Features like multicol had to take vertical into the account, and as you know, it's all logical already. There will be more features that need to design with vertical in mind. Text flow is not something that can be done once and leave afterwards; it needs to be in the fundamental part of the browser, and each feature must take it into account. I understand it's burden for you all, I appreciate that and I'm willing to be any help if that helps.


Regards,
Koji

Received on Monday, 25 October 2010 14:06:41 UTC