Hacker News Reader

Comment by brundolf | Hacker News Reader

I wrote a (much shorter) article in a similar vein a few years ago: https://css-tricks.com/css-is-awesome/

I find it fascinating (saddening, but fascinating) that so many programmers are so turned-off by CSS and find it so unintuitive. I almost want to set out on a research project to figure out why that is. My experience with it couldn't be more different.

Here's one way of looking at CSS (which I didn't think of until just now): CSS is not a language you build something up out of. It's more like you're carefully taming a wild horse, or pruning a plant. You have to embrace the natural movement of the thing, and strategically redirect it only where necessary. If you come in with the mindset of constructing the world from scratch (which works in most programming languages), you're just going to be fighting the beast the whole way, and you're going to lose.

View on HN

This isn't fully formed in my mind yet so go easy:

Intuition is linked to elegance, an elegantly designed language is intuitive. An elegant language is one that starts with a few core principles and from that derives the rest of the language. Lisp is an example of a programming language that does this beautifully well.

Usually (always?) such core principles themselves are taken from mathematics. After all, maths is heavily engaged in the business of elegance.

CSS doesn't feel like it's built in this way. When you read a tutorial it doesn't begin with: "these are the fundamental concepts of CSS", rather it feels more like a hodgepodge of lots of different ideas and when they intersect you end up with confusion.

Part of that is for sure the nature of the evolution of CSS. But I don't see any "core" of CSS that you could extract that would be elegant and intuitive now.

I think programmers develop this strong instinct for when things "make sense" in that they're intuitive and elegant. It's like taste. CSS leaves a bad taste.

The best comparison I have for how it could be are the UI layouts of Java, Android, iOS. Java and Android aren't great tbh (don't have much experience with iOS) but at least you can see the design behind them.

It feels like something should begin "there are these elements. each have a bounding box. to see how bounding boxes are calculating for text etc you can deep dive into docs. Anyway, these bounding boxes may also be enlarged (through padding etc.). Now, each box has three properties that define its interaction with other elements..." like a maths class and not "if X is inside Y then you can set Y to make X appear on the left if X has its margin set to Z" uggggg.

CSS was never meant to be used for applications.

What happened was this: Once upon a time, there was only HTML. It could only make simple text pages.

Then the internet revolution of the 1990s happened, and everyone wanted to put make their webpage look like a glossy pamphlet. So along came extra HTML tags, and the widespread abuse of <TABLE> and other tags added to HTML to make web pages look like glossy pamphlets.

At the same time, CSS was developed so the HTML could stay clean and maintainble, and the layout of the “glossy pamphlet” look was in a separate file. HTML + CSS wasn’t designed to make an interactive app. It was designed to make a magazine article or an online resume. One would use Java (1990s) or Flash (first 2000s decade) for anything interactive.

It was in the 2010s, long after Java applets stopped being widely supported, and when Flash was too proprietary and too insecure, that the ability to make a fully interactive app was tacked on to Javascript; this was not the original intent of Javascript nor of CSS.

So, there is no real underlying design. It was something hacked on to a standard designed to share text documents.

If Steve Jobs were alive today, I think Apple or someone else would create a new interactive standard without all of the baggage of HTML + CSS + Javascript. It’s like the problem we have had for years, where a modern x86_64 chip is a 64-bit extension of a 32-bit extension of an originally 16-bit chip; it’s only now with the M1 that we are finally using a more elegant and well-designed chip architecture for desktop computers.

Yes and no. The "flex" display model was developed by Mozilla all the way back when they crated XUL for defining GUI's.

So this part of the spec was specifically developed for GUI's rather than documents.

This is more a failure of the tutorials than of CSS itself though. CSS has a pretty simple and elegant core. You just have to understand the problems it was designed to solve.

- Readable documents at any screen dimensions or resolution (i.e. you should not need to scroll horizontally back and forth to read each line just because you have a smaller screen.)

- Incremental rendering - the document could be rendered as the data arrives over the network.

- The user should be able to increase the text size.

The "normal flow" layout model is designed in such a way that these constraints are fulfilled by default. You can make a layout which only works on a screen of a particular size, or where the user have to scroll horizontally for every line, but you have to do it deliberately.

I'd say the fundamentals of CSS is to understand the "normal flow" and the box model.

> CSS has a pretty simple and elegant core.

Where can I read about this - has someone written "CSS: the good parts", for example?

Dunno if this exists. Maybe I should write one?

The CSS 2 spec was actually a good introduction to the fundamentals, but it is 20 years out of data now, and the new modular specs does not works well as a tutorial.

