This reverts most of commit 2d842f1425,
leaving only the test added in it, and reimplements the same
functionality better.
Instead of stripping /*@noflip*/ annotations in CSSJanus, which is
incompatible with other implementations that preserve it, extend
CSSMin to allow other CSS comments to be present before the
rule-global @embed annotation. (This required making the regex logic
in it even worse than it was, but it's actually slightly less terrible
than I expected it would be. Good thing we have tests!)
Bug: 69698
Change-Id: I58603ef64f7d7cdc6461b34721a4d6b15f15ad79
To do it, just remove /*@noflip*/ annotations in CSSJanus after
we're done processing. They are not needed anymore and some obscure
interactions with CSSMin logic for preserving comments caused
`/*@noflip*/ /*@embed*/ background-image: url(…)` not to work
correctly (it would not be embedded).
This also requires us to always do CSSJanus processing, even when we
don't need flipping, to consistently handle the annotations.
I'm not entirely sure if this is worth it, but I still greatly prefer
doing it to documenting this stupid limitation. :)
Bug: 69698
Change-Id: I311b12b08b2dff9d45efb584db08cf4a11318f59
Was incorrectly assuming values between -1 and 1 were 0
Fixes an issue with mw-ui-input class in RTL mode which
makes use of box shadow.
Change-Id: I13e52467721bc2534e0a7c5245e3380ac43736ef
Recognize selectors of the forms [attr=val], [attr*=val], [attr~=val]
and [attr^=val], optionally with single-quoted values.
Because these selectors previously weren't recognized, trying to
apply /* @noflip */ to one of them would be recognized as a
single-property noflip rather than a rule-wide noflip, and so only
the first property in the rule would be noflipped.
The (simplified) input that triggered this bug was:
/* @noflip */ figure[typeof*='mw:Image'].mw-halign-left { clear: left; float: left; }
which became { clear: left; float: right; } when run through CSSJanus.
See also I4cddce80397d8 which is a workaround for this issue
Bug: 50910
Change-Id: If424a1df26bb7a5a18cee4b0318b029392528fc0
We just need to negate the horizontal offset value in both of them.
This only supports *a single shadow* per element; multiple shadows
are not supported (only the first will be flipped).
Second attempt. First, reverted one: I14822955.
Bug: 45677
Change-Id: I97ee7431e1a5acb35d594076a88a0f9acf290402
The values are not "top right bottom left" here, but
"top-left top-right bottom-right bottom-left".
Bug: 49074
Change-Id: I22bc777b59e667aeb36727fdc8e41e8681979128
The 'color' rule, and by extension 'four_notation_color' too,
only understood #rrggbb and named colors. Extend it to match
rgb[a](...) and hsl[a](...) syntaxes as well.
This makes usage of rgb(a)/hsl(a) syntax in declarations like
'border-color: a b c d;' be interpreted and flipped correctly.
Change-Id: I218a9aa55a86b3d955b92375c1a209fdde312138
Don't mangle 5+ consecutive numeric values in the
'four_notation_quantity' and 'four_notation_color' rules. This
prevents box-shadow rules from being utterly broken in RTL (but still
doesn't flip them properly).
Bug: 45677
Change-Id: I16cb9e171a79c6f299b40fa02908b0c045e3c474
We just need to negate the horizontal offset value in both of them.
This only supports *a single shadow* per element; multiple shadows
are not supported (only the first will be flipped).
Also, to make it possible:
* don't mangle 5+ consecutive numeric values in the
'four_notation_quantity' rule
* support rgb(a) and hsl(a) colors in the 'color' rule
Change-Id: I148229558e1b9a0516e413ffe86007235c3c3ef8
