.. But then we've ended up with bootstrap and it's grid layout, where we're doing exactly that, and for some reason it's perfectly fine.
Regardless of how you feel about CSS 2.1, it's indisputably better than the table-based layout we had before. Speaking as someone who has implemented both table-based layout and CSS 2.1, it's really unfortunate to see people want to return to the bad old world.
Completely disagree. The Unix philosophy is right when it comes to layout: you want to be simple, fast, and predictable.
This attitude is also why we are in a situation where the Web is slow compared to native platforms. Simple things tend to be fast things. Complex things tend to be slow things.
Your implications that table layout can be "well defined" or "heavily optimized" are both false. The problem is that table layout is ill-defined: it's really a pile of hacks upon hacks that were invented at Netscape a long time ago and still not standardized or consistent between browsers. And, speaking as someone who optimizes layout engines for a living, complexity is the #1 enemy of "heavy optimization". Spec complexity is the #1 reason why layout is so slow, because it makes layout engines large, complex, and brittle.
You can always increase complexity. For instance, by doing all math in Roman Numerals. Thus, in at least some cases you can decrease it. So your statement doesn't hold.
I think you were referring to something like inherent complexity, but then you would have to somehow prove that all this complexity is inherent.
Not really. CSS grid systems (like in Bootstrap) require some ugly and non-semantic markup, but they're not very complex.
If you write your styles in the same preprocessor as the Bootstrap package you chose (Less by default, but optionally Sass), you can mix Bootstraps grid classes into your own semantically meaningful classes, and drop all the col-xs stuff from your markup. Your markup elements can have class names that are purely semenatic. Almost every modern grid system offers preprocessor mixins that can be used in this way.
There are methodologies like BEM that are great for providing a semantically meaningful layer of classes in your markup.
It's true that the complexity remains and is shifted. The important part is that it's no longer interlaced with the complexity that describes the fine-scale structure of the page.
There have been some huge deficiencies in CSS over the years. It is frustrating to have to use complex sets of counterintuitive rules to achieve seemingly simple effects. But there are techniques for helping to manage it in modern web development.
Which is completely not like using CSS at all, right?
This. And the confusion around those two goals is what drives a lot of useless arguments with people who have Stockholm syndrome towards HTML and CSS. Those arguments can often be summarized like this:
- Hey, we're complicating things too much, how about just focusing on rendering a text communicating a message?
- No no no, the web is not just about documents, it's so much more now! It's about applications.
- Ok then, so let's drop the nonsense about separation of concerns, that you can have layouts separate from content.
- No no no, HTML is for describing documents, and CSS is for describing its layout!
The primary problem with layout tables was that they involved tightly coupled inlining of your layout rules.
Honestly sure you need js for most interactions and animations still, but layout? I wouldn't merge any pr that uses js for layout. Including fully responsive layouts.
A failure of function availability from turning off images or CSS is a failure of developers, not a failure of the platform or user agent. You can find sites even in 2015 that either straight up work or degrade gracefully when being browsed by Lynx (a browser that I don't think has seen even a dot-release update since 1999) because they were put together by thoughtful professionals who understand the platform.
If you're trying to deliver an application that absolutely requires client side computation or specific browser APIs, you can have a pass for choosing the have your site not work without JS.
If your site really is just a series of documents (either static or dynamically computed), though, there really isn't much of an excuse.
In cases like this, wouldn't it make more sense to have that information available in an API? Once you've removed all styling and interaction, it seems like something that would work better as simply sending raw data, and letting the client decide what to do with it.
Schema.org is a good example of how this would work with the modern web. Markup relevant data (eg. product ratings, movie times) and let the clients render it as desired. You can still provide CSS/JS for modern browsers.
Seems a lot more elegant to me than designing pages to gracefully fallback when JS/CSS is missing, as that would seriously restrict design.
The crucial question is probably what's considered "raw" -- or perhaps to talk more in terms of web-related philosophy, which media type you'd expect most user agents to be able to handle by default... and despite the (reasonable) popularity of JSON, the answer is pretty much HTML with some kind of microformat information embedded via attributes.
In other words, the schema.org approach is arguably pretty much what you're supposed to do in order to design pages to gracefully fall back. I'm not sure why you might think those two concepts are at odds. :)
Seriously, I don't know what's more broken - CSS itself or the web developer community, with the amount of self-deception, cargo-culting and stockholm syndrome cases present there.
The whole web is fad-driven, so I'm glad at some point, pendulum will swing back.
Meanwhile, I'm just happy parallax fad is dying out.
<table sortable >...</table>
Grid based layouts are obviously useful but the table tag isn't the right tool.
<div style="display:list-type; type-of-list:unordered">
Of course, the issue would probably come up rarely, since the browser stylesheets for those tags don't do anything particularly useful for anything other than lists and list items.
What are you trying to say?
The phrase you were looking for is " I don't understand what you're saying."