HTML hacks that shaped the Internet

Using tables for layout is pretty understandable.

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."

As W3Schools still likes to call it: the new, modern clearfix hack [1]

    .clearfix::after {
      content: "";
      clear: both;
      display: table;
    }

[1] https://www.w3schools.com/howto/howto_css_clearfix.asp

W3Schools is a horrible resource. I'd like Google to hide all of their results.

A lot of people on HN seem to have this opinion. A lot of the content on that site has been re-written, and it's now a pretty fantastic resource for beginners.

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.

i'm mostly upset that they use "w3" in their name to masquerade as an "official" source of documentation. i know their about page clears this up, but it's pretty buried.

Well perhaps W3C's official site would rank higher if it actually offered any tutorials, i.e. the thing people are searching for, as opposed to a list of specifications and draft specifications that won't be finalized for 10 years.

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.

won't be finalized for 10 years

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.

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

Have you ever had academics that have nothing to do with you, your company, or your product, tell you how to do your job?

And besides, what makes you think Google listens to them?

I disagree, "w3" doesn't have any official connotation, it is literally the name of the thing they are teaching (or the alternate spelling of the abbreviation, but same thing). It is a common pattern for a school that teaches [thing] to call themselves "[thing] school", nothing wrong there.

You're telling me it's unreasonable for people to mix up W3schools and W3C? lol

I agree with you.

The name is so confusing that if you search for "w3c" on DuckDuckGo, the first result is W3Schools, and then the official W3C website.

And if you tell 2 experts to build something with W3Schools as the resource against better documentation, I'm sure the results will be the opposite.

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.

I disagree with you. "Learning" to use a particular documentation website (which, mindyou, changes its layout frequently) is not very time consuming.

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.

That's exactly what the progression was for me. W3S laid the foundations, and then I went on to MDN and other sources once I felt more comfortable.

An expert wouldn't go to W3schools to begin with. They would have far more specific problems that would be better explored on Stack Overflow.

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.

This exactly. I still look to w3school over mdn if I can. The information is just friendlier. I'll use "proper" documentation if needed and never post anything to SO for the reasons you state.

What would be the point of that exercise though? It's true they might produce something faster, but if those sources are meant to be an educational resource then they'll learn more reading through actual documentation than copy-pasting questionable code to get something done.

You need a ‘tutorial’-style guide to bootstrap your knowledge. After that, you’re ready to use a technical reference.

Some programming languages ship a good tutorial as part of their documentation (e.g. Python), but not all.

I haven't noticed a difference since I first heard of the site. They may have corrected factual inaccuracies, but the overall organization and prioritization of information is not for me.

My main issue with them is not their content proper, but that their SEO ranks them above much more topical results. That's clearly also Google's fault, but it's also clearly w3school's strategy.

Amongst many other sites, I have w3schools blocked in my Kagi search results, along with MDN being raised/prioritized.

From the looks of it, it seems like blocking w3schools is quite popular among Kagi users [1].

[1]: https://kagi.com/stats

Kagi, what an unfortunate name. It means "you take a shit" in Italian :(

Could I ask real quick why you dislike W3Schools? I def learned SQL syntax and basic HTML/CSS (I needed to use CSS selectors but had basically no knowledge) through them and actually thought to myself they did a great job at keeping things need-to-know for immediate use.

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.

Kagi let's you hide it.

 That works?  

I was going to comment that I took offense to calling table-based layout a hack in the first place. When tables went out of favor, and I saw many, many front end dev teams waste cumulative months of time creating a much less understandable web page fiddling with float nonsense all over the place, solely so "purists" could keep their religion in tact, I learned a valuable lesson. Joel Spolsky calls them "Architecture Astronauts" in a great blog post - the types of developers who forget that their job is to actually produce working software that does something well with the least amount of effort (architecture astronauts also gave us the ridiculousness of the first EJB spec, and stuff like the widely derided AbstractFactoryBuilderConstructor nonsense from Java). I feel like I've done a good job over time recognizing these architecture astronaut personalities and staying far away.

IIRC non-table based layouts are rendered progressively, while table-based layouts have to be loaded fully first, and only then rendered. At the point when this was relevant, the Web was slow (slow connections, slow rendering engines), so one of the primary motivations for ditching tables for layouts was an increase in the perceived page rendering speed, not just a purist quirk.

I don't think that's accurate. It was old Internet Explorer that wouldn't render tables progressively.

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.

I don't think that's accurate. It was old Internet Explorer that wouldn't render tables progressively.

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?).

IE had a setting that forced tables to render progressively. They documented it on the Microsoft web dev site and also I’m reasonably sure in their “cool things you can do in IE5.5” book.

Didn't know that! Wonder what made them choose to turn this off by default. Must be an interesting eng story.

I used it and it almost progressively updated too often - like cell by cell, so it wasn’t very pretty. So you kind of had to know when to use it and when not to.

> I don't think that's accurate. It was old Internet Explorer that wouldn't render tables progressively.

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…

