Closed ry5n closed 11 years ago
Its definitely telling that we were both working on this at the same time. :-)
I think rem is a great unit for developer authoring, but I don't see a need to change the output unit to rem. I would support any changes needed to make it simple for authors to pass rem-based values to the compass mixins but when using absolute units -- let's keep the px output. Please let me know if I'm missing something.
Also, seems like this could be done as non-breaking addition to stable. If not, it'll need to go onto master for 0.13.
@chriseppstein I'm not 100% sure what you're suggesting and I'd like to understand. Are you suggesting we allow rem inputs (with rem outputs) but no pixel fallbacks? I think that that's already supported (except for +establish-baseline operating on the body rather than root).
Maybe I can restate the rationale for this better by laying bare my thought process:
***$64,000 question. cc @JohnAlbin
I'm saying we don't need pixel fallbacks. As long as the author tells us that 1rem = 16px (or whatever), then compass can still output pixels, and the author can pass rem-based numbers to all the compass mixins. As far I can tell, rem is a authoring convenience and has no other semantic differences over using pixels than the mental model.
As far I can tell, rem is a authoring convenience and has no other semantic differences over using pixels than the mental model.
That is incorrect in the real world. Otherwise em
s would just be an “author convenience”. By only using ems or rems or percentages for font-size in our stylesheets, we are allowing the user to change the default font size. The UAs give a default default font size of 16px; they also allow user's to set the default font-size for the UA.
This is what @ericam was pointing out in #766. Currently the vertical-rhythm outputs a px value on the body tag (except for IE6). That overrides any default font size settings the user has specified in the UA. Compass users should have the option to use relative sizes (even in the establish-baseline() output) so that we can respect the UA users' choices.
So if we give the authors the option to output in ems or rems (and we should), then when we output rem we have to have a px backup for browsers that don't support rem.
compass can still output pixels, and the author can pass rem-based numbers
Actually, I think most authors would want the opposite. Input numbers in px
and have the Compass mixin calculate the rem
values, while still outputing px as a back-up for non-rem-capable browsers. That's what I want.
Our tools (Photoshop, font faces, etc.) all describe font sizes in pt
s or px
s. If we were forced to enter font sizes in rem
s then we'd be doing the calculation in our head. (Or using Sass math to calculate it. Isn't that what a mixin is for?)
I don't know of any tools that describe fonts in terms of percentages of a base font.
So, to reiterate…
That is incorrect in the real world.
Let's avoid the loaded language. We're all operating in the real world here :)
they also allow user's to set the default font-size for the UA.
Excellent. This was the point I was missing. Thank you for clarifying it.
Actually, I think most authors would want the opposite.
Maybe so, but I vastly prefer to author in em
s because the font size (rhythm) of the page is such an natural unit of measure. If something doesn't look right on a finished design, my designer usually says "can you add a half-lines worth of padding there?" Not "please add 8px there". But I hate how em
s are relative to their context, so I end up translating that to px
. So I guess both input modes are important to support.
we need a flag to have font size output in relative or fixed units; since we are currently only outputting fixed units in establish-baseline(), I'd suggest that flag be a new parameter.
This is not correct. We have a flag for this ($relative-font-sizing
) and we have the $base-line-height
which could be a value set in rem
s. So I don't think we need any new public facing flags... we should be able to discerns the right behavior from that.
And we need a flag to specify whether we want to output px backup when using rem output.
If the author has specified rem
as the output unit, I don't see any harm in setting the px
fallback. Users expect compass to do the "right thing" with respect to legacy browser support.
That is incorrect in the real world. Let's avoid the loaded language. We're all operating in the real world here :)
Sorry! What I meant was to compare what the CSS spec says versus user experience in browser realities. But I definitely did not phrase that correctly. I apologize.
my designer usually says "can you add a half-lines worth of padding there?"
Really? That'd be nice! I used to work with a designer who wanted me to move something over "a pixel to the left". x-p
So I don't think we need any new public facing flags... we should be able to discerns the right behavior from that.
You could be right, but I'm not sure. Let's see what @ry5n and I come up with first. :-) @ry5n, I'm going to be at the Drupalcon Denver conference next week, so it will probably be after that before I get a chance to work with you on this.
If the author has specified rem as the output unit, I don't see any harm in setting the px fallback. Users expect compass to do the "right thing" with respect to legacy browser support.
Good point!
@JohnAlbin @chriseppstein Sounds like we're agreed on the basics then – improve rem support and allow for outputting pixel fallbacks when using rems as the internal font unit. John, I think that will be fine, I may do a bit of work in the meantime but let's check in when you're back. Have a great time in Denver. :)
@JohnAlbin I now have a working dev environment for Compass, and just pushed a vastly improved rem mixin that should prove useful. I’m ready to move ahead; how about you?
@JohnAlbin, @chriseppstein, and @ry5n: I've addressed one of the issues mentioned above in #844 - using $relative-font-sizing
to set the font as %
rather than px
on the html
tag. If there are no objections to that, I'll go ahead and merge it into master.
That's a blocker for the next version of Susy, so I'd like to take care of it asap.
Thanks Eric. I notice you'd fixe this and skimmed the solution. Looked good as I recall. I'm hoping to update that issue wih my progress this weekend.
Ryan
On 2012-04-13, at 4:34 PM, Eric Meyerreply@reply.github.com wrote:
@JohnAlbin, @chriseppstein, and @ry5n: I've addressed one of the issues mentioned above in #844 - using
$relative-font-sizing
to set the font as%
rather thanpx
on thehtml
tag. If there are no objections to that, I'll go ahead and merge it into master.That's a blocker for the next version of Susy, so I'd like to take care of it asap.
Reply to this email directly or view it on GitHub: https://github.com/chriseppstein/compass/issues/775#issuecomment-5127011
will it be possible to use REM for type unit and ems for leading?
@pdewouters The way the VR partial works is it will output rhythm values based on a couple of configurable variables, so you can (I believe) set your $base-font-size
and $base-line-height
in ems (or rem, px, %) and by default the mixins will output ems. But you can also change the $font-unit variable
which determines the output unit.
Not sure if that answers your question. Do you have a particular use case in mind?
Bumping myself. Been working on this and almost have something for review, but not confident it’s the right approach. @JohnAlbin will you have a bit of time in the next week to review some code?
bump
This conversation isn't dead, it just moved. See Pull Request #896 for discussion
Currently the vertical-rhythm module supports setting the unit of font-size to rems, but doesn't provide pixel fallback declarations for older browsers and has some other issues. More complete support for rems, including pixel fallbacks, would be an awesome addition to this module. See #766. #771 is also relevant.
Additional rationale:
Considerations: