andamira / medula

Starter Theme & Plugin for WordPress
MIT License
8 stars 0 forks source link

The most appropriate default CSS unit #37

Open joseluis opened 9 years ago

joseluis commented 9 years ago

Right now Medula is using rems almost for everything, except for media queries. It was a decision at some point, in order to avoid using pixels, but not necesarily is the best one possible. I'd like to discuss some alternatives.

This is a list of resources I've found:

  1. R.I.P. REM, Viva CSS Reference Pixel! (pro pixels)
  2. You should understand CSS units Pro ems & against pixels
  3. Use the em and the rem for the right use cases
  4. A Case Study On Art-Directed Responsive Web Typography
  5. Why I dislike the rem unit
  6. Font Size Idea: px at the Root, rem for Components, em for Text Elements

I find myself leaning on the side of using ems a little bit more, and leave rems in the cases where inflexibility is preferred. I like the simplicity of them being equivalent in size and scale, with the only difference being that ems listen to their parents, and rems don't.

About the readability concerns, sass gives us the possibility of be more clear using expressions like font-size: 21/16*1em; to avoid numbers like '1.3125em'

YemSalat commented 9 years ago

As I said before - I don't see any reason to use em/rem because SASS is already successfully solving the problem of having a 'standard size unit'

So in your example, why not instead of this: font-size: 21/16*1em;

write this: font-size: $standard-font-size * X

In the second case the behavior is more explicit, and does not limit you to any particular CSS units.

I also don't see much benefit in using em for anything to be honest, what in your opinion are the benefits? (rem is a bit different because it indeed is not dependent on the parent style)

I usually use % for all widths/heights and px for almost everything else. Plus in some cases other layout methods like flexbox are preferable and they don't rely on any particular units. I experimented with vw / vh before but they are too buggy at the moment (I even submitted an issue to Chromium: https://code.google.com/p/chromium/issues/detail?id=536793 which turned out to be quite a long-standing one)

YemSalat commented 9 years ago

Your first link is actually talking about the same points that I do and comes to the same conclusion: https://mindtheshift.wordpress.com/2015/04/02/r-i-p-rem-viva-css-reference-pixel/

joseluis commented 9 years ago

The rest of the links say defend other points of view. And not many commenters seems completely satisfied with their current solution. it is a controversial matter. For me too.

I think $standard-font-size is too long. Is it really already in Sass? Or do you mean defining it (e.g. $standar-font-size = 0.625em)?. I can see the point in the utility of having a standard-font-size but I'd had to call it $ssize or something like that. Because writing 1em, (or even 2.75em) is very short and to the point. I'd prefer more than one good reason to use something which is longer, and provide less information.

In this case I'd prefer to make a choice, a good one, than to be 100% neutral, because I I'd like to avoid passing annoying mental weight to the user when I can provide a smart choice.

I see the appeal on em unit precisely in the fact that it IS dependand on the parent. It complements rem, and it forces you to be aware of the context in which it is used, which at our job I think that's a pretty good idea. And sometimes you want to create trees of styles, that can be applied to modular elements that may be commonly placed in different containers, so they automaticaly adapt to the size, simply but graciously. I intend to make a living example of that on the styling of the forms at least. They could be much better and simpler. But there are some other issues that comes first, like this one.

The key is complement. I don't see it makes sense to use only ems or only rems. But I do see the appeal on using both em, rem, and %. There is nothing more needed really for normal usage. The rest is just a matter of choosing when to use em and where use rem, as a default. (e.g. I prefer to use em in media queries. What about you?).

And also have one or two examples with more exotic and subtle units. But I'd use them sparingly. e.g: Using vw / vh in a particular aspect of the search form. I'd like Médula to be didactic and easy to read, as long as it doesn't mess up the simplicity nor the handiness.

And we could use flexbox in a module and check the modernizr class for it or just let it degrade gracefully.

P.S. Google sometimes doesn't seem to care how long it takes to solve some bugs. Look at this bug that I also discovered when starting working on Médula, and that was one of the reasons that convinced me of not changing the font-size to 62.5% in the root by default, speaking about font-sizes.

YemSalat commented 9 years ago

Regarding $standar-font-size - yes, sorry, I do mean just declaring it as a variable. The name can be different, I just used this one as an example.

This way the user can choose any css unit they like, for example: $size-unit: 16px; And then do things like: font-size: $size-unit * 120%; or padding-left: $size-unit * 2;

Or if they want to use _em_s - they can just set $size-unit: 1em and then set the value on the root element to whatever they need.

Regarding which units I usually use in my code - as I said before I prefer using percentages % for width / height. And pixels for almost everything else. _rem_s I would use for font-sizes, typography margins, and everything related to text and fonts. I would not use _em_s at all, apart from the situations where I actually need the font-size to depend on the parent. I don't use _em_s for width/height/margins.

Here is a quick example of how I would utilize various CSS units: http://codepen.io/yemsalat/pen/GpBRVN/right/?editors=110#0

I kept it in CSS to make the concept more clear and made it 'mobile-first'. In the example above I use _rems to set content font sizes and margins, and %_ for the widths/heights. If you resize the right panel in your browser - you will see that it has 3 media query breakpoints. This way I get responsive layout almost 'for free' and I don't have to adjust much.

Do you have any examples of how you would usually do something similar?

jan-dh commented 9 years ago

I feel that media queries are the only place where it's actually good to use pixels. For the rest I would use percentages for grids, width, height,...rem for everything typography-related (incl. paddings etc.) There is basically no good reason to include em.

That being said, I'm not sure if you need to make that decision for the developer in the starter theme. I would base the homepage on the html5 - boilerplate and let the developer decide for himself how he would like to style his theme. Some people will use bootstrap with it and then you really just use bootstrap for most of the things, other times you will start from scratch. Some people might choose to go for Suzy or something else.

YemSalat commented 9 years ago

I agree, the theme should not be deciding for the developer which CSS units they use, as everybody's approach is different. When using a starting theme - those default styles are the first thing most people remove.

joseluis commented 9 years ago

I think a starter theme must do exactly that, make decisions in advance and provide choices only when it's worth it.

I don't understand the fears about em, as I said, it provides something no other unit does, which makes it very useful in certain places. And I like the elegance of having 3 basic units to do all the basic styling: A relative to the parent unit, an absolute unit (or relative to the root) and a percentage unit.

  1. Using both pixels and rems by default is an absolute no. That's redundant and confusing.
  2. Apparently most people are comfortable using pixels, it is the most intuitive for beginners too. And it is the most common option for borders, media queries, and for thinking about the size of images.
  3. I like the em + rem combination because they use the same scale.
  4. Using variables for the default units is an option, but I'm not sold in this idea yet. I see it is as an unneeded crutch.
  5. It may be handy to define a relative-pixel variable $rpx: 1em/$base-font-size; (or even a function rpx()) as an alternative to em for homogeneous pixel-minded thinking.

So as I see it the choice is between:

Between rem and pixel, I don't think the difference of being relative to the root is so important. But if it turns out it can be important for certain projects, I could add an optional settings to gulp to convert all pixel values to rems, in the same way there is an optional setting right now to create a rem pixel fallback which may no longer be needed.

P.S. I created a new issue for the grid options in #40

jan-dh commented 9 years ago

I really see no reason to include em as a unit measure. Even bootstrap 4 has removed all of the em's and switched them out for rem's. Even in their grid system. Could you provide an example where you feel you need to use em?.

I would go full-out for the rem + % and remove the emfrom it.

As for the starter theme - decision making. I feel that a framework (grid system, javascript-framework,...) should make decisions for a user to make it easy for him to follow a certain flow. A starter theme however should provide a good stable starting position that can be easily adapted by the developer to make it his own. If you are going to make a generator and include all these options (different grid-frameworks, different units for styling, ...) that makes it bloated and not easy to maintain. If you leave those choises to the developer they only have to set them up once and save that starter theme and they are good to go for all their projects.

YemSalat commented 9 years ago

I am also for the rem + % approach. @joseluis maybe you could show us how you are planning to use ems (basically just go ahead and implement it with ems) and then we can decide whether its justifiable?

As for descisions and the whole starter theme thing - it is probably OK to have some default styles for things like sidebars, navigation, etc. Just so when the theme is installed it has some basic page structure and follows wordpress templates (like showing latest posts, working search results, etc) and doesn't just load a bunch of unstyled tags on the page.

But I would really like to see a starter theme which is: a) Super simple, does not have 1000+ lines of CSS already in it. b) Has no 'theme' (if that makes sense) What I mean by this is that I don't want to see any colours, round corners, borders, shadows, fancy fonts, etc.

When I start a new project - I want to work on a blank canvas which takes care of all the boring stuff and leaves all styling to myself.

YemSalat commented 9 years ago

Also, wanted to add that I prefer working with px for typography when converting PSD and InDesign mockups to html, since all the measures are in pixels there.

To be honest I don't know why pixels are getting all the bad rep, they are basically an absolute size unit which is not dependent on the actual pixel density (my iPhone 5 reports 320px width, however the actual pixel width of the screen is 640px).

Granted with rem you can change all the measures at once, but how often do you need to do that? (Its kind of like 'zooming' the page) With responsive layouts I still find myself having to set all the font sizes / margins with rem the same way as I would with pixels. Since sass has been around using pixels became even easier.

Am I missing something?

PS This is all of course only with regards to typography (font sizes, text margins, etc.)

joseluis commented 9 years ago

I like your suggestion. Personally I also feel more comfortable using rems. So let's say for now that we're going with rem + % and em sparingly, mainly to show how ems can be used for adapting the size of some modules to its parent, building on the ideas from css-tricks.com/rems-ems.

I like that this is a very simple solution that doesn't require any extras, variables, mixins, anything else.

I also share the sentiment of aiming towards a blank canvas that is very clean, very emtpy, with minimal styling. Which is there mainly to provide 3 things:

  1. Sensible defaults
  2. Handy choices
  3. Didactic / cheatsheet-like info (Docblock comments and commented out selectors)
joseluis commented 9 years ago

I should add that the developers of course will use whatever they want for their custom styling. All we are discussing is for the minimal default styling.

I agree with the sentiment expressed by this user:

Although it’s true that the CSS pixel is not a physical pixel and thus not as bad for responsive design as generally thought, you cannot simply ignore the “base text size” that users might want to assign in the browser settings. Yes, it’s not as popular as its “zoom page” counterpart, but those people who rely on changing the base text size do need it for real!

And it's true we could use a gulp filter to convert all pixels to rems but that adds another layer of complication that maybe is not needed.

And lastly, when I try to use px values I realise I don't like to work with big numbers, and that I prefer to work with the smaller numbers that rem provides. It's much easier to compare in your head using smaller numbers, even if they have decimals, or are combined in fractions.

The only thing that worries me a little bit is compatibility. http://caniuse.com/#feat=rem Fortunately the old chrome bug that affected the rendering of borders when specified in rem it seems to have been fixed yesterday. Also, there is also the remPixelFallback option in gulp (for now).

YemSalat commented 9 years ago

Although it’s true that the CSS pixel is not a physical pixel and thus not as bad for responsive design as generally thought, you cannot simply ignore the “base text size” that users might want to assign in the browser settings. Yes, it’s not as popular as its “zoom page” counterpart, but those people who rely on changing the base text size do need it for real!

To be honest I disagree completely with this statement. First of all, in order to change the default size (at least in Chrome) you have to go to advanced settings, many people don't even know those settings exist. I also just tried changing my font size settings and turns out it does not work properly. Google Search - works only on some text resulting in page looking ugly and not improving accessibility at all, Facebook and GitHub - no effect at all, Wikipedia - increases font size but page goes outside the viewport.

I think browsers keep it mostly for historical reasons, it is rather obvious in my opinion that zooming the page is the preferred method of increasing font size. Plus, if you use em to style width and height of your elements - the page will go outside the viewport when zoomed and users will have to scroll horizontally in order to read it.

Regarding pixels - I honestly don't see how 15px and 25px Are harder to understand than 0.9375rem and 1.5625rem

Keep in mind that we are talking about typography, so the pixel values rarely go above 50-100px. It is also worth noting that when the page is rendered everything is converted to pixels anyway, so I often see use of other units as more of a 'fashion' thing rather then something that solves a particular problem (I am not denying that there are use cases where rem or some other units would be preferred)

Having said all that, I am still not against using rem for basic theme styling. Just wanted to make a case for the good old pixel :)

joseluis commented 9 years ago

I think browsers keep it mostly for historical reasons

I also just tried changing my font size settings and turns out it does not work properly

if you use em to style width and height of your elements - the page will go outside the viewport when zoomed

We would benefit for some official info, test or statistics on this regard. But what I like is that by using rems I don't have to care about this issue. If changing the root font-size is useful for somebody, or some device (ebook?) or some use-case, it will continue to do so.

Regarding pixels - I honestly don't see how 15px and 25px Are harder to understand than 0.9375rem and 1.5625rem

That's a biased example. I don't see how the relationship between 1.4rem and 1.6rem is harder to understand than the relationship between 22.5px and 25.6px.

Keep in mind that we are talking about typography

I'm also thinking about media-queries and grids, and every element, really. But typography is arguably the cohesive element that holds a website together. I want to treat it with special attention.

It is also worth noting that when the page is rendered everything is converted to pixels anyway, so I often see use of other units as more of a 'fashion' thing rather then something that solves a particular problem

That may be so, but the real utility to me is the mental simplicity of the small numbers. And I also think it's important to have a unique voice in this regard, that is coherent with the philosophy of the project.

Just wanted to make a case for the good old pixel

I appretiate it. I recognize pixels has its advantages. I'm still tempted on using pixels for borders and text shadows, etc... That's one of the grey areas I'm still debating on.

As I said at the beginning this is a controversial subject, and everyone seem to make good points. At the end it has to be a decision that is never going to be perfect. I'll be happy with perfect enough.

YemSalat commented 9 years ago

That's a biased example. I don't see how the relationship between 1.4rem and 1.6rem is harder to understand than the relationship between 22.5px and 25.6px.

To be honest, I think your example is even more biased because I have never seen anyone use fractional pixels. Plus, in most cases browsers will round them anyway, checkout this example: http://codepen.io/yemsalat/pen/LpJYpr/right/?editors=110

scr1

scr2

Anyways, I'm fine with rems :)

joseluis commented 9 years ago

To be honest, I think your example is even more biased

Haha, yes, I was trying to overcompensate. Forget about the fractional pixels and the example still stands.

I'm glad we've been able to reach some kind of consensus. I'll start working on this issue soon.