It's far from clear to me that flexbox actually solves the problem. For example, consider the following:
<table style='height: 100%; width: 100%'>
<tr><td align=center valign=center>
<h1>Hello world</h1>
The following button should be centered:<br>
<button>Button</button>
</td></tr>
</table>
Can you reproduce that with flexbox? In a way that works across all browsers? Without writing huge amounts of code?
[NOTE: This example has a bug in it. See the subsequent comments]
Margin: auto doesn't center vertically. Also, it only centers the element that it applies to, not the contents of that element. My example was supposed to illustrate this, but it actually has a bug. I thought buttons didn't get centered by text-align, but they do. Here's an updated example:
<table style='height: 100%; width: 100%'>
<tr><td align=center valign=center>
<h1>Hello world</h1>
The following green square should be centered:<br>
<div style='width: 30px; height: 30px; background: green'></div>
</td></tr>
</table>
margin:auto also requires you to manually set the width of the div you're trying to center in order to work.
Display: table is cheating, and essentially conceding that you should have been using tables all along. And there is no such thing as display: inside-block. (You probably meant inline-block.)
The devil is in the details. I believe if you try it you will find it is nowhere near as easy as you imagine.
> Display: table is cheating, and essentially conceding that you should have been using tables all along.
Not at all. "display: table" (and the related "display: table-cell" and similar) mean that you've written something which is not semantically a table, but which should use the browser rendering conventions of a table. That's a perfectly reasonable distinction.
Otherwise, would you suggest that every use of "font-family: sans-serif" is cheating and essentially conceding that you should have been using a <font> tag all along?
Even if you argue that HTML tags don't have semantic meanings (which I'd strongly disagree with, pointing to numerous tools that derive useful semantic information from such tags), there's quite a lot of value in defining your markup in terms of semantics and then separately defining what you want those semantics to look like. With good semantic markup, you can easily retheme your site to look completely different, make it scale to a mobile UI, or make it accessible to users of screen readers.
So, there's a major difference between using font-family and a <font> tag, and a major difference between using display: table* and <table>/<tr>/<td> tags. And for the same reason, you shouldn't use class="sidebar" if what you mean is class="navigation" (or for that matter <nav>). Let alone class="big-red-button" when what you mean is class="delete".
To use an example from that article: sure, <p> is not as semantically significant as <section> or <h1>, but it's a lot more semantic than, say, <br/><br/>, which I've seen used between paragraphs. "This is a paragraph" is more semantically useful than "this has an indent on the left and 1.4x line spacing"; "this is a heading" is more semantically useful than "this is 24pt and bold".
Vertically centered on Chrome Mac as well. Safari (and IE) still requires a vendor prefix to use flexbox, but with that added, it works in Safari as well:
CSS-based layouts, done right, still leave the underlying HTML heavily semantic. And even with a few extra un-semantic divs and spans around, you can just ignore those. The two biggest problems would be with sites that don't bother to put content in a sensible semantic order (putting huge amounts of sidebar/navigation content before the main content) and sites that generate everything with JavaScript with no fallbacks.
If what you're building is actually a table, use table markup; that's the semantically correct markup. Just don't use it for something like a sidebar or footer, or otherwise for positioning.
But even if you use a div, as long as the semantic content makes sense without the div, you're fine. For instance, put one div with your article content starting with an appropriate heading tag, and another div for your navigation. Without the CSS, it still makes sense to have a section for content and a section for navigation.
Also, there is actually CSS markup to make something look like a table, if that's what you want; see http://caniuse.com/#feat=css-table for instance.
I agree with everything you're saying, but I'm not sure what this is a response to? The site layout looks acceptable on this 30 years old computer precisely because it does not care about semantics.
When I was in elementary school and used to do this many years ago, the best way to connect a Mac Plus to the web was to use a Mac new enough to support Ethernet but old enough to support MacIP, and use IPNetRouter (http://www.sustworks.com/site/downloads_classic.html) to bridge TCP/IP over Ethernet to MacIP over LocalTalk, then use a serial cable (or the old PhoneNet adapters) between the two computers. That requires more old hardware to act as a bridge, but yields a blazing fast 230 kbps network connection.
Oh, yes, IPNetRouter was my first exposure to NAT. That horrible, infuriating technology. But NAT works so much better than SOCKS proxies, especially since my first attempt at "Internet Connection Sharing" was with a SOCKS proxy on Windows 95. I remember when opening more than a couple copies of AOL Instant Messenger meant that Windows ran out of sockets and we weren't able to load any web pages.
Another way to copy files over is to put the scsi hard driver in a modern computer running Linux. There are some userspace tools to access the hfs formatted hard drive. I had good luck with them.
I would love to try something like this on my SE/30 but sadly it doesn't have any useful software on it other than a 1989 copy of MS Word and lemmings. Any ideas how to get some new files onto it without a terminal?
The SE/30 at least had a PC-compatible floppy drive. If you could find a disk image with the desired software, a floppy disk, and a computer with a floppy drive, then you could transfer software that way.
But a lot of Mac disk images might be in some weird Apple-proprietary Disk Copy format. I think modern Disk Utility may be able to open them. I'm not sure. I haven't tried anytime recently.
Jeff mentioned a Zip drive. You could try that, too, if you have USB and SCSI Zip drives. Files are much more likely to transfer correctly if you use a Mac instead of Windows.
"A few weeks ago I was walking along the street in Cambridge, and in someone's trash I saw what appeared to be a Mac carrying case. I looked inside, and there was a Mac SE. I carried it home and plugged it in, and it booted. The happy Macintosh face, and then the finder. My God, it was so simple. It was just like ... Google." ~ Great Hackers, Paul Graham
such a great article, thanks for @teuobk writing this & @franze for re-posting this. It means I can have a crack at using the classic as a web client/proxy. I'm still up to the lets plug a modern keyboard and mouse stage but this is a great push forward to connecting to the network, the hard bit: MacPlus and TCP/IP.
People have been able to access the Internet from a C64 (1982) - there's even several browsers available ( http://www.c64-wiki.de/index.php/Webbrowser ) - and that's a far less powerful machine than this Mac. Compared to a 1MHz 6502 with a 64K address space, an 8MHz 68000 (32-bit!) with a few MB of RAM and a 16MB flat address space is spacious.
Too bad the demoscene didn't really catch on with Macs for some reason... the hardware is theoretically quite capable and I'm sure they could've done some awesome effects with it if they tried.
48 comments
[ 4.1 ms ] story [ 91.0 ms ] threadSay what you will about table based layouts, but they sure are backwards compatible.
Still valid after all these years.
[NOTE: This example has a bug in it. See the subsequent comments]
The devil is in the details. I believe if you try it you will find it is nowhere near as easy as you imagine.
Not at all. "display: table" (and the related "display: table-cell" and similar) mean that you've written something which is not semantically a table, but which should use the browser rendering conventions of a table. That's a perfectly reasonable distinction.
Otherwise, would you suggest that every use of "font-family: sans-serif" is cheating and essentially conceding that you should have been using a <font> tag all along?
Yes, if your intent is to use font-family as an example in an argument for using CSS.
> and essentially conceding that you should have been using a <font> tag all along?
No, I'm saying that a font tag and a font-family style are equivalent. One is as good as the other.
You should read this:
http://blog.rongarret.info/2009/02/on-semantics-of-html.html
So, there's a major difference between using font-family and a <font> tag, and a major difference between using display: table* and <table>/<tr>/<td> tags. And for the same reason, you shouldn't use class="sidebar" if what you mean is class="navigation" (or for that matter <nav>). Let alone class="big-red-button" when what you mean is class="delete".
To use an example from that article: sure, <p> is not as semantically significant as <section> or <h1>, but it's a lot more semantic than, say, <br/><br/>, which I've seen used between paragraphs. "This is a paragraph" is more semantically useful than "this has an indent on the left and 1.4x line spacing"; "this is a heading" is more semantically useful than "this is 24pt and bold".
I completely agree. But HTML+CSS does not achieve that goal, at least, it didn't when that post was written.
Here's a working example that doesn't use tables: https://jsfiddle.net/q8zxxr3b/
Or, here's the inline example:
https://jsfiddle.net/k281a8v0/
Could you give an example? I've done "tables" in CSS, and most of the time you're using DIV to manage most of the positioning, which is non-semantic.
If there was a CSS table replacement which defaulted back to something which looked like a table in HTML, I'd be impressed.
If you're building a navigation area, a callout, or some similar semantically significant sidebar, take a look at https://html.spec.whatwg.org/multipage/dom.html#sectioning-c... for the nav and aside elements.
But even if you use a div, as long as the semantic content makes sense without the div, you're fine. For instance, put one div with your article content starting with an appropriate heading tag, and another div for your navigation. Without the CSS, it still makes sense to have a section for content and a section for navigation.
Also, there is actually CSS markup to make something look like a table, if that's what you want; see http://caniuse.com/#feat=css-table for instance.
http://www.keacher.com/1216/how-i-introduced-a-27-year-old-c...
And here's the HN discussion from last time:
https://news.ycombinator.com/item?id=6892935
Pretty misleading of them to date it March 22, 2015, but perhaps that was just a technical glitch.
http://blog.rongarret.info/2008/06/bugged-life.html
http://flownet.com/ron/plisp.html
I'll fix the blog post too.
https://news.ycombinator.com/item?id=6892935
Mods changed the URL to point to the original.
Ahh... the memories! Though for me it was 300 baud on an LSI ADM-3a with an acoustic coupler.
http://bytecollector.com/lsi.htm
But a lot of Mac disk images might be in some weird Apple-proprietary Disk Copy format. I think modern Disk Utility may be able to open them. I'm not sure. I haven't tried anytime recently.
Jeff mentioned a Zip drive. You could try that, too, if you have USB and SCSI Zip drives. Files are much more likely to transfer correctly if you use a Mac instead of Windows.
And I do mean images that you can just use dd to write to the floppy. Then you just need a USB floppy drive.
It has been a few years since I tried that though.
So I'm going down a street and I see a Mac being thrown out :) ~ https://www.flickr.com/photos/bootload/14378861885
such a great article, thanks for @teuobk writing this & @franze for re-posting this. It means I can have a crack at using the classic as a web client/proxy. I'm still up to the lets plug a modern keyboard and mouse stage but this is a great push forward to connecting to the network, the hard bit: MacPlus and TCP/IP.
Too bad the demoscene didn't really catch on with Macs for some reason... the hardware is theoretically quite capable and I'm sure they could've done some awesome effects with it if they tried.
http://www.unrealvoodoo.org/projects/three-and-a-half-inches...