Isn't this the default?
align-items: stretch
> The days of needing separate constructs because of bandwidth are over
That wasn't the reason for stylesheets. It was for ease of changes. For example, to change the color of the headings on all of your HTML pages, you would change just the stylesheet. This was when each web page was a static HTML file. Few websites used programming languages to render pages. So the benefit today is less.
But I guess if you don't care about that nor bandwidth then you can use inline style attributes.
I'm referring to this. Got bitten by it recently.
> That wasn't the reason for stylesheets. It was for ease of changes. For example, to change the color of the headings on all of your HTML pages, you would change just the stylesheet. This was when each web page was a static HTML file. Few websites used programming languages to render pages. So the benefit today is less.
Interesting, I didn't know that. Still, CSS doesn't make a whole lot of sense to me. Here's a bunch of global state, some of which is hidden in gigantic minified files, now edit it!
Well, there's your problem. I'd recommend reading about things like atomic css, BEM, OMACSS, etc.
We've obviously gone well off the rails. Selector specificity was supposed to be the scoping mechanism. And it works great in the original envisaged usescase: a single person making a single website. it just doesn't scale to large teams, and ancient software projects, with complicated layouts.
CSS was a great idea but it’s always been a garbage execution of that with no single browser following the spec correctly for years then each browser going off and adding their own crap when the spec ended up languishing (thank you W3C for sleeping while the web leapfrogged into the future).
I’m not a fan of HTML (I think that was good for it’s time but could use deprecation) nor JavaScript (but I’ll concede this is personal preference - however wouldn’t it be nice to have browsers run byte code so you could have a choice of languages rather than having compile everything down to JavaScript?) but CSS is easily the worst of a bad bunch in my personal opinion.
Frankly I don’t even get why people are defending it. Any programming tool that reduces the developer down to hours of trial and error just to do basic things is clearly a misstep. Sure, expert front end developers with years of experience and using bloated frameworks cope fine; but why have we allowed ourselves to get into this kind of mess in the first place?
I would honestly welcome a ground up complete reimplementation of the web if browser vendors all decided to work together on one.
can help with the trial and error bit. It impossible to get an intuitive feel for nearly 400 keywords IMHO.
Talking personally, I published my first website in 1994 when there wasn't different layout modes. Now it is suggested that I read a multi-chapter book just to learn what's changed in CSS so I can publish the same content I had before but in a "web 3.0" (for want a better description) format.
I appreciate my comments are very ranty / preachy and do value your comment as I hadn't seen that link before; so my comments are not directed at you in any negative way at all! What I'm essentially just trying to say is web development has become very frustrating for anyone outside of the webdev community. Heck, I find it frustrating and I used to specialise in hardening web servers so have worked quite close to that community.
It's just that what people want has gotten a lot harder to build.
I should add that I don't disagree with the deprecation of <center> from a language purists perspective. However it was still a step backwards in terms of ease of development when centring stuff in CSS is so clunky in comparison.
Was that the sound of a pig flying by, or the sound of hell freezing over? Any time specs can be interpreted, there will always be these differences in browsers. Maybe we could not call them specs, and just call them suggestions?
However, as you said, the chances of that happening are remote. Even putting personal agendas aside (eg Google wanting to control content via AMP), the web in it's current form is "good enough" that there's no real drive to reinvent the wheel for something with such deep market penetration already.
How are those two situations different? You're compiling one language to another language. Does it matter if one of them is called "bytecode"?
The problem here is specifically having a percentage sized child of a flex item (and Chrome and Safari don't match the current spec, as the flex item is indefinite sized in too many cases; Firefox doesn't either, as the flex item is definite sized in too many cases!); to make the flex item definite sized everywhere you can typically just add height: 0.
> It was for ease of changes.
Wat? Not solely. CSS had many goals, the primary reason was a separate styling language that could be universally interpreted and expanded, without involving HTML (or any other standard like ECMA). HTML versions were already bogged down in semantic squabbles.
parent {
child {
}
is just so much more development friendly than
parent {
}
parent child {
}
(This is https://github.com/w3c/csswg-drafts/issues/2701 .)
The key difference IMO in how to think about CSS nowadays is to move away from the paradigm of CSS as a global system, and instead, use it locally scoped to components. I like to think of CSS classes as a kind of local state. Most often, in layout components and whatnot, its static. Otherwise, in more dynamic situations, rather than messing with css properties directly (or passing vars via css-in-js), the component's js manages the "state" of the classes being applied by adding/removing.
When you start to think in this composable component framework, styles are just another component. And js is used to manage changes in state, which it is much more apt to do.
It's not easy, but it's possible. All animated/transioned elements emit lifecycle events like animationstart/transitionstart so you can use those to orchestrate complex animations. This is AFAIK how ng-animate works internally.
There's a slightly more reliable and less ugly hack than using a timeout, which I _think_ is applicable to the scenario you're describing: instead, force a reflow by reading the element's .offsetHeight. I wrote about this on Stack Overflow years ago: https://stackoverflow.com/a/16575811/1709587
Not disagreeing with the overall thesis of this post, just pointing out a slightly less annoying way to work around the problems from application-developer-land.
Am I the only person who thinks this is a feature, and that the "bad part" is CSS supporting animations and transitions?
I mean - HTML for markup, CSS for layout and colors, JS for logic and animation. There was a very clear and well defined separation of concerns to the web, why did we have to go and ruin it by making CSS almost Turing complete then having everyone generate CSS and HTML with javascript?
Just yesterday I was making a music player position bar, and using CSS transitions to have it smoothely update itself. Set the duration of the transition and it goes on.
But what about when the transition takes effect? JS doesn't know when a style is actually updated and can then have a new property overwriting it to make the transition happen. If you do properties too quickly the transition won't happen. Such as if a user clicks on the bar to change the position, I have to hack in a 100ms setTimeout to set the new transition duration after stopping the transition with transition:none;
Why can't I control a transitions location? Chrome's animation viewer can go back and forth in time easily.
Why isn't interactivity seperate from CSS? CSS elements cannot effect those outside of its scope. You require JS for just dumb simple things that should be natively supportable. For instance you can make CSS do things based upon URL hash names like #somename, but you can't set them in CSS. You can't change attributes on elements, or classes or anything like that.
I think we've gotten to the point where JS is the 'programming language' of a webpage that has intentions far beyond rendering and interactivity. Perhaps we need a newer kind of CSS that's made for dynamic interactions. That way great UI's can be built in a safer css-like environment.