
Write HTML Like It's 1999 - bradley_taunt
https://bradleytaunt.com/2019/06/08/html-like-1999/
======
elderK
As someone who has a pretty serious visual impairment, I find the attitude of
so many of these comments really... disappointing.

You wouldn't believe how much effort people with poor vision have to go to, to
consume the modern web.

You can't even take simple things for granted like being able to zoom. So many
websites pollute their page with pointless navigation elements that block most
of the content when the page is zoomed.

Or say pages that try to be elegant, centering everything with some margin.
Sure, it looks "great" if no one zooms it. If you do, you wind up consuming
the content in three or four word chunks...

Or even worse: Elements that have hardcoded minimum widths. When you zoom,
nothing reflows and you wind up having tons of content "off screen."

At best, this is annoying because you have to constantly scroll horizontally.

At worst, you're screwed because for some bizarre reason, scroll bars never
appear.

I'll wrap my rant up here but I'll leave this:

Do you really want the web to be like reality, where the needs of a few are so
often ignored simply because of some trait?

"Oh, there are so few of them, why bother..." "Oh, they don't matter because
<whatever>"

Sound familiar? I'm sure you can fill in the blanks.

The web gives us a unique opportunity to improve on the real world in so, so
many ways.

Don't waste it.

~~~
HocusLocus
+++

I'd like to throttle the first person who ever decided that if the window
width would not 'comfortably' accommodate their vision of the page, certain
elements would just DISAPPEAR. Like GONE. When you have to zoom out to make
hidden elements (not just hanging off the edge, as in never drawn) appear...
someone has been naughty.

~~~
arendtio
Just a week ago I wanted to factory-reset an old router before dumping it.
Because my modern laptop doesn't have a LAN-connector, I used my old Eeepc
with a 7" display.

Everything worked just fine until I was on the page where I was supposed to
press the 'Confirm' button for the factory reset. It just wasn't anywhere and
I was wondering what I was missing. So I started to dig into the framesets and
finally found a frame where the code looked like there was that button.

