Those tags were deprecated back in 1997 - HTML 5 kept support for them though even though it was supposed to be removed simply because too many web pages still use them - despite being given 18 years to replace them.
There have been several different variants on CSS. Netscape developed their own they called JSS that was based on JavaScript style syntax. The original web browser had its own CSS but it was defined by the browser owner and not by the web page.
Ok thanks for the clarification; wasnât sure I was thinking that they had to have been around since before CSS since they wouldnât have been introduced otherwise.
Appreciate it 
The last popular browser to not support CSS was Netscape 4 which basically dies out around 2005 or so - so it took about 8 years after the tags were deprecated before people could finally get rid of them completely.
I have no problem with tables in CSS either. To be honest, I think that technique should be more accepted. The reason it isnât is because of the fear of âsemanticâ loss (which I agree is a non issue) and the fact that IE6/7 didnât support table layout in CSS (which is also a non issue now).
So youâre right, itâs just that many people avoid that technique for the reasons mentioned, and they probably shouldnât.
Nothing wrong at all and there are no issues (apart from the extra div). Vertical alignment has always been simple but widely misunderstood. Display:table is the most useful property around and I use it in hundreds of sites instead of floats now that I donât support (fully ie7 and under).
The fact that it is not a block element is neither here nor there as you simply set width:100% if you want it full width but it is actually just as useful with no width because it will auto center horizontally without a known width with a simple margin:auto. It still behaves a block element but just shrink to fit.
I believe the author of the article has some valid points though but just picked the wrong property to complain about.
There are many other properties that work against the layout (margin-collapse for example which 99% of the time does what you donât want).
I also agree that while flexbox is great it is just too complicated for most people and could have been a lot simpler.
I have to say that I agree with @mawburn⌠and some with the comments made by @louislazaris.
@louislazaris I canât agree with your last comment though. The semantic web was created with certain purposes including automatization and accessibility. So if I have to create a full layout with tables with CSS properties⌠then why shouldnât I use a full HTML table instead? Because I still need to think about screen readers, bots, etc.
I donât see a problem with using a CSS version but⌠wouldnât it be better if instead of creating a table, I could apply that vertical alignment to any element and work as it should instead of being forced to create a CSS table?
Things in the CSS world are getting more difficult instead of easier⌠furthermore when you think about SASS, LESS, Jeet and the whole new bunch of stuff coming out.
I like SASS and LESS⌠but Iâm starting to feel like I feel with javascript libraries , blogging platforms, boilerplates, etc. There are so many of them that it is impossible to choose the right one so you stick to what has become more popular. With these CSS preprocessors and the like, it is starting to feel the same. Overcrowded.
So yes, I wish they did things simpler, no more complicated.
Yes of course; there are a few things in CSS Iâd change if I could, but nothing is perfect; every language has faults and itâs ridiculous for us to get out the pitchforks due to mistakes we believe should be rectified. Itâs completely overblown.
The problem with your argument though, is youâre using an example that goes outside the specifications as to why there is nothing wrong with the specification.
Using a display:table-cell outside of itâs proper parents should, by specification, be the same as using display:superman or display:batman, in that itâs not recognized. But it works, as do a lot of other things, because the browser developers are more in tune with developers than those who are making the specs.
I agree, itâs really starting to feel like this right now.
I just ignore all the others because itâs pointless. I already donât even see much of a difference in LESS and SASS. But everyone wants to switch to SASS all of a sudden. If you look up why people switch, basically you get no real substance other than âIS NEW! IS BETTA!â Iâve actually found SASS more cumbersome with some environments because of the Ruby requirement, where LESS has Node.js and Java implementations which pretty much guarantees it will work in any build environment.
Some of these newer ones actually do have some things that would merit a switch, but also come with slightly higher learning curves and LESS/SASS already work really well.
I think @RyanReese that the point that @mawburn is making (watch me put words in someoneâs mouth 
- just slap me if Iâm wrong) is not that youâre âdoing it wrongâ - you donât need to defend your choice of styling there. His point is that the standards should be such that you donât have to step outside of them [to do the thing in question]. If the standards are going to exist, they should be in tune with what developers actually need to develop for browsers.
The problem with your argument though, is youâre using an example that goes outside the specifications as to why there is nothing wrong with the specification.
Using a display:table-cell outside of itâs proper parents should, by specification, be the same as using display:superman or display:batman, in that itâs not recognized. But it works, as do a lot of other things, because the browser developers are more in tune with developers than those who are making the specs.
Again - not arguing that these are things you canât or shouldnât currently do. Arguing that the specifications should be in place to not force us to have to invent our own solutions (even if weâve been using them for years).
And I love that cartoon, seen it beforeâŚ
Edit:
Itâs not feasible for the specification to go over every little detail. Browsers worked it out. Browsers are now uniform on it. Thus nothing in the future is broken.
Why is it not feasible for the specification to go over it? I feel like thatâs the point of specifications. Once itâs left up to the browser, we become in danger of multiple browsers making multiple separate âdecisionsâ on a subject /cough IE /cough. Thatâs the very point of a specification - to enforce uniformity.
Itâs not feasible for the specification to think of every little detail. That was my point. The specification would be 10x as big as it is now if we forced the specification to make a point about every situation it can encounter.
Itâs not feasible for the specification to think of every little detail. That was my point. The specification would be 10x as big as it is now if we forced the specification to make a point about every situation it can encounter.
Perhaps, but thatâs why the open discussions are important, I suppose - to let the body(s) making specifications know whatâs important to developers. Youâre probably right that we canât expect everything to be included. But after years of use, I think we can, among us, come up with many opinions on what things arenât in the specification that perhaps could or should be. Or things that are that shouldnât be, or⌠whatever. Point is, there are some things that are widely used enough that you can make a point for the specification needing to realize a solution and incorporate it.
And I for one would rather it be bigger and therefore more uniform than smaller and more open to interpretation. Maybe it doesnât need to include everything, if thatâd make it 10x as big (an arbitrary amount Iâm sure) but maybe it could be twice as big and cover another X% of use cases or something. I wish that browsers could be UI and feature differences for users, but that rendering engines would treat styling, etc uniformly.
And then I woke upâŚ
Sorry, but the specifications clearly state (and I have known this since day one) that vertical-align only applies to inline elements and table-cells. How in the world is that outside of the specifications?
It does exactly what it says on the tin
Maybe it would have been better if there was a similar property that applied to normal block elements but then unless you change the nature of the block element you donât have a basis for the vertical centering whereas as the table/table-cell construct already has this built in. For block elements you donât have a relationship between one block and the next as such unlike table-cells.
The way that developers are making things vertically align (when not using an actual table) is outside of specifications. No oneâs arguing that the specification doesnât speak to vertical-align. Youâre right, it does. Weâre saying that people have to jury rig solutions to (whatever problem, not just this one) when there could be an actual provision for it somewhere if itâs a common issue, instead of it merely being ignored.
Which is the reason for discussion before new specifications.
I think that extremism as far as the OP goes is a bit much, and stubborn âitâs ok we can code like we always haveâ is a bit much as well. People just need to contribute opinions, and work with the specifications group(s) as best as they can to come up with better ones in the future, that work better for the current state of web development. Refusing to change is silly, as is demanding absurdly sweeping changes that would break the Internet in general . Just my opinion.
Edit:
Maybe it would have been better if there was a similar property that applied to normal block elements but then unless you change the nature of the block element you donât have a basis for the vertical centering whereas as the table/table-cell construct already has this built in. For block elements you donât have a relationship between one block and the next as such unlike table-cells.
Right. Thatâs the issue, is the need to look into if things (not just this example that everyone is stuck on) could be better - and how - and what would have to be altered to make that happen. Maybe itâs entirely impossible without extensive redesign of our thought process around block elements and etc. Maybe itâs not and we just havenât come up with a good idea yet - I hope none of us is magnanimous enough to believe weâre omniscient when it comes to development, layouts, etc. Things expand and grow for a reason - we come up with new ideas!
It does. But are you giving every table-cell itâs proper table-row parent element and every table row itâs proper table as is also defined by the specifications? If not, youâre not using the spec the way it was written. Therefore, there is a problem with that spec. Thankfully the browser developers have decided this was dumb, but there is nothing saying that they need to do this. If they followed the spec, a lone <div style="display:table-cell"></div> would be the same thing as <div style="display:batman"></div>.
Donât mistake the choices of the browser/engine developers for those of the w3c.
Again you are wrong on this point and the specs clearly state that when used in isolation (e.g. display:table-cell) the UA must construct an anonymous table-row and anonymous table element.
The point of the css table specification is that you donât need those extra elements unlike the html table version which must have the proper structure. You are not doing it wrong in any way (unless you create a design that doesnât work) 
A lot of misconceptions in CSS come from peoples misunderstandings on how things work. Donât get me wrong though it is far from perfect and discussions like these show how awkward people still find these things.
I think things could have been a lot simpler but at times they also need to be complex enough to cover most situations. I still find it strange that even advanced CSSers still donât understand new block formatting contexts and which elements create them and why they automatically contains floats. Maybe its the details like these that should have been simplified.
So I am. Thanks. I figured I might be, but couldnât find where.
But thatâs what we have you here⌠to correct us and make us understand
@PaulOB Iâm curious why (quoting the entire paragraph)
The CSS model does not require that the document language include elements that correspond to each of these components. For document languages (such as XML applications) that do not have pre-defined table elements, authors must map document language elements to table elements; this is done with the âdisplayâ property. The following âdisplayâ values assign table formatting rules to an arbitrary element:
Is an argument being used to promote using these elements âin specificationâ within HTML, which is a language that has pre defined table elements?
To be clear, I agree with you that itâs not âwrongâ - I just donât see how that use case matches specification.
Edit:
A better argument that seems to prove you right without being wrong, if Iâm reading this right, is
User agents may ignore these âdisplayâ property values for HTML table elements, since HTML tables may be rendered using other algorithms intended for backwards compatible rendering. However, this is not meant to discourage the use of âdisplay: tableâ on other, non-table elements in HTML.
(emphasis mine)
The css table model is a mechanism to imitate (some of) the visual layout that html tables have. It also serves to apply rules to table elements as basically all elements are inline by default until the UA applies rules to the contrary (which is why some of the new html5 elements needed display:block to make them work properly as they should (until the UA added the styling to its defaults.)).
I believe the specs are saying here that if you have html table element and you apply a property of display:table-cell (instead of display:table) then UAs could ignore that for backward compatibility. I commonly set display:block to td elements so that I can linearise the display for small screens and seems to work well on modern browsers.
Yes the section I meant to quote originally is this which shows no ambiguity at all.
lol - I just got lucky 
Yes the section I meant to quote originally is this which shows no ambiguity at all.
Your section still is debatable because it says âDocument languages other than HTMLâ
But I still think youâre possibly/probably right, because they note that their wording isnât intended to discourage use on non table objects?
So itâs all semantics at this point. (See what I did there )
And yeah, that @mawburn, he caves too easy!
But yeah. So, swinging back to the major issue here⌠are you against adding to the specification in this or any other case for ease of use, basically, or are you just arguing this single case?