From dcfb172704f3afb68a30425029ec834be2883274 Mon Sep 17 00:00:00 2001
From: bt
Date: Sat, 8 Jun 2024 13:22:19 -0400
Subject: More content porting, on-going markdown changes for lowdown support
---
build/html-like-1999/index.html | 93 +++++++++++++++++++++++------------------
1 file changed, 52 insertions(+), 41 deletions(-)
(limited to 'build/html-like-1999')
diff --git a/build/html-like-1999/index.html b/build/html-like-1999/index.html
index b24d2fd..a9202ea 100644
--- a/build/html-like-1999/index.html
+++ b/build/html-like-1999/index.html
@@ -1,64 +1,75 @@
-
+
Write HTML Like It's 1999
-
-
+
+
+
-
Write HTML Like It's 1999
+
Write HTML Like It’s 1999
+
2019-06-06
-
I am sure it's safe to say that most developers love to use the latest and greatest web tools available. Helpful resources such as preprocessors, template engines, syntax formatters - you name it - can all make a developer's life easier. Unfortunately, this sometimes comes at a cost: the HTML structure.
-
This is why I try my best to write HTML as if I'm stuck with the constraints of the 90s (within reason). What does this mean exactly? It means that tables are coded with table elements. Navigations are coded with nav and ordered/unordered list-items. Form inputs are not set with display: none and replaced with custom containers. You know, semantic HTML.
-
To be clear, I'm not advocating for creating projects that look like they belong in the 1990s. I would just prefer developers / designers be more conscious of their HTML skeleton.
-
Bad HTML practices
-
Let's do a very simple breakdown of some of the more common HTML no-nos:
-
-
Using span or div elements for navigations or list components
-
Implementing custom div layouts for forms while removing items like select or radio
-
Creating tables built out of custom div elements
-
Over-nesting elements or making overly complex depth to simple components
-
Content being heavily reliant on JavaScript "injection"
-
-
Good HTML practices
+
+
I am sure it’s safe to say that most developers love to use the latest and greatest web tools available. Helpful resources such as preprocessors, template engines, syntax formatters - you name it - can all make a developer’s life easier. Unfortunately, this sometimes comes at a cost: the HTML structure.
+
+
This is why I try my best to write HTML as if I’m stuck with the constraints of the 90s (within reason). What does this mean exactly? It means that tables are coded with table elements. Navigations are coded with nav and ordered/unordered list-items. Form inputs are not set with display: none and replaced with custom containers. You know, semantic HTML.
+
+
To be clear, I’m not advocating for creating projects that look like they belong in the 1990s. I would just prefer developers / designers be more conscious of their HTML skeleton.
+
+
Bad HTML practices
+
+
Let’s do a very simple breakdown of some of the more common HTML no-nos:
+
+
Good HTML practices
+
So what should you do in place of these bad HTML implementations?
-
-
Use proper nav, ul and ol for navigations or list components
Build tables using table element structure (mind-blowing, I know!)
-
Keep element hierarchy as slim and top level as possible
-
Avoid injecting any content via JavaScript (I understand this is difficult for certain apps, but try to minimize this as much as possible)
-
-
My basic "structure" test
-
I've found a pretty simple starting point for testing the bones of a website by using the following single line of CSS:
+
+
My basic “structure” test
+
+
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;
}
+
This property simply outlines all elements on the current page in a dotted border. By placing a border on every HTML element you can instantly see how overly complex or ugly your structure might be under the hood.
-
"Thanks, Captain Obvious!"
-
I know, this stuff is pretty basic. The point of this post isn't to tell you (developers) something brand new or mind-blowing, but instead should inspire you to keep things simple.
-
Don't forget that there is always someone new into the world of design and development. Hopefully this post steers others towards keeping HTML code semantic and clean.
-
Update to this article
-
Since this post received so much more attention than I ever expected, I've decided to touch on a few small points brought up in the comments.
+
+
“Thanks, Captain Obvious!”
+
+
I know, this stuff is pretty basic. The point of this post isn’t to tell you (developers) something brand new or mind-blowing, but instead should inspire you to keep things simple.
+
+
Don’t forget that there is always someone new into the world of design and development. Hopefully this post steers others towards keeping HTML code semantic and clean.
+
+
Update to this article
+
+
Since this post received so much more attention than I ever expected, I’ve decided to touch on a few small points brought up in the comments.
+
-
What is the benefit of semantic HTML?
- - Accessibility. Programs like screen readers are built around the foundation of proper HTML hierarchy. I highly recommend testing all your projects with a screen reader - it will open your eyes to a lot of issues users with disabilities suffer through.
-
-
Tables not being responsive
- - This simply isn't true. It is much more semantic to layout your tables as you would normally, then for mobile devices you can target specific inner elements and alter them with flexbox etc. (You can see responsive tables in action here)
-
-
Instead of the CSS one-liner, simply use Firefox debugger
- - Fair point. Firefox is great!
-
+
What is the benefit of semantic HTML?
+
+
+
Accessibility. Programs like screen readers are built around the foundation of proper HTML hierarchy. I highly recommend testing all your projects with a screen reader - it will open your eyes to a lot of issues users with disabilities suffer through.
+
+
Tables not being responsive
+
+
+
This simply isn’t true. It is much more semantic to layout your tables as you would normally, then for mobile devices you can target specific inner elements and alter them with flexbox etc. (You can see responsive tables in action here)
+
+
Instead of the CSS one-liner, simply use Firefox debugger