If you added attributes for the number of rows and columns (something like <table ... rows="4" cols="4">), it could render it progressively.

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.

Not in the HTML 4.01 spec (https://www.w3.org/TR/html401/struct/tables.html), so probably a vendor extension (don't think I ever used these attributes).

For sure. While tables went out of fashion, there was nothing usable to replace them.

I was not really interested if those doing a "View Source" are going to be offended by my "incorrect" use of tables.

Check out a "View Source" on HN ;)

what do you mean by "purists" wrt tables? not nesting them or something? or using them only for marking up "relational" data and not page layout? or were these purists from the design side?

Tables semantically are meant to represent tabular data and using them for layout became “wrong.”

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.)

Floats were ugly but once you did enough of them, you could nail it every time. It shouldn’t have taken months if you had an experienced team.

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.

Yep replacing tables with floats is just swapping one hack for another, with its own set of edge cases, browser incompatability etc.

The good news is now flexbox and grid work in all modern browsers, so this is (finally) a solved problem

Not everyone who cares about accessibility is an architecture astronaut.

Every time I need tabular layout I try the tool du jour: Floats, CSS grid, etc.

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.

Speaking of floats being used for layout, you could probably add the clearfix hack to this list too.

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.

https://css-tricks.com/snippets/css/clear-fix/

The linked article includes an example of the "commented backslash hack," a variation on point #3 in this article

Fell out of use because "nobody uses IE for Mac" :)

IE for Mac was so atrocious, there's a chapter dedicated to it in iWoz.

As I understand it - I was a bit young when it happened, so all I have are secondhand accounts - IE 5 on Mac was substantially better that other browsers due in part to its CSS support.

The chapter on IE for Mac in iWoz has nothing to do with how the browser render engine worked. It is about how the OS behaved after it was installed.

Tasman was way ahead of Trident actually. It had many problems Gecko had in that the web didn't care much for standards so implementing the standards, even well, wasn't considered a selling point. It was years of mostly Mozilla effort to make standards matter enough that web developers came around to them and then Tasman was viewed as an amazing pioneer alongside Gecko.

It amazes me to this day that IE for Mac wasn't even the Trident rendering engine.

While at Mozilla for a quarter century, I got to work for many years with one of the people who made Tasman, Mac IE's engine. It was a phenomenal engine from what I learned. I wasn't on Macs in that era so didn't use it much, but knowing today what I've learned about it, I believe it to be one of the better pieces of software Microsoft people ever built.

it was all about using floats for layout for a few years

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...

don't forget that the holy grail was to have a locked in header and footer with the middle section as scrollable 3 columns

This is firmly cemented in my mind as completely impossible. I won't listen to reason.

It because of this exact technical challenge that ads nowadays appear between paragraphs in the middle content column, instead of in the right column where they belong.

never underestimate the levels ad tech will stoop to interfere in an attempt to gain even more eyeballs/clicks. your attempt to sit them at the table in the back of the room next to the kitchen was never going to be the final placement

I will go a step further and argue that all the websites we see today with dropdown menus at the top, a huge header image below it, one blob of disjointed content(?) below that, and finally the footer at the end is(was?) a direct result of the Holy Grail being so difficult to achieve outside of using tables.

I had to develop some email templates a while back for the first time and was almost shocked that they still use the "tables method" for layouts. Overall I'd say developing email templates now is much like developing websites in the early 2000's, email clients have such a wider range of CSS support that there are hacks all around. We now have frameworks like MJML and Foundation that do their best to abstract all that stuff away through components but take a look under the hood at the rendered HTML and it's a very scary and nostalgic place.

E-mail was never meant to support HTML, though, and it's a major vector for attacks. I wish more servers would disallow or strip HTML from their incoming messages.

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.

As I’ve been converting from .docx to HTML, I was pleasantly surprised to find that using flexbox to lay out three elements in a single row is perfectly fine and - bonus points- the CSS doesn’t make want to gouge my eyes out.

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 JUST had this same issue. Even worse, the Sendgrid "sample renderer" supports flex, but Gmail doesn't, so I didn't notice there was a problem until I started sending myself test emails, and then had to rewrite the whole template with tables.

Madness!

But if you wrote an email template app based on tables, why would you change it if it's not broken? Why would you go through the hassle and expense of redeveloping your app just to not use tables? No sane person looks at the HTML of an email. Only poor souls that get a request on how to send email spam in-house might ever consider it, or just the perversely curious. Either way, nobody cares what it looks like under the hood as long as it looks good when viewed in the client.

The era between tables and flexbox/grid was a difficult one. Floats were finicky and hard to get right. A lot of people just went back to tables, and I honestly didn't blame them.

The era between tables and flexbox/grid were the glory years of Bootstrap and Foundation CSS frameworks.

Or the rare-in-the-wild but somewhat funky method of using the display: table/table-row/table-cell CSS declarations to create table-based designs, but applied to different tags so at least your HTML still only shows those fancy modern divs :)

