6 ms·

I usually roll my eyes when people claim that CSS is just too hard to learn, or that these new features are just too complex. I am generally of the opinion that

I usually roll my eyes when people claim that CSS is just too hard to learn, or that these new features are just too complex. I am generally of the opinion that once you are a day-to-day practitioner, CSS does broadly make sense once you build a mental model of how the system works. And then they throw in this dynamic viewport unit stuff, and I realize…oh, I am guilty of hubris. I have angered the CSS gods, and they have struck me down for my arrogance—because this is complicated stuff. https://blog.logrocket.com/improving-mobile-design-latest-css-viewport-units/ https://blog.logrocket.com/improving-mobile-design-latest-cs...

deleted 3y ago
[deleted]
Waterluvian 3y ago
For any CSS newbie I would encourage them to learn Flexbox and Grid. I find that layout is the most confusing and those two display modes have greatly cleaned things up. It’s amazing how much they behave the way you intuitively expect them to. They eliminate… I’m going to dangerously say… most newbie gotchas. Beyond that, 100% in agreement. There’s just so much and when it all interacts it can be a nightmare.
- farazzz 3y ago
  Finally figuring out Flexbox was the moment I stopped dreading writing CSS because it does make a lot of things so much easier I recommend the game Flexbox Froggy, which is how I learnt it
  - gmt2027 3y ago
    Flexbox Froggy is great. Thanks for the recommendation.
- pucado 3y ago
  I have been writing code for over 10 years, I just end up using bootstrap every time.
hinkley 3y ago
People who learn things by increment do not have the slightest idea how hard it is to learn them from first principles. You are reasoning from long term memory. They new person is reasoning from working memory. You can only juggle a handful of new concepts at once.
deleted 3y ago
[deleted]
jorams 3y ago
The CSS viewport unit situation is so frustrating. First they introduced vw and vh, and those did the obvious thing: reflect the viewport. Then mobile WebKit/Safari broke vh for many use cases, because they couldn't make the obvious behavior perform at 60fps in combination with their UI choices (the actual problem always remained vague: "looks like shit but we can't show you"). Instead these units started ignoring any browser chrome that could change size. This makes them useless for any purpose where the actual size of the viewport matters. Other browsers followed because Safari was not going to change. Now, years later, the obvious behavior is re-introduced in the form of dvh. vh and vw are no longer recommended because their behavior regarding changing UI is unspecified. The idea of a static viewport unit is not bad. It's useful for things that don't actually care about the viewport size, but just want to be somewhat responsive (font size). I don't think I've ever seen a situation where lvh vs svh matters, because the web developer has no say in browser UI behavior. It's just sad how many hours have been wasted working around a problem only introduced because Apple couldn't deal with a small temporary framerate drop.
- bongobingo1 3y ago
  > because Apple couldn't deal with a small temporary framerate drop and one that we probably Moore'd past pretty rapidly anyway.
  - noduerme 3y ago
    I think we Moore'd past the iPhone's sluggishness running decent AS3 code around 2012 once Adobe got Flash Player iOS into beta... still didn't stop Apple from decimating a million lines of my code and destroying everyone's ability to play my games.
- chrismorgan 3y ago
  > First they introduced vw and vh, and those did the obvious thing: reflect the viewport. Well… not the viewport you’d expect. They reflect the viewport including document scrollbars, which means that, if scrollbars are, say, 17px wide, then on a vertically-scrolling document with no margins, 100vw is equal to 100% of the body width plus 17px. The result of this is that viewport units have always been fundamentally broken and incorrect in the main place people wanted to use them: 100vw will cause overflow if scrollbars take any space. Then along comes this new generation of viewport units, fixing an artificial problem (as you say), and continuing to ignore the actual bug, because the browser makers don’t care much about non-overlay scrollbars any more, even though that’s still the considerable majority of non-mobile users, and supported even on those non-mobile platforms that default to overlay scrollbars. (Aside: I’m glad that even when Windows is heading in the direction of overlay scrollbars, they’re at least not hiding the thumb whenever possible like macOS and all mobile platforms do. Also I miss Ubuntu’s Ayatana overlay scrollbars from about a decade ago—a bit gimmicky, but they showed care in balancing considerations and generally worked very well.) And perhaps the worst part of it all? The spec actually included a practical workaround (give the document `overflow-y: scroll` so there’s always a vertical scrollbar, and vw will exclude any space allocated to that scrollbar—and the same for overflow-x/vh), but only Firefox implemented it, and no one else wanted to, and so it was eventually removed from the spec and from Firefox.