Took me a while to find out how to press it (simply opening the frame in a
separate window didn't work because there was some JS magic involved). The
solution was to zoom out. So much fun when a task that was supposed to take 15
minutes takes 2 hours because someone built an over-the-top web-interface.

~~~
HocusLocus
> my modern laptop doesn't have a LAN-connector

I thew a head banging spittle-fit when laptops no longer carried RS232 ports.
Then my boss handed me a 'modern' laptop without an Ethernet port. The theme
seems to be, let the things evolve forward with LSI/VLSI/ChipsetBuiltins until
the port costs a mere 19 cents... then drop it... to save 19 cents.

------
lstamour
Was I the only one who clicked this expecting React components for modern CSS
layouts using markup like <img src="spacer.gif" width="390"> and <font
color="red" face="Helvetica,Verdana" size="7"><b>Last Updated: June
1999</b></font> Otherwise you’re not writing HTML like it’s 1999, you’re
writing HTML like it’s the web standards movement of the early 2000s before
AJAX and Web 2.0 started trending.

If you really want to write HTML like it’s from 1999, read this blast from the
past: [https://www.w3.org/TR/2018/SPSD-
html32-20180315/](https://www.w3.org/TR/2018/SPSD-html32-20180315/) Remember
image maps? That’s real <nav> (which is HTML5 a decade later, iirc)

But to address the point of the article, you can use JS or backend code to
enhance accessibility, such as by disabling focus on parts of a page when it
should be disabled, or setting h1-h6 tag levels dynamically based on nested
heading tags. If your aim is accessibility, this list may be useful:
[https://developers.google.com/web/fundamentals/accessibility...](https://developers.google.com/web/fundamentals/accessibility/a11y-for-
teams)

~~~
masswerk
While the spacer.gif made me really nostalgic, this is one of the things I
don't miss.

However, layoutwise HTML is at the moment much like it had been in 1999: The
basic structure with banner, nav, main, footer is much like the standard
frameset, if there had only been role/landmark-markup for frames, and CSS-grid
in its basic form is much like table-layout (less those Daliesque "poles" for
positioning). Where there had been those fancy CMS templates with modular
components, there are now frameworks… (However, JS is "a bit" more powerful
and has grown out of `document.write()`.)

That said,landmarks and aria-markup are really a great deal when it comes to
accessibility and are probably the most underrated additions to HTML.

~~~
Izkata
> However, JS is "a bit" more powerful and has grown out of `document.write()`

Wasn't innerHTML still settable back then?

~~~
lstamour
InnerHTML arrived as a proprietary IE 4 feature and IE 4 launched in 1997, so
yes. In Googling to double-check, I came across this little incompatibility:
[https://gist.github.com/jakearchibald/4489851](https://gist.github.com/jakearchibald/4489851)

~~~
masswerk
On the Netscape side of things innerHTML didn't arrive until NS Navigator 6.0.
For Netscape's dynamic HTML model with NS 4.x, it was still a matter of
opening a document stream and writing to it (`document.open()` …
`document.write()` … `document.close()`), in this case the document of a layer
or ilayer element (`document.layers[<layerName>].document`).

There was an interesting bug with `document.write()` in early versions of
Netscape Navigator: If you wrote to table cell (td) or row (tr) code
containing any embedding elements (like images or form elements) and there was
adjacent whitespace around the script tags, the embedding elements (images)
would show up twice. This was one of the more obscure bugs in the browser,
which likely prohibited a broader use of `document.write()` with dynamic
layouts etc at the time. However, if you knew the quirks, you could load data
objects in an invisible frame and render/update regions (frames or later
layers) much like today.

What was initially setable: Beginning with NS 2.0 (JavaScript1.0) the state of
form elements and window locations. Later (NS 3.0, 1996) also href and src
attributes of images and anchors (links), the document title, and you could
navigate the history, or call print() and find(), as well as manipulate a few
other things, like keyboard focus. Of course there were event handlers, but
they were quite specific for a few elements. (E.g., onclick or onmouseover
were available for links and images only.) More complex interaction (including
playing sound!) was possible via a proprietary Netscape Java/JS-bridge, called
"LiveConnect".

------
arendtio
While I agree that semantic HTML is a nice thing, I am also confused because
the HTML I saw in 1999 didn't look like what the author suggests. If I am not
completely mistaken, nav is an HTML5 element that didn't even exist back then.

Instead, we used tables inside tables insides tables inside iframes to
structure our navigations. CSS was still some mystic magic that only a few
wizards knew how to use effectively. And in many cases, the result was
actually less semantic than what we see nowadays.

So the arguments seem a bit odd, although I support the spirit of the message.

~~~
majewsky
> tables inside tables inside _framesets_

FTFY

~~~
lstamour
I was just about to say that. I also found that a surprising number of sites
that used framesets would also embed midi files as entertainment...

~~~
pierrec
I guess there's some logic to that. If you want the ability to navigate within
a website without restarting the music all the time, you need to implement
some kind of hack. Back then, it was frames. Nowadays, it's SPAs.

------
_bxg1
Really almost all of this comes down to, "don't use JavaScript to replace
HTML". Everything else on this post derives from that one guideline. For
example, "Implementing custom div layouts for forms while removing items like
select or radio" is only possible if you're replacing native functionality
with JavaScript.

Which is perfectly fine advice if you aren't doing anything really novel. You
probably don't need a custom library for dropdowns or forms or whatever else
and would gain performance, accessibility, and stability by hooking into the
native versions instead.

The one part I disagree with is necessarily using <table> in place of divs
with CSS Grid. The latter is native and is a perfectly legitimate replacement,
with some added benefits like responsiveness.

Also the title is a bit of a misnomer, because lots of the HTML features that
allow you to forego JavaScript are pretty recent:

[https://developer.mozilla.org/en-
US/docs/Learn/HTML/Forms/Fo...](https://developer.mozilla.org/en-
US/docs/Learn/HTML/Forms/Form_validation#Using_built-in_form_validation)

[https://developer.mozilla.org/en-
US/docs/Web/HTML/Element/da...](https://developer.mozilla.org/en-
US/docs/Web/HTML/Element/datalist)

[https://developer.mozilla.org/en-
US/docs/Web/HTML/Element/In...](https://developer.mozilla.org/en-
US/docs/Web/HTML/Element/Input/color)

~~~
doc_gunthrop
> Content being heavily reliant on JavaScript “injection”

Salient point right here. Being served a blank white page (when JS is
disabled) can deter a person from ever visiting a site again. Some peope out
there want to vet a site before allowing it to run arbitrary code on their
machine.

~~~
_bxg1
> run arbitrary code on their machine

That's a bit of an exaggeration. JavaScript is strongly sandboxed and has a
pretty good permissions system. The only malicious things it can really do are
1) based on cookies or 2) crypto mining.

Personally I think it's unreasonable to expect today's sites to work without
JavaScript completely. The real benefits of using it sparingly are:

\- Pages load faster

\- Pages are more responsive

\- Applications are less stateful and call out to systems that have a larger
number of eyes on them, making them less fragile and lowering maintenance
complexity

Minimalism is a virtue in any programming context

~~~
bo1024
3) Fingerprinting and tracking in general are heavily javascript-focused. Less
common in practice (I assume), but still possible, are 4) Rowhammer or
Spectre/Meltdown style attacks that break out of the permission system.
Finally, there's general trickery, manipulation, and malware, like trying to
embed a frame from Facebook and steal user credentials or so on (I'm fuzzy on
these sorts of attacks, not an expert).

