I've just been watching a colleague learning HTML/CSS for the first time. HTML was easy and she has a very good handle on that, producing some nice HTML5 markup by hand very quickly. CSS has been a nightmare - mostly not because of selectors or values (that comes later), but because of basic layout issues caused by the nasty hacky layout model of CSS - in particular the concepts of floats, block and inline and unpredictable element sizes due to the box model.
But I disagree that CSS should thus become a general purpose programming language - the separation of concerns in HTML into content/style/controller is very useful and would be terrible to throw away, just because our current styling language is so lacking.
The problem with CSS is layout - properties, selectors and values could do with some work of course, but they're mostly passable if a bit underpowered. Layout is insane and it's down to assumptions made at the creation of CSS - a very simplistic doc model assuming some basic structure of heads, text and a few pics flowing in a linear fashion down a page - like a technical paper or simple book layout. Flexbox looks equally unintuitive if a bit more powerful.
It is a hard problem, but there has to be a better way than the current agglomeration of hacks upon hacks - something akin to the HTML5 movement for styling - remove or deprecate most of the overcomplex spec and refine what is actually in use. Grids are key here - they've been used in graphic design for centuries, and they are a fundamental part of organising information which is entirely missing from the CSS spec and should be the basis of layout, not an afterthought.
Indeed CSS is broken. But, if you tried to make that case several years ago during the Great War on Table-based Layout, you'd have been absolutely persecuted. Oh how we wrangled with the utter pain that is CSS layout, only to appease the tableless zealots. I can remember wrestling for hours with simple layouts that just wouldn't cooperate cross-browser. Meanwhile, I could achieve those layouts in mere minutes with tables. Not only that, the resulting table-based design HTML was an intuitive read.
The reason was as you say: Grids are key.
How many people would now honestly say that we are better off for CSS-layout vs. tables? But, it's amazing how an entire industry lurched in one direction so quickly, based on ideology. The pressure to use the "right" approach was immense. The whole thing had a very "Emperor's New Clothes" feel to it. Everybody seemed to agree that CSS layout was completely awesome, while I beat my head against the wall trying to make it work. Now, we all see that so many were actually suffering in silence.
>the separation of concerns in HTML into content/style/controller is very useful
This is a belief that I question to some extent and I've wondered whether it's a core assumption that sounds great and thus goes unchallenged, but fails to make the cut in the practical world. In particular, how much do we really need to separate content from layout? Styling is one thing, but layout tends to be intrinsically tied to the content. You can change the appearance of content without modifying its meaning, but changing its organization or layout can render it absolute nonsense. Thus, if CSS were all about colors, fonts, etc., it would actually be a somewhat reasonable approach to separating reasonably separable concerns.
But, as most now agree, it's CSS's horrible attempt at managing layout that makes it so painfully bad. And, I really wonder if the core problem is just that there's no real benefit to trying to separate layout (vs simply style) from content in the first place. What we're really saying in attempting to do so is that we want to be able to create a document wherein we have a bunch of unstructured content that we want to insert in an essentially random fashion, then create a second document that rearranges the content.
It's an unnecessary abstraction that seldom provides an ROI. How often do we later want the content to stay exactly the same, but simply want to change where it appears on the page? And, if we do, is it really easier to change the layout in an external document (CSS or otherwise) than it is to modify the document?
I have yet to hear a proposal that makes more sense than the old-table based design. The purists said that tables are strictly for presenting tabular data. Fine. So, let's create a new tag called "grid" for layout and give it the same layout flexibility as the tables of old.
Styling is one thing, but layout tends to be intrinsically tied to the content.
This is an interesting distinction - thanks. As you say there are issues with separating layout and content, because the two can be hard to separate effectively. I think it is worth the effort though, and sometimes pays off (for example reflowing content for a mobile device). An interesting thought though that we should separate style and content, not layout and content.
As to tables, I think there were two issues mixed up in that religious war - the nasty markup of table/tr/rd, sliced images etc polluting every website when it was intended for data, and grid layouts (which it made easier). Unfortunately grid layouts were thrown on to the auto-de-fé along with sliced images and table markup, and then promptly reinvented (with much pain) by entire frameworks designed to make up for the shortcomings of CSS.
There have been very recent attempts to add grids to CSS, and hopefully they'll come to something (see link above from buovjaga) - I do think they're far more intuitive and most importantly impose a sensible structure on people attempting to lay out information.
Untying styling from layout is what OOCSS does. All styling is written only with classes. This makes it easy to reuse styles. All other selectors, especially nested, are avoided, since they rely on a certain layout and can't be reused.
Good points. I think that responsive design is probably one of the biggest use cases for CSS layouts these days, though I don't know that it was a driving force or even a consideration when The Great Tableless War began. In any case, I'm not quite a believer in responsive design either. The short is that, as commonly practiced, responsive design fails to acknowledge the relationship between content and layout. I posted a lengthy comment on this thread with more on that, so I'll spare HN's bandwidth the duplication.
Image slicing was indeed nasty and I don't think it was as much a function of table-based layout as an implementation choice. Some tools were particularly nasty with this, but they were less famously also capable of outputting equally nasty CSS/div based code. So, good handcoding is really required to achieve any semblance of maintainable design, whether CSS or table-based.
But, I think you nailed the history. And, it just happened that table capabilities were remarkably useful for laying out a page. Had this been intentional vs a byproduct of that tag's function, the outcome may have been different. One could literally rename "table" to "grid", "tr" to "row", and "td" to "col" and be most of the way there. Would a separate tag of this ilk that could be additionally styled with CSS have silenced the tableless zealots? We may never know. But, if so, it's amazing to think that all of this upheaval, pain, and lost hours was the result of such simple puritanical ideology.
Such an HTML tag vs. pure CSS construct would have also pointed to the already blurred lines between HTML's suggested role as merely a data container vs. its unavoidable role in presentation. The theory that HTML represents only data still manages to sell itself when we are talking say, paragraph and list elements. This is so, in spite of the fact that, like "real" tables, even those elements are themselves completely loaded with implicit layout information.
We need to embrace the fact that a paragraph tag implies that this element will need to be offset and, yes, the details can be found in the CSS. But, when reading/writing the code, the order and structure are intuitive. We don't randomly spit out a group of paragraphs, then impose the ordering via a stylesheet. Instead, we expect the order to be as it exists in the document. Same with lists and other elements. Likewise, the fact that the structure of the document has implications on its layout even leaks through when using CSS. For instance, assigning a value of absolute to the position attribute of an element, positions it relative to its ancestor in the document structure.
But, it's when "pure" layout is involved that things become murkier. We suddenly want to disavow that the natural layout clues are already there and instead force this unnatural separation into CSS. The problem is that much like with tabular data or a series of paragraphs, all content on a page has a relationship to other content that is best expressed in a natural grid like structure. It's not just visual, but actually semantic. So, it is natural to express this relationship in the markup and leave the styling details to CSS. Perhaps more importantly, it is unnatural to spit a bunch of related content into a document in a completely unstructured fashion, then impose structure in a separate document.
So, let's not repeat the ideological mistakes of the last Great War. Ask your Congressperson to keep the grid element out of CSS (except for styling) and add it to HTML where it belongs! :)
"Not only that, the resulting table-based design HTML was an intuitive read."
Wow, Stockholm syndrome can be really messy.
It's likely possible to produce readable table-based design, but the tools at the time most assuredly did NOT produce that. Nothing sucks like spending a couple hours figuring out which of the eleventy-billion inline-styled cells Dreamweaver has bumped to 2px too wide, shattering an entire image-sliced layout.
If you're talking Dreamweaver, auto-generated inline styles, and image slicing, I think it's safe to say that you're signing up for pain irrespective of what the output is.
Still, finding a 2px misalignment would likely be a more masochistic exercise if you were wading through nested divs with no clear grid layout vs. nested tables.
But, I think your complaint is with the tool itself. Maybe that's why I sincerely know of no web devs who have implemented a serious project with Dreamweaver. My personal (brief) experience with it was that any support for real separation of concerns was so lacking that whether it generated tables vs. CSS was the least of my worries.
The root of the problem has little to do with either technology: it's related to the desire to cart application chrome around with documents, using a technology that was designed to render documents -- and documents only.
At a fundamental level, what's missing is the ability to add a link rel=chrome tag in a document's header, such that you'd only sends a header with a title, that link rel=chrome tag, and its contents within the body. The header, footer, navigation items, etc. should all be defined outside of the document itself, as part of the chrome.
Put another way, a level of abstraction is still missing in the web developer's toolkit. Over the years, we've been compensating by:
1. mixing chrome and content together in html documents
2. sending boat loads of chrome-related styles alongside
Add to this that a great many web developers received little to no education in computer science, and it's no wonder that web development is such a mess.
>a level of abstraction is still missing in the web developer's toolkit.
As CS people we kind of intuitively feel this, but I'm not sure we really are missing anything, because, basically, HTML is already at the presentation layer. Remember when the proposed solution was to use XSLT to transform XML into HTML? Terrible as that was, the motivation behind it was a nod to the fact that XML is data and HTML is presentation.
So, I also wouldn't agree that mixing chrome and content together in HTML documents was a compensation as much as simply using HTML for its purpose. The content actually starts elsewhere (XML,database, etc.). It ends up in HTML for the very purpose of presentation.
There are ways to separate out chrome and modularize it that can use pure HTML. That makes sense. But, I don't think we really need another tech, language, or abstraction.
Now, we have added CSS to further abstract and LESS on top if that for still more abstraction. It can go on ad infinitum, but at some point, we are losing value with each additional abstraction.
The chrome (nav, footer, etc.) that you mentioned is one part of the equation, but the other part is styling/layout of the content itself. That is, within a page that features chrome, there is still the need to layout other elements of the page.
So, CSS fails miserably at the latter. And, ironically, the former (i.e. chrome) can largely be handled very cleanly via other means (e.g. a templating system that modularizes the chrome and content elements).
In any event, what you're saying is true to a large extent. It is not ideal to cart around data with presentation, so it is tempting to impose some degree of additional separation by some technology.
But, the challenge is that it doesn't tend to match the real world. That is, the idea that there are or should be these agnostic HTML documents lying around filled with, effectively, unstructured data is more myth than anything. The unstructured data is in the database or elsewhere. What you're generally doing is taking all of that raw content and presenting it. That's how it ends up in HTML. And, the truth is that HTML is really a presentation language more than a document/data language. If you want the latter, then you'd move up a level to "pure" XML. But, the same problem exists: now you really do have raw content akin to DB data, so how do you now impose a visual layout on that data?
So, here, I would argue that the separation has largely occurred before you get to HTML, thus it is OK to use HTML's more intuitive layout capabilities to layout the document.
Attempting to instead remove it from the HTML is simply adding an abstraction. And, honestly, we haven't decoupled anything. We've just moved it to an interdependent, less intuitive document that must now be carted around too.
So, while CSS is onerous for layout, I think the motivation behind relocating layout responsibility must also be scrutinized. Even if a less onerous CSS replacement existed, the cost of separation must really be weighed against what is actually being gained.
I think part of the story was that people wanted to write cross-browser code and that limited your tools to the bits of CSS that IE supported at the time. I doubt any system you could design, even tables, would be considered anything less than broken when a majority of the market was indifferent or actively hostile to it.
Even today I regularly think "I wish I could just use X", then I remember that my current project is targetting IE9+ and that means often I can. It gives me that same warm glow you get when you remove shoes that are too tight or stop banging your head against a brick wall.
I tend to agree with how using table to do layout got vilified for often very little reason. On the other hand, when dealing with responsive sites, or wanting to switch layouts in javascript for a reason or another, using css is the only sane way.
Hopefully, css tables are very usable, and playing with them is nice and smooth most of the time. Being able to cleanly redeine grids of content on the fly is one of the big advances that css brought to the table I think.
I am probably an outlier in my views on responsive design, but I'm not really sold on it either. Part of the reason is that, again, I think content is more tied to layout than people acknowledge. Also, I haven't really seen a compelling implementation of responsive design.
Most of the time, I see responsive sites hiding the site nav into a pull down menu and smashing, say, a three column layout into a single column. There are also responsive sites that outright selectively hide some content on some devices.
Hiding content implies that either the content isn't that important in the first place or that a diminished experience will be delivered to a particular device. Neither of these seems desirable.
Likewise, smashing a multi-column layout into a single column is also frequently a suboptimal user experience. In these scenarios, at least one column is usually more akin to nav, which means the user must now scroll past an entire column of nav to get to content or vice-versa. In effect, the layout change has altered the meaning of the content.
So, in general, to really deliver an optimal experience per device (if device specificity is even truly required in the first place), I believe it's worthwhile to consider different sites per device. Responsive design is a compromise that tempts devs into a "reuse" approach but, in truth, neither the required CSS nor the resulting output are optimal. So, the user experience suffers and the code isn't a lot of fun to write or maintain.
In other words, the more you want to thoughtfully vary the layout per device versus, say, just cramming everything into a single column, the more CSS you'll have to write. At some point, the volume and hackiness begs for a separate-site solution. To avoid this, responsive design just sacrifices the user experience instead.
The last part of this is that responsive design feels like a kludge aimed at solving a transient problem that is increasingly being solved by better hardware and interface design at the device/browser level. For instance, bigger and more readable displays on mobile devices, combined with pinching plus auto-zoom and auto-sizing by mobile browsers means that full desktop sites are generally very presentable on mobiles now.
In that regard, responsive design feels like WAP did years ago. Smartphones with full browsers, increased bandwidth, etc. killed the need for WAP in short order. IMO, responsive design will ultimately go the same route and has already to some extent. I, for one, already request the desktop site on all of my devices and much prefer the experience.
> But I disagree that CSS should thus become a general purpose programming language - the separation of concerns in HTML into content/style/controller is very useful and would be terrible to throw away, just because our current styling language is so lacking.
Separation of concerns or technology? For example if you use React.js you have view-controller, therefore why do I need CSS in an external file? I don't, it's there only because can't be into the React.js view. I would prefer to have the styles right in the view. The colors and this stuff might be per template basis which can be changed with js.
If they still want to continue with CSS they should really make some stuff like in javascript "use strict" which works a lot as expected. No more margin:0 auto to center no more of that unintuitive rules and specifications that varies so much.
Even responsive design only cares about window width, this is not enough to design a responsive website/app. Now are preparing something that is relative to a parent, which is even more useful, but not yet working.
This could be solved with a proper javascript layout engine: like qooxdoo for example which has layouts like in flex; I don't say this is a good or bad framework but for me was just to invasive and rigid. I come back to css+react.js but no html, I also don't thing that you should think of UI based on html terms but on component terms like react.js.
I've just been watching a colleague learning HTML/CSS for the first time. HTML was easy and she has a very good handle on that, producing some nice HTML5 markup by hand very quickly. CSS has been a nightmare - mostly not because of selectors or values (that comes later), but because of basic layout issues caused by the nasty hacky layout model of CSS - in particular the concepts of floats, block and inline and unpredictable element sizes due to the box model.
But I disagree that CSS should thus become a general purpose programming language - the separation of concerns in HTML into content/style/controller is very useful and would be terrible to throw away, just because our current styling language is so lacking.
The problem with CSS is layout - properties, selectors and values could do with some work of course, but they're mostly passable if a bit underpowered. Layout is insane and it's down to assumptions made at the creation of CSS - a very simplistic doc model assuming some basic structure of heads, text and a few pics flowing in a linear fashion down a page - like a technical paper or simple book layout. Flexbox looks equally unintuitive if a bit more powerful.
It is a hard problem, but there has to be a better way than the current agglomeration of hacks upon hacks - something akin to the HTML5 movement for styling - remove or deprecate most of the overcomplex spec and refine what is actually in use. Grids are key here - they've been used in graphic design for centuries, and they are a fundamental part of organising information which is entirely missing from the CSS spec and should be the basis of layout, not an afterthought.