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

Re: RTL support in CSS (Was: [css3-box] Float start/end issue)

From: Julien Wajsberg <jwajsberg@mozilla.com>
Date: Wed, 24 Sep 2014 18:17:37 +0200
Message-ID: <5422EEA1.2000407@mozilla.com>
To: "Tab Atkins Jr." <jackalmage@gmail.com>
CC: www-style list <www-style@w3.org>
Le 24/09/2014 17:44, Tab Atkins Jr. a écrit :
> On Wed, Sep 24, 2014 at 6:13 AM, Julien Wajsberg <jwajsberg@mozilla.com> wrote:
>> Le 23/09/2014 22:22, Tab Atkins Jr. a écrit :
>>> On Tue, Sep 23, 2014 at 8:29 AM, Julien Wajsberg <jwajsberg@mozilla.com> wrote:
>>>> Tab Atkins Jr wrote:
>>>> On Wed, May 28, 2014 at 2:17 AM, Salar Khalilzadeh <salar2k@gmail.com>
>>>> wrote:
>>>>> Back in 2009 a few values added to the float property in 'CSS basic box
>>>>> model' module  but they haven't finalized yet.
>>>>> These new values for float property would be very helpful for RTL
>>>>> languages.
>>>>> Please give the module more attention.
>>>>> I wanted to hint on the Issue 61 which says "Adding ‘start’ and ‘end’ was
>>>>> decided at 2009-12-02 telcon. Precise definitions not yet decided: does it
>>>>> depend on ‘direction’ of the element itself or its parent? "
>>>>> http://dev.w3.org/csswg/css-box/#the-float-property
>>>>> I strongly believe that start/end should depend on the element itself.
>>>>> They
>>>>> should follow the behavior of the float which applies on the element, so
>>>>> the
>>>>> new start/end values will depend on the direction of the element.
>>>>> Otherwise I as a developer have to wrap my element with another element
>>>>> and
>>>>> change the direction there!! what a waste.
>>>> On the other hand, that means you can't set "float: start;" on a bunch
>>>> of elements in some container and expect them to float to the same
>>>> side.
>>>> We've addressed this in the Alignment module by having start/end base
>>>> themselves off the container's direction, and having separate
>>>> self-start/self-end values that base themselves on the item's
>>>> direction.
>>>> Is it something there is a good agreement about?
>>>> I also agree that "start" and "end" should be relative to the containining
>>>> box's direction (so, I don't agree with the initial mail), for consistency
>>>> with other specs, especially [css-position-3], where we alway refer to the
>>>> containing box.
>>>> I have no opinion about self-start/self-end, but from the initial message in
>>>> this thread it looks like there is at least some request.
>>>> What's needed to move forward about this?
>>>> [css-position-3] http://dev.w3.org/csswg/css-position-3
>>> What do you think needs to be moved forward on?  Alignment is stable
>>> in this regard; Box isn't a good reference for these topics (2.1 is
>>> still the correct reference).
>> Well, I'm looking forward seeing the "start" and "end" value specified
>> and implemented for the "float" property. I don't see this discussed in
>> 2.1 at all.
>> Some context can be useful. I work on a core Firefox OS app and as I
>> result I have the luxury to be able to use new CSS features, and give
>> early feedback. These days we're working on supporting RTL languages.
>> The usual way of doing this is overriding all properties that use
>> left/right. There are tools that do this automatically. However while
>> this is good for one-shot conversion, this is really bad for long-term
>> maintainability. That's why I'm looking for the "native" CSS support for
>> this. "start" and "end" values for the "float" property is only one part
>> of the support obviously.
> Ah, gotcha.  Unfortunately, there's no real timeline for continuing
> work on 'float' right now. :/

Besides float, I'm interested in other RTL matters too:
offset-start/end, support in background-position, margin-start/end,
padding-start/end (and support in the shorthand notations). I think
border properties are important as well, but not so important for me.

Gecko currently supports: margin-start, margin-end, padding-start,
padding-end (prefixed), text-align: start/end, and of course the
standard support in flexible layout.

What could help pushing this forward? Should we continue implementing
this in Gecko behind prefs?


Received on Wednesday, 24 September 2014 16:18:08 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:08:46 UTC