Hi Fred,
Interesting idea!
Why does your postcss plugin replaces start by left/right equivalent (if
I understand the README correctly)? In the general case you don't want
to do that: start/end are perfectly fine and BiDi-proof. You want
explicit left and right only when the direction depends on the content,
ie only when you have dir="auto".
I would expect it to leave alone start/end properties, but add a right
property for rtl when there is a left property, and add a left property
when there is a right.
This way, CSS writers would use start for elements without any
dir="auto", and would use left for element that needs explicit
alignment, and things would be done correctly in RTL.
And +1 with Sam: the specificity problem we create by having the same
specificity in ltr and rtl for direction-specific rules are easier to
detect and fix, and much less frequent than by using asymetric rules as
you do now.
Some missing features I see. You might want to add support for:
- background-position for background that are not sprites. (how will the
css dev indicate that?)
- transform: translateX
- margin/padding shortcuts with 4 values when the left value is not the
same as right.
Have you thought of a way of telling the postprocessor that a specific
line should not be processed? There are always exceptions... I suggest a
/* BiDi-proof */ comment on the previous line for example.
You'll also need to exclude rules that /already/ have a
html[dir="ltr|rtl"] prefix.
Of course, I think you'll still need to have manual coding for some
cases. For example, in contacts, the scrollbar (with the letters) stays
right in rtl, which makes this automatic process not applicable (because
the mirroring is not symmetric any more). Or sometimes you need to
mirror some icons (and some of them are NOT a true horizontal symmetry
unfortunately, for example the "edit" icon).
That being said, this could ease the dull part of mirroring a
stylesheet, although I would personally use it more as a pre-processor,
test and then commit the result, than as a post-processor.
Augustin Trancart
Phoxygen
On 26/11/2015 02:04, Sam Foster wrote:
One of the issues we had to be careful of when implementing RTL/BiDi
with CSS was that html[dir="rtl"] .foo has greater specificity than
.foo, so there could be unexpected fallout from this translation. The
best-practices doc [1] suggests always balancing the rules for this
reason, i.e. use html[dir="ltr"] for the LTR version of the rule as
well. Note, that doesn't make the specificity problem go away
entirely, as another .foo rule will now be overriden by this rule. But
at least these problems will now be evident in the LTR mode. In
practice we saw only a couple of places that needed further correction
to address this. For an automatic translation, perhaps its enough to
document this potential gotcha?
1)
https://wiki.mozilla.org/Gaia/CSS_Guidelines#Direction_.28RTL.2FLTR_and_Bidi.29
On Thu, Nov 19, 2015 at 6:34 PM, Fred Lin <[email protected]
<mailto:[email protected]>> wrote:
Hi,
With recent FxOS release, we use several new CSS syntax to deal
with left/right(LTR/RTL) issues. I feel it might be useful for
general web developers.
So I write a postcss (like Babel for CSS) plugin to translate
these syntax into current physical directions (left/right)
properties and values in build time.
For example, input syntax:
.foo {
text-align: start;
}
will be compiled to
.foo {
text-align:left;
}
html[dir="rtl"].foo {
text-align:right;
}
It enable web developer to use these syntax now.
And if we do the similar thing for other moz-only CSS syntax, we
are able to publish a 'preview' version of FxOS Building
Block/Components CSS styles for web developers.
[1]
https://gniithub.com/mozilla-b2g/gaia/blob/master/apps/settings/style/settings.css
[2] https://github.com/gasolin/postcss-bidirection
--
Fred
_______________________________________________
dev-fxos mailing list
[email protected] <mailto:[email protected]>
https://lists.mozilla.org/listinfo/dev-fxos
_______________________________________________
dev-fxos mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-fxos
_______________________________________________
dev-fxos mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-fxos