I had an internship during college at a small web shop that did a ton of HTML mail. Early on, after I had completed a project, they took a half day to try and teach me how floats worked.

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.

Floating divs killed the Dreamweaver. CSS came and broke your heart. Oh, a, a, a, oh.

We browse through Wayback and it seems so long ago...

I met your children -- what did you tell them?

I told them to behave, but I don't know if they listened, because my old ears are plugged up, and I can only barely hear them. Hee dee hee, hee dee ho

When floats first came out (or around that time) I wrote my computer repair site using them, all developed in FF. Then, as I was finishing, I opened it in IE and watched the entire design fall apart. Unfortunately the people I would be targeting with my website would almost certainly be using IE so I had to go back to the drawing board and rewrite it using tables. It was a sad day.

Unfortunately, the opposite could also happen. You just needed to test every commit (or check in... ugh writing that word brought back painful memories) in different browsers

Something related to this:

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.

Possibly the svg element was inline, so sitting on the text baseline rather than the limits of the container element?

I'd say that using floats to make columns and rows in layouts was way worse hack.

the time after table layouts and before flex and grid really sucked. table layouts sucked too but at least they made sense lol

I still remember article after article coming out with the newest "holy grail" of 3 column layout.

If you're specifying @screen as the Media Type, the primary reason I can think of for going back to floats is art direction - especially if you wanted to float images alongside a block of text. I know there are "better" methods in more modern versions of the spec, but this is one that still seems to get a fair bit of use.

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.

I like how HN employs one of these today:

- Use HTML tables for layout

Hahaha :)

On a more serious note, this list highlights how development without standards leads to control information being encoded in various tolerable side-channels.

The potential mess and collision of this brings into relief the disdain that's sometimes levelled at the current W3C process. This process marries a standards-driven evolution of web technologies with browser-driven innovation, with the two alternately either leading the other, or proceeding in lock-step.

While it's often derided, this process could be interpreted as more sustainable and stable than the one which came before.

I wonder how many of those who decry the new W3C-vendor norm would choose to return to the heady days recalled by these 10 weird hacks? :)

I love how tables "went away", and were widely replaced with bootstrap. Which gives you ... tables. in divs. But only 12 columns wide.

I think the value of Bootstrap was consistency across browsers. The grid system was the most important part. With standard Grid, Bootstrap is effectively legacy - you shouldn't really be using it at this point.

With standard Grid, Bootstrap is effectively legacy - you shouldn't really be using it at this point.

Bootstrap first adopted Flexbox for its grid system Bootstrap 4 (2018), and Bootstrap 5 (2021) added support for Grid. It's conservative about supporting new web standards, but I wouldn't personally think of it as a "legacy" framework.

They absolutely are not tables though.

They weren't <table>s through, meaning they could be easily made responsive.

Unfortunately today w3c and tc39 (Javascript) are completely dominated by Google who ram through a lot of standards while barely paying lip service to the process.

Unfortunately a lot of players who rely on browser functionality are completely silent in the standards committees (like the TV vendors who all run their apps in a webkit or chromium version), so it's barely a three-way tug-o-war between Google, Apple and Mozilla

I’m still bullish on the possibility of Microsoft edge shaking up this dynamic a little, but maybe I’m naïve.

They did start https://open-ui.org which really deserves special recognition.

This is a cool idea! Thanks for the link <3 :)

And really barely. My impression is Chrome still innovates (though somewhat unilaterally), Mozilla sleeps (no clear path towards view transitions ...) and Apple sometimes contributes small quality of life things.

On a more serious note, this list highlights how development without standards leads to control information being encoded in various tolerable side-channels.

I don't think it's a lack of standards, it's more of a lack of necessary functionality. If the thing you want to do isn't an addressed feature, you'll do it one way or another creatively. Standards provide rigidity that create this situation to begin with unless the standard is mature enough that it captures all the potential needs, especially in cases like the web where your often locked to some standard that may or may not suit your needs. In other spaces, you usually have enough options that one thing or another is flexible enough you can do what you need to do and go with that choice.

Having worked in research long enough you'd be surprised how often something someone wants to do requires some hacky technology approach because many standards exist around business/consumer interaction and systems built around that, because that's where the money is which drives those standards and feature sets.

Yeah, that's a fair point. But normally standards imply functionality. And if something's useful enough that people are inventing creative ways to achieve it, it would likely be standardized, if there's a process to do so. So, the issue about a standard process remains.

It's not really possible to separate that from functionality.

Your point about the potential rigidity of standards is well taken. However, it’s important to note that a standard, by its nature, doesn’t necessarily have to be rigid and inflexible in a way that hinders progress or creativity. Standards can be designed with adaptability in mind, providing a stable foundation while still allowing for innovation and flexibility. This balanced approach ensures that standards serve as helpful guidelines, not as constraints that stifle growth or possibilities.

