28 ms·

Write HTML Like It's 1999

254 points by bradley_taunt 7y ago

hestefisk 7y ago
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 7y ago
  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 7y ago
    You can't see the source code which I think is a huge step backward.
    - anthonybullard 7y ago
      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.
sandymcmurray 7y ago
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 7y ago
  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.
- dsparkman 7y ago
  To this day, HomeSite was my favorite HTML editor. The Allaire ColdFusion Studio variant, my favorite IDE for a language. Everything went downhill when Macromedia purchased Allaire, and we got Dreamweaver.
MH15 7y ago
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.
jefftk 7y ago
The article is completely missing an argument for why you should code pages this way.
mycall 7y ago
zombo.com
elderK 7y ago
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 7y ago
  +++ 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.
  - dleslie 7y ago
    But it's reactive! Clearly by zooming in the user wants a more minimal display with less elements, right? /S
  - arendtio 7y ago
    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 7y ago
"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.
xtracerx 7y ago
This is not how people wrote html in 1999
forgotmypw3 7y ago
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?
josteink 7y ago
> 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.
whalesalad 7y ago
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.
- dillonmckay 7y ago
  I also make the body background pink and the outline a different color.
- trnglina 7y ago
  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 7y ago
    * { 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 7y ago
      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 7y ago
        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
enlyth 7y ago
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 7y ago
  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.
- rangerpolitic 7y ago
  That's because people are trying to use HTML for applications rather than documents.
Causality1 7y ago
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.
- HocusLocus 7y ago
  Looks great on my 900x1600 monitor... portrait just like the content I read. Using a tall not wide monitor makes reading more fun than watching movies! Mom would be proud.
- indigodaddy 7y ago
  Agree. Is it a Jekyll theme or some totally customized template?
  - bradley_taunt 7y ago
    Just FYI - I've open sourced this Jekyll theme: https://github.com/bradleytaunt/taunt-jekyll https://github.com/bradleytaunt/taunt-jekyll
    - indigodaddy 7y ago
      Cool, thanks a lot for that!
  - saagarjha 7y ago
    Might be backed by this: https://github.com/bradleytaunt/accssible https://github.com/bradleytaunt/accssible?
  - bradley_taunt 7y ago
    It's just my personal Jekyll theme I custom made. I plan to open source it very soon (I didn't think there was any interest lol)
- 7y ago
devin 7y ago
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.
- tambourine_man 7y ago
  Yes it was. It also bothered me while reading. I think he’s advocating for semantic HTML, not 90s HTML
- isostatic 7y ago
  It was. So was styling form elements. The idea isn't to pretend it's 1999 and only use stuff that works in netscape4/IE5, but to build pages in the same way as then. <nav> adds something useful - it helps screen readers out, but costs nothing.
- rzzzt 7y ago
  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 7y ago
    There's no reason to "resolve" it. It's just a name, not a gettable resource.
pvitz 7y ago
After reading the title, I thought I would see a proposal to use mostly tables instead of divs for designing websites again...
- bullen 7y ago
  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 7y ago
    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
justjonathan 7y ago
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 7y ago
  nah, newfangled stuff, cross browser compatability issues, not worth it - it won't catch on
  - im3w1l 7y ago
    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.
- krapp 7y ago
  I legitimately remember the day I first saw an iframed site and how cool I thought it was. God I'm old.
- rolltiide 7y ago
  iframes have had a wild ride in acceptance 1999 - Cool and Clever 2005 - Horrible 2010 - Horrible but sometimes necessary 2015 - Awesome
  - majewsky 7y ago
    > 2015 - Awesome Huh, what happened?
    - EdwardDiego 7y ago
      We started injecting everyone else's JS everywhere.
    - d_k_f 7y ago
      Limitations imposed upon embedded scripts from foreign domains by technologies like CORS and the like, combined with modern styling abilities. You can place another service's elements on a page that look like they're actually part of the page layout while the JS running them can freely communicate with the service's backend without having to bother with cross domain problems. Think of all the support/chat widgets you see on modern-day pages, they're all iframes. And obviously: tracking all the things!
