Hell Yes CSS
wizardzines.com
wizardzines.com
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.
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..
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.
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.
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 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 thought this was a myth on level of teenagers eating tide pods.
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
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.
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 :)
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.
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.
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.
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.
So this part of the spec was specifically developed for GUI's rather than documents.
- 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.
Where can I read about this - has someone written "CSS: the good parts", for example?
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.
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.
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...
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
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.
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.
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.
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.
You: Learning CSS is like taming a wild horse.
I think you are in agreement.
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"
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.
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.
- 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.
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.
* CSS isn't easy: https://wizardzines.com/comics/css-isnt-easy
* Inline vs block: https://wizardzines.com/comics/inline-vs-block/
* Specificity: https://wizardzines.com/comics/css-specificity/
* Centering: https://wizardzines.com/comics/css-centering/
* Hiding elements: https://wizardzines.com/comics/css-hiding/
* The box model: https://wizardzines.com/comics/box-model/
I also put together a site with a few examples of CSS behaviour I find surprising here: https://css-examples.wizardzines.com/
PS Separately, if you ever felt like it, it would be lovely to have a poster (or similar short thing in your style) about CSS Selectors specifically, to give to our customers. (To use our stuff, it's good to know about selectors but don't need to know about styling/positioning and such.)
- browser incompatibilities (Last bug I fought: top/left/right/bottom behave differently in Chrome vs. Firefox when `position: sticky`. Fantastic.)
- messy refactorings: Sure, CSS3 variables are nice but you can still tell that they were bolted onto the language. Moreover, elements and their rules can interact in lots of ways and CSS code (especially code by other people haha) often doesn't make these interactions immediately clear. Besides, everything is global state and IDs and classes are the only way modularize CSS code.
- the fact that it's impossible to use HTML only for semantics and do all the layouting in CSS. (Wrapper divs, I'm looking at you!)
- weird precedence of CSS rules / specificity (https://developer.mozilla.org/en-US/docs/Web/CSS/Specificity)
- missing type separation and missing type checks. All CSS properties live in the same namespace and may or may not interact with one another. For instance, top/left/bottom/right, margin etc. behave completely differently depending on what you set `position` and `display` to.
Things are getting better with web components now but I'm still not sure I'll ever be entirely happy with CSS.
I’d like to fix that, and learn CSS well. I’m not looking for a quick zine like this, more of an in-depth course, say roughly 5-10 hrs. Ideally free, but I’d pay if it’s good. Anyone have any favourites?
Learn the basics of CSS first. Even after then, it is hard to recommend this Every-Layout approach.
Can I achieve the same without those "algorithmic aspects"?
What do you mean by that? calc()?
It's called "How To Debug CSS"[1], if you go through my post history, you'll get a good idea of the backstory behind it.
Essentially, what I'm trying to do is help developers like you (who are like me, or at least how I was), in that I knew CSS for a long time, but never really felt like I 'got it', in the same way that I 'got' many of the other aspects of web development.
I've now gotten to a point where this is almost the complete opposite. I now feel like I have gained a certain level of mastery over CSS. And most of it had to do with a simple change of perspective.
Here's an article I wrote as sort of a subset of the book, that covers a lot more about how you can truly start to get better at CSS, as a developer: https://planflow.dev/blog/how-to-get-better-at-css.
[1] - https://gumroad.com/l/Debbg/z823cp8 (I've added a pre-order discount code to the book for those interested).
Despite the recent improvements to CSS, I agree that it is quite horrible to work with.
IE9 was probably the first version of IE with decent CSS (read ”display: table” which wasn’t broken); all of the other browsers (which didn’t have IE9’s market share at the time) had already added “display: table” support.
Before “display: table” was widely supported, people would either mix CSS with a <table> layout, or have a fixed width (usually) single column design.
Now, I think what helps me is that I've had 20 years to learn it as changes appeared.
If I had to learn it all in one go now, how confused would I be? Very? Lots?
It could be that a good way to learn CSS would be to try and replicate that experience and learn the history of it, not just the current state.
CSS has endless ways of writing and representing the same thing which actually makes things harder, not easier in my opinion.
.my-container {
display: flex;
justify-content: center;
align-items: center;
}
.my-video {
--my-video-height: 120px;
height: var(--my-video-height);
width: calc(var(--my-video-height) * 16/9);
}These things are getting better. CSS was a nightmare in the 2000s.
So for instance I would do the responsive page layout in grid, probably. Then I would do positioning the elements within a article or section with flexbox.
.centered { display: flex; justify-content: center; align-items: center; }
Indeed there are two (at least) more ways to both horizontally and vertically center something (using CSS Grid and the good old translate(-50%, -50%)) and with flex I always have a hard time remembering if it is justify-items or justify-content..
<style>
.foo {
display: table;
margin-left: auto;
margin-right: auto; }
</style>
<div class=foo>
<h1>Hello, world!</h1>
</div>
<style>
.foo {
/* display: table; DISABLED */
margin-left: auto;
margin-right: auto; }
</style>
<div class=foo>
<h1>Hello, world!</h1>
</div>
<style>
.all {
display: table;
margin-left: auto;
margin-right: auto;
}
.sub {
display: table-row;
}
.left {
display: table-cell;
}
.right {
display: table-cell;
}
</style>
<div class=all>
<div class=sub>
<div class=left>
<h1>Hello, world!</h1>
Left side.
</div>
<div class=right>
<h1>Right bar</h1>
Right side.
</div>
</div>
</div>
But then again if you look at the origin of CSS, it all makes sense. CSS was never developed to be used for app-like interfaces. At it's inception, it was intended as a style sheet for documents (specifically scientific documents). The original idea was that everybody would have their own CSS which they could then apply to HTML locally. Interestingly, 30 years later, HTML and CSS are used for almost anything but scientific documents and nobody uses a personal style sheet.
The technology is really not well suited for the cases it is most often used for today and there is a superb blog post on the topic that has featured several times on HN:
The Blog Post: https://eager.io/blog/the-languages-which-almost-were-css/
HN 4 years ago: https://news.ycombinator.com/item?id=11994405
HN only 4 months ago: https://news.ycombinator.com/item?id=24118151
For the newbies, back in the CSS 1 days, the intention was to create separate styling rules to make maintaining or changing styles easier. If you ever had to style HTML before CSS by wrapping each and every any colour or font change in HTML elements or embedding background colour attributes inside each table cell, you'll understand the pain it was addressing. The CSS 1 spec was relatively small and easy to understand - although pretty limited.
I first seriously tried to make that work in the IE4 days. IE4 was almost kinda OK at CSS1, but NN4.x was just awful. Opera was (not surprisingly) the best at CSS, but nobody used it.
The complex layout stuff came not log after in the much bigger CSS 2, but the nature of IE only badly implementing a fraction of it for a decade or more meant that most people just cargo culted IE work arounds and never really sat down to learn any of the principles. Not claiming they were great principles, just that there were some :)
I keep hearing that it has settled down, though, so I am looking forward to learning it properly next I need to do something interface-y.
I know I am not the target audience since I know CSS enough but I think that this is just a very short reference to some aspects of CSS that can't help you much?
I also quite enjoy her other writings, so it was also purchased to support her as well!
Why? Having it this way round is definitely less common than the other, but by no means is it rare, and there’s nothing at all wrong with it.
CSS doesn’t control how a page looks, it controls how the browser ”flows” a sequence of boxes and text onto the page one by one.
Block boxes are 100% wide, grow to fit their content, and stack vertically with other boxes.
Inline boxes grow to fit their content, and flow into the same rows with other inline content. They cannot have margins or paddings like block boxes.
Inline-block boxes flow with other inline content like inline boxes, but can be styled like block boxes.
Never have different types of boxes directly as siblings. Instead, create block wrappers for any inline content. This alone saves a lot of headache.
For example, it makes perfect sense for an empty inline-block to get aligned to the text baseline, while an inline-block with text also gets aligned to the text baseline. That is precisely what ”vertical-align: baseline” means: align this element’s line of text to the surrounding baseline. If the element doesn’t contain a text node, the inline-block does align correctly, but by default does not have a size unless explicitly specified.
And if there’s something in CSS that is to be avoided unless necessary, it’s specifying things explicitly.
Anyone who would take offense at that is going to find something to be offended by in anything ediger than Mr. Roger's Neighborhood.
Here in Australia, hell / damn aren't considered bad words. I think americans have a perception that australians swear a lot. We do - but also, a lot of what my american coworkers considered swearing doesn't register as swearing in my head.
Here in australia (at least how I was raised), "hell" is just a word.
Hell, sometimes it would be weird and just plain confusing not to say the word!
It's like those creative kids building super Mario-clones in Excel, It's certainly possible but it's still madness. But I guess those kids don't complain about Excel being a lousy game engine...
As it turns out, HTML wasn’t even originally a Word alternative. The original web, as envisioned by Tim Berners-Lee used something called “semantic” markup. For example, a HTML page would have <STRONG>, and it was up to the browser and end user whether <STRONG> was bold, italic, or in another color.
It was only in the late 1990s, during the Netscape-IE wars, that CSS was tacked on to HTML; that’s why CSS syntax looks nothing like HTML syntax. CSS changed the web from a world where <STRONG> could look any of a number of different ways in to a world where <STRONG> would be, say, Lora Serif 600 weight italic at 24point.
Javascript dynamically altering webpages to make applications was never the plan. It only ended up that way because Java applets on the web were effectively killed by Microsoft when Internet Explorer won the IE-Netscape wars, and no other plugin was widely available to fill the gap Java left. Flash was too proprietary and closed-source to take over the web, but it was huge for a while until Javascript finally caught up in the post-IE web of the 2010s.
Also because CSS is rule-based rather than hierarchical.
but yes, linking to non-free resources should be discouraged