Your final point about the practical realities where standards rubber meets the road, so to speak, is also a good one. But there's a distinction between the type of standards you might be referring to, such as in manufacturing or quality assurance, and web. In the former, standards indeed can produce this kind of regulatory capture or bloated compliance industry, and associated restriction on innovation and competition. And on the other hand, the type of standards that we mean when we talk about the web, even though it's the same word, I think they're very distinct in fundamental ways.

Although they share the same terminology, web standards tend to be more about enabling interoperability, innovation, and accessibility, rather than imposing restrictive regulations. However, restrictions do occur and they are sometimes abused, seemingly by big vendors to enhance their value capture by penalizing alternatives in the name of “user safety”. In that sense, web standards can share the “corruption of standards” which I think is invoked by your last point.

WHATWG didn't advance the Web for anyone except for-profit interests.

I cut my teeth on HTML 3.2 so I know what byzantine BS was needed for IE and Netscape. Those were choices made by MS and Netscape, however, so even with a bigger W3C presence, there was no guarantee or even hint that MS and Netscape would fall in line with new standards to begin with.

And it was better then than the garbage we have now where if one big company decides they want it, the rest of the Web gets to deal with it.

That's SO much better, man. /s

I'm not sure "shaped the Internet" is the right description. These are 10 HTML/CSS hacks that enabled you to work around browser quirks and poor support for certain features.

If you want to know a JS hack that truly "shaped the Internet", that'd be ActiveXObject("Microsoft.XMLHTTP"). It's the origin of AJAX, allowed GMail to dynamically update the mail list, and led to the entire SPA craze.

If you read ancient articles like this one https://support.microsoft.com/en-us/topic/dynamic-page-updat... you can truly see just how much it changed the internet.

Hah I was hoping someone would bring this up..

We were using that XMLHTTP object as far back as 1999 (I just went to look at old source code) to load page fragments do quasi-SPA stuff before it was a thing.

Same - I recall using it heavily in 99. But that was just on one internal app. I admit that I didn't really predict the SPA thing until Google maps came out and really showed how far it could be taken.

I worked for an ISP in the late 90s and we built a call center app using IE6, SSI, XMLHttp and also IE's built in CSS classes that matched the Windows colours to essentially have a UI that looked and felt like a Windows 95 app..

It was completely unnecessary (at least the look and feel part) but the ability to load in new information into the UI without a full refresh was great.

At the time this was running on Apache 1.1 via Perl CGIs and backed by an mSQL database (that was single-threaded!) so we wanted to minimize complex SQL queries as much as possible..

We eventually moved to a system that would batch pre-render customer details and call history to static HTML overnight when our call center was closed, to reduce the startup time of bringing up a customer's info when the agent had them on the phone. Then for that day we'd use XMLHttp to dynamically append new information from the DB (using a limit statement) and then re-build the static files the next night etc..

In hindsight, we did some creative problem solving for a bunch of self-taught 20-year-olds in the 90s.

That one is truly ancient, and unique in that it actually uses XML, and even SOAP, in AJAX calls. (Although the SOAP is mostly a façade and a fancy way to call a function without any arguments.)

Some of them are definitely more "historic" than others.

For instance, #2 (<table>-based layouts) definitely shaped much of early-to-mid-2000s web design, and can be viewed as a precursor to flexbox/other modern layout engines.

Same with sIFR -- custom webfonts are totally taken for granted today largely because of "hacks" like this.

I strongly agree with table layouts being historic. A large reason we now have flexbox is because early CSS was really bad at replicating table-based layouts, so people didn't stop using then despite the drawbacks.

Same story with rounded corners, which were originally accomplished with tables and images. And a lot of the conventions for website navigation were established in table-based layouts

I don’t know about others, but I hated sIFR. It was routinely deployed without sane fallback (so that if you didn’t have Flash, headings were broken, for example—it being common to deploy it on headings only, since it was overall so awful), it butchered performance, the rendering was ugly and often difficult to read, and it thwarted regular operations like text selection.

Yeah. I was hoping for a list of hacks that got promoted to standards. That would have been a really cool read.

"list of hacks that got promoted to standards. That would have been a really cool read."

I guess that would be just called "history of the internet". Originally designed to display text with links - and after decades of hacks, a browser is now allmost an OS, capable of allmost anything computer related.

It's funny how we came around to JSSS, and it's now everywhere: from CSS-in-JS to web components coding their CSS in strings inside Javascript

I've looked up some JSSS code examples, and it seems like it's pretty much the only type of code where the "with" keyword makes sense:

  <style type="text/javascript">
  tags.H1.color = "red";
  tags.p.fontSize = "20pt";

  with (tags.H3) {
    color = "green";
  }
  with (tags.H2) {
    color = "red";
    fontSize = "16pt";
    marginTop = "4cm";
  }
  </style>

I think it also makes sense in Python, where it can be used to automatically close a file, or

  with open(filename) as my_file:
      data = my_file.read()

Or with acquiring and releasing a lock:

  lock = threading.Lock()
  with lock:
      pass # do stuff