woah 7y ago
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.
- patrick5415 7y ago
  Because the idea that one can separate content from presentation appears as an elegant Platonic ideal to a lot of folks. The trouble seems to be that content and presentation are not actually disjoint sets. And (a perhaps different) set of folks want a slice of the juicy middle.
- tomhoad 7y ago
  > explicitly checked for as part of a QA process After you've written the application? That makes absolutely no sense, unless you enjoy renaming lots of elements. > instead of relying on some vague standard of semanticness It's not vague, there is an actual international standard... WCAG!
- pbhjpbhj 7y ago
  Screen readers, distilled/simplified views, other automated parsing. Things like marking up addresses, phone numbers - as examples - means that a search engine can log a website as associated with a particular address, a browser can link to enable a number displayed to be called direct. If for example there was a microformat (or other semantic markup) for opening times then SE/social sites could read and display (and update) that info without owners having to go on 20 sites if they change opening times. Of course it can also help infer which parts of a page are advertising, or impressum, and not render that. A plugin could offer to work on tables, or import them to a spreadsheet. Lots of scope for advanced automations.
- LocalH 7y ago
  When done properly, it increases the separation between the actual content, and the styling on top of it. Any time you get closer to that ideal separation, accessibility is enhanced (and it’s also forward-thinking towards yet-unknown methods of accessibility assistance).
deleted 7y ago
[deleted]
burgerzzz 7y ago
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.
- detaro 7y ago
  Ever tried to use your pages with a screen reader? It's quite an interesting (and potentially maddening - screen readers are power-user tools, and quite difficult to get into if that's not how you normally operate) exercise.
  - strken 7y ago
    I tried doing this once, and I wasn't even able to install the damned thing. If you've got any advice or instructions on how to get started with a screen reader for testing purposes, I'd be really interested.
    - syntheticcdo 7y ago
      VoiceOver is built into OSX and is fairly full featured. Anything for Windows is either expensive or half baked IMO.
      - extra88 7y ago
        NVDA is free and not half-baked. In some respects, NVDA works better on the web than the expensive, dominant screen reader, JAWS.
    - detaro 7y ago
      On Windows I tried NVDA and the demo version of JAWS. Installation worked without issues for me, and I looked for tutorials on how to use them/put up the keyboard shortcut overview. Sorry I can't point you to anything more specific right now.
vikingcaffiene 7y ago
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 7y ago
  id settle for front end devs not abusing flipping h tags
no_gravity 7y ago
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 7y ago
  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.
SquareWheel 7y ago
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 7y ago
  > 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/).
  - redwall_hp 7y ago
    HTML5 was honestly the opposite. XHTML and XHTML2 were born of a desire to have stricter, more semantic markup. But we live in the shitty timeline where XHTML2 died and we got HTML5 instead.
  - SquareWheel 7y ago
    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 7y ago
      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
butz 7y ago
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.
lstamour 7y ago
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/a11y-for-teams https://developers.google.com/web/fundamentals/accessibility...
- masswerk 7y ago
  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 7y ago
    > However, JS is "a bit" more powerful and has grown out of `document.write()` Wasn't innerHTML still settable back then?
    - lstamour 7y ago
      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
eurg 7y ago
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.
temp129038 7y ago
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 7y ago
  > 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 7y ago
Ironically, the lists on this page are paragraph tags.
- plibither8 7y ago
  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 7y ago
    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.
- bradley_taunt 7y ago
  Yes that was an overlook on my part when formatting the markdown file. Fixed now!
numlock86 7y ago
> 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 7y ago
  it's better than "mid-2000s teenager"—purple on black with glitter gifs