I like this page: https://www.taniarascia.com/overview-of-css-concepts/

"box model" is the term to google.

I'm not convinced. Literally none of these 3 bullet points are problems with plain HTML since at least 1993 or so - it's responsive by default, incremental by default and user agents are free to zoom in or out at will by default.

But HTML doesn't say anything about how things need to be rendered / presented. It was never intended to do that.

All it does is mark the structure in a document. "This is a header", "this is a paragraph", "this is a quote". That's basically it. The "hypertext" part of HTML refers to the notion that it uses URI's that can be used to identify resources, and dereference them.

It's entirely up to the consumer of a HTML document to decide how it gets rendered. A browser engine comes with a layout component that determines how the constituent parts of a document need to be painted before they are actually painted on the canvas.

Browsers in a GUI come with a default CSS definition that will be used if the document doesn't reference a companion CSS stylesheet.

Moreover, a browser doesn't have to be a GUI browser. What about text browsers on the command line?

I'll give you an example:

This is the hard coded default style definition of the Lynx browser when running through curses:

https://github.com/kurtchen/Lynx/blob/8b3a9d48dc6737e2062c56...

And this is the parser that will parse whatever limited user CSS is provided, as it is a text browser.

https://github.com/kurtchen/Lynx/blob/8b3a9d48dc6737e2062c56...

CSS was exactly designed to solve those 3 problems and much more.

The separation of structure and presentation is by design. Why? Because HTML and CSS never were intended to be used as tools for building "Rich Web Applications". They were originally intended to render hypertext and static web pages.

As it happened, the world wanted rich, interactive, animated web applications. And it needed technology to build such complex applications. Web technologies have evolved over 30 years to get to that point. Remember Flash? Java applets? Silverlight? Those were all attempts to do what HTML and CSS didn't do. Until the big vendors who came to dominate the browser market expanded on what HTML, CSS offers, and build new API's into their browsers that allow for exactly that.

There's nothing wrong with wanting to build rich web applications, and trying to leverage these affordances. But if you get hit by the limits of what web technologies have to offer in terms of maintainability, performance and what not, that's because you're still building on top of a historical foundation of basic principles that was never intended to be used in ways that it is used today, 30 years into the future.

HTML absolutely used to “say how things needed to be rendered”: with tags like B, I, FONT and so on. It was developed when documents were expected to be WYSIWYG-style markup (Word/WordPerfect, Latex, etc).

CSS was designed to strip that away only after people decided the future of hypertext should look more like XML. In doing so, they added the constraint that you should be able to get completely different outputs depending on which media you use to access the content - which at the time largely meant printing vs browsing.

But I agree that the whole thing was fundamentally document-based and has been bent out of shape in the subsequent decades. Once the content/presentation separation was abandoned, all bets were off. Now we are in a situation where content is driven by CSS properties via JS manipulation. We have the worst of both worlds. Ironically, this was enabled by something called XMLHttpRequest...

> HTML absolutely used to “say how things needed to be rendered”: with tags like B, I, FONT and so on. It was developed when documents were expected to be WYSIWYG-style markup (Word/WordPerfect, Latex, etc).

Yes, those tags do exist. However, their story is more complex, and intertwined with the rocky road towards standardization. And their importance gets easily overstated, even though they were a boon for budding website builders dabbling with HTML in the late 1990's. [0]

These didn't exist in the original HTML document as drafted by TBL. They were tacked on in what we know as HTML 2, which wasn't an W3 recommendation but an IETF RFC. [1] They were kept in HTML 3.2 which is the first formal W3 recommendation recognized as a standard in january 1997. [2]

HTML 4.01 deprecated FONT, CENTER, U and STRIKE in december 1999, barely 2 years later. [3] At the same time, HTML 4.01 introduced and promotes the use of stylesheets for presentational purposes to overcome the limitations of HTML. [4]

> Style sheets represent a major breakthrough for Web page designers, expanding their ability to improve the appearance of their pages. In the scientific environments in which the Web was conceived, people are more concerned with the content of their documents than the presentation. As people from wider walks of life discovered the Web, the limitations of HTML became a source of continuing frustration and authors were forced to sidestep HTML's stylistic limitations.

> ... Style sheets solve these problems at the same time they supersede the limited range of presentation mechanisms in HTML.

Moreover, the use of the elements that weren't deprecated - I, B, BIG,... - was discouraged by the HTML 4.01 specification itself in favour of stylesheets. That's since December 1999. [5]

> The following HTML elements specify font information. Although they are not all deprecated, their use is discouraged in favor of style sheets.

Also, I would have to disagree with this:

> CSS was designed to strip that away only after people decided the future of hypertext should look more like XML.

