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