I’ve been a long time user of Compass and really like it. As I have helped set up many other developers, designers, and other environments (e.g. CI), the ruby dependencies became harder and harder to manage. This is a very interesting proposal to go all node which is easier to set up (for me) and faster overall (a growing complaint from team members).
Generate a useful summary of the CSS on your (or any) site including palette, fonts, specificity and more with CSS Stats
em CSS unit is one of the tougher to master because it is relative in nature. You have to know or figure out something else before you know what the value you’re declaring actually means. When you don’t calculate what your declaration equates to when the browser interprets it, you can come across some goofy behavior.
That doesn’t look right. There’s this huge heading crammed in there that doesn’t make any sense.
Why is that?
Chrome Canary has a bug where it is not respecting that
text-indent property value of
Why is it a bug?
According to the CSS3 spec, the
text-indent property takes a length or percentage as a value. A length is a dimension. A dimension is a number immediately followed by a unit identifier 1. Because
text-indent does not restrict the number value to some range (as far as I can tell), the UAs (User Agent) “must support at least up to ±230; unsupported values must be clamped to the closest supported value.” 2
em is a length type distance unit that is computed based on the value of the
font-size property of the element. The
h1 in this case has an inherited
40px which means
-999999em equates to
To be fair, -39999960 is well within -230 (-1073741824). To put it in perspective, 39999960px is wide enough to span well over 15,000 monitors whose resolution is 2560 x 1440 pixels. This text replacement technique only needs to clear one monitor who might have a resolution that big.
Maybe this isn’t a bug
Perhaps the Chrome dev team wants developers to take a pragmatic approach to declaring property values. A
text-indent that spans 15,000 27″ monitors doesn’t make any sense in any scenario. Since the
h1 is inheriting a
-99em would suffice to move the text 3,960 pixels.
If you don’t want to think about calculating what an
em will compute to, just use this newer technique which is based on 100%.
The beta has new themes and demos, support for new events, including swipe detection and page transitions, and new options for fullscreen mode, including icon and startup screen. jQTouch is written in HTML5, CSS3, and jQuery. Check out the demo video to see it in action!