Hacker News Reader

A layout engine and design are two entirely different concepts.

CSS has nothing to do with design. It is the tool used to implement the design and there are loads of other layout tools out there that don't have CSS's infuriating quirks. On the flip side, they usually have steep learning curves because they are strict.

For a long time, until less than a decade ago, designers knew nothing about CSS. They'd do a design in pictures and their design would be implemented by a programmer.

Some (unlucky) programmers entire job was turning PSDs into HTML and CSS.

> Some (unlucky) programmers entire job was turning PSDs into HTML and CSS.

That was my entry into programming many years ago. But I wouldn't call it unlucky - early web devs like me (we didn't really call ourselves programmers back then) had front-row seats at the beginning of a revolution, and it certainly was entertaining to watch and be part of.

> CSS has nothing to do with design

CSS works the way it does because it was created to make the kind of designs that designers wanted possible. It has everything to do with graphic design. All the web designers I knew back in the early days knew some HTML and CSS and we'd often discuss possibilities and limitations of browsers and standards, and how to work around issues. They didn't just lob PSDs over the partition to the devs - there was an active dialogue and they knew their stuff.

> CSS works the way it does because it was created to make the kind of designs that designers wanted possible

Well, not originally. Later that became a thing, yes - but all the design that was already there at that point (circa CSS 2) remained, as did the overall approach with cascading styles.

A styling language designed for HTML5 today from scratch, accommodating modern use cases, would likely look a lot different.

It would probably be written in JS, maybe something like JSSS [1]. I remember playing with it when it came out and thinking it was very cool. Pity it never went anywhere.

If we were going to start from scratch though, we wouldn't do HTML5, we'd use some other format. JSON maybe?

1. https://en.wikipedia.org/wiki/JavaScript_Style_Sheets

Display PostScript? Only kidding, maybe.

Extremely doubtful, given that many of the modern ones have been written in XML (e.g. xaml, android) and iOS went old skool with a drag/drop GUI.

