Page MenuHomePhabricator

CSSMin should crop leading 0 from fractional values
Closed, DeclinedPublic


The leading 0 in fractional numeric values of CSS properties is optional and values like margin: .5rem; are globally supported by rendering engines.
Current CSS Coding Convention misses a clear guideline on how to write fractional numbers with leading 0. Therefore we're facing differences across project implementations, for example in

font-size: 0.8em;


font-size: .9em;

It is definitely micro-optimization, but there is a fairly good amount of those values available.

I'd suggest to include a cropping mechanism for the following fractional numeric values (mind the preceding whitespace/colon/comma!):

  • 0.7rem -> .7rem
  • :0.7rem -> :.7rem
  • -0.7rem -> -.7rem
  • ,0.7 -> ,.7

Code example before:

.mw-selector {
    color: rgba( 255,255,255,0.7 );
    margin: -0.7rem;
    padding:0.7rem 0.77rem;

and after:

.mw-selector{color:rgba(255,255,255,.7);margin:-.7rem;padding:.7rem .77rem;}

Event Timeline

Volker_E raised the priority of this task from to Lowest.
Volker_E updated the task description. (Show Details)
Volker_E added subscribers: Volker_E, Jdlrobson, Krinkle.

To do this reliably requires a context-aware parser. We should not attempt to do this with regexes.

Due to how ResourceLoader works (see RL/F), it is vital that minification is highly performant and acceptable for large amounts of content within GET request.

It'll be tough to re-implement CSSMin in an equally or almost-as-performant way through building a tree, optimising, and re-serialising.

Also note that, while this is only a minor obfuscation, I would strongly recommend we invest in Source Maps (T47514) before we depart from minification without obfuscation as otherwise this makes debugging harder.

Krinkle renamed this task from CSSMin.php should crop `0` CSS property fractional numeric values with leading `0`. to CSSMin should crop leading 0 from fractional values.Sep 2 2015, 8:11 PM
Krinkle moved this task from Inbox to Backlog on the MediaWiki-ResourceLoader board.

To do this reliably requires a context-aware parser. We should not attempt to do this with regexes.

Hmm… why? The only problem I can think of is strings in CSS, but we already handle them incorrectly (T37492) and this would probably be less of an issue than that.

@Krinkle +1 for source maps support first!
We should also be 100% sure if inline SVGs might in some edge cases contain the mentioned strings at the wrong places.

Declining as with T37493. Minimal gain, increased risk. If we have source maps (T47514), and a less fragile but performant way of minification (T37492), we could reconsider it at that time, but closing for now.

@Krinkle Both your if's have become true. :)

@Krinkle Both your if's have become true. :)

I don't think they have. The way we minify CSS has not changed (T37492 was closed as declined, not resolved), and source maps were implemented for JS, not CSS.