<table height=100% width=100%><td valign=center align=center>
And what the hell does "margin: auto" mean? I'd like to hear some print designers using that in normal conversation. "oh and also i'd like these margin's auto'ed".
At this rate the table tag is going live longer than the copyright on mickey mouse.
It means "calculate the margins automatically according to available space". Nothing complicated about that.
Print is quite different from web. The most noticeable difference is that paper cannot be resized, nor does it adapt it's content when you rotate it.
position: absolute; top: 50%; left: 50%;
I'm not a fan of CSS due to issues like this. It falls in the same line as issues where, for example, paddings and margins (and borders) are added to the size of your div rather than subtracted. There's a solution for that that makes sense nowadays but by the time that came about, I'd already stopped liking CSS.
.. 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.
<div style="display:list-type; type-of-list:unordered"> <div style="display:list-item;">
?
What are you trying to say?
The phrase you were looking for is " I don't understand what you're saying."
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.
The primary problem with layout tables was that they involved tightly coupled inlining of your layout rules.
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. :)
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.
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.
Grid based layouts are obviously useful but the table tag isn't the right tool.
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.
Not really. CSS grid systems (like in Bootstrap) require some ugly and non-semantic markup, but they're not very complex.
[0]: https://www.ostraining.com/blog/coding/bootstrap-right-way/
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.
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.
Which is completely not like using CSS at all, right?
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.
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!
<table sortable >...</table>
Author email in straight text? Markdown is what you're writing already.
Author it in WYSYWIG/GUI clients? You only care about presentation.
They look for the div with the most text/paragraphs in it and assume that's the article. At least, that's what the open source ones I looked at a while back do -- the proprietary ones that force you to go through their own server could use other tricks.
The stakes are much lower for Readability-esque algorithms, when they fuck up the user can just go back to the site's native presentation; screenreader users don't have that choice.