Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.Problem/Motivation
We don't have anything in our CSS standards about which units to use and when, apart from media queries
We have a really inconsistent implementation just in Seven alone, it would be nice to have some guidance for contributors.
Proposed resolution
Use rem units preceded by px units for a safe fallback, unless it creates an undesired effect.
Remaining tasks
Discuss
Agree
Add to the standards document
User interface changes
None
API changes
None
Comments
Comment #1
sarahjean CreditAttribution: sarahjean commentedAgree. Seems like rems would be a good choice, although ems would also be fine.
Comment #2
smira CreditAttribution: smira commentedI would suggest rems with a px fallback (or not, since I believe we're not supporting IE8, correct?).
Comment #3
chippper CreditAttribution: chippper commentedAs we're not supporting IE8, especially on the admin side, I would suggest standardizing on rem's. It has excellent browser support -http://caniuse.com/#feat=rem - and is the best of both worlds. You get the benefits of relative font size units (scales nicely), but the numbers don't make your head implode. More info here: http://snook.ca/archives/html_and_css/font-size-with-rem
Comment #4
nod_Comment #5
karolus CreditAttribution: karolus commentedAgree. rems are a good choice, ems for fallback. With more users moving to mobile, pixels are becoming a hassle to work with, especially with retina and other high-resolution formats.
Comment #6
LewisNymanhmm, looks like the current version of Opera mini still doesn't support rem. In that case I would prefer a pixel declaration before the rem. It's useful as documentation to understand the size and also as a fallback. Pixels aren't much harder to work with on different resolution displays because a CSS pixel is different to the device pixel A pixel identity crisis
Another point, this is clear we should use this technique for font sizes but should we use it for everything else? Padding? Margins?
Comment #7
sarahjean CreditAttribution: sarahjean commentedI think it makes sense to use it for padding and margin also, then everything continues to resize relatively. One of the big benefits to ems/rems in my opinion. The pixel fallback makes sense if we go with rem.
Comment #8
LewisNymanBut when you increase the font size, do you want to increase horizontal padding? You're reducing availiable space for text as the text size is gettign bigger, that's going to result in sub-optimal line lengths?
rem > em in my opinion.
Comment #9
rootworkWell damn Opera Mini, that really sucks that they don't support rems yet. Weird.
Given that, I'd support rems with pixel fallbacks.
Relative units should definitely be used for padding/margins between blocks of text -- paragraphs and menu items, for instance. The margins are logically related to the size of the text and should vary based on the size of the text.
Padding/margins around boxes (regions, entities, etc.) are trickier because of the issue you raised, Lewis, but I think it still makes sense to use relative units for those. It's true that if you dramatically increase or decrease text size, line lengths are going to get comically too short or too long. But most text resizing is done at smaller intervals, and the relationship between an element's padding/margin and its text size will still be strong. (And, of course, if the window itself is being resized, we'll have media queries to just set different padding/margins.)
So I'd go with rems + pixels for everything.
Comment #10
LewisNymanI would prefer a simple rule like that that's easy to understand instead of having exceptions. Who wants to update the documentation?
Comment #11
LewisNymanSorry wait, if we use rems and pixels for everything, that's going to require a lot more code to be added for everywhere use margin/padding in core with equivalents for RTL?
Comment #12
LewisNymanSorry I totally derailed this issue with indecision. Yes let's do px+rem for everything. I think we can make one big patch that changes all the units in core. I've added guidance to the CSS standards and updated the code examples: https://www.drupal.org/node/1887862
Note the caveat here, there may be some properties that look strange when scaled up, like borders or box shadows, so ultimately it's a judgment call.
Comment #13
bryanbraun CreditAttribution: bryanbraun commentedSo since we don't support IE8, is the px fallback just for Opera mini?
The reason I ask is that putting in place a px fallback for every instance of rems adds some CSS bloat... something we wouldn't want to introduce unless there is a good reason. To be explicit, this is my understanding of how the changes affect a rule in Bartik:
Before:
After:
Looking at this Opera Mini release post, it looks like Opera mini support for REMS is in the works, and once it's added all users will immediately be "upgraded" (since Opera mini uses server-side rendering). How likely is it that they support REMs by the time Drupal 8 is released? I don't know.
I support the current consensus (rem with px as fallbacks). It's going to be some work to add in all the fallbacks and (inevitably) pull them out again, but oh well.
(also updating the issue summary)
Comment #14
LewisNymanLet's sort this out, shall we specify rems for font size properties only? That makes it a lot easier to implement and to be honest that's the most important property. Happy to go REM only in this situation.
Comment #15
axe312 CreditAttribution: axe312 commentedAs u can see on caniuse.com the REM issue is now fixed on Opera Mobile. With the server side rendering, all clients should be automatically support it now.
If we decide to move only some values to REM, I'd love to see media queries also using rem instead of pixel/em.
We should also keep the known issues in mind, in my opinion especially the line-height issue in IE and the borders in chrome. The problems with some (old?) Android phones should not bother us, for every day D8 takes longer, the usage of older mobile browsers should drop :)
Comment #16
LewisNymanComment #17
LewisNymanThis tweet captures what I was trying to say and failing. We can't just choose one unit and enforce it. It's about picking the right unit for the right job.
Comment #31
smustgrave CreditAttribution: smustgrave at Mobomo commentedBelieve with the switch to claro and olivero a much more standard approach has been taken.
Could this be close.d