Hacker News Reader

Comment by combatentropy | Hacker News Reader

> Try setting a child of a flexbox container to 100% height.

Isn't this the default?

   align-items: stretch

--- https://css-tricks.com/snippets/css/a-guide-to-flexbox/

> 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.

View on HN

https://stackoverflow.com/questions/33636796/chrome-safari-n...

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!

>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.

That's why I use CSS in JS :D. But we're just putting abstractions/stopgaps over a fundamentally flawed design. Not to mention, since everybody uses a different standard for isolation, CSS in JS is not compatible with BEM is not compatible with SASS, etc.

CSS was originally designed with the idea that you would have one css file for your whole site, and it would be maybe 300 lines max.

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.

It never worked well in the original envisaged usecase. CSS 1 didn’t work properly with tables which meant I used to have to inline style attributes for tables as well as set a CAS file. It’s always been garbage for centering things, in the early days that meant using the <center> tag. Then you have all the different browser extensions (o-, mo-, etc) the inconsistent preferences for font-face, etc.

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.

>I would honestly welcome a ground up complete reimplementation of the web if browser vendors all decided to work together on one.

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?

Ostensibly I do agree with you however that is the reason I phrased it "browser vendors working together" rather than "a new spec being written".

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.

> 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?

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 Javascript equivalent of byte code would be web assembly and that is still a long way from being ready for primetime.

The question is, why isn't "the javascript equivalent of bytecode" just javascript? Why do you think there's a difference between "javascript" and "bytecode"?

Learn CSS Layout the pedantic way at:

http://book.mixu.net/css/

can help with the trial and error bit. It impossible to get an intuitive feel for nearly 400 keywords IMHO.

That's great reference (thank you for the link) but one of the great - if not the single greatest - accomplishments of the web was that it allowed anyone with a text editor and access to the internet to publish content with ease. I get that commercialisation of any platform will lead to specialities in that field; however the tools shouldn't make it objectively harder for new comers to contribute. Let alone discriminate against hobbyists who might not want to spend several hours of their life learning CSS (never-mind HTML, perhaps Javascript, how cookies work and any regional legislations, OWASP should they dare to have any user submission forms, etc).

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 is as simple as it ever was to do what could be done 15 years ago with a simple text editor and access to the internet. Any adjoining aspect has gotten easier and cheaper by a magnitude.

It's just that what people want has gotten a lot harder to build.

The removal of the <center> tag in place of CSS black magic is definitely not "easier" than it was 15 years ago. However I suspect this is going to be one of those debates that we have to agree to disagree on.

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.

though i resisted for a long time, bootstrap brings back some of the old ways. <div class=“d-flex justify-content-center”>centered</div>

Back when CSS was useful for changing the color of all your headlines without changing all your HTML, it wasn't delivered in giant minified files, it was a couple dozen lines written by hand.

The spec has changed on multiple occasions around whether flex items are definite sized or not, which is part of what of what's caused the lack of interop here.

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.

> The days of needing separate constructs because of bandwidth are over

> 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.

Reply on news.ycombinator.com