~~~
_bxg1
3) Right - and I guess "fingerprinting" goes slightly beyond cookies - but
when people say "execute arbitrary code" they typically imply something has
free-reign, which JavaScript generally doesn't.

4) True, although it's my understanding that the exploits are hard to
implement, doubly-so from an abstracted layer like JavaScript.

> trickery, manipulation...like trying to embed a frame from Facebook and
> steal user credentials or so on

This falls under "cookies-based", and I'm pretty sure no JavaScript is
necessary for these kinds of attacks.

~~~
bo1024
Good point on 3. I guess the main point is browsers at least disallow reading
and writing arbitrary files directly.

------
whalesalad
Instead of a _border_ I tend to have a debug helper that adds a 1px _outline_
of cyan or pink. To get the “bones” of a component or page.

Good advice. Definitely sounds like captain obvious but it’s also something I
think needs to be said.

~~~
trnglina
And for anyone who isn't familiar with (what I would consider) the most
important difference in this use-case: borders affect the positioning of other
elements, whereas outlines do not. You don't want to be using a temporary
border, since it can significantly affect the layout of your site when you
remove it.

~~~
mdtusz
* { box-sizing: border-box; }

I have never wanted anything other than this behaviour, so I pretty much
always include it when starting on a fresh project.

~~~
adamwathan
Borders still affect the positioning of things even with box-sizing set to
border-box. For example, here "Block 1" is still two pixels taller than "Block
2":

<div style="padding: 8px; border: 1px solid black"> Block 1 </div>

<div style="padding: 8px;"> Block 2 </div>