_bxg1 7y ago
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/Form_validation#Using_built-in_form_validation https://developer.mozilla.org/en-US/docs/Learn/HTML/Forms/Fo... https://developer.mozilla.org/en-US/docs/Web/HTML/Element/datalist https://developer.mozilla.org/en-US/docs/Web/HTML/Element/da... https://developer.mozilla.org/en-US/docs/Web/HTML/Element/Input/color https://developer.mozilla.org/en-US/docs/Web/HTML/Element/In...
- doc_gunthrop 7y ago
  > 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.
  - darepublic 7y ago
    Hence the move toward static site frameworks like react static and gatsby
  - _bxg1 7y ago
    > 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
chx 7y ago
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.
cgb223 7y ago
If we’re writing HTML like 1999 then where’s my <blink> tag?
- DaiPlusPlus 7y ago
  To be fair, <blink> is more 1994: http://www.montulli.org/theoriginofthe%3Cblink%3Etag http://www.montulli.org/theoriginofthe%3Cblink%3Etag
dehrmann 7y ago
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 7y ago
  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.
kccqzy 7y ago
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.
arendtio 7y ago
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.
- dosy 7y ago
  I think clearly author was using "like it's 1999" as a metaphor, not literally. It's a fairly common phrase (originating from a Prince song I think) that you can take to mean "like a throwback to a more authentic and possibly prior era." In this case the era is prior the explosion of frameworks and div soup. Which strangely in this case is not necessarily prior but in parallel, as you said. This is English, it doesn't have to be precise like programming. You can use it for effect.
  - Izkata 7y ago
    Funny enough, that song is from 1982. It's looking forward towards the end of the world on 2000-01-01, and to "party like it's 1999".
- majewsky 7y ago
  > tables inside tables inside framesets FTFY
  - lstamour 7y ago
    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 7y ago
      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.
harrydry 7y ago
i like the border idea
quickthrower2 7y ago
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.
- tuespetre 7y ago
  No, not unless you are for some reason doing something the intended audience’s browser may not support
- runarberg 7y ago
  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 7y ago
    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 7y ago
      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.
lhenk 7y ago
Using `outline` instead of `border` won't actually affect the layout. https://developer.mozilla.org/en-US/docs/Web/CSS/outline#Borders_vs._outlines https://developer.mozilla.org/en-US/docs/Web/CSS/outline#Bor...
snek 7y ago
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 7y ago
  I wrote a small tool to test for this https://github.com/prettydiff/semanticText https://github.com/prettydiff/semanticText

254 points by bradley_taunt 7y ago

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 7y ago
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 7y ago
  You can't see the source code which I think is a huge step backward.
  - anthonybullard 7y ago
    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.

sandymcmurray 7y ago

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 7y ago
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.
dsparkman 7y ago
To this day, HomeSite was my favorite HTML editor. The Allaire ColdFusion Studio variant, my favorite IDE for a language. Everything went downhill when Macromedia purchased Allaire, and we got Dreamweaver.

MH15 7y ago

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.

jefftk 7y ago

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

mycall 7y ago

zombo.com

elderK 7y ago

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 7y ago
+++ 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.
- dleslie 7y ago
  But it's reactive! Clearly by zooming in the user wants a more minimal display with less elements, right? /S
- arendtio 7y ago
  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 7y ago

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

xtracerx 7y ago

This is not how people wrote html in 1999

forgotmypw3 7y ago

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?

josteink 7y ago

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

whalesalad 7y ago

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.

dillonmckay 7y ago
I also make the body background pink and the outline a different color.
trnglina 7y ago
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 7y ago
  * { 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 7y ago
    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 7y ago
      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

enlyth 7y ago

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 7y ago
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.
rangerpolitic 7y ago
That's because people are trying to use HTML for applications rather than documents.

Causality1 7y ago

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.

HocusLocus 7y ago
Looks great on my 900x1600 monitor... portrait just like the content I read. Using a tall not wide monitor makes reading more fun than watching movies! Mom would be proud.
indigodaddy 7y ago
Agree. Is it a Jekyll theme or some totally customized template?
- bradley_taunt 7y ago
  Just FYI - I've open sourced this Jekyll theme: https://github.com/bradleytaunt/taunt-jekyll https://github.com/bradleytaunt/taunt-jekyll
  - indigodaddy 7y ago
    Cool, thanks a lot for that!
- saagarjha 7y ago
  Might be backed by this: https://github.com/bradleytaunt/accssible https://github.com/bradleytaunt/accssible?
- bradley_taunt 7y ago
  It's just my personal Jekyll theme I custom made. I plan to open source it very soon (I didn't think there was any interest lol)