That being said, I prefer the C++ approach of using constructors and destructors to automatically acquire resources (like locks and files) by declaring variables within some block scope, and release them once the scope is left.

Javascript with and python with are completely separate things.

Javascript with comes from Pascal with (which was perhaps copied from somewhere else) and is used to modify variable scope.

    with (my.long.variable.reference) {
        a = 1;
        b = 2;
    }

is equivalent to:

    my.long.variable.reference.a = 1;
    my.long.variable.reference.b = 2;

or at least, it might be ... due to Javascript's dynamic and typeless nature you might not know for sure what will happen until runtime. Which is one reason it's now deprecated and not allowed in strict mode. In pascal, variables have a type, records have fields, and these are known at compile time so that's not an issue.

https://wiki.freepascal.org/With

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

I knew about the Pascal "with", but I didn't know JavaScript had the same construct.

That kind of "with" is a lot less intuitive to me.

I was responding with Python's "with" because it sounded like they were talking about programming languages in general, but now I can see they were obviously talking about JavaScript's "with" given this context.

It was also a rarely-used classic way to deal with variable references that changed in a loop:

  var values = [];
  for (var i = 0; i < 3; i++) {
    values.push(function() { console.log(i); });
  }
  for (var j = 0; j < 3; j++) {
    values[j]();
  }

This would log 3, 3 times. The usual fix (before the variety of modern ways) was to use an IIFE in the first loop:

  for (var i = 0; i < 3; i++) {
    (function(i) {
      values.push(function() { console.log(i); });
    })(i);
  }

Alternatively, this works:

  for (var i = 0; i < 3; i++) {
    with ({i: i}) {
      values.push(function() { console.log(i); });
    }
  }

A common case of W3 actively choosing the worse option

CSS seems better? Much less verbose for same effect, doesn't require enabling Javascript. The 'with' selectors do predate jQuery and querySelector, but that was a problem with Javascript and not CSS.

Some of my favorites:

- Faux columns, to get a visual stretch and make it appear that the sidebar was as long as the content https://alistapart.com/article/fauxcolumns/

- Or take that even further, with a nine-patch and 9 div's or a 3x3 table you could hack your own borders by repeating backgrounds in some axis. With CSS3 we got border-image that could help this a bit. These border styles aren't that much in favor anymore, though.

- To make rounded borders, one could use the nine-patch. But many would also use a generator to make some HTML that basically simulated a rounded border, by making lots of elements. Found this article describing it: http://benogle.com/2009/04/29/css-round-corners.html Conventional wisdom was that the added markup would be more bytes than an image would be, but less roundtrips and quite easy to do.

Golly. It’s a bit of a slap in the face to click through to A List Apart and see the header broken on mobile.

It’s still so clean though after all these years.

you mean the title cut off? it happens on desktop too. i wonder if it's intentional

Yes, it is intentionally their design.

In that case, awesome.

Aldo worth mentioning; the sliding doors technique for rounded corners; https://alistapart.com/article/slidingdoors/

Faux columns

Still live on our main-website because there’s never time to replace it with something more modern ;)

That 3x3 was used so much with our team that we built a component just to do that. I even wrote an article about it, more of an ActionScript thing but same idea for styling -- https://brajeshwar.com/2005/splice9-bitmap-window-resizer-co...

The other nice thing was the use of the cicada principle for a background styling pattern that 'do not repeat.'

Why it was useful: Because Internet Explorer was trash

Great insight

Specifically: IE6 was trash.

Microsoft had won the browser war, but at the same time the dotcom crash and antitrust action over the tight integration between IE and Windows caused Microsoft to stop investing in it.

Did they ever invest much into it? As far as I understand they got the core components from Spyglass Inc. and avoided paying licensing fees by giving it away for free.

Sounds like they avoided paying licensing fees by not paying licensing fees and then acting surprised when called on it.

https://archive.ph/20120919002551/http://www.windowsitpro.co...

Wasn't it that the Spyglass deal was MS paying a percentage of revenue, and MS releasing IE for free, so that Spyglass got to keep a percentage of $0?

Feels like when Microsoft licensed Mosaic from Spyglass to become Internet Explorer, and a chunk of the compensation was tied to a fraction of revenue from Internet Explorer. Of course Microsoft gave IE away as part of Windows so IE never had any revenue associated directly with it. Eventually MS did settle a lawsuit brought by Spyglass for $8 million to make the issue go away

https://news.ycombinator.com/item?id=27999293

I don't agree IE6 was trash at that time. It was much better than the competition. IE was much faster and less resource intensive than Netscape, which was a big deal when RAM was measured in megabytes. It's not fair to compare it to browsers which came out years later.

I really hated IE with a passion.

This doesn't include my "favourite," putting a heading for accessibility at a -10000 position, so screen readers would read it, but it didn't render on the screen.

Does it still work? Or do you have to use ARIA?

I think you can use `visibility: hidden` or something like that.

Most screen readers ignore hidden elements IIRC.

