Fun fact: the earliest browsers only supported color images of the GIF variety. I won’t get into the technical details here, but you can blame CompuServe for its creation.
No they didn’t, they didn’t support any images. The <IMG> tag was a introduced by NCSA Mosaic in 1993. I believe Netscape Navigator supported GIF and JPEG images from the start. TBL has later stated that the tag was a mistake because the alt text was an attribute which meant that earlier browsers didn’t gracefully fall back to rendering the text (and because it didn’t nest, so you couldn’t do <img src="foo.png" type="png"><img src="foo.gif" type="gif">an amazing image</img></img> to provide PNGs to browsers that understood them and GIFs to ones that didn’t. The object and embed tags were meant to address these limitations (and let you do things like have a video that gracefully fell back to an animated GIF, then a static GIF, then text).
Also don’t forget XBM, which I believe was added at the same time. The rule of thumb was JPEG for photographic images, GIF for solid-color images, and XBM for small black-and-white images. (Quote-unquote black-and-white … actually they were generally rendered in the page’s native coloring, which was usually black-and-light-gray.)
I always smile when I read about the table tag. The reality was it was great for consistent layouts for a long time as CSS was broken in various ways. If they had called the table tag grid and had another one called “layout” I think we would not have had the same history with CSS.
Tables are a PITA to style well. It’s fine as long as you can guarantee a screen size, but as soon as you need to have any flexibility at all, it falls over. I’ve had lot of situations where the data I need to style is basically tabular (a list of election candidates, for example), and it’s a headache trying to make it work on a phone. It’s easier to use plain old blocks and fake a table than vice versa. And that’s ignoring flex and grid, which are great.
What? Tables were a huge source of many of the quirks that make quirks mode - tables were exceedingly broken, just like CSS you had to be very careful what you used, and how you used it, or things would just break. Pixel precise layout with tables required immense effort, and was only used because of how bad the rest of IE’s layout engine was.
If you’re always smiling I question how much time you actually spent trying to get table layout to match between browsers.
I blame the hiring managers who insist on hiring print designers for web work and the product managers who pretend the print designers should have final say on all design issues. The designers themselves are doing the best they can with a toxic situation.
If you were trying pixel precise layouts with tables you were doing something wrong. Tables were useful for dynamic flow layouts. I’m sorry you tortured yourself for years. Perhaps you should find another profession.
No, I spent most of my time ensuring other - very large - sites worked correctly in WebKit, where I did a moderate amount of the layout and rendering logic over the years.
People expected to be able to do pixel layout in browsers, and so people were able to approximate pixel layout in browsers.
but all modern browsers automatically redirect to HTTPS
Just tested it with chromium (version 101.0.4951.41-1~deb11u1) and this is not true.
just don’t force an HTTP => HTTPS redirect on your users
The problem with this: As soon as you have an service where at least one user has a security requirement you don’t want to break all possibilities to avoid https can used to break his security. So as soon as you allow login on the domain you might want to protect the credentials. But also for content only, you might want to protect the users from getting the contend changed. Injected ads[0] are the one think, but what about replacing your cat pictures with porn? Not to forget about exploits, special for older software with known bugs.
Yes a redirect don’t solve this in a proper way, but it makes it harder for an attacker.
As soon as you have an service where at least one user has a security requirement you don’t want to break all possibilities to avoid https can used to break his security
Worse, as soon as you provide a support for non-HTTPS connections you introduce a number of ways for people do do downgrade attacks. Someone able to MITM your connection just enough to cause packets to drop can just block the HTTPS port and make normal users fall back to the HTTP URL. A more active adversary can also then rewrite the unencrypted things to prevent you from moving to the HTTPS version.
Only enable HTTP if you want to reason about all of these threat models. If you don’t, then just stick to a recent TLS as the only option.
Relevant to this article, I don’t redirect because I’m supporting very old browsers intentionally. But I suppose that’s the whole point. There’s HSTS available for those who want it.
Problem with HSTS is, that it only triggers if you connect with https. Currently some browsers still first try to connect with http, when you only enter a domain. As far as I know there is currently no way to have a site available as http and https while directing all modern clients to the https variant.
I understand what the intention of the article is, I just wanted to point out some downsides of such decisions.
No they didn’t, they didn’t support any images. The
<IMG>tag was a introduced by NCSA Mosaic in 1993. I believe Netscape Navigator supported GIF and JPEG images from the start. TBL has later stated that the tag was a mistake because the alt text was an attribute which meant that earlier browsers didn’t gracefully fall back to rendering the text (and because it didn’t nest, so you couldn’t do<img src="foo.png" type="png"><img src="foo.gif" type="gif">an amazing image</img></img>to provide PNGs to browsers that understood them and GIFs to ones that didn’t. Theobjectandembedtags were meant to address these limitations (and let you do things like have a video that gracefully fell back to an animated GIF, then a static GIF, then text).Also don’t forget XBM, which I believe was added at the same time. The rule of thumb was JPEG for photographic images, GIF for solid-color images, and XBM for small black-and-white images. (Quote-unquote black-and-white … actually they were generally rendered in the page’s native coloring, which was usually black-and-light-gray.)
Wow, I’d forgotten about XBM. It was an awful format, 5-6 bytes to encode 8 bits of information. GIF was almost always smaller.
Yeah, it was never meant to be small – just convenient to C programmers.
Eh? Surely, the
<style>section should be in your page’s<head>, not in its<body>. No workaround HTML comments needed.I always smile when I read about the table tag. The reality was it was great for consistent layouts for a long time as CSS was broken in various ways. If they had called the table tag grid and had another one called “layout” I think we would not have had the same history with CSS.
Tables are a PITA to style well. It’s fine as long as you can guarantee a screen size, but as soon as you need to have any flexibility at all, it falls over. I’ve had lot of situations where the data I need to style is basically tabular (a list of election candidates, for example), and it’s a headache trying to make it work on a phone. It’s easier to use plain old blocks and fake a table than vice versa. And that’s ignoring flex and grid, which are great.
I’m older than you and I’m talking about the pre-phone days. 90’s through around 2010.
I made my first website in 1997. :-)
What? Tables were a huge source of many of the quirks that make quirks mode - tables were exceedingly broken, just like CSS you had to be very careful what you used, and how you used it, or things would just break. Pixel precise layout with tables required immense effort, and was only used because of how bad the rest of IE’s layout engine was.
If you’re always smiling I question how much time you actually spent trying to get table layout to match between browsers.
“Pixel precise” is normally a phrase that indicates doing something horribly wrong. Pixels are not real
Blame the site designers, they’re the ones making layouts based on absolute pixel positions
I blame the hiring managers who insist on hiring print designers for web work and the product managers who pretend the print designers should have final say on all design issues. The designers themselves are doing the best they can with a toxic situation.
If you were trying pixel precise layouts with tables you were doing something wrong. Tables were useful for dynamic flow layouts. I’m sorry you tortured yourself for years. Perhaps you should find another profession.
No, I spent most of my time ensuring other - very large - sites worked correctly in WebKit, where I did a moderate amount of the layout and rendering logic over the years.
People expected to be able to do pixel layout in browsers, and so people were able to approximate pixel layout in browsers.
Just tested it with chromium (version 101.0.4951.41-1~deb11u1) and this is not true.
The problem with this: As soon as you have an service where at least one user has a security requirement you don’t want to break all possibilities to avoid https can used to break his security. So as soon as you allow login on the domain you might want to protect the credentials. But also for content only, you might want to protect the users from getting the contend changed. Injected ads[0] are the one think, but what about replacing your cat pictures with porn? Not to forget about exploits, special for older software with known bugs.
Yes a redirect don’t solve this in a proper way, but it makes it harder for an attacker.
[0] https://www.pcworld.com/article/435150/comcasts-open-wi-fi-hotspots-inject-ads-into-your-browser.html
Worse, as soon as you provide a support for non-HTTPS connections you introduce a number of ways for people do do downgrade attacks. Someone able to MITM your connection just enough to cause packets to drop can just block the HTTPS port and make normal users fall back to the HTTP URL. A more active adversary can also then rewrite the unencrypted things to prevent you from moving to the HTTPS version.
Only enable HTTP if you want to reason about all of these threat models. If you don’t, then just stick to a recent TLS as the only option.
Relevant to this article, I don’t redirect because I’m supporting very old browsers intentionally. But I suppose that’s the whole point. There’s HSTS available for those who want it.
Problem with HSTS is, that it only triggers if you connect with https. Currently some browsers still first try to connect with http, when you only enter a domain. As far as I know there is currently no way to have a site available as http and https while directing all modern clients to the https variant.
I understand what the intention of the article is, I just wanted to point out some downsides of such decisions.
You could add your domain to the hsts preload list
I’m aware of that and there’s no good solution to it, but if you access it over TLS you’ll get a header, and it will stay secure.