Re: [CSS3] ltr and rtl pseudo-class proposal

Andrew, and the rest of CSS proponents:

Justin's questions helped focus my thoughts, and now I have a couple  
of questions which may focus the discussion, or may expand it.

1. Is there a reason for limiting the scope to the two attributes:  
ltr and rtl? What about ttb and btt (for other languages)? Would it  
make sense to consider these as well now, rather than make decisions  
about ltr/rtl and then have to add them later? (I checked the  
specifications and, currently, 'direction' only refers to ltr and  
rtl, but may have to change.)

2. Alternatively, could we stop thinking about left and right (and  
top and bottom) completely and change everything to refer to 'start'  
and 'end'? I realize this is a major step, as many styles refer to  
'top, right, bottom, left' and other combinations. I am not proposing  
that the group completely rid themselves of these, only that they  
consider that they may already be on the wrong path and have a chance  
to consider that path and whether they should change it.

In defense of question #2, I would like to say that, if EVERYTHING  
changes to only refer to start and end, the question of :ltr and :rtl  
might go away. List markers could be placed :before or :after, and no  
new feature such as ':rtl' would be needed. Other simplifications  
might take place with paragraph first line indents and first  
character placements. If the group really wants to consider this, I  
might be able to produce a few more use cases, as well. (I recognize  
that any suggestion this huge needs lots of defense.)


On Mar 17, 2008, at 8:04 AM, Justin Rogers wrote:

> ... [some text clipped here]
>
> I think where the conversation is going here is:
> 1) Are we done with just these two additions for inherited  
> properties? (:ltr/:rtl)
> 2) Are more coming down the pipeline?
>
> If 1 then just define the behavior in a module and let it go. If 2  
> then we need a special attribute selector which is capable of  
> walking the parent chain with notes in the specification that  
> performance of such a selector might be less than optimal.
>
> Justin Rogers [MSFT]
>



</James>

Received on Monday, 17 March 2008 15:32:47 UTC