Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Fwd: Re: (RTL 2.5) can we use *-inline-start / *-inline-end?

8 views
Skip to first unread message

sfoster

unread,
Sep 15, 2015, 10:53:51 AM9/15/15
to dev-...@lists.mozilla.org
I think this is a question for the list. I'm a bit worried its late in the cycle for this kind of change and there may be unknowns. That said if were are going to adopt these properties, doing it once while we refactor is a great time to do it

--
Sent Using Firefox OS

-------- Original message --------
Subject: Re: (RTL 2.5) can we use *-inline-start / *-inline-end?
Date: Tue Sep 15 2015 03:28:06 GMT-0700 (PDT)
From: "Ahmed Nefzaoui" <nefz...@arabicmozilla.org>
To: "Fabien Cazenave" <ka...@phoxygen.com>
Cc: "Samuel Foster" <sfo...@mozilla.com>, "Tech" <te...@phoxygen.com>, "Francesco Lodolo" <fl...@mozilla.com>
I guess someone's already working on upgrading to 43 (see gaia#pull31847) :) Which is good, I totally agree we should alwyas be using the latest CSS logical properties for their many benefits as that's the point of having them :)

Thanks!
Ahmed

On Tue, Sep 15, 2015 at 10:55 AM, Fabien Cazenave <ka...@phoxygen.com> wrote:
Hey Sam,

we just realized that Gecko 43 supports new direction-sensitive CSS properties that would make it much easier to write BiDi-proof stylesheets:

 • float: {left,right} can be replaced by inline-{start,end}
 • absolute positioning: {left,right} can be replaced by offset-inline-{start,end}
 • -moz-{margin,padding,border}-{start,end} can be replaced by {margin,padding,border}-inline-{start,end}

This could be applied to all elements that don’t have a `dir="auto"` attribute: fewer html[dir="{ltr,rtl}"] selectors, and fewer occurrences of `left` and `right` in stylesheets (thus, making it easier to check their BiDi-friendliness).

The main drawback we see for now is that the CSS linter doesn’t support these properties yet, because the build system still uses Gecko 39. If we can’t upgrade it to Gecko 43, we could just activate the `layout.css.vertical-text.enabled` pref: that would work for {offset,margin,padding,border}-inline-{start,end}, but not for `float: inline-{start,end}` — in which case, we’d either keep `float: {left,right}` behind a `html[dir]` or add a few lines to csslint/xfail.list.

Do you see other reasons for *not* using these CSS properties?

Cheers,
:kazé

Jonathan Kew

unread,
Sep 15, 2015, 11:08:24 AM9/15/15
to sfoster, dev-...@lists.mozilla.org
I don't believe 'float' accepts inline-{start,end} values. They're in
the current draft of CSS Logical Properties, but we haven't implemented
them yet AFAIK.

See https://bugzilla.mozilla.org/show_bug.cgi?id=1122918.


> • absolute positioning: {left,right} can be replaced by
> offset-inline-{start,end}
> • -moz-{margin,padding,border}-{start,end} can be replaced by
> {margin,padding,border}-inline-{start,end}

Yes, these should work fine.

JK


>
> This could be applied to all elements that don’t have a `dir="auto"`
> attribute: fewer html[dir="{ltr,rtl}"] selectors, and fewer
> occurrences of `left` and `right` in stylesheets (thus, making it
> easier to check their BiDi-friendliness).
>
> The main drawback we see for now is that the CSS linter doesn’t
> support these properties yet, because the build system still uses
> Gecko 39. If we can’t upgrade it to Gecko 43, we could just activate
> the `layout.css.vertical-text.enabled` pref: that would work for
> {offset,margin,padding,border}-inline-{start,end}, but not for
> `float: inline-{start,end}` — in which case, we’d either keep
> `float: {left,right}` behind a `html[dir]` or add a few lines to
> csslint/xfail.list.
>
> Do you see other reasons for *not* using these CSS properties?
>
> Cheers,
> :kazé
>
>
>
>
> _______________________________________________
> dev-gaia mailing list
> dev-...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-gaia
>

0 new messages