The development on XML happened at the same time as HTML and CSS. XML was first published in February of 1998, well after HTML 3.2 and before HTML 4.01.

However, XHTML 1.0 was based of HTML 4.01 and was basically a transposition of HTML 4.01 using XML. XHTML 1.0 only became a W3 recommendation in January 2000, well after HTML 4.01 and XML were first published. [6]

Moreover, CSS 1 was first published in 1996, CSS 2 in May 1998. The first draft of XHTML only was published in December of 1998, well after CSS was established. [7]

My point is that all of these technologies were developed by committee. In separate Working Groups, which didn't necessarily align their efforts. That's basically why the road towards convergence was - and to a degree still is - this rocky.

And all of that is discounting the browser wars with vendors such as Microsoft applying their own interpretation of the specifications in their engine.

[0] http://www.martinrinehart.com/frontend-engineering/engineers... [1] https://www.ietf.org/rfc/rfc1866.txt [2] https://www.w3.org/TR/2018/SPSD-html32-20180315/#body [3] https://www.w3.org/TR/html4/appendix/changes.html#h-A.3.1.2 [4] https://www.w3.org/TR/html4/present/styles.html [5] https://www.w3.org/TR/html4/present/graphics.html#h-15.2 [6] https://en.wikipedia.org/wiki/XHTML#XHTML_1.0 [7] https://en.wikipedia.org/wiki/CSS#Variations

Actually, the original HTML was not designed to have the end user agent determine how a page looks, and was designed to specify presentation. <FONT> was not part of the original HTML specification. <TABLE> was never meant to lay out a page.

The WYSIWYG-like tags were added in the late 1990s during the dot-com era because companies wanted to be able to make web pages “glossy brochures” and were doing things like making web pages huge imagemaps until Netscape added HTML tags specifying presentation.

Exactly! The default CSS browser stylesheet is a reverse engineering of how Netscape 2.0 rendered HTML. It had to be, since otherwise CSS wouldn't be backwards compatible, which would have killed it. But it was also a good starting point because browsers had to solve this exact problem: Layout text so it it readable regardless of screen dimensions.

Except that HTML rending was never specified (and varied significantly between browsers), so CSS basically codified the defacto HTML rendering in mainstream browsers, and then described this as the "browser style sheet".

CSS then allowed the author to override anything they wanted to change. But the default for anything not overriden was the browser style sheet, which was a sane default which adapted to all screen sizes.

>This is more a failure of the tutorials than of CSS itself though.

But therein lies the rub. Where do you go for authoritative information on CSS that doesn't involve digging through winding, terse technical specifications? That may be fine for developers making web browsers but becoming an 'expert' in CSS shouldn't be a requirement just to make a web page. Hell, even the experts struggle with it otherwise all web browsers would have consistent CSS rendering. A good example is centering an element in CSS. What's the right way to do it? There's a multitude of techniques with varying advantages and trade-offs. I first cut my teeth in web development in 2001 and we still don't have a simple, straight forward, codified way to accomplish this seemingly simple task. Instead we have an ever changing standard coupled with a dizzying amount of opinions on the matter and inconsistent browser support on mobile devices. We can't really blame the failure of tutorials when there's no clear authoritative reference point to work from.

I hear you and think you make great points. Thankfully, there IS a resource and approach to using CSS properly, embracing the nature of the browser environment and building up from profoundly well-researched and -articulated first principles. The approach is called "Axiomatic CSS", and the website is https://every-layout.dev.

Disclaimers:

1. No affiliation, just a grateful follower.

2. The site includes a mix of free and paid content. The free content includes the axioms you're seeking, and compelling examples of their use. The paid content includes a book and access to the full suite of composable layout primitives, and a component generator. Best $100 business expense of my 22+ year career in web development.

This actually looks really great, thanks for sharing!

I'll bite.

I'm not a fan of CSS. I learned it well enough to build a decent UI toolkit (draggable modals, collapsible, etc.)

I hate how CSS tries to mix layout and style. A million articles about not using tables for layout, and it took 20+ years to get a grid. I tried to do some fancy text and element alignment with CSS, and it was not having it (and, yes, I know about display: table). In the end I reverted to a table. It worked, and I moved on with life.

It is ridiculously hard to draw things in absolute positions. In many cases, it is easier to do a tiny bit of math and compute the positions of objects, rather than have to define parent/child relationships. But for true absolute positioning, you have to throw divs into a "portal" of some sort, and move that object into the root element. This makes doing things like pretty drag and drop extremely painful.

Browsers are buggy as hell, and often something works on everything but [insert your most hated browser]. That's a hint that the spec is too complicated.