This still works and is a somewhat common practice, especially for something like a skip link. Try pressing tab on some of your favorite websites you might find they use this technique.

https://developer.mozilla.org/en-US/docs/Web/HTML/Element/a#...

I don't see why it wouldn't work, but the right thing to do is use accessibility features.

This (as well as close relatives of this) is still relatively common because we still don't have a great option for to have non-visible text that's screen-reader accessible in all cases.

aria-label and things like that have replaced some usages of this pattern but not all.

Is responsive design really a hack? Media queries are awesome

Putting that stuff in css vs having conditional logic in the javascript is a huge win, esp when you want to ssr

No, it's not a hack. You can query different things about the user agent and serve different CSS based on those queries. Anyone calling it a hack is ignorant, it's a necessary part of producing responsive designs.

It is when then query doesn't query what you want to know but something that happens to correlate with the thing that you actually need.

I had the same thought. Media queries to support different... media seems like the exact proper use case.

Sometimes I can't tell if modern web developers are spoiled, by having CSS Grid and IE being dead. Or if we were spoiled back then, by not having to deal with the complexity of modern frameworks and build processes.

There is something unique in web development connotation to the other fields I've worked in. The industry has made a habit of reinventing the wheel in every more complex ways.

My best guess is that this is a side effect of web being a field that's more often picked by new or less experienced devs.

The web is essentially UI development. And UI frameworks and libraries have always had lots of churn. Even ultra-conservative Java has had AWT, Swing, and a couple varieties of JavaFX. And then a few more developed by other groups like SWT. The expectations of both developers and users increase as computers advance, and older frameworks can't always keep up.

Probably both, though I think it's probably easier nowadays simply because you don't technically need modern frameworks and build processes, and can create what would previously be complicated sites and apps with ease using modern CSS and JavaScript.

Why exactly was Internet Explorer so bad? In hindsight, it looks like a huge missed opportunity for Microsoft.

They were attempting to replace standards-based rendering with their idiosyncratic version. It wasn't that IE was bad; it was that it was deliberately that way b/c they saw the web as a threat to the desktop, and wanted to Embrace, Extend, and Extinguish it.

They won. The world was running on desktop computers, and those desktop computers were running Windows, and Windows was running IE.

So they rested on laurels.

It had the majority share of users, lots of bugs, and didn't update itself (in the sense that modern evergreen browsers do).

This turned into a chicken/egg problem where apps only worked in IE6. Mitigated somewhat by "evergreen" browsers that update themselves regularly.

No respect for spacer.gif?

It's still here on HN of course, included in every page request:

https://news.ycombinator.com/s.gif

No story of table-layout is complete without spacers images

I came here to say the same thing. :)

I remember the good old days of the transparent 1×1 pixel gif to keep table cells in check.

I used to slice large images in a grid pattern, held by a table. Don't even remember why... For faster loading?

"Good old days"? You are currently on a page using this ;)

https://news.ycombinator.com/item?id=38485665

This gave me ptsd haha. Also shows how mush cost we have/had with one company (MSFT) fucking up so bad. Imagine the hours incurred because IE sucks?

Nowadays it's Microsoft Teams, one step forward and two step backwards, every. single. update.

ptsd.psd ?

Remember when our browsers defaulted to gray backgrounds? That was weird, right?

better than white themes we have today

The best part is going between two dark themed sites at night and get a blinding bright flash as a transition.

I used to override the default style to do white text black background and I lost count of the number of sites that would set one of those properties to the common default causing everything to be invisible.

Did anyone actually use Chrome Frame? Were there so many users that were so used to the IE interface and were unwilling to accept Chrome itself?

Plenty corporates had IE only/first policy. This meant everything intranet had to work on IE. A website developed for chrome was allowed to request chrome frame, but it had to undo itself for any external links when linking to other intranet sites (plenty active-x / silverlight).

I wish there was an option to specify per website domain which browser to use.

And more importantly, as I recall, you could install chrome frame without admin access.

The amount of conflation between "the Internet" and "the Web" is way too high in here. It is the most popular protocol, but it is not the only protocol.

The amount of conflation between "The Web" and "HTTP" is way too high in here. "The Web" is not a protocol.

The article and every comment in this thread thereof is a thermonuclear illustration of (part of) why I hate web development. This is what so many of my peers told me was the way to develop applications. Nevermind that the desktop frameworks, quirky though they were at times, had none of these issues and didn’t force some absolutely wild hacks on their users.

I will never not be salty about the DOM, CSS, and all the wonky apis to control them. JavaScript in comparison was the least of the sins of web dev.

In an odd way, I miss the time when web dev was so quirky and unpredictable. It was a never-ending process of experimentation, puzzle solving, discovery, and, once you figure out a hacky way to do something as basic as a 3-column layout, very gratifying.

I guess for me it was more of a creative outlet than just a job.

Dupe: https://news.ycombinator.com/item?id=38423981

Why are here so many duplicates? One should look before posting.

No mention of the html5 shiv we all installed before any CSS so all browser quirks were removed?

