0

For example, a selector like

. t { margin: 0 0.5em 1em-0.2em; }

is compressed to

.t{margin:0 .5em 1em -0.2em}

Perhaps this is an old bug in the YUI Compressor.

John Conde
  • 217,595
  • 99
  • 455
  • 496
user1162152
  • 1
  • Possibly, they just didn't think of it? I suggest asking Yahoo. Contact and bug reporting information is available at the bottom of http://developer.yahoo.com/yui/compressor/ … Otherwise, you need to reword your question to be something that isn't aimed at discussion. – derobert Jan 21 '12 at 10:59

1 Answers1

0

The zero is needed to identify the value as a number. The CSS tokenizer requires this:

num [0-9]+|[0-9]*"."[0-9]+

Otherwise it would interpret the identifier as a dimension:

ident -?{nmstart}{nmchar}*

Due to the fact that the 1em dimension can have the minus sign - as part of its identifier:

CSS Syntax ident Railroad Diagram CSS Syntax number and dimension Railroad Diagram

It can be interpreted as:

1em- 0.2em

or

1em -0.2em

References

Paul Sweatte
  • 24,148
  • 7
  • 127
  • 265
  • I'm not sure what you quoted supports your conclusion at all. To me, the opposite is true, and that regex says _A number is a set of 1 or more digits between 0 and 9 inclusive, OR 0 or more of said digits followed by a decimal point followed by 1 or more of said digits._ Removing the leading zero appears to be a fairly widely accepted idiom and, presumably, not to trip up any mainstream parsers: http://hey.georgie.nu/leadingzero/ I also don't think whether it could resemble an identifier is significant, as the parser would not be looking for an identifier in this context so it shouldn't matter – underscore_d May 27 '17 at 13:11
  • Yeah, this user found this and other quotes from the spec: https://stackoverflow.com/a/42863815/2757035 _When written literally, a number is either an integer, **or zero or more decimal digits followed by a dot (.) followed by one or more decimal digits** and optionally an exponent_. This and another section discuss how to combine the sign and the numeric value, and it does not mention any special-cased requirement for the leading 0 if the sign is -ve. So I think this is wrong, and again, whether it matches a pattern for identifiers is not relevant, as the parser need not check for those here. – underscore_d May 27 '17 at 13:22
  • The edit might explain why `yui-compressor` adds a space between the two dimensions, although if identifiers can contain trailing `-` then technically `yui-compressor` is silently altering the potential meaning of the input code. Either way, I don't see how this explains why it leaves the leading `0` before the decimal point in the value. – underscore_d May 28 '17 at 11:02
  • @underscore_d https://github.com/yui/yuicompressor/blob/master/src/com/yahoo/platform/yui/compressor/CssCompressor.java#L368 – Paul Sweatte May 29 '17 at 04:38
  • I'm not sure what it achieves to link me to the code that doesn't strip the 0 in that case, since the subject of this thread is that we _know_ it doesn't but are questioning whether it _should_, and my entire point is that by my reading, it _could_ strip the 0. – underscore_d May 29 '17 at 09:18
  • @underscore_d It could if and only if `strip the 0` has a defined relationship to `adds a space between the two dimensions`. The spec says `The only requirement for serialization is that it must "round-trip" with parsing, that is, parsing the stylesheet must produce the same data structures as parsing, serializing, and parsing again, except for consecutive s, which may be collapsed into a single token.` – Paul Sweatte May 29 '17 at 11:09
  • Put another way: `sassc`, compiled directly from git master, _does_ strip the leading 0 in negative numbers when using `--style=compressed` - thus merrilly outputting e.g. `-.25em`. So, which is more plausible: that such a widely used CSS preprocessor is producing code that violates the spec, or that the spec does allow such numbers and one Stack Overflow user is interpreting the spec wrongly? – underscore_d Jun 19 '17 at 15:09
  • @underscore_d `producing code that violates the spec`? [One Stack Overflow user](https://stackoverflow.com/questions/25925189/)? – Paul Sweatte Jun 19 '17 at 15:31
  • I don't see how the linked question conflicts at all with what I've said so far. Nor do I see, still, how there is ambiguity where you claim. By my current understanding (with the caveat that I find the spec hard to read), the originally posted code is ambiguous because of the lack of a space between the `em` unit and the following quantity. Adding a space there removes that ambiguity, then we have an optional sign followed by an optional zero followed by the decimal component, which is A-OK. I can't yer clearly see why `yui-compressor` insists on stuffing a leading 0 back in negative numbers. – underscore_d Jun 19 '17 at 16:20
  • @underscore_d There are [splitting rules](https://lists.w3.org/Archives/Public/www-style/2008Mar/0254.html) which define the ambiguity, but no indication on any formal implementation or specification. – Paul Sweatte Jun 19 '17 at 17:45