I agree with your assessment, in that if you try to construct the world from scratch, you'll be "fighting the beast the whole way." I disagree that this is positive quality of the thing.

>A million articles about not using tables for layout, and it took 20+ years to get a grid<

To be fair, CSS 2.0 (from 1998) has “display: table” which allows table layout in pure CSS. [1] The problem was not CSS. The problem was Internet Explorer 6; “display: table” was not viable to use until the early 2010s when IE6 usage finally plunged.

[1] Edit: CSS was designed for styled documents, such as online resumes or blogs. It was not designed to make interactive apps, which is why it doesn’t fit that paradigm well. Everyone thought Java applets would run the interactive web, and we would be making web applications in Java today if Microsoft had not killed Java on the web in the late 1990s with IE.

In my experience, "display: table" is not really identical to the behavior of <table>. I gave up on it for my project, though unfortunately I don't remember the specifics.

I think it's just a fundamental issue where CSS is trying to be both layout and style. Works great for basic document formatting, but once you try to do something complex, it all falls apart. Or, rather, it should fall apart, but we've spent the last couple decades duct taping it together.

Every JavaScript framework ultimately hits a wall where it has to interact with CSS. It can't be abstracted away.

I really do believe more money and effort should be spent looking for an alternative.

The biggest thing missing in “display: table” is “colspan”, allowing a table cell to take up multiple columns of the table. That can be a big deal with some layouts. One workaround is to use “position: absolute” inside a CSS table cell to have an element which can span more than one table column.

Why not use a <table>?

For layout?? Burn the heretic! [1]

The real reason we don’t use tables for layout (and only for the occasional tabular data) is because a table layout doesn’t work really well on the screen of an iPhone or Android phone, especially when they are vertically aligned. So, the workaround is to use media selectors: Desktops, laptops, and tablets get a table layout; phones get a simpler one-column layout.

I believe grid and flex layouts allow one to use a single design which will appropriately scale from a phone screen to an ultrawide monitor, but I use a two-layout or three-layout design for my web pages.

[1] In the days when the CSS Zen Garden was new, all of the web design blogs and comments felt using <table> for anything at all was heresy, since abusing <table> resulted in really ugly and hard to maintain webpages during the dot-com days of the late 1990s. It would be an extended discussion whether it was OK to even use <table> for clearly tabular data.

I think the don't-use-tables argument is from way before mobile devices were something web developers cared about. I recall it as being mostly about semantics, i.e. tables should only be used for tabular data, not setting up the layout of your entire page.

That's right. The argument was separating document structure from layout. Using a table for page layout makes the document structure incoherent.

The Jeffrey Zeldman era of CSS.

I have never seen anyone arguing <table> was not OK for tabular data.

I thought this was a myth on level of teenagers eating tide pods.

Those kinds of discussions have dropped off of the Internet over the last decade and a half, being hosted at places like the now defunct original Digg website. It was an era when one could said something really stupid online and it would become mercifully forgotten.

What I have found is a 2014 blog posting where another web designer from that era says “the early anti-HTML table movement was strong. It managed to brainwash many generation of developers into thinking that any usage of table is evil. [...] I am one of those developers who avoided table layout, even for displaying tabular data.”

Reference: https://colintoh.com/blog/display-table-anti-hero

These days you actually can use <table> without compromising accessibility, by adding aria-annotations. So if you prefer this to CSS, go ahead.

Most of the angst around <table> was before aria support, so using <table> purely for layout impacted accessibility, which meant it was not viable for most real-world scenarios.

That said, if you need stuff like colspans for a layout, you are probably better of using grid.

Exactly.

td supported vertical-align:middle since css1. But you're not suppose to use tables because... hmm. The user sees no difference. Google doesn't care. The browser has no problem with it. It's easier to code. Oh, but it's bad practice... how? I feel like we just listed what qualifies as good practice.

What is it called when following rules only leads to breaking rules? Hint: Sometimes it even leads to javascript.

CSS :)

That is not why you're not supposed to use tables for layout. It is for accessibility reasons. This is routinely ignored because approximately 0% of rich web apps are accessibility-friendly and people with screen readers have pretty much just learned to make do.

Wouldn't accessibility software back then have been able to deal with table based layout, considering most websites were constructed that way?

No, they weren't, at least not usefully. It was a major problem and made a lot of the internet unusable for vision-impaired people.

This is such an oversimplification. Since when did a table contribute to the richness of an application? Most modern sites are built with divs and remain inaccessible.

