Live data from Hacker News

Relearn CSS layout

every-layout.dev

21–30 of 187 posts

Re: Relearn CSS layout

#21
post #16

The code examples are overengineered. For example, the code generator for stack uses rem units and CSS variables, while it could be written without them and have better cross browser support (and the code would be easier to read and maintain in long-term perspective). The author just wants to use modern CSS features without clear rationale for this. Rem units can cause issues in long term. For example, imagine if a s…

> There are cases when rem is useful and there are cases when it is not, but the author doesn't give a choice and doesn't explain it. and > I recommend using pixels for projects that are going to be maintained and developed in the long term. Directly after lambasting the author for failing to elaborate, perhaps you could go into more depth yourself?

A website that is maintained in a long term will be worked on by many people, and CSS will become quite large and complicated. So using the simple constructs like pixel units is better than using rems that create implicit dependence on main font size. This way there are less chances to break something in one place when editing code in other place.

The same is about CSS variables. An example with one variable might look nice. But what if your code has hundreds of variables? It would take more time to understand how they are related and how do I change the size of this button without breaking something on another page.

Re: Relearn CSS layout

#22

The code examples are overengineered. For example, the code generator for stack uses rem units and CSS variables, while it could be written without them and have better cross browser support (and the code would be easier to read and maintain in long-term perspective). The author just wants to use modern CSS features without clear rationale for this. Rem units can cause issues in long term. For example, imagine if a s…

This is plain FUD, sorry.

The rem unit is remarkably well supported, going back to IE9, Android 2 and iOS 4.

It has a specific meaning: it's relative to the root element, which usually means it's relative to the font size the user set as the default font size for the browser — 16px by default in most devices. It's not just a stuffy alias for the px unit, used by sneaky developers to make maintenance harder.

It has a semantic purpose, which makes it useful for maintainability: if your body text is 1rem, when a heading should be double the size of body text, writing it as 2rem makes the sizing relationship between these two values immediately recognizable.

https://caniuse.com/#search=rem

Re: Relearn CSS layout

#23
post #16

Earlier quoted context omitted.

> There are cases when rem is useful and there are cases when it is not, but the author doesn't give a choice and doesn't explain it. and > I recommend using pixels for projects that are going to be maintained and developed in the long term. Directly after lambasting the author for failing to elaborate, perhaps you could go into more depth yourself?

A website that is maintained in a long term will be worked on by many people, and CSS will become quite large and complicated. So using the simple constructs like pixel units is better than using rems that create implicit dependence on main font size. This way there are less chances to break something in one place when editing code in other place. The same is about CSS variables. An example with one variable might lo…

If you hard-code everything in pixels, you have the same implicit dependency as with rem. It's a design, after all! Things have to "fit together". You're not changing every element's font size to an individual value and on a whim.

But now you have to keep all those relevant "main font sizes" in your head and do constant divisions. rem units give you the ratio directly.

Re: Relearn CSS layout

#24
The knowledge contained in the articles is very good but I got the feeling that it was written for an audience that already undertands the problems being solved. The Stack for instance is written in a language that only really makes sense if you've spent a lot of time with CSS and contains some extraneous paragraphs. I only mention this as the problems and solutions being explored are very valuable to learn but I think it could be written simpler and more succinctly so that meaning isn't lost for new-comers.

I'd be happy to contribute if it was open to suggestions.

Re: Relearn CSS layout

#25
post #17

The code examples are overengineered. For example, the code generator for stack uses rem units and CSS variables, while it could be written without them and have better cross browser support (and the code would be easier to read and maintain in long-term perspective). The author just wants to use modern CSS features without clear rationale for this. Rem units can cause issues in long term. For example, imagine if a s…

On the topic of rems, when using them for layout, you'd use a body font size rather than the root element's font size to control the size of text in your page. At that point the root font size exists only as a scaling factor, decoupled from the base font size of content within the page, but allowing the user to control that scaling factor via their browser's global default font size preference. In fact, you could thi…

It is not as simple as just replacing pixels with rems. Do you test your markup with different root font sizes? Do you add special rules for cases when the font size is too small or too large? Unlikely. Then you better not pretend that you support scaling the fonts using browser settings.

Also, I think that changing font size in browser settings doesn't work on most sites, so people don't use it. For example, I use normal scaling (using Ctrl + +) on this site and it works good enough, and what's most important, it works everywhere. So there is no need to support changing root font size.

Re: Relearn CSS layout

#26
post #23

Earlier quoted context omitted.

A website that is maintained in a long term will be worked on by many people, and CSS will become quite large and complicated. So using the simple constructs like pixel units is better than using rems that create implicit dependence on main font size. This way there are less chances to break something in one place when editing code in other place. The same is about CSS variables. An example with one variable might lo…

