A sewing page that never closed its font size HTML tags
web.archive.org
web.archive.org
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.
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.
And if so what godforsaken reason would you have for doing that.
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:
<h3><span>hello
<h3><span>hello
<h3>hello
Which is parsed as: <h3>
<span>hello
<h3>
<span>hello
<h3>hello</h3>
</span>
</h3>
</span>
</h3>
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.
[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>.
I wonder if internally, browsers now convert and parse old <font> tags as <style> tags which would explain the modern behaviour.
and guess what, this page was made with
<meta name="generator" content="Microsoft FrontPage 5.0">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.
"If a problem persists, we recommend that you contact Sewing and Embroidery Warehouse"
This website has a lot of unclosed h3 tags - https://news.ycombinator.com/item?id=7351838 - March 2014 (132 comments)
Don't forget to close your HTML tags - https://news.ycombinator.com/item?id=5194843 - Feb 2013 (11 comments)
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.
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.
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?
Does this mean: "it's complicated"?
(Apologies for my ignorance)
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.
h3 {
font-size: 1.17em;
"(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."So this used to work and look normal.
(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.)
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.
<meta name="generator" content="Microsoft FrontPage 5.0">
Google learned from the best https://www.zdnet.com/article/former-mozilla-exec-google-has...> font-size: 1.17em;
I think this is default chrome value for h3 tags.
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:
- tr #1 contains h3 #1
- h3 #1 contains h3 #2
- tr #1 does not contain h3 #2
It might be of interest that the DOM there contains no tr or td tags.
You'll probably have to jump through hoops to actually get it to open in Windows 10 though...
It looks like some postmodern piece of art.
<style>
* * {
font-size: 120%;
}
</style>
<div>
Hello
<div>
Hello
<div>
Hello
<div>
Hello
<div>
Hello
</div>
</div>
</div>
</div>
</div>