Tables simplify the code for simple content placement. That's it. It's only one of a long list of requirements to satisfy all sorts of requirements including screen reader compatibility. And if one were to use tables, it's only one of a long list of hacks and non-hacks that would break screen readers.

The root of the problem is with web designers not prioritizing accessibility-friendliness in their sites to begin with, for the basic reason that it prevents them from building the site that they need to build. And "what breaks or doesn't break accessibility" is not part of the spec description and is not enforced technically. We get recommendations, but it's up to us to test everything against everything else and compromise. Not just with accessibility but with everything else as well including backwards compatibility.

If you're a developer and someone decides to have a layout for the emails sent to customers, you probably still have to use tables.

I find that designers who create their own CSS are pretty rare. Most times I've seen frontend developers slice up designs. I think you need to have a workflow to do this properly. I needed someone to show me how to do it and I often preferred to just use an open source CSS lib like Bootstrap.

The problem is that most CSS properties are contextual. They'll work one way in a certain hierarchy, and a different way in another. I've had issues where items would suddenly appear in REVERSED order if I changed the width of the container object (which would be fine if there were a CSS property "component-alignment: reversed", but there isn't). There are no enforced types. You can assign any value to any property name, even though invalid names will do nothing (and so typos cause hours of lost time). Some properties won't do anything unless they're done in conjunction with other properties, but you have no way of knowing that because there's no debug feedback mechanism. Even worse: some properties do nothing unless the SURROUNDING object has certain properties set to certain values. That's INSANE.

There's very little logic, but much lore and arcane incantations to CSS, which is what makes it a bad system (much like the crotchety systems in the bad old UNIX engineer days of "if it was hard to write, it should be hard to understand").

I've worked with a number of UI systems, and the best ones are ALWAYS component based, where component properties ALWAYS behave the same way internally, and where you can COMBINE them into more powerful components. This is not what happens with CSS. Basic things like alignment, size, borders, padding, margins all behave in weird ways depending on the context, or the presence or absence of text, or rely on similar sounding but subtly different properties that only work in certain contexts and not others, with no debug information to tell you why it's not affecting anything. That's not cool. If someone were to invent a programming language that behaved this way today, they'd be laughed out of the room.

What you’re saying is ”I don’t understand what ’cascading’ means in CSS”

CSS has a fundamentally different cognitive kalkül. You can do things fast, but if you do not have a deeper understanding, it can get pretty frustrating. At least historically.

It is like asking a Python programmer to write Prolog. Anyone can write Prolog, but only if you are willing to learn. The difference is: Prolog is an optional choice for most, CSS is a must for certain applications..

Them: CSS is unintuitive.

You: Learning CSS is like taming a wild horse.

I think you are in agreement.

Okay, to balance out the analogies let's say regular programming is like building a skyscraper brick by brick ;)

The idea is that to some people, having total control and building something up piece by piece comes totally naturally, while understanding and then selectively guiding a thing that has a will of its own does not, even if in some since it's more "elegant"

Having worked with a variety of GUI frameworks on small projects for work (WPF, Windows Forms, Xamrin, Android, iOS), I think HTML and CSS are the best out there for easy of use. It definitely helps that it has so much history and documentation behind it, but if I could build my GUIs in standard HTML and CSS without being forced into Electron or something else and still have my choice for a backend language, I'd find building GUIs way more fun.

I have a feeling people like to hate on CSS because making GUIs is hard and tedious work in general and introducing bugs is way easier than fixing them.

And since many applications nowadays run in your browser, people end up having to use CSS, thus getting blamed for the general pain it is to make a good GUI. I have used native GUI kits like Tk and Qt and found myself fiddling just about as much as I would with CSS.

YMMV of course.

YMMV but, almost every single GUI framework outside the web has:

- virtual lists

- customizable controls (including selects)

- easy solutions for layouts of any complexity (CSS got flexbox in 2015, Qt had it in early 2000s)

- a plethora of complex components out of the box (and most complex controls are rather trivial to implement yourself): date pickers, modals and dialog boxes, tree views, splitters, you name it.

Yes, building GUIs is hard. But building GUIs on the web is approaching impossible. There's a reason why most GUI frameworks on the web only manage to implement the same paltry set of components: buttons, badges, inputs. Very rarely there's a date picker and a table. And... that's about it.

Agreed. CSS is a more of an artistic design task than a programming one. You have to have the mindset of a sculptor, meticulously chipping away, fiddling with tiny bits as the figure gradually takes shape.

Now that I think about it, I feel like this is what CSS Zen Garden was all about. You have to embrace the fact that you’re gonna sit there tweaking margins and experimenting with various incantations.

Reply on news.ycombinator.com