If you hard-code everything in pixels, you have the same implicit dependency as with rem. It's a design, after all! Things have to "fit together". You're not changing every element's font size to an individual value and on a whim. But now you have to keep all those relevant "main font sizes" in your head and do constant divisions. rem units give you the ratio directly.

Yes, but a typical change request would be something like "make this menu font size larger", and in this case having menu independent from other parts of the page is better. Also, if you build a framework with variables, dependence on root font size, it would be complicated and most devs won't like to spend time learning it and thinking how to solve their task within it. Simple is better here.

Re: Relearn CSS layout

#27

Out of curiosity, why doesn't the stack layout use flexbox? It seems like flexbox is the perfect fit for such a layout.

Margins of flex child elements won't collapse automatically like regular elements. It can be solved but it would be unnecessarily complex for the simplicity of the layout.

Re: Relearn CSS layout

#28
post #16

Earlier quoted context omitted.

> There are cases when rem is useful and there are cases when it is not, but the author doesn't give a choice and doesn't explain it. and > I recommend using pixels for projects that are going to be maintained and developed in the long term. Directly after lambasting the author for failing to elaborate, perhaps you could go into more depth yourself?

A website that is maintained in a long term will be worked on by many people, and CSS will become quite large and complicated. So using the simple constructs like pixel units is better than using rems that create implicit dependence on main font size. This way there are less chances to break something in one place when editing code in other place. The same is about CSS variables. An example with one variable might lo…

If you code everything in pixels, your site only will look good on your particular screen. This has become so much of a problem that browsers now use a ‘standard’ pixel that is divorced from an actual pixel. I also find sites that do everything in rem/em more assessable as the padding also scales if they have a increased font size due to low vision.

Also, hardcoding things instead of using variables makes things harder to maintain. If someone didn’t use variables randomly, it’s easy to update the CSS to match. Ideally, you have one css (less, etc) file that defines that variables and their relationships, just like a .h file in C, so you can quickly grasp what each variable does.

Re: Relearn CSS layout

#29
post #5

Earlier quoted context omitted.

Flexbox has been supported by all browsers for years now, even by IE11. What on earth do you need to support if you cannot use flexbox?

Caniuse says that IE11 has a lot of bugs regarding flexbox. Firefox supports flexbox only since 2013-2014. So it would make sense to add a simple non-responsive fallback for older browsers. Also, if I remember correctly, the default browser in Windows 7 is IE9. It makes sense to support default browser in the most popular desktop OS. Some of older browsers, released in 2012-2014 support flexbox only with vendor prefi…

I haven't had any trouble doing flexbox for IE11. I always make sure to test in IE11 because of the caniuse warnings; I have very rarely run into any problem with IE11, maybe once or twice, and they were easy to work around problems.

I wouldn't be scared of using flexbox even if you need to support IE11. I'm not sure where caniuse's dire warnings come from. (I have run into different flexbox behavior between FF/Chrome about as often I have run into flexbox problems with IE11; I generally couldn't tell you which of FF or Chrome is correct/incorrect in those cases).

I've in the past done flexbox without too much trouble even on IE10, but I am not myself concerned with IE10 anymore.

Re: Relearn CSS layout

#30
post #17

Earlier quoted context omitted.

On the topic of rems, when using them for layout, you'd use a body font size rather than the root element's font size to control the size of text in your page. At that point the root font size exists only as a scaling factor, decoupled from the base font size of content within the page, but allowing the user to control that scaling factor via their browser's global default font size preference. In fact, you could thi…

It is not as simple as just replacing pixels with rems. Do you test your markup with different root font sizes? Do you add special rules for cases when the font size is too small or too large? Unlikely. Then you better not pretend that you support scaling the fonts using browser settings. Also, I think that changing font size in browser settings doesn't work on most sites, so people don't use it. For example, I use n…

If you build sites that can support arbitrary viewports, extrapolating to arbitrary scaling factors on a given concrete viewport does not create an explosion of scenarios to manually test -- all you need to know is that your scaling works, and if you always build your functionality responsively, the scaling and responsive layout together just work. (I'm talking about building the whole layout with rems, not just using them for font sizes. For the latter, I'd agree with you that it's brittle and falls apart quickly.)

It's fair to point out that the browser feature is not widely used, but when it is used, it's likely by users who benefit most from the small amount of effort it takes to support it. (It's really a few lines of CSS, plus simply using rems as your websites unit whenever you'd otherwise use px. It's even easier in terms of avoiding weird 16px-based rem calculations if you make your rems 10px for a default 16px browser preference by applying a straightforward conversion on the root element.)

Post reply on HN