https://paulirish.com/2011/the-history-of-the-html5-shiv/

Nor of reset, normalize etc.

Rounded corners using images? Usually using a sprite.

Also I worked somewhere that used Flash as a proxy for realtime socket support. I believe web sockets were not around then or maybe not fully supported.

Sockets are very new. Way back when, you'd either use COMET, which was a connection that the server wouldn't close, and you'd append data to it, for the js in the browser to use. This was one directional, so going the other way still required separate requests

For real bidirectional sockets, it was common to make or use a small flash file. You'd talk to it with js, and it would handle the actual socket stuff. Worked pretty well

The font size on this site is huge. Why do blogs now follow this?

Because it's easier to read.

No mention about HTC?

    .fancy { behavior: url("path/to/pie_files/PIE.htc"); }

(It is still online [1]! And even on GitHub [2]!!)

[1] http://css3pie.com/ [2] https://github.com/lojjic/PIE

I have a stupid fondness for the level of hacks that we all collectively developed for IE6-9. One of my favorites was tricking IE6/7 into supporting Base64-encoded images in CSS by essentially triggering Outlook rules.

They're 100% things that shouldn't exist, mind you.

The one I still remember: Clearfix

This one needs an ayahuasca trip to heal the trauma.

Have used all of them, and will use some of them even today

Comment conditionals still needed to render proper tables in email for different versions of Outlook.

My favourite was using iFrames as a type of ersatz AJAX. Click a link, make the target the iframe, an voila! No page refresh, and the iFrame gives visual feedback.

I recently did sort of the inverse as an experiment: put a button in a frame to avoid reloading the main page:

https://log.schemescape.com/posts/web-development/interactiv...

I remember running a project to build a mortgage calculator/spreadsheet 'app' for a bank that had to work in 'Dynamic HTML' in Netscape 4 and IE. A never ending hell of compatibility, functionality and appearance differences that took many sleepless nights to fix.

But hey, it gave us http://www.dynamicdrive.com!

Remember when we rounded corners using images placed at each corner.

It was a nightmare.

Another technique: 3 1-pixel <b>s per corner. For example, look at the buttons here https://web.archive.org/web/20070624110053/http://vkontakte....

Anyone remember DHTML chromeless windows? http://www.dynamicdrive.com/dynamicindex8/chromeless.htm

That conditional commenting is still amazingly prevalent. It's strange how many websites "don't support ie" but have three sets of conditions for different ie versions.

This is why "HTML/CSS/JS isn't supposed to be used like that" is a weak argument. Browser features we take for granted now grew from developers popularising hacks that pushed the boundaries (usually in ways people complained about at the time) until official support was gradually built into the browser e.g. AJAX, responsive layouts, complex/flex/grid layouts, reactivity with proxies, JavaScript modules, desktop-like web UIs in general.

TypeScript, JSX, Tailwind and bundlers come to mind of current trends that get some strong negative reactions but could become more mainstream later.

I still have a physical copy of, "Creating Killer Web Sites." That era of web dev was hacky and super fun.

wow - this was a great walk down memory lane. I remember using all of them, particularly tables for creating complicated layouts. it worked beautifully but was an unbelievable pain to maintain when making layout changes. what's wild though is that this technique eventually went way beyond the category of "hack". slicing tables into layout became officially supported by major software such as dreamweaver (big at the time) and photoshop! yes, you could open a static design in photoshop and use the "slice tool" to cut it up into an HTML table. good times...

filter:progid:DXImageTransform.Microsoft.AlphaImageLoader Brings me back

I will often slap a dumb 3 line http server into my long running tools / applications for debugging - provide ReSTful channel to toggle debug flags. I “learned” html in the 90s and don’t use it otherwise, so <table> figures prominently in generating the structure of the page.

11. Using JavaScript to build applications

The moment I saw filter:progid:DXImageTransform I had an urge to call my therapist. So much trauma in one article.

