Note: If you think web browsers are weird, just wait until you try doing things in email clients or - $deity forbid - ebook readers.
As you say, it was weird and initially quite difficult to wrap my head around it. Surprisingly, I didn't actually learn about the "clearfix" hack until a couple of years later when I interviewed for a Front-End job at - of all places - Fox News.
The person who I talked with there gave me a take-home to work on and send back. Tl;dr I didn't get it quite right because I hadn't really taken the time to understand what the particular styles did to the layout.
Fast-forward to today and I'm using floats w/ @print and a div class of "clearfix" set to "both" in order to reset the layout of a document that was converted from Word's .docx to HTML.
How times change.
I met your children -- what did you tell them?
That was an essential part of my CSS toolbox for years, and something that ended up being one of the first things added in every new project.
Fell out of use because "nobody uses IE for Mac" :)
Called these "faux columns" and a basic 3-column layout was so difficult it was referred to as the "holy grail" of layouts
https://en.wikipedia.org/wiki/Holy_grail_(web_design)#Faux_c...
Old CSS never dies, it just goes to live on a very special farm upstate where it only has to do 1 or 2 jobs.
.clearfix::after {
content: "";
clear: both;
display: table;
}
If you tell 2 beginners to build something with PHP/jQuery/JS, and send one person to W3Schools and the other to PHP.net/jquery.org/MDN, I have no doubt that the W3schools person will get something done in workable state faster.
Some programming languages ship a good tutorial as part of their documentation (e.g. Python), but not all.
In any case, "W3" is just another representation of 'www', which the W3C doesn't have any kind of claim over.
OpenAI isn't open. W3Schools is unaffiliated with the W3C. The world keeps spinning.
That's optimistic, optimistically. It's a group of ivory tower academics with no stake in any browser implementation acting like they have any right to tell actual browser implementors how to behave.
Well, I totally prefer that, than letting Google decide by themselves
And besides, what makes you think Google listens to them?
The name is so confusing that if you search for "w3c" on DuckDuckGo, the first result is W3Schools, and then the official W3C website.
That's not the point though, I'm not going to say different strokes for different folks.
Instead I'd say, if that beginner uses the 'slower' path instead, that will pay dividends in time -- they are better of learning to use the docs than getting paid peanuts for delivering that project which depends on the juniors faster.
So a beginner should use w3schools while they see fit, and then move on to MDN, etc. when they find it to be unsuitable for their purposes.
A beginner on the other hand would have their SO questions locked/closed within minutes because it would likely break any one of the thousand little rules SO has (to reduce duplicates) that are unknown to beginners.
Horses for courses; I read the official MDN and PHP docs now, but I didn't when I began because those sites assume an enormous amount of prior knowledge about programming.
From the looks of it, it seems like blocking w3schools is quite popular among Kagi users [1].
I have a feeling I know your answer - as a financial professional I initially used Investopedia in a pinch but over the years realized their accuracy has an inverse relation with the specificity of the topic. After seeing incorrect formulas and descriptions a handful of times, I eventually stopped using it completely.
Madness!
Generally speaking, if I see an HTML e-mail I know the other end cares NOTHING about security or efficiency, and is actively trying to snoop on me with analytics.
Not surprising you had to fall back to very old HTML to hit a common featureset.
To your point that HTML can be a security risk, I remember interviewing at The College Board in mid 2011 and finding out that they still sent critical information - think testing admission tickets - with a MIME type of text/plain.
If you need to guarantee delivery and readability, no matter where people are getting the message, I don’t see how you can do it any other way.
I was not really interested if those doing a "View Source" are going to be offended by my "incorrect" use of tables.
See here, where it includes a demo: https://www.vbulletin.org/forum/showthread.php?t=161099
Non-table layouts also came into fashion when screen resolutions started to vary more, and some degree of fluidity and responsiveness could've been implemented with non-table layouts while IE was still a target. However, IE was lacking so badly even with IE8 that a lot of CSS that had been a W3C recommendation for years at that point just either didn't work, it was quirky because IE handled the box model a little differently. Ít was one of the reasons why Javascript shims and IE-specific CSS had to help out fairly often.
IIRC Netscape didn't either around the IE4/5 days. It also had significant performance problems with large sets of nested tables which IE6 (and perhaps IE5) did not.
For example back at University on 133MHz Pentium-class CPUs a large slashdot page with all threads open could take minutes to render where IE took merely a noticeable number of seconds - a co-student use to make a big thing of this as a reason to dump other browsers and use IE. There was actually a use case for this away from the University's fixed line connection: on dial up you could, RAM+swap and browser-not-crashing permitting, open a couple of windows like that then disconnect the modem and read at your leisure without racking up a per-minute phone bill.
Or maybe NS was capable of progressive display and this was just hidden in extreme cases by the performance issue, that was a time ago and memory is hazy…
I think it was around the time of Firefox 1.6 when it felt like it was about on par with IE 6 in rendering speed for me, after tweaking some of its settings. I think it was also rendering tables progressively at the time.
You both agree and disagree with my comment :)
If memory serves me right, I started migrating off table layouts at the time when IE6 was still by far the most popular browser (>80% of the market?).
It was probably a case of killing several birds with one stone - make layouts fluid while avoiding IE's issues with rendering tables.
I don't recall if that was vanilla HTML or vendor extension, I suspect not vanilla.
I stopped doing front end work about the time tables for layout went out of fashion, my dorky internal tools still use them.
From a practical point of view too, if you wanted to make separate mobile and desktop views just by using different stylesheets, using a table made it very difficult.
(That said, in 2000, if you were using separate mobile and screen stylesheets, you were in an extreme minority because there were relatively few full HTML web browsers on mobile devices. Instead, most phones, if they could access the Internet, accessed a different version of the Internet accessed over WAP.)
It never works like I want it to, and I never know if it's because I'm dumb or the tool is poorly-designed, and by then I've wasted two hours, so I always end up just going back to tables because they freaking work.
The good news is now flexbox and grid work in all modern browsers, so this is (finally) a solved problem
The only issue with floats was that there were a lot of edge cases that happened in only certain browsers, so you had to be careful. Lots of browser bugs.
Job security.
I made an SVG interface for displaying/editing diagrams using nw.js (essentially Electron). It would adapt the SVG viewport height and width based on the amount of space that's actively being used so that scrollbars will appear only when needed.
The interface would work perfectly in Chromium and Firefox. But in nw.js I was using their menu api to display a window menu. That menu wasn't part of the DOM-- not sure how nw.js displays that menu but you can't introspect it in devTools. Anyhow, this was somehow creating an off-by-one problem where scrollbars would one pixel too early.
The only way I stumbled upon to fix the issue was to set the SVG style to add "float: left;"
Any ideas on what magic spell this casts? Technically the svg was the only DOM element in the page. I never did figure it out.
But when tables went out of fashion it was all about using floats for layout for a few years. That was wild, I am surprised it was left out from that list.
https://developer.mozilla.org/en-US/docs/Learn/CSS/CSS_layou...
"Originally for floating images inside blocks of text, the float property became one of the most commonly used tools for creating multiple column layouts on webpages. With the advent of flexbox and grid it's now returned to its original purpose, as this article explains."