7y ago

devin 7y ago

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.

tambourine_man 7y ago
Yes it was. It also bothered me while reading. I think he’s advocating for semantic HTML, not 90s HTML
isostatic 7y ago
It was. So was styling form elements. The idea isn't to pretend it's 1999 and only use stuff that works in netscape4/IE5, but to build pages in the same way as then. <nav> adds something useful - it helps screen readers out, but costs nothing.
rzzzt 7y ago
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 7y ago
  There's no reason to "resolve" it. It's just a name, not a gettable resource.

pvitz 7y ago

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

bullen 7y ago
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 7y ago
  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

justjonathan 7y ago

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 7y ago
nah, newfangled stuff, cross browser compatability issues, not worth it - it won't catch on
- im3w1l 7y ago
  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.
krapp 7y ago
I legitimately remember the day I first saw an iframed site and how cool I thought it was. God I'm old.
rolltiide 7y ago
iframes have had a wild ride in acceptance 1999 - Cool and Clever 2005 - Horrible 2010 - Horrible but sometimes necessary 2015 - Awesome
- majewsky 7y ago
  > 2015 - Awesome Huh, what happened?
  - EdwardDiego 7y ago
    We started injecting everyone else's JS everywhere.
  - d_k_f 7y ago
    Limitations imposed upon embedded scripts from foreign domains by technologies like CORS and the like, combined with modern styling abilities. You can place another service's elements on a page that look like they're actually part of the page layout while the JS running them can freely communicate with the service's backend without having to bother with cross domain problems. Think of all the support/chat widgets you see on modern-day pages, they're all iframes. And obviously: tracking all the things!

woah 7y ago

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.

patrick5415 7y ago
Because the idea that one can separate content from presentation appears as an elegant Platonic ideal to a lot of folks. The trouble seems to be that content and presentation are not actually disjoint sets. And (a perhaps different) set of folks want a slice of the juicy middle.
tomhoad 7y ago
> explicitly checked for as part of a QA process After you've written the application? That makes absolutely no sense, unless you enjoy renaming lots of elements. > instead of relying on some vague standard of semanticness It's not vague, there is an actual international standard... WCAG!
pbhjpbhj 7y ago
Screen readers, distilled/simplified views, other automated parsing. Things like marking up addresses, phone numbers - as examples - means that a search engine can log a website as associated with a particular address, a browser can link to enable a number displayed to be called direct. If for example there was a microformat (or other semantic markup) for opening times then SE/social sites could read and display (and update) that info without owners having to go on 20 sites if they change opening times. Of course it can also help infer which parts of a page are advertising, or impressum, and not render that. A plugin could offer to work on tables, or import them to a spreadsheet. Lots of scope for advanced automations.
LocalH 7y ago
When done properly, it increases the separation between the actual content, and the styling on top of it. Any time you get closer to that ideal separation, accessibility is enhanced (and it’s also forward-thinking towards yet-unknown methods of accessibility assistance).

deleted 7y ago

[deleted]

burgerzzz 7y ago

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.

detaro 7y ago
Ever tried to use your pages with a screen reader? It's quite an interesting (and potentially maddening - screen readers are power-user tools, and quite difficult to get into if that's not how you normally operate) exercise.
- strken 7y ago
  I tried doing this once, and I wasn't even able to install the damned thing. If you've got any advice or instructions on how to get started with a screen reader for testing purposes, I'd be really interested.
  - syntheticcdo 7y ago
    VoiceOver is built into OSX and is fairly full featured. Anything for Windows is either expensive or half baked IMO.
    - extra88 7y ago
      NVDA is free and not half-baked. In some respects, NVDA works better on the web than the expensive, dominant screen reader, JAWS.
  - detaro 7y ago
    On Windows I tried NVDA and the demo version of JAWS. Installation worked without issues for me, and I looked for tutorials on how to use them/put up the keyboard shortcut overview. Sorry I can't point you to anything more specific right now.