No-one went pure code (because it's a massive PITA).

^this

I think the best illustration of this "fight" between CSS as a tool for styling "traditional" hypertekst documents, vs CSS as a tool for styling "web pages" is the fate of Adobe's CSS regions proposal - and Håkon Lie's opinion piece arguing against it:

https://alistapart.com/blog/post/css-regions-considered-harm...

That was when "design" lost. But now with grid and transitions, there's a "new" CSS - one that is oriented around UX for "web apps". But apps evolved from documents, mind - not from windowing toolkits like smalltalk morphs or Java swing etc.

Fwiw I really liked the idea of regions for laying out rich documents - like what you might want for epub.

I must admit I'm not that concerned about "web apps" - everyone seems to end up doing their o we n abstraction anyway, and the CSS that "falls out" isn't really sane anyway.

I just wish we decoupled apps and sites, instead of forcing it all together in a large and incoherent design. This is especially painful now that it's spilling over into the desktop world because of all the Electron apps.

>They didn't just lob PSDs over the partition to the devs

You were one of the lucky ones. I worked with designers who would've done fine designing a printed flyer, but couldn't comprehend the idea of a scrolling website with dynamically-populated content (of varying lengths) being viewed at different sizes on different devices/browsers.

Their solutions were along the line of "Force the browser to be XxY resolution and limit the number of words that can be entered in this area."

> All the web designers I knew back in the early days knew some HTML and CSS and we'd often discuss possibilities and limitations of browsers and standards, and how to work around issues. They didn't just lob PSDs over the partition to the devs - there was an active dialogue and they knew their stuff.

I find this false. PSD-to-code was very common back then. There even still some designers today that only work via images/PSD.

Not disputing the 'PSD-to-code'. Did it myself many, many times. I was disputing the idea that designers knew nothing about CSS. The good ones did.

I remember slicing designs in Photoshop into sections, to be dropped into pages...gross.

> CSS has nothing to do with design.

What a bizarre statement. That's like saying words have nothing to do with stories, or paint has nothing to do with art.

If anyone doesn’t get the “Buffalo buffalo...” reference here’s the Wikipedia about that bizarre English sentence [1].

[1]: https://en.m.wikipedia.org/wiki/Buffalo_buffalo_Buffalo_buff...

Oh wow. I'd always just assumed it was a US idiom along the lines of yada yada or something. Buffalo buffalo... doesn't work in British English as it is only a noun.

Nearest English silliness I can remember hearing is: police police police police.

Don't tell me you can't verb a noun in English English? "police police police police" - please...

Of course nouns have been made verbs in English. You'll find no British English dictionary listing where buffalo is, unless noting US usage, where it is both.

Police police police police is grammatically correct, but of little meaning : (the) police police(v) police (of) police (ie overseers of the police).

I read it as: police police (Internal Affairs) police(v) police.

FWIW I'm an ESL speaker from a non-English speaking country and despite having had endless exposure to (mostly American and British) English since a young age, I've never encountered the verb form of "buffalo" outside that one sentence. It's an informal North American idiom and by international standards apparently a fairly obscure one.

Policing OTOH seems to be a fairly widespread verb form with a clearly understood meaning (i.e. what the police conceptually is supposed to be doing). Unless you have close experience with buffalo, you probably can't infer buffaloing means "intimidating".

EDIT: Also as mentioned elsewhere, not everyone outside the US knows there are places actually called Buffalo or makes that leap when hearing the word "buffalo". So "Buffalo buffalo" is more likely to be read as "buffalo(n) buffalo(v)" (which already sounds weird if you don't already know what "to buffalo sb" means) which breaks down as soon as you add more buffalo to the sentence.

It’s extremely obscure as a verb in North America too, fwiw.

Buffalo the city was probably better known 150 years ago, when it was an economic powerhouse as one of the end points of what’s still the second most famous canal in the Western Hemisphere. Afterward it continued to be a significant industrial center until the decline of manufacturing turned the Great Lakes region into part of the “Rust Belt” in the past 50 years. Most Americans probably know of it these days because it still hosts an American football team.

Anyway, the point isn’t that that’s a common sentence. It’s that it’s a grammatical one.

>tons of edge cases, dialects, and straight up absurd rules (Buffalo buffalo..). It's a language primarily improved through experience and memory.

Yeah, I'd sum it up by saying CSS makes hard things barely possible and simple things hard.

The example OP gave of centering divs illustrates this point, and there are unnecessary weaknesses in laying out a page when, for example, sizes aren't known in advance. Overall, there's a divide between intuitive expression and output, wherein the browser ends up saying things like, "I won't do this (e.g. center) unless you also do that (e.g. tell me how big it is)." Really? Why?

In all, it's never been an efficient solution to the problem it seeks to solve. When the Great War on Table-based Layouts broke out, it was even less suitable, which made it even more painful that you were persona non grata for resisting. So, rather than demand a better standard and uniform browser support, we just hacked and kludged and shimmed around it. So, the need to support the legacy has made it even more impractical to fix, hence the attempted do-over with flexbox.

CSS has been the bane of front-end development for many a dev. Amazing that we largely just suffer through it, and its tyranny has reigned for so long.

Everything you say rings true ca 2000 to 2012. Today, CSS and the rendering engines have both improved and converged to such a degree, I’m not sure it’s fair to still criticize them quite so harshly.

Of course the cutting edge will temporarily see one rendering engine a few months behind another. But that’s unavoidable unless you prefer a monoculture, which is liable to move slower than slowest of today’s major rendering engines.

It’s perfectly normal today to create CSS (and JS) in one browser and find it working flawlessly in another. 10 years ago, you would have called everyone over to your screen to have them witness this miracle.

I think there's edge cases, dialects, and straight-up absurd rules in JS too.

I don't think CSS is any less logical... but some might not be use to _declarative_ languages like CSS is?

The difference is that with JavaScript, you can install a linter and happily restrict yourself to the sane subset of the language. It's very realistic to never have to deal with any of the uglier parts of JS, even as a full-time front-end developer.

With CSS, you can't avoid hacks. If you try to design anything non-trivial, you will have to employ tricky non-semantic tricks, run into edge cases, and have to settle on ugly, non-optimal solutions.

I don't think it's a declarative vs imperative thing. It's more that CSS was designed to be easy to use and relatively terse for a specific, outdated use case (20+ years ago when a website page was thought as a 1 dimensional flow of text and pictures).

Nowadays our requirements encompass pretty much the full spectrum of 2D space design, yet we still use a language that builds on high level primitives designed for a narrow usecase.

New features like Flexbox and CSS Grid help with the layout part, but it's not enough.

> 20+ years ago when a website page was thought as a 1 dimensional flow of text and pictures

Here's the thing though — most websites are still just a '1 dimensional flow of text and pictures'. They try to disguise it with multiple columns of guff, but it's still just text and images. Sometimes a video.

Sure there are web 'apps' now too, but most websites are not apps (thankfully).

>Sure there are web 'apps' now too, but most websites are not apps (thankfully).

The thing is, web apps are also just a more complex version of the same '1 dimensional flow of text and pictures,' just maybe with Canvas and a lot of javascript. There's no real difference between a web app and a document, as far as HTML/JS/CSS is concerned. The dirty secret of the whole "the web used to be documents but now it's applications" meme is that the applications are still documents.

What does installing a linter have to do with using a subset of a language?

Just... use the constructs you're familiar with? It's not like you can "accidentally" use an ES6 class or something.

You can accidentally use == instead of ===, or even accidentally use the assignment operator instead of one of the comparison operators.

You can know about for..in without knowing about hasOwnProp.

You can forget to enable strict mode.

The list goes on. Static analysis is universally a good thing.

installing a linter and limiting yourself to a subset of the language has to do with the fact that most development is done in teams, so when you limit yourself you limit the team to an agreed upon good subset of the language and nobody screws you over because they think the with statement needs a workout.

I experience the same than the author. But I have absolutely not the same problem with a declarative language such as QML, Cascade, Android xml, Jboss rules engines, etc...

I don't think it is caused by this aspect of CSS.

The problem could come from the fact that it mixes 2 purposes: style AND layout to apply it globally with rules that get harder to understand the bigger the project.

I’m in the same exact role, leading both UX and FE engs. It’s exhausting.

> Javascript is logical (sort of...), and a lot like learning math. It's fairly easy to validate your output. It works well with the logical side of your brain.

No, it really isn't.

Some languages are, JS definitely isn't. It's mostly illogical / broken / mental.

That isn't an argument, you're just expressing your disagreement.

Even if it were an argument I'm not even sure it would be an argument worth having because it's likely entirely orthogonal given the context of the original statement (i.e. contrasting JS with CSS and HTML -- where whatever esoteric programming language you're thinking of is not an option to begin with).

if you avoid the absurd parts, JS is perfectly acceptable. The standard ways people write modern ES6+ CSS is fine.