paulddraper 3y ago
I have been learning CSS since....as long as it has existed. And I would like miserably fail any "CSS gotcha" test. ("What does this code do?") If you learn some subset of CSS you can be productive, but stray outside of that, and who knows.
danielvaughn 3y ago
I was complaining on HN about this property the other day, and got quite a bit of pushback. But I really believe that "dynamic viewport" is a terrible decision. Instead of Safari and other mobile browsers simply respecting the viewport itself, we're bending over backwards and adding more complexity to CSS just so they can have this little one-off feature of theirs. It's very frustrating.

deleted 3y ago

[deleted]

Waterluvian 3y ago

For any CSS newbie I would encourage them to learn Flexbox and Grid. I find that layout is the most confusing and those two display modes have greatly cleaned things up. It’s amazing how much they behave the way you intuitively expect them to. They eliminate… I’m going to dangerously say… most newbie gotchas. Beyond that, 100% in agreement. There’s just so much and when it all interacts it can be a nightmare.

farazzz 3y ago
Finally figuring out Flexbox was the moment I stopped dreading writing CSS because it does make a lot of things so much easier I recommend the game Flexbox Froggy, which is how I learnt it
- gmt2027 3y ago
  Flexbox Froggy is great. Thanks for the recommendation.
pucado 3y ago
I have been writing code for over 10 years, I just end up using bootstrap every time.

hinkley 3y ago

People who learn things by increment do not have the slightest idea how hard it is to learn them from first principles. You are reasoning from long term memory. They new person is reasoning from working memory. You can only juggle a handful of new concepts at once.

deleted 3y ago

[deleted]

jorams 3y ago

The CSS viewport unit situation is so frustrating. First they introduced vw and vh, and those did the obvious thing: reflect the viewport. Then mobile WebKit/Safari broke vh for many use cases, because they couldn't make the obvious behavior perform at 60fps in combination with their UI choices (the actual problem always remained vague: "looks like shit but we can't show you"). Instead these units started ignoring any browser chrome that could change size. This makes them useless for any purpose where the actual size of the viewport matters. Other browsers followed because Safari was not going to change. Now, years later, the obvious behavior is re-introduced in the form of dvh. vh and vw are no longer recommended because their behavior regarding changing UI is unspecified. The idea of a static viewport unit is not bad. It's useful for things that don't actually care about the viewport size, but just want to be somewhat responsive (font size). I don't think I've ever seen a situation where lvh vs svh matters, because the web developer has no say in browser UI behavior. It's just sad how many hours have been wasted working around a problem only introduced because Apple couldn't deal with a small temporary framerate drop.

bongobingo1 3y ago
> because Apple couldn't deal with a small temporary framerate drop and one that we probably Moore'd past pretty rapidly anyway.
- noduerme 3y ago
  I think we Moore'd past the iPhone's sluggishness running decent AS3 code around 2012 once Adobe got Flash Player iOS into beta... still didn't stop Apple from decimating a million lines of my code and destroying everyone's ability to play my games.
chrismorgan 3y ago
> First they introduced vw and vh, and those did the obvious thing: reflect the viewport. Well… not the viewport you’d expect. They reflect the viewport including document scrollbars, which means that, if scrollbars are, say, 17px wide, then on a vertically-scrolling document with no margins, 100vw is equal to 100% of the body width plus 17px. The result of this is that viewport units have always been fundamentally broken and incorrect in the main place people wanted to use them: 100vw will cause overflow if scrollbars take any space. Then along comes this new generation of viewport units, fixing an artificial problem (as you say), and continuing to ignore the actual bug, because the browser makers don’t care much about non-overlay scrollbars any more, even though that’s still the considerable majority of non-mobile users, and supported even on those non-mobile platforms that default to overlay scrollbars. (Aside: I’m glad that even when Windows is heading in the direction of overlay scrollbars, they’re at least not hiding the thumb whenever possible like macOS and all mobile platforms do. Also I miss Ubuntu’s Ayatana overlay scrollbars from about a decade ago—a bit gimmicky, but they showed care in balancing considerations and generally worked very well.) And perhaps the worst part of it all? The spec actually included a practical workaround (give the document `overflow-y: scroll` so there’s always a vertical scrollbar, and vw will exclude any space allocated to that scrollbar—and the same for overflow-x/vh), but only Firefox implemented it, and no one else wanted to, and so it was eventually removed from the spec and from Firefox.

paulddraper 3y ago

I have been learning CSS since....as long as it has existed. And I would like miserably fail any "CSS gotcha" test. ("What does this code do?") If you learn some subset of CSS you can be productive, but stray outside of that, and who knows.

danielvaughn 3y ago

I was complaining on HN about this property the other day, and got quite a bit of pushback. But I really believe that "dynamic viewport" is a terrible decision. Instead of Safari and other mobile browsers simply respecting the viewport itself, we're bending over backwards and adding more complexity to CSS just so they can have this little one-off feature of theirs. It's very frustrating.