vikingcaffiene 7y ago

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 7y ago
id settle for front end devs not abusing flipping h tags

no_gravity 7y ago

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

SquareWheel 7y ago

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 7y ago
> 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/).
- redwall_hp 7y ago
  HTML5 was honestly the opposite. XHTML and XHTML2 were born of a desire to have stricter, more semantic markup. But we live in the shitty timeline where XHTML2 died and we got HTML5 instead.
- SquareWheel 7y ago
  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 7y ago
    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

butz 7y ago

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.

lstamour 7y ago

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/a11y-for-teams https://developers.google.com/web/fundamentals/accessibility...

masswerk 7y ago
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 7y ago
  > However, JS is "a bit" more powerful and has grown out of `document.write()` Wasn't innerHTML still settable back then?
  - lstamour 7y ago
    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

eurg 7y ago

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.

temp129038 7y ago

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 7y ago
> 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 7y ago

Ironically, the lists on this page are paragraph tags.

plibither8 7y ago
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 7y ago
  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.
bradley_taunt 7y ago
Yes that was an overlook on my part when formatting the markdown file. Fixed now!

numlock86 7y ago

> 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 7y ago
it's better than "mid-2000s teenager"—purple on black with glitter gifs

_bxg1 7y ago

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/Form_validation#Using_built-in_form_validation https://developer.mozilla.org/en-US/docs/Learn/HTML/Forms/Fo... https://developer.mozilla.org/en-US/docs/Web/HTML/Element/datalist https://developer.mozilla.org/en-US/docs/Web/HTML/Element/da... https://developer.mozilla.org/en-US/docs/Web/HTML/Element/Input/color https://developer.mozilla.org/en-US/docs/Web/HTML/Element/In...

doc_gunthrop 7y ago
> 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.
- darepublic 7y ago
  Hence the move toward static site frameworks like react static and gatsby
- _bxg1 7y ago
  > 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

chx 7y ago

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.

cgb223 7y ago

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

DaiPlusPlus 7y ago
To be fair, <blink> is more 1994: http://www.montulli.org/theoriginofthe%3Cblink%3Etag http://www.montulli.org/theoriginofthe%3Cblink%3Etag

dehrmann 7y ago

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

kccqzy 7y ago

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.

arendtio 7y ago

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.

dosy 7y ago
I think clearly author was using "like it's 1999" as a metaphor, not literally. It's a fairly common phrase (originating from a Prince song I think) that you can take to mean "like a throwback to a more authentic and possibly prior era." In this case the era is prior the explosion of frameworks and div soup. Which strangely in this case is not necessarily prior but in parallel, as you said. This is English, it doesn't have to be precise like programming. You can use it for effect.
- Izkata 7y ago
  Funny enough, that song is from 1982. It's looking forward towards the end of the world on 2000-01-01, and to "party like it's 1999".
majewsky 7y ago
> tables inside tables inside framesets FTFY
- lstamour 7y ago
  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 7y ago
    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.

harrydry 7y ago

i like the border idea

quickthrower2 7y ago

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.

tuespetre 7y ago
No, not unless you are for some reason doing something the intended audience’s browser may not support
runarberg 7y ago
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 7y ago
  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 7y ago
    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.

lhenk 7y ago

Using `outline` instead of `border` won't actually affect the layout. https://developer.mozilla.org/en-US/docs/Web/CSS/outline#Borders_vs._outlines https://developer.mozilla.org/en-US/docs/Web/CSS/outline#Bor...

snek 7y ago

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 7y ago
I wrote a small tool to test for this https://github.com/prettydiff/semanticText https://github.com/prettydiff/semanticText