[https://jsfiddle.net/t4rkvfzx/](https://jsfiddle.net/t4rkvfzx/)

~~~
GrantSolar
Does that really matter though? A difference of 2px for something temporary
doesn't seem like much concern. While I understand the implication is that
these can accumulate and cause larger layout issues, the purpose of this
practice is to highlight those areas to remove that accumulation anyway

~~~
ComputerGuru
The bigger issue is that you don't know if a UI inconsistency is a bug or a
side-effect.

------
kccqzy
So many people seemed to have forgotten what HTML in 1999 looked like. Layouts
done with <table>s. Extreme <table> nesting to get layout just right. 1px
spacer gifs everywhere. <font> tags. Very little CSS. Despair in the messiness
of HTML and hope XHTML or whatever XML-based alternative was going to eat your
lunch.

Semantic HTML only came back in the 2000s. Remember CSS Zen garden? Write HTML
once and style it differently to achieve completely different looks. Even
then, you had huge amount of CSS bugs. Like the voice-family hack or the

    
    
        * > html 
    

selector. Reading up on standards mode and quirks mode.

------
butz
It would be more convincing if you had provided examples, why bad HTML
practices are bad. For using nav element good example is screen reader use,
which will read all items if not using nav. Custom form controls usually make
developer life harder as they need to re-implement all functionality, that
browser already provides with standard form elements. There was a good article
about custom button implementation a while ago. Building tables from divs and
using "display: table" probably has been done to solve some complicated
responsive layouts. I have no examples here. Deep nesting usually makes
debugging harder and sometimes leads to unclosed tags. Javascript injection is
usually a bad thing and you should prevent it with CSP.

------
dehrmann
My biggest gripe with how modern html is written is not using <a> tags for
link-like things. I often center click to open links in new tabs (Chrome and
Firefox support this), but the way links have changed to <spans> with a
listener attached that navigates to a new page--sometimes in a new window--
really annoys me.

~~~
timClicks
That's one of the underlying messages of this article. We're replacing
elements with semantic meaning, such as <table>, with poorly implemented
alternatives. Discarding <a> is part of that.

Some web designers just really want full control, even if that makes for a
shoddy user experience.

------
vikingcaffiene
This is all well and good but front end devs often don’t code semantically
because frequently the designs we are asked to build aren’t idiomatic to the
web. It’s less about wanting to use a div and more about not being able to
style a frigging select box easily in a cross browser way (or add more
advanced things like multi select and what have you...

In other words, our first concern is making things easy to change. The
semantic web (at least some of it) just isn’t there yet.

I’ll finish by saying, that there are certain semantic elements that are safe
to use. In that case, by all means.

~~~
walshemj
id settle for front end devs not abusing flipping h tags

------
Causality1
My God that page is beautiful. Over half the vertical space is content without
me touching anything. No banner bar asking me to install some bullshit mobile
app. No 800-pixel panel at the bottom telling me what a cookie is. No
incredibly obnoxious warning that I only have one more free article before the
wisdom of the ages is lost to me so I'd better cough up five bucks.

~~~
indigodaddy
Agree. Is it a Jekyll theme or some totally customized template?

~~~
bradley_taunt
Just FYI - I've open sourced this Jekyll theme:
[https://github.com/bradleytaunt/taunt-
jekyll](https://github.com/bradleytaunt/taunt-jekyll)

~~~
indigodaddy
Cool, thanks a lot for that!

------
forgotmypw3
I want my website to work on any device you happen to have around, not just
the top 99% of the stats, but also the other 1%. Your 486 with Opera 3.62?
Come on by. iPad 1? You're welcome. You are allergic to JS? You still have the
basic features. JS is pepper and salt, used sparingly and best left up to the
diner. Netscape 3.04 Gold is on oldversion.com, runs on Wine without any
issues (ironically not on Windows 10), and there's no reason not to test with
it. So does Opera 3.62. Both are decent browsers capable of doing most things
a website needs. And yes, that means supporting HTTP, not just HTTPS. Are you
really that worried about your blog being mitmed?

------
justjonathan
It is embarrassing, but I only know how to write HTML like it’s 1999. The last
new thing I learned was an iframe, the kids tell me CSS something I should
learn...

~~~
isostatic
nah, newfangled stuff, cross browser compatability issues, not worth it - it
won't catch on

~~~
im3w1l
Keeping up is an endless treadmill. If your primary work is in some other
domain, say backend infra or some non-coding profession that writes a line
every blue moon, the investment may not pay off.

If you are a front-end dev it's of course a no-brainer to keep up.

------
josteink
> I’ve found a pretty simple starting point for testing the bones of a website
> by using the following single line of CSS

Or just use Firefox. The built in CSS-designer/debugger has a button to do
just this on demand.

Browser-suggestions aside, I really agree with the sentiment of this article.
That’s how I like to build sites and solutions when not forced to use some
other framework or approach.

------
snek
Using the correct semantic element goes a huge way for people using screen
readers and other assistive tech. One of the things I hate most about
react/vue is how casually people use divs for everything from inputs to
images. Over 20% of people use some assistive tech, whether that be zoom,
contrast controls, screen readers, etc. Even if you can't test all this, being
aware of it when building/coding is a huge step forward.

~~~
austincheney
I wrote a small tool to test for this
[https://github.com/prettydiff/semanticText](https://github.com/prettydiff/semanticText)

------
hestefisk
I hope there will be a return to simple web pages where HTML is used for
content, not apps. That’s the way the web was intended. Web assembly is nice
and all, but it does smell an awful lot like Java applets in 1997.
Proprietary, slow and hard to grok.

~~~
anthonybullard
I'm interested in hearing what is proprietary about wasm? It's a standard[1]
implemented in most browsers.

[1]: [https://www.w3.org/TR/wasm-core-1/](https://www.w3.org/TR/wasm-core-1/)

~~~
chj
You can't see the source code which I think is a huge step backward.

~~~
anthonybullard
I think that ship sailed a long time ago. With transpilation, minification,
and source mangling, the JavaScript ecosystem is largely opaque when trying to
view sources anyway.

------
enlyth
I feel like there's strong friction between HTML trying to semantically
describe the structure of a page page and JS frameworks where you try to build
custom reusable components which might not fall into the rigid structure
defined by classic HTML.

~~~
cljs-js-eval
The spec authors would have done better to make the semantic stuff attributes.
It's difficult to tell what CSS rules you're going to have to apply to any
given semantic tag, which makes people instinctively reach for <div>s and
<span>s. React native gets this right, with <Text> and <View> and just a
handful of others, with attributes like testID and accessibilityLabel driving
automated software that needs to read the screen.

------
devin
I’m a little confused by the title. Wasn’t nav introduced in HTML5?

Anyway, agree with what’s being said here. K.I.S.S.

~~~
rzzzt
The XHTML default namespace URL is
[http://www.w3.org/1999/xhtml](http://www.w3.org/1999/xhtml) in W3C's HTML5
documents (the link resolves to a page that lists references).

~~~
Tomte
There's no reason to "resolve" it. It's just a name, not a gettable resource.

------
no_gravity

        I’ve found a pretty simple starting point for
        testing the bones of a website by using the
        following single line of CSS:
        
           * {
               border: 2px dotted black;
           }
    

Another nice way to find obsolete elements is to simply type this in the
console:

    
    
        $$('*:only-child')
    

Elements with only one child usually can be optimized away. For example here
on HN, it shows that every <code> element is wrapped in a <pre> element. I
would think the same could be achieved by just setting the right styles on the
<code> element.

~~~
ddebernardy
That wouldn't necessarily be correct. <pre> is for preformatted. <code> is for
code. The first tells the browser it's preformatted (which, to your point, is
style related); the second tells you and the browser why that is -- it's code.

A poem might be a good example of something else you'd want to preformat.

Also, <pre> is a block element, while <code> is not.

The real issue is that there's something to be said about suggesting to write
<pre class="code"> and <pre class="poem"> etc., or for that matter <pre
type="whatever"> or simply <div class="whatever">. The real wtf here is that
<code> has a special status in html while <poem> and other things that might
want to be preformatted don't have their own tag. And that <pre> merely is a
special type of <div> with some styling (which suits code just fine, but not
poems) attached to it.

------
sandymcmurray
In 1999 I think I had just switched from HotDog to HomeSite. Honourable
mention to HoTMetaL and Microsoft FrontPage, which I tried then abandoned for
various reasons. Eventually I started using a plain text editor (BBEdit).

~~~
EdwardDiego
Oh my God, FrontPage, I used to edit pages built with it by hand for money.
Having flashbacks now. <font face="arial, arial, verdana"> everywhere.

------
HocusLocus
"Reach out and chat with me on Twitter. That way your thoughts aren't lost
forever on this site."

Funny I feel the other way. Twitter is rolling html flypaper with people stuck
to it. You can hear their muffled voices and see their wiggling legs as they
go past. Pages static'd with comments are forever, like web.archive.org
forever.

------
quickthrower2
Any reason it is bad to use divs with aria attributes over <input> for a radio
button choice? Because radio buttons are a pain to style and require all sorts
of hacks to look nice. And in a real job you sometimes get asked to brand
things, not just let the default styles come through.

~~~
runarberg
Aria attributes aren’t enough to make an element accessible. You still need to
set up listeners for keyboard navigation, you need to make the element
focusable, you need to remember the aria attributes for labeling, etc. Chances
are you are going to miss some of these. Better use a battle tested third
party library for these, or—better yet—the native `<input type="radio">`.

Edit: Radio buttons are _not_ hard to style[1]. Just use `appearance: none`[2]
and style them as you wish with custom background colors and svg masks and
whatnot.

\---

1\. [https://codepen.io/anon/pen/qGeJWL](https://codepen.io/anon/pen/qGeJWL)

2\. [https://developer.mozilla.org/en-
US/docs/Web/CSS/appearance](https://developer.mozilla.org/en-
US/docs/Web/CSS/appearance)

~~~
extra88
Yes, the First Rule of ARIA Use is first for a reason. [0]

Also for styling, visually hiding the <input type="radio"> and using a custom
radio-like icon with its associated <label> can be a decent option. Use a CSS
selector like this to "check" an icon with the label: #radio1:checked +
label::before

[0] [https://www.w3.org/TR/using-aria/#rule1](https://www.w3.org/TR/using-
aria/#rule1)

~~~
runarberg
Yes the `input[type="radio"]:checked + label::before` selector was for sure
used a lot in the past for greater browser compatibility.

But in 2019 I think it is safe to style the radio element directly along with
vendor prefixed `appearance: none;` possibly inside an `@supports` rule so
that IE users will fall back to the native style while users of modern
browsers get a custom style.

------
burgerzzz
Don't get me wrong, I used to write as semantic HTML as I could; nav for
navigations, table for table's, aside for well asides, etc as the author
suggests, but ultimately it just really doesn't matter. nav and div render
exactly the same. In fact, I find zero value in using ul/li's for lists that
aren't bulleted. I know it's an unordered list of items, but really, what _is_
the value in writing semantic HTML if the devs/browser/users don't care or
know the difference? Especially if you're changing the "semantic" element's
default behavior in order to get a look and feel or behavior that is far from
the original "semantic" intent.

~~~
tomhoad
> I find zero value in using ul/li's for lists that aren't bulleted

Browsers don't care. You may not care either. But people with disabilities
attempting to make sense of your website do, very much so.

There's absolutely no reason __not__ to use semantic HTML, and many reasons to
do so.

~~~
burgerzzz
Are you suggesting you can't write accessible Web applications without using
semantic HTML?

~~~
kungtotte
If you use semantic HTML you get a lot of accessibility for free, since screen
readers etc. all speak semantic HTML.

That doesn't mean you can't write accessible web applications without semantic
HTML, but it does mean you have to spend time adding the accessibility after
the fact.

------
woah
I've never understood the purpose of "semantic" html. It seems to be bandied
about as some sort of unquestioned good, but why? If the code is easy to
understand who cares that the "correct" tags have been used?

Obviously there are some benefits for screen readers and search engines, but
these uses should be explicitly checked for as part of a QA process instead of
relying on some vague standard of semanticness.

~~~
crazygringo
Honestly, there isn't, except for a small subset related to screen readers.

At one point there was a kind of hope that semantic tags would make web
content easily machine-parseable, unlocking a bunch of meaningful content
reuse somehow that better semantics would make possible. (Big data, ML and all
that.)

The two canonical examples being that lists were important so software could
extract meaning from list items, and not using tables for layout so software
could trust tables actually had meaningfully tabular data.

But... that never really happened, it's not clear it ever will, and it doesn't
benefit the content author directly anyways, so... yeah.

(Like you say, screen readers are the main thing, so use the tags and
attributes that are important to screen readers, like buttons and alt text...
but that's a very specific subset. A screen reader certainly doesn't care if
you use a <div> or an <li> or a <td>.)

Edit: I stand corrected on my example, for <td> specifically I forgot <table>
lets screen readers navigate vertically and also read column/row labels.

~~~
kolanos
> A screen reader certainly doesn't care if you use a <div> or an <li> or a
> <td>.)

It absolutely does. Try firing up a screen reader before you make such
comments spreading misinformation.

For example, it's maddening to see people now making tables out of flexbox
grids and such. In a screen reader you can navigate a <table> in two
dimensions (rows and columns). The flexbox variety completely breaks
navigating up/down columns.

------
eurg
Also: It's not just for blind people using screen readers; but also to improve
end-to-end testing.

Yes, nowadays we hook into React components themselves, or even if not we can
use those frameworks to strongly simplify writing selectors, because testing
libraries have some magic built into them to use the component hierarchy
directly...

... but depending on the amount of legacy and old in the app (and there will
be legacy, and old stuff), and how strongly E2E you want to go (like "survive
adding stuff from our team in that other city"), a "nav ul li[id='something']"
will work ok for the developer maintaining the code, even if it is not the
shortest possible selector; whereas a "div[...] div[...] div div + div" will
catch up with you, even if you think you abstracted it away.

------
SquareWheel
The author is arguing for semantic markup, but prior to HTML5 the concept
barely existed. Everything was kludged together. Site layouts were tables.
Later divs/spans ruled. Eventually sanity reigned and semantic elements were
introduced.

So while I don't disagree with what they're saying, the title is a bit of a
misnomer.

>[Don't] create tables built out of custom div elements

Tables aren't responsive. Those fancy div tables are used because they work
better on mobile. With a splash of JS (or overly-clever CSS) you can also
introduce interactivity, tabbed layouts, etc.

Unless dealing with a very small amount of tabular data, it's really hard to
recommend tables anymore.

Otherwise, yeah, fair advice. Nothing really too controversial in there.

~~~
glenscott1
> The author is arguing for semantic markup, but prior to HTML5 the concept
> barely existed

Not really. The concept existed and was well known in many developer circles
(e.g. List Apart Issue 268 from 2008
[http://alistapart.com/issue/268/](http://alistapart.com/issue/268/)).

~~~
SquareWheel
That's fair. Semantic markup did exist pre-HTML5. I guess I should say that
HTML5 emphasized it and drove adoption.

This article is from 2008, but I think it would be quite challenging to find
something similar from 1999.

~~~
combatentropy
Semantic HTML was already fashionable in late 2004, when I was a graphic
designer arguing against table tags. But my own exposure is a bad measure,
just as is anyone else's. One of the most famous groups pushing for well-
written HTML was WaSP, and it turns out that it was founded in 1998,
[https://en.wikipedia.org/wiki/Web_Standards_Project](https://en.wikipedia.org/wiki/Web_Standards_Project)

------
MH15
I'm a huge fan of the `* { border: 2px dotted black; }``` snippet he uses to
debug the flow of his content. I've been doing this for years now (albeit my
snippet is a bit different) but it helps so much for understanding the
document.

------
temp129038
I didn’t find this particularly insightful, and disagree with many of the
points made.

First of all the post is arguing for more semantic HTML and says nothing about
using semantic HTML5 tags over <div>? AFAIK semantic tags didn’t even exist
before HTML5 which is definitely not the 90s.

I also find using the <table> element generally be bad practice. There are
much better/easier ways to build responsive tables using grid or flexbox than
dealing with <tr>/<thead>/<td> everywhere.

~~~
kolanos
> I also find using the <table> element generally be bad practice. There are
> much better/easier ways to build responsive tables using grid or flexbox
> than dealing with <tr>/<thead>/<td> everywhere.

Try using that monstrosity in a screen reader. You completely break
vertical/column navigation. Hardly better.

------
jchw
Ironically, the lists on this page are paragraph tags.

~~~
plibither8
Since the page is built on Jekyll, I'm guessing the article's HTML has been
generated, thus explaining why paragraph tags are used.

Otherwise, one must explicitly use HTML to specify lists which is more
laboriousa nd not as neat because of mixed content. In the end it works either
way ¯\\_(ツ)_/¯.

~~~
jchw
I think I get what you’re saying, but let me repeat it to make sure I
understand: Jekyll, and of course Markdown, sites can use unordered lists, but
you would need to specify explicit HTML _for custom bullet points_ because
there’s no obvious way to generate list elements with a specific class in
Markdown.

That makes sense. I initially was confused because unordered lists themselves
are very easy in Markdown, and indeed will generate <ol>s.

------
pvitz
After reading the title, I thought I would see a proposal to use mostly tables
instead of divs for designing websites again...

~~~
bullen
I still use tables. Always when I need to position things relative to each
other and have them squish properly. I tried really hard to use/like divs but
they are not helping me most of the time.

~~~
err4nt
What I'll call 'table layout' can be done via CSS on any tags, you don't need
to use `<table>` elements to make use of the 'table layout' you like. Lately
CSS has added two new 'layout' modes you might like even better: Flexbox, and
CSS Grids. Both of these take the ideas from table auto-layout, using
constraints and content to help size things.

Separately from how you want things to look (CSS), you shouldn't be putting
content into `<table>` elements that aren't the sort of thing you'd put into a
spreadsheet. That's not using HTML well. Keep in mind you can still use the
table layout with other tags via CSS. Always wrap your content in the most-
fitting tag HTML has, then worry about the layout after :D

------
lhenk
Using `outline` instead of `border` won't actually affect the layout.

[https://developer.mozilla.org/en-
US/docs/Web/CSS/outline#Bor...](https://developer.mozilla.org/en-
US/docs/Web/CSS/outline#Borders_vs._outlines)

------
chx
If you want to write HTML like it's 1999 then you should use
[http://www.ihtml.com/](http://www.ihtml.com/) on the server side. I did.
Somehow this didn't scare me away for life from web development. Somehow.

------
xtracerx
This is not how people wrote html in 1999

------
jefftk
The article is completely missing an argument for why you should code pages
this way.

------
cgb223
If we’re writing HTML like 1999 then where’s my <blink> tag?

~~~
DaiPlusPlus
To be fair, <blink> is more 1994:
[http://www.montulli.org/theoriginofthe%3Cblink%3Etag](http://www.montulli.org/theoriginofthe%3Cblink%3Etag)

------
numlock86
> To be clear, I’m not advocating for creating projects that look like they
> belong in the 1990s.

Funny enough, only changing the body's background color to "lightgrey" and the
font face to "serif" makes it look exactly like that.

~~~
salutonmundo
it's better than "mid-2000s teenager"—purple on black with glitter gifs

------
harrydry
i like the border idea

------
mycall
zombo.com