What about those weird proprietary HTML tags (ilayer, blink, etc.( that were not supported by both IE and Netscape Navigator that on first release required you to write the tag inside an HTML comment so as not to break the competing browser?

That not hacky enough to make this list? :)

Regarding the closing statement: I think, a major, now mostly forgotten influence were CD-ROMs and an ambition to match those.

<blink> don't forget

I fondly remember the times.

I'd built a site for Firefox and then conditionally import IE patches via those hacks to fix issues.

In the worst case, I'd hand to bludgeon it into the right form with JS, but usually I got pretty far with those CSS hacks.

Seeing the title of the article, it was surprising surprised to not use the use of xmlhttprequest to invent the category of JavaScript driven apps, by Microsoft no less.

Let’s be sure to call the programming style of using this function Ajax, and then create Microsoft Outlook for web as the first browser side Javascript app and modern JavaScript framework.

https://en.m.wikipedia.org/wiki/Ajax_(programming)

Walk down memory lane. I've used almost all of these over the nearly 27 years I've been doing web development. I kind of feel like the old float/clear and 1px x 1px transparent gif hacks should have been in there as well.

My favorite from 20 years ago: Doug Bowman’s “Sliding Doors” of CSS to make rounded corner tabs that would expand to fit the text: https://alistapart.com/article/slidingdoors/

Not a web dev, but I heard of this hack called XMLHttpRequest...

No love for the OG box model hack by Tantek Çelik?

Using a corrupted CSS 'voice-family' rule to make IE play nice: https://tantek.com/CSS/Examples/boxmodelhack.html

Those were the days...

Tldr: XHR

Notice how many of these hacks grew out of what was called the "pixel perfectionist" crowd in those days. The Web and HTML came out of a community that valued logically, semantically organized content. Communication was largely about words and ideas. If the result looked about as exciting as an academic paper, well, that was fine. The adoption by a community concerned with communicating with design, using color, layout, and other visual elements, came with a host of ways to squeeze it out of the limited capabilities of HTML.

Notice also how many of the hacks were about making it the design look the same in IE as in Netscape. Or in some cases, making it just work, at all, in IE while not breaking in Netscape or Opera or other browsers.

One could argue that this mix of competing rendering engines led to a great deal of creative discovery that drove future developments, and today we have, essentially 3 engines: Chromium, WebKit, and Quantum (formerly Gecko)

SWFObject deserves a shoutout if sIFR is getting one.

It was a JS library required just to get a cross-browser Flash player.

Putting an underscore in front of a CSS style

Not just underscores! You don't want to exclude Opera do you?! All types of hacks existed to target specific browsers. *+html anyone?

https://css-tricks.com/snippets/css/browser-specific-hacks/

http://browserhacks.com/

And PNGs for rounded corners. I can't remember what the term was when you took two images overlayed to make a rounded button that was resizable. Sliding door buttons?

And transparent gifs to set a width without being seen.

One more to add from the early days: widespread use of  , the character entity for a non-breaking space.

They were used to move text to the right to the left within a container. Or (IIRC) in table cells to make them behave, similar to 1x1 spacer gifs. Some pages had hundreds of nsps. Just kind of a general way to add margin or padding.

They were dark days. This is why I get agitated about browsers that don't properly support CSS standards in the present day, most notably Safari mobile. Garbage browser that should be illegal.

IE for Mac was great.

People forget that IE for Mac was the best & most standards compliant browser for Mac ~25 years ago.

All of the “IE hate”, was only directed at the Windows version … not the Mac version.

https://en.m.wikipedia.org/wiki/Internet_Explorer_for_Mac

Here’s Gruber also saying it was great.

https://daringfireball.net/linked/2020/01/06/grewel-ie-5-mac

I missed out on 1. because it was before my time, and I never needed 7., everything else I used at some point :D

I’m actually missing a bunch of CSS hacks for IE10+ and I think even early Edge version where MS said "No more conditional comments, we can now do everything"[0], but ended up still being buggy and incomplete and requiring special CSS to work properly.

[0]: I can kinda understand it. People had "if !IE" conditional comments, but they now supported that stuff. But they should just have changed the supported syntax, their browsers were still utter crap.

I developed extensively for IE6 back in the day and never actually used that underscore hack - found it too confusing in codebases. We'd use the asterisk html selector path instead. IE7 had a similar hack for marking off CSS using some first-child trickery, e.g:

    * html #myDiv { /* IE6 stuff */ }
    *:first-child + html #myDiv { /* IE7 stuff */ }

One could also trick IE6/7 into loading base64-encoded images in CSS by shoving in an mhtml boundary in CSS files.

Also love that the article called out sIFR - cannot believe I'd actually forgotten about that one.

https://www.youtube.com/watch?v=9sKppwrLBY8

Firefox ad from that era

One of the major differences between tables and block elements, is that block elements react to the context, and tables react to the content. I used to use "display: table" a lot, even on divs.

Nowadays, the block model has matured enough to moot the point, but back then, it was the best way to have content that didn't reflow, but would still be presentable.

"Creating Killer Web Sites." That brings back memories...

A lot of folks hated that book.

Wow. Remember those days. I went through all of these hacks except No. 7 & 8 (pre-header text hack, Google Chrome Frame). I'm not sure about the "Shaped the Internet" title, but these indeed go as defaults when starting a CSS project. In fact, one way to highlight front-end candidates was to include these hacks in interview questions.

Actual HTML title: "10 Weird HTML Hacks That Shaped The Internet"

Is there a difference between "the Web" and "the Internet".

As a loyal text-only browser user (not lynx or w3m), I have safely avoided all 10. It's possible for me to disable tables and normally I do. Breaking out of frames is one keypress.

Great article. I love everything related to the "old internet" (as you can see from my nostalgic point of view on some of my comments in Hacker News). Is there a good book about that particular time? I'd like to read a very good book about not just browsing the internet back then, but doing some kind of development (especially frontend, which I think it was the one that required most hacks and changed more than the backend in a few years)-