<body background="animals.jpg">
<center>
<body background="animals.jpg">
<center>
Like compare that mess to the elegant semantic structure of a state of the art webpage like google.com
<div class="gb_Ld"><div class="gb_Xc"><div class="gb_k gb_Fd gb_z" data-ogsr-fb="true" data-ogsr-alt="" id="gbwa"><div class="gb_f">> Open up wide! Here comes some 'content'! Quit complaining, you can handle it!
Not that tables were perfectly standardized or anything, because I do remember Netscape and IE not totally agreeing on how to handle column widths, but they sure were, well, simpler.
If the comments were properly nested you would just have a standard left margin and the tables would be completely unnecessary.
The Web is a ton worse because we decided to build apps on it but never built the tools to do it right, even though the building blocks were right there.
I think I would've rather seen it go that direction, but it's hard to say. Without a crystal ball, we can't really compare the outcomes, and it's hard to imagine what would've happened in this hypothetical. I mean, I don't think in 2004 I would've been able to guess (or stomach) what the web was going to become 20 years down the road.
I hope <frameset> continues to work into the future. I'm sure eventually it will wind up on the chopping block, and personally I think that'll suck.
It's more: has made it into a standard and was commonly supported.
Sadly, the browsers aren't trying hard enough not to break anything. They are trying hard not to break anything standard, but the problem with that is that the standards can change, or that some things can be claimed to never have been standards all along. A bunch of IE/Netscape things have broken already such as BLINK and MARQUEE, despite being common enough to "feel" standard even though yes they were never actually standards. Also, as we've seen with the MathML battle in recent years, even standards aren't guaranteed to be kept in browsers if not "commonly supported".
The MDN deprecation warning on FRAMESET:
> Deprecated: This feature is no longer recommended. Though some browsers might still support it, it may have already been removed from the relevant web standards, may be in the process of being dropped, or may only be kept for compatibility purposes.
The browser support table says that every browser still currently supports FRAMESET with simple COLS and ROWS, but as I recall FRAMESET used to also support more complicated layout tools. My brain recalls it as being very similar to TABLE layout at one point in time that you could also have (limited) COLSPAN and ROWSPAN options. Such things may also have been IE/Netscape era "non-standards". If I had examples, they are probably lost to time. Similarly, with nearly no way to easily search in today's indexes for things specifically from the 1990s I can't think of a good way to find old examples either. It's also possibly my memory is just failing me on this and the crazy things I recall doing with framesets were just table layouts after all and maybe iframes, but I do recall doing some crazy things in the 90s that certainly aren't "standard" today and I know wouldn't work in today's framesets.
Otherwise, we're stuck with Chrome Forever. I'd rather not.
We'll get better at building software. Even with huge engineering teams, we can only build the browsers that we have today due to improvements in large-scale software engineering.
Keep your eye out for Ladybird Browser and Servo.
I still use tables (seriously).
So: <table role="presentation"> is probably mostly fine, but not great, and not good practice.
The ARIA spec [1] says:
> 2. Notes on ARIA Use in HTML
> 2.1 First Rule of ARIA Use
> If you can use a native HTML element [HTML51] or attribute with the semantics and behavior you require already built in, instead of re-purposing an element and adding an ARIA role, state or property to make it accessible, then do so.
That's because simpler is easily more accessible. ARIA is last resort, when all else failed. ARIA is complex and not always well implemented, or implemented at all, and when it is implemented, interpretations can differ. Your content will be more accessible to more users / for more browsers if it doesn't rely on ARIA to be accessible. And more often than not, you can do more harm than good by using aria attributes, because it's easy to misuse them, which is worse than not using them at all. Now, ARIA is still very useful and should be used when it improves things over what HTML/CSS supports by itself, but table-based layouts have readily available HTML/CSS solutions.
My opinion is that there's no good reason today to use tables for presentation. One of the reasons is always the same: separation of concerns. Structure your content, in the simplest possible way, and then style it. Structured content, with a structure that's as simple as possible, is more easily accessible. Add divs if really necessary for styling (which don't really change the structure, since they don't have meaning - keeping in mind that they are a compromise).
It's funny how everyone seem convinced by the principle of separation of concerns, except for HTML/CSS/JS.
You could use divs with display:table(-row|-cell) for the same result. Although CSS flex or CSS grid would let you achieve the same thing with a simpler structure and will allow you to have a responsive design. Fat tables with side menus are unwieldy on small screens and your <table><tr><td>-based structure will make it more difficult to offer a usable design to them.
Table layout are also not great on text / terminal-based browsers. Letting the content flow from top to bottom will be way better. You have this for free if you don't use tables, because usually terminal browsers don't understand CSS.
I would then reverse the question: why use tables when you can use display:table, CSS Flexbox or CSS Grid? What are the benefits? Especially when they are simpler as soon as you learned once how to do your favorite layout using these "new" things. I won't be convinced by any answer that sounds like "I don't really want to learn this stuff" because if we are trying to answer "What is the most correct way to do this", we should seek to use the better version, not the one we are familiar with.
It seems to me "Why not use <table role=presentation>?" is a bit like "Why not use this carafe labeled 'this is a glass' as a glass?". Sure, why not, it will work, but if you have a glass now, even if you need to pour the water into the glass before you can drink it, isn't it better? (of course, maybe not the best analogy, I'm not good at analogies, but I hope it can help understand my perspective on <table role=presentation>).
I also believe role="presentation" or role="none" is a code smell. It has legitimate uses (I guess), but the use better be clearly justified.
The benefit would be that the author can understand how to use it better.
css also gets complicated much faster than html. I like to offload complexity to less complicated areas.
a practical example: i look at each row and set rowspan for duplicate values. a series of rows might have week 22 as their first cell and multiple with monday as their second.
How about "one pretends to be a layout, and the other is a layout"?
I don't understand well what you are saying, but:
> a practical example: i look at each row and set rowspan for duplicate values. a series of rows might have week 22 as their first cell and multiple with monday as their second.
This seems to be a case of using a table as a table, which is fine. You should use tables when you are trying to represent tabular data.
you use grid flex or even float (if you need L or Z shaped cells)
I wonder if any notable sites still use tables even for complicated things such as, say, nested comment threads?
Good one
Although I suppose at this point Hacker News is the peak of table layout!
Look, it works and lets me move on to stuff that matters.
Later I learned that having 3 or more different ways to get an identical result is... time-consuming, at best. When they all might work slightly differently depending on several layers of context (or just not work), you realize CSS is ripe for massive pain points to spring up, and they can happen unexpectedly. I understood why everyone else hated CSS - under time pressure, it's just not worth dealing with 99.9% of the complexities for immeasurably small + abstract returns.
Eventually, I determined that I both love and despise CSS in different aspects. It's complex enough to hold both attitudes. And I'm very, very satisfied that Tailwind came along and (nearly) perfected what Bootstrap et al were figuring out before it.
We had used Bootstrap and similar frameworks for years prior, but all the battling with different CSS layout techniques to render the UI on this project made me realize I was wasting my time, and the fact that the designer couldn't give developers working CSS made me wonder if the entire promise of separating design from functionality was a mirage.
<body style="background: url('animals.jpg')">
<div style="text-align: center">
Hard disagree on both points.
Disclaimer: I'm not found of web techs...
Also, there's nothing XML-but-not-actually about HTML. Both HTML and XML are derived from SGML.
The `<center>` element spans the width of it's container, is only as tall as it's content, and only centers the content contained inside it horizontally, but this isn't immediately obvious just from looking at the element's name. Using `text-align: center` instead is a much more obvious way to describe what the `<center>` element is actually doing.
Yes, this is more complicated, but it is more obvious, which, I think, is more useful when someone is learning a complex topic.
Have you met any 7 year olds? Have you taught any beginners to do computer stuff?