For those who think that you can simply build something “fluid” or “flexible,” it’s a lot harder than it seems. A lot of the industry jargon comes from print and the printing process; margins, padding, kerning, spacing, etc. There is no such thing as a fluid layout on a printing press (as far as I know :-). So we are stuck with a language to describe design based on a different era. Additionally, in the design phase you HAVE to select a layout/viewport for proofs and examples. Which in turn the client will expect to look exactly right on every surface. There is obviously room for client education and pushback but fluid designs seem like an afterthought in html/css where we are adding new features on top of html/css that are best used in a fixed width based system.
It largely refers to the complexity of the layout. HTML and CSS were made for styling pages of text with headings, images, perhaps a table here or there. But now people want to make application UIs with fluid layouts with them.
The problem is that, unlike Word vs. Publisher, we don't have a set medium that we're working toward (e.g. paper.) When CSS was created, it controlled and formatted all the things that browsers could present, which wasn't very darn much. Then we thought of more things for browsers to do, and had to make our CSS much more complicated to get the same effects.
To give an even older parallel, when HTML was created, it had formatting primitives that were just fine for the browsers that existed at the time. Then, as people wanted more from browsers, spacer gifs and other such aberrations were invented to allow us to achieve our complex ideals, until we invented CSS and things were simple again, for a time.
The point is, the web is an ever-changing medium. We create a language for easily expressing existing web designs, and then set our sights higher and bludgeon that design language into expressing new (and previously unachievable) designs—such as, say, multi-column text layout—until we create a new web design language and the process starts over. This isn't a problem with CSS; no matter what we create, it will never be enough. There's only so much you can do with ink on the boundaries of a page of paper; there'll never be a limit to new ways to lay out shapes and vectors in an infinitely scrollable, resizable, dynamic, animated and reactive space that can be variously interpreted by different clients.
That's not to say CSS isn't showing its age. It's just that this isn't shouldn't be considered a failing in the original design of CSS; rather, it should be seen as a sign of experience for web designers, that they now have newer, larger ideas that their smaller, brittler tools aren't up to expressing. Perhaps this is the best argument of all for separating content from presentation—if they're separate, we can replace CSS with something more robust (and then replace that with something even robust-er-er) without touching the content itself.
HTML is easy. CSS is hard. CSS is hard partly because it's a mess, but mostly because designing for the web is hard.
Normal human beings understand pages, in the papery sense of the word. They don't understand viewports. It takes an enormous leap of abstraction to reason about a document that could be any shape or size. Responsive design is a fundamentally unintuitive process. A lot of professional designers fail to understand this, even after years of designing for the web.
Am I alone in thinking that the way we're doing brochures as layering multiple complicated ad-hoc layout constraint languages on top of a markup language that itself hasn't much changed in 20 years is absurd? What is really gained by such a powerful, yet highly idiosyncratic construct that not only can insert and/or delete content elements, but also rearrange the order in which they were specified in the input document in the first place, weighed against the complexity this brings to authors and implementers? Is the HTML+CSS stack victim of self-imposed, arbitrary principles of separation of structure and presentation? I can see the practical use of grids and subgrids etc., but who really authors an HTML document with the expectation that it should render as a traditional hierarchical and flow-based layout, and a grid-based layout at the same time? Translated to the domain of programming languages, CSS is to HTML what eg. ten times the amount of LOCs of annotations are to regular Java code. Why not just use a responsive table layout based on revised HTML tables when, clearly, the author's intent is to layout page elements in a tabular fashion?
You're comparing a layout engine for print where the creator has control over all aspects of the presentation (font size, page size, etc.) with CSS where the content is displayed in an environment where the user is in control of many of those? Apples to Oranges. Pretty much all the things that are difficult to do in CSS have to do with this uncertainty and lack of control.
For example, centering in CSS is trivial if you're only doing it for one viewport size, font, font size.
> That sounds a lot like EPub, where you have html and CSS.
Eh, kinda. CSS requires the assistance of the HTML, though; HTML is "the boss" in the relationship, in that it gets to define where markup boundaries are, declare what CSS classes and identifiers apply to what elements, etc. So "I write the HTML, you lay it out with CSS" isn't really a valid pipelined workflow, if you expect to do anything fancy with your layout.
In GUI desktop-publishing programs, the layout document is "the boss." It's as if CSS could target its rules by byte-slices, rather than needing HTML to hand it ready-made selectors. You can take arbitrary bits and pieces of the linked source, style them how you please, and throw them onto parts of pages as you please.
Consider: in GUI desktop-publishing programs, a "pull quote" is not a second copy of the text in the source. It's just a second reference to the same text-slice of source-text, within the layout.
> Why all this work for a dying medium? Paper is on it's way out.
Layout/typesetting isn't just for books. Posters need layout. Billboards need layout. Business cards need layout. None of these are dying out in the least.
Heck, even for screen media, text within videos (e.g. title cards, ad copy, etc.) has static layout, and so benefits from layout/typesetting.
There will always be a place for tools that allow someone to efficiently describe (or hint) the best way to show text (on a screen, or on a page) for best readability — or best impact.
And even leaving aside the practical uses of text layout, I should note that kinetic typography is also an artform, done for its own sake—and one that often requires the assistance of a layout-constraint engine to achieve it. Do you think you can write something like House of Leaves purely using design tools like Adobe Illustrator? ;)
This may be off-topic, but progress with CSS (flowable text, etc.) is not only glacially slow, but we're still stuck with the terribly-designed CSS standard.
I find myself wishing for some kind of "layout bytecode" -- basically, machine-readable instructions which would size every element in a browser's page using custom layout algorithms that would depend on the size of the page and the size of font glyphs.
CSS would be compiled into this bytecode, but we'd be open to inventing new and better style languages which could be compiled as well. So we could create layout languages based on columns instead of floats, for example.
If this were actually implemented in newer browsers, it could actually be emulated in older browsers using JS libraries (although it would be much slower).
Note that this really only has to do with the layout properties of CSS. Things like color, rounded corners, drop shadows -- all that would still be implemented traditionally, but these aren't generally what people have problems with. It's the terrible layout algorithms of CSS which generate endless headaches.
As a classically trained graphic designer, I find the biggest problems to layout is more due to the fact that the display is completely unknown. It can range anywhere from hundreds of pixels in width/height to thousands of width/height in pixels. Not to mention the differences in pixel densities and orientations.
If one were to consider these problems alone, CSS works quite well for what it was designed to do. Most designers I've discussed these problems with have problems more in their thinking than with the tool itself. They mostly try to apply print design thinking to web design, which simply does not work.
It's not illogical, but it's not adapted to half the applications it's being used on. That's what's illogical about it. "Document flow", "writing mode", the language used in this post indicates what CSS is meant for, formatting documents on screens. Yet half of us try to beat it into submission building highly interactive applications.
While I get the sentiment, as someone who knows CSS and HTML5 well, I can't help but feel there are reasons why this can't work.
Aside my web involvement I did a lot of print design as well. For print wysiwyg is perfectly fine.
But how would you wysiwyg for a medium that is inherently multifaced? I mean your window could be small, or huge, portrait or landscape, it could have colors or not, heck it could even be print.
So you won't get what you see unless you replicate the exact conditions under which it was seen when tou made it. Do you want that thing that you scale to stay at fixed size, should it stay at fixed distances to the viewport borders? If yes which ones? What happens if users set their font sizes differently and your perfectly scaled text box overflows? Either that wysiwyg editor has very opinionated choices that won't work for half of the people, or it will have auch a complexity in its options you will be better off with learning css in the first place.
Web is not print, nobody will get what you see.
That being said, if you are really just about content, I would just use the most basic default browser css (so basically none) and html and call it a day. That won't look shiny, but if people want shiny they can do their own styling. Some of my favourite blogs do this.
Other than that I wouldn't discount the fact that a backend can be a crucial part of the content as well as it allows you to do valuable things that are geared towards the consumption of said content, e.g. taxonomy (tags, categories, authors, consistent dates), but also more specialized things like linking between relevant topics, etc.
Of course you could also do that by hand, but then you wouldn't be focusing on the content, wouldn't you?
In the end it is your content and you want to present it in a certain way. If you want precise control over the how, you have to deal with these things — if it ia just about the content, use whatever CMS you like and never look back.
I'm not sure what your point is. Web standards have had a turbulent history? Of course that's true.
- CSS 2 was originally published as a recommendation in 1998. CSS 2.1 was pushed as a recommendation in 2011. Maybe something was wrong?
- "Ignored by vendors" is a bit of an understatement, because your "close to 20 years" includes 5 years of the vendor with 90% marketshare not releasing anything at all.
- FWIW, what became flexbox was useable (assuming polyfills aplenty) in Firefox and Webkit browsers 5 years ago[1]. It took some time to standardize, but while frustrating in the present, it's ok to take time to make sure the spec works, because it will be (in theory) around for quite a while.
> It makes it 'easy' by introducing yet another weird box modelism that doesn't really fit anything else that's already there
What many people don't appreciate about layout in general (and WRT to the web, dynamic layout in particular), is that it turns out to be difficult (and sometimes extremely computationally expensive) to implement an expressive layout system that does what we intuitively think it should. A good example is word wrapping, which is easy to tell when it "looks right" (at least to a trained eye), was done by hand by many when printing was done more manually, but turns out to be difficult to assign a metric that handles all use cases, especially when you're trying to be computationally efficient.
Web layout is like a whole set of word wrapping requirements, expected to get along and paint a page in real time. The process that birthed CSS is nowhere near what you'd turn to if you wanted to develop a cohesive styling whole, but it's how history usually plays out. If it's any consolation, I personally don't think there's a comprehensive theory of everything for styling anyways, so there are always going to be aspects that need to be learned, not inferred.
In any case, flexbox is pretty straightforward if you spend an afternoon with it, just a constraint-based layout system that maps pretty well to how you would describe a layout like that.
First, I agree wholeheartedly that the language we use is never powerful enough for us to express ourselves. I'd say that even goes for print... but whatever.
I spent a few hours reading old RFC's because of this whole thread.
It looks to me like rfc 1942 got popular, and the CSS folks never came to grips with that. CSS1 is pretty given the constraints of the day. I think about CSS in two terms (I don't think there's a standard for this, i just made them up) Formatting, setting fonts, colors and padding; and layout, i think old newspaper guys would call it paste up, where the big blocks go on the page.
They must have known, and i don't think they had a credible solution to layout problems. they weren't willing to make a full layout language, so tables won.
HTML and CSS often feel like they are poor fits for the purposes we put them to.
HTML works well enough for its purpose, but its SGML heritage makes it awkward to read and write; it is implemented inconsistently and sometimes clumsily, with countless edge cases where each browser pivots a different way; and it changes far too slowly to live up to our demands.
CSS is worse: it is simply unsuited for layout. Don’t believe me? Without looking anything up, design a three-column layout where all columns have equal height even when their contents are unequal. There’s a reason this layout was called “The Holy Grail”.
I used Flex for several years, before returning to Javascript at Paperless Post, and I have to say that Flex may have been huge, may have been overengineered, may have been Flash (an unforgivable sin indeed), but it was also consistent, layered, and open. Open in the sense of open source, but also in the sense this article demands: you could subclass or monkey patch everything in the system. You could make your components do anything you want, while keeping everything that was good about the superclass.
It isn't baffling that "open web" technologies lack this kind of programmer-facing openness. That's a result of the browser wars, the underlying implementation, the original design concerns, the limitations of the early internet, and umpteen other factors both human and technological.
But our systems _should_ become open and layered, or else Javascript polyfills and libraries will be the new platform, and HTML and CSS will simply be the uneven ground upon which that level platform was built. This is very nearly the case already. It's not a future that appeals, but maybe it's what we'll have to learn to expect.
It amazes me a little, and says something about Håkon's perspective, that all of his examples are newspaper pages.
This looks like the makings of a high quality spec from 2004. Granted, CSS should natively support responsive columns, but it's a solved problem. Does he really think that Figure support is what limits web from competing with native? The problem with presentation of web apps has always been that we use a language designed for describing newspaper layouts to structure a dynamic, morphing interface. And its creator wants more succinct descriptors for recreating the above-the-fold of the New York times at variable widths.
It's almost saddening when the creator of something is no longer the guy driving it forward.
I don’t think you need even that to have a reasonable compact layout system. There might be an opportunity here for a kind of subset of css that covers all modern needs, documented, and with a linter to enforce it.
The font styling and padding stuff aren't really the meat and butter (edit: sorry, bread and butter... English isn't my first language) though. They're the kind of stuff you learn on day 1, then from day 2 to day 1000+ everything else remains hard.
"Layout can be tricky" is a... slight understatement? These days almost all web layout is handled through CSS, which means multiple layers of flex and grid, yes, along with axes and media queries and unit scales, pseudo classes, inheritance and priority, animations, transitions, gradients, shorthands, variables... and all of that is before adding in frameworks like Bootstrap or transpilers like Sass or abstractions like tailwind and other newcomers.
Remember how many years it took major browser vendors to reach a decent score on the ACID tests? (https://www.acidtests.org/) That was before flexbox and it was already insanely difficult to properly render CSS. It's gotten orders of magnitude more complex since then.
Cross browser issues are more of an issue than ever, since nobody uses CSS alone anymore there's different permutations of layout engines, permissions, web APIs, JS features, etc.
It's... just not simpler. You used to be able to learn nearly all of CSS in a week or so. Then over the last decade or so, I've been unable to even discover new features, much less keep up with them. Granted I'm getting old too, but man, it's really not a simple language.
Markdown is somewhat simple, but even writing a parser for that is hard. CSS and the DOM are waaaaaay complex. There's a reason there's only like three actual parsers for them (Blink, Webkit, Gecko).
reply