In case anyone is interested, this is what it looks like on Internet Explorer 5 in Windows 9x: https://i.imgur.com/g668yBy.png
What's happening is that the <h3> tags are all nested, since they don't auto-close in this situation, and modern browsers define the <h3>'s size as "font-size: 1.17em;" which of course adds up over time. I'm not sure how IE5 interprets the page. Maybe I can get an older embedded version of Firebug to check.
I think it's important to not break even older websites even if they have totally busted HTML, but this is probably such a rare case that no one ever thought of it, and at this point it'd probably be much more disruptive to try and "fix" it.
The problem is that these older websites depended on lax HTML parsing behavior, which still exists but has since been standardized in extensive detail.
It’s quite likely this site was already broken in other browsers, or even other versions of IE. And really, it’s not even broken now, the content does render. It’s just difficult to use.
And it’s not as if there aren’t a slew of sites that render differently on Wayback for a variety of reasons. This is in no way meant to disparage the Internet Archive, but I don’t think it’s a reasonable expectation that a site hosted in a way it wasn’t set up by its creators will always accurately render the way it did in its original context.
The increasing size is due to the unclosed <h3> tags combined with unclosed inline level tags. This is parsed into a nested structure, with h3's nested into h3's deeper and deeper. The font-size of h3 is defined as relative increase, so the nested h3-elements get increasingly larger size.
The effect can be reproduced with this HTML snippet:
Usually a h3 would be automatically closed when a new h3 (or any block-level element) is encountered, but because of the unclosed inline element (span in the above example) it is instead parsed as a nested structure. In OP it is unclosed font-tags which cause the h3's to nest, but it has nothing to do with the semantics of <font> per se, it is just because they are unclosed.
So why did it look correct in old IE? I think this comes down to the built-in browser style-sheet. I suspect h3 is defined with an absolute font size in the IE browser style sheet which means nesting does not increase the size.
I'm kinda just pulling this out of the swamp of 25-year-old web design knowledge, but the unclosed code on that page consists of <font> tags, which are long since deprecated, and those font tags have size="2" / size="-2" attributes. I'm pretty sure the old behaviour was that <font size="[signed int]"> affected the size relative to the parent in the same way that CSS "font-size:200%;" or "font-size:50%;" would do. So nesting them doesn't create any new block elements, but it modifies the font size within a <td> or <p> relative to the parent. Just at a look, that seems like the explanation for the increase in font size, in this admittedly odd document.
[edit] I believe the page would look as intended if each <font> tag overrode the prior unclosed <font> tag, rather than treating it as a parent, and that was probably how IE 6 interpreted it. In fact I think old browsers would auto-close </font> if you wrote a new <font>.
There are 189 "<font" and 189 "font>" on that page. This is not the problem. Its the h3 being rendered without automagic IE auto closing fixes prevalen in pre 2000 internet to F@@@ with Netscape users. Pages written by amateurs/idiots/generated with bad tools(/1) would render fine in IE despite not being valid HTML.
Digging in the darker crevices of my brain, I concur. Back in the day, before the HTML spec was tightened up, the <font> tag always took the base document font style as a starting point.
I wonder if internally, browsers now convert and parse old <font> tags as <style> tags which would explain the modern behaviour.
The <font size=...> tags are only in the top navigation bar and is not the cause of the increasing text size. The increasing text is due to nested <h3> elements, where h3 is defined to have a relative size.
If a font tag automatically closed a previous font tag, then you couldn't have nested font styles (e.g giving a word a different color than the containing text). But this have always been possible, otherwise the font element would be next to useless.
Because in old IE, <h3> was defined with an absolute font size in the built-in style sheet, in newer browsers it is defined as a relative size. Since we have nested <h3>'s they get increasingly bigger in newer browsers, but in old IE they would all have the same size.
It's because some browsers close the currently open heading tag when they encounter a new one (since these tags can't be nested) and others do not. Since the text size is applied as an H3 style and is relative to the parent, the nesting of these tags (or not) determines whether the effect of the style is cumulative.
I have this page backed up personally on my machine. I love it so dearly, whenever I find myself scrolling through it again I always end up cackling with laughter.
Yeah, that footer looks surprisingly normal. But I don't see a whole bunch of closing tags just above that part. Why did the font size suddenly revert to normal? Is there something that means "reset everything"?
A single `</h2>` is there. That caused the subsequent `</center>` match to the very first `<center>` tag, popping every nested element from the stack over the course.
I haven't thought about styling tags like `<center>` and `<font>` in quite some time, and I'm glad for it. CSS is quite the wonder and I'll never talk bad about it again after this reminder.
I miss the old web, because we had vision and dreams for grander technology back then.
Bolted on design took a front seat, but it shouldn't have been our focus.
Open-ended CSS enabled us to reinvent styling and designs over and over and over. We've spent countless hours as a species grappling with how to present information, and how to reinvent the wheel. (Every brand needs to feel special, every company needs a design system.)
If these hours had been spent on semantics and reusability, we might have arrived at a different future. Perhaps rich document sharing rather than a web that's about who can have the fanciest scrolling upvote attention grabbers.
There were some bold ideas in the semantic web, microformats, RSS/RDF. Imagine sharing news and articles like P2P, insightful comments being ranked and scored, interest graphs being cultivated to better you rather than get you to like/subscribe. Platforms as an open and extensible standard.
CSS, meanwhile, is a tool that's being used to position a smiling alien creature that tells you to log into the mobile version.
We focused on the wrong things and evolved in the wrong direction. Shiny and flashy distracted us from rigor and enlightenment.
You know, this is a great example how people will find a reason to whine about just anything at all.
We still have microformats, and you're for some reason you're ranting about web economy issues like "like/subscribe" that have absolutely nothing to do with CSS.
In an interlinked multidimensional state space optimization problem, it has everything to do with CSS and the focus on form over function. We stopped thinking about how to make information exchange better, and instead on how to make it look good.
How energy is spent, and where focus is concentrated, are absolutely a limited and frequently pooled together resource. We like to bet on the horses people are feeding. When everyone boards the same ship, it becomes difficult to build new ones. To fund or succeed at other ventures.
I wasn't whining, I was making an observation amongst my shared state space explorers and perhaps wanting for some stories or commentary that rhymed. You made the leap to something that's not quite a personal attack, but that is definitely meant to sting. Attitudes on the web are really starting to sour these days. Have you any idea of the suffering everyone goes through? Just how similar we are?
Persons are meant to question the status quo and past decisions. There shouldn't be anything wrong with that. We shouldn't feel our pride being beaten by words that critique, but should take things into consideration. Perhaps the outcome is to discard outright, but maybe there's a glimmer of truth worth integration.
If I were a whining, I wouldn't be spending every other cycle I have building to fit my vision. I just don't have the time, capacity, or capability to build it all myself.
I see a better connected world without tyrannical ad giants controlling and extracting from us, telling us how to think and feel to drive engagement. The preamble to our evolution to post-biological entities that will one day inherit the stars. In that limit, there's no need for CSS or whatever bullshit we deal with today. Everything is just a temporary bridge to the future, including our minds and bodies themselves. Is that cynical?
> In an interlinked multidimensional state space optimization problem, it has everything to do with CSS and the focus on form over function. We stopped thinking about how to make information exchange better, and instead on how to make it look good.
You don't get to just decide that CSS is the most significant component that caused lack of magical unicorn semantic web.
Sure, if you want to look at the complete vector of reasons, maybe "John spent 2 years working on a CSS engine instead of accidentally inventing semantic unicorn web while high one day" is probably in there. But its weight is quite likely next to zero.
Wanna optimize the world? How about fight for more automatization of low-salary jobs, better education, and forming organizations around the initiatives you wanna see? Oh and let's ban reality TV shows and spectator sports while we're at it.
Said unicorn semantic web didn't happen for the same reason unicorns didn't happen. Just because a magical horned horse can be drawn or photoshopped together doesn't mean you have the actual thing.
Semantic web is ironically not semantically sound. Google fought for the semantic web in the 90s, saw it was 99% abused by spammers, and moved on. We still have microformats and so on.
This entire argument is just bunch of losers nerding over a failed concept from the 90s that was DESTINED to fail.
"(historically the em unit was derived from the width of a capital "M" in a given typeface.). The numeric value acts as a multiplier of the font-size property of the element on which it is used."
Another dilemma for website archival, then. It'd be cool the Internet Archive came up with some JS shim to render websites how they were supposed to look.
(Enough so that if I find a website with JS required, I'll usually defer first to opening it in Archive.is, though of late the endless CAPTCHAs are somewhat chilling the enthusiasm of that.)
I've started opening Bloomberg articles in archive.is since they started not serving the article content. (And, presumably, loading it later through javascript?)
That is not correct. The em unit has always behaved with respect to the inherited font size. If your body has font-size: 16px; then a child with font-size: 1.5em; would appear the same as using 24px for the value. This can recur with nesting, so that 24 could become 36 with another layer added. The rem (root em) unit solves this “problem” as it’s always relative to the document root (usually the font-size you’ve set to html/body)
em was always compounding, but this website used to work in IE because it was generated by Frontpage. Microsoft made tools generating non valid HTML so they would break in Netscape.
But... they aren't nested. HTML doesn't allow interleaved tags.
Here's a snippet of relevant page source:
<tr><td><h3><font color="red"><font face="arial">Improper Thread <br><width="25%" align="left"></font><font color="#0033FF"><font face="arial"> Try re-threading the machine; make sure the thread goes through all guides.</font></td></tr>
<tr><td><h3><font color="red"><font face="arial">Burrs <br><width="25%" align="left"></font><font color="0033FF"><font face="arial">There may be burrs in the needle's eye, on the thread guides, needle plate or the hook. Replace the needle and try buffing the thread guides and needle plate. Buffing may alter the timing, so it's a good idea to replace a damaged hook.</font></td></tr>
The <h3> tags are not matched by explicit </h3> tags. But they are closed; it isn't possible for the <h3> tag to extend beyond the boundaries of the <td></td> tag that contains it.
(Granted, there is no <table> containing these <tr> and <td> elements...)
> font-size: 1.17em;
Where is this applied? I'm looking in the page source and there are only six instances of `font-size`, none of which match this. There's one `<style>`, which doesn't have a font-size and doesn't style h3 tags. The string "1.17" does not appear in the source. The page inspector shows no styling applied to h3 elements.
They are nested in a physical sense, its simply not valid html. Im sure it was purely coincidental IE had a special mode to fix broken HTML on the fly, and one of the most popular beginner friendly web authoring tools generated strictly broken html
> They are nested in a physical sense, its simply not valid html.
For this to be true, you'd need containment to be a nontransitive relationship. In the sense in which h3 #2 is contained within h3 #1, all of the following hold:
This is one of the funniest things I have ever seen. I was reading this on my phone in bed last night and couldn't breathe because of how hard I was laughing.
There are 1.86 billion websites online right now, many more that used to be online, and over 1.2 million TB data. Probably a lot of it is generic content or machine-generated, but I wonder how many unique, weird sites there are like this.
The title is not correct. It should be Header tags. But then on the other side, I only clicked on your post because I was curious what a font size tag is LOL
If this was a skit, it would be a teacher yelling louder and louder explaining all the things that can go wrong with the machines until a sonic boom destroys the classroom.
What's happening is that the <h3> tags are all nested, since they don't auto-close in this situation, and modern browsers define the <h3>'s size as "font-size: 1.17em;" which of course adds up over time. I'm not sure how IE5 interprets the page. Maybe I can get an older embedded version of Firebug to check.
I think it's important to not break even older websites even if they have totally busted HTML, but this is probably such a rare case that no one ever thought of it, and at this point it'd probably be much more disruptive to try and "fix" it.