12 ms·
A collection of bad practices in HTML
- keithnz 7y ago#11 Giving a numbered list that has no ranking meaning and showing things in reverse order #10 Making a simple webpage with 9 things on it and spanning it across two pages instead of just letting people scroll.
- deleted 7y ago[deleted]
- dlbucci 7y agoTo be fair for #11, it appears to be a blog, so that kinda makes sense. But with only 9 entries, it's a bit odd. No excuse for #10 though!
- mikeyjk 7y agoIs this pattern for SEO generation? So many sites take this approach - I'll be preaching to the choir complaining about how frustrating that user experience is. While I'm ranting about web experience, how about Bitbucket hijacking the normal behaviour of ctrl-f in pull requests? Just.. why?!
- stan_rogers 7y agoNo, it's typical behaviour for blog-type software: X numbers of entries per page; no allowance made for the length of each entry. Five novels on page one, four sentence fragments and a limerick on page two, etc.
- codeulike 7y agoHaha yes, some of the examples aren't that bad so it's quite fair to cast a few stones back in that direction I think
- bil7 7y agoVery good.
- syntheticcdo 7y agoThese patterns look familiar to me, having retrofitted a functional, though poorly architected AngularJS app for WCAG compliance. Would it have looked better if from the beginning semantic HTML were used? Sure. But does the aria- and role- soup improve the functionality and usability for non-typical users with little impact on maintainability? You bet.
- ggmartins 7y agoDon't forget the overflow:hidden for paywalls/alerts: https://www.youtube.com/watch?v=9IYZ8mktk7k https://www.youtube.com/watch?v=9IYZ8mktk7k
- anm89 7y agoIt feels like if your goal here was to improve the web you'd go into some explanation of why these are bad practices and how it can be done better.
- shhsshs 7y agoClick on each one and you’ll find an explanation
- bbody 7y agoI stumbled onto that by accidentally, really needs more context.
- oneeyedpigeon 7y agoYou could almost add "Hiding links via styling" to the list, but I feel like this site gets away with it; even though they're not blue, it's still pretty obvious those headers are links.
- ng12 7y agoI feel like there's something poetic about a site complaining that people do HTML "wrong" having terrible UX.
- bartread 7y agoIt's not terrible UX. Whilst the headings aren't blue, they are underlined, which makes it pretty clear they're links. I don't love hyperlinks in headings, and would prefer a more explicit link to each good example, tabs for good and bad, or even inline content to show the good examples below the bad, but it's a bit strong to be calling it "terrible". Nowadays people are pretty slack about links: good UX generally mandates either a different colour to body text, or underlining, or both. Blue has for many years been the default rather than the standard: people have been heavily deviating from it since the 90s. Underlining tends to be optional if there's some other way of distinguishing links (here there isn't).
- juskrey 7y agoLinus would have said, your expectations are not user experience. If I want my images to execute on click events, and so on, I probably have a reason for that. If that thing looks and works horrible, I'll learn that, but it may also work perfectly, or in 99% nobody cares.
- DocTomoe 7y agoWho cares about the "Check Engine" light as long as the car drives, right? After all, as long as it works, you probably have a good reason for ignoring it, for starters, going from A to B instead of paying maintenance and waiting. ... only eventually, a quick fix will have morphed into a destroyed engine.
- jordan801 7y agoThat's horribly out of context. Pretty much every item in this list is unnoticeable to anyone but a developer. Leaving them where they lie wont cause your website to explode or stop running. In fact, I can't recall one, that the average user would notice.
- Tyr42 7y agoUsing links instead of buttons makes accessibility to screen readers worse. Just because you can't see it doesn't mean it doesn't have an effect
- codyb 7y agoPlus, just being aware of how these elements interact with screen readers, and what you need to do for them and keyboard users can make you more aware to write better, more accessible HTML in the future. It’s a bit strange to me that in my last position all these great JavaScript engineers were still using div’s for everything when there’s so much you can harness directly from the browser’s interpretation of these elements to give you a pleasant and consistent user experience for your clients. Besides that, it makes trawling through your elements in your web inspectors a lot easier to read when you actually have lists, sections, headers, buttons, etc.
- bartread 7y agoI feel like Bootstrap (and similar) are a lot "to blame" for some of these. People have been using HTML tags non-semantically for a very long time and, to be honest, before HTML 4 you often didn't have a lot of choice in the matter. Still, when I was getting back into web development in 2013 I became aware of an "I can just use <div> and <a> for everything, and then stick Bootstrap classes and event handlers on to get it to look and behave the way I want" attitude that had become pervasive amongst developers. Now, to be fair, at the time this was legitimate: in 2013 older versions of Internet Explorer were still quite prevalent. They didn't support newer HTML5 constructs, or proper styling of certain elements. The <div>/<a> approach was often the only way to get things to look good, or even to look the same, across all browsers. Those days are long since gone (for most of us, anyway[1]), but I wonder if the reason we continue to see this style of HTML is that we're still living in a sort of post-IE hangover period? Old habits die hard[2]. [1] I'm aware that even now not everybody has the luxury of pretending that IE doesn't, and never did, exist. [2] Again, reminds me of the migration from earlier versions of HTML, where you'd really had to do things like use tables for layout and use various HTML elements for styling (with variable cross-browser support), to HTML 4, where you nominally didn't (except, of course, that not all browsers were created equal).
- FloNeu 7y agoWhen i started working web IE6 was still far far in the future, i also learned the semantic use of html JADAJADAJADA table-layouts bad JADAJADAJADA and i most of the time enforced myself to apply this 'best'-practices - truth is - i never saw this providing value in any kind. The web is so full of shit and abuse of 'best'-practices - nothing will every really on this and work. I would often have saved myself and my clients a lot of headaches/time and money if i had just used table-layouts instead of css-layouts and other crap - but hey whatever 'float's your boat.
- tsukurimashou 7y agogood practices and HTML don't really exist, the reason we have things like buttons inside a div and other hacks like that are because the web evolved too fast and people had to find solutions to bugs / problems.
- WilliamEdward 7y agoThat's not true, is it? You're supposed to use the right tags so people with visual impairments can use screen readers to gather the right info, and so people can gather the data of your source more effectively. If you do this from first principles it's actually quite simple and integrates better with the css / js. Overuse of tags if anything just makes it more complicated. The html may as well be the bedrock of your entire website, why not put in the extra work to find the best solutions?
- tsukurimashou 7y ago>it's actually quite simple and integrates better with the css / js That is just untrue, it that was the case, people wouldn't go for hacks, I agree the web for some parts are in a better state now that a few years ago, but for me it is still a nightmare, between features / tags / attributes that only works with X or Y browser, the number of bugs, the number of features still not released after being requested for years. Also if you want a specific design for your websites, sometimes going for <div> instead of "that more correct element that adds loads of shitty css by default" prevents some headache and allows you to prototype faster.
- thinkxl 7y ago> good practices and HTML don't really exist They do, we have a standard for that, https://html.spec.whatwg.org/ https://html.spec.whatwg.org/
- bennyelv 7y agoI sympathise with people using HTML "incorrectly" because there's a mismatch between how HTML is designed and what it actually has to do in the wild. Maybe using the "correct" element structure is going to be much more complex in a given situation due to the fact that you've got CSS rules that will be in scope that will style it for another purpose, and you'll have to undo and override all that work bit by bit to get it to match what the designer envisaged in this particular placement. So instead you just use some divs, stick a few generic classes on stuff and get on with your day. The tools are supposed to be the slave of the workman, not the other way round. I'm not saying that all of these are examples of this situation of course!
- tannhaeuser 7y agoIndeed. HTML was designed as simple vocabulary for casual hierarchically structured documents in academia with anchor links and, later, forms. Then it was used for all kinds of online documents and apps as they evolved. To say that the HTML vocabulary hasn't exactly kept pace is an understatement IMO. What has evolved is bolted-on tech such as CSS and JavaScript, and as soon as that happened, HTML evolution was kindof doomed because changes to HTML weren't essential (could be implemented in an ad-hoc way once a Turing-complete language was in the mix). Today, people praise CSS Flexbox and Grid, and they're no doubt a step-up from a practical PoV. But what has really just happened is that another ad-hoc syntax was introduced as a replacement for what previously went into HTML attributes, and worse, a syntax that needed to be able to roundtrip through HTML attributes via quoting and escaping. The notion of "semantic" markup and the HTML-CSS-JS trinity is really an after-the-fact rationalization of this syntax soup accident. From a comp.sci. PoV, there is no rationality and progress in piling up syntaxes over syntaxes with identical purposes, nor in equipping CSS with the power to rearrange element order, insert content, and whatnot, especially since HTML always had adequate typing based on a formal ISO standard (using SGML) whereas CSS lacks this completely.
- code_code 7y agoI've only looked at web components casually, but the examples I saw seemed a greater mess than this. Interact DOM components, CSS, slots, JS, private DOM, ... AND plan for late-loading code and resources. ?!
- b0rsuk 7y agoHow about destroying a whole table and rebuilding it each time a checkbox loses focus? I've spent nearly a month debugging that one. Also, why create one table when you can create two overlapping ones? (it was a jQuery plugin, and a vendored one at that).
- onion-soup 7y agoI often found that stressing about "semantic html" and the "correct way" is just virtue signaling and in reality, in real projects, if it works it works, and you move on.
- Vinnl 7y agoIf "it works" means "it also works for people with screen readers, people reliant on the keyboard, and makes use of the easiest input methods on phones", then I might be inclined to agree with you - although in practice, your HTML will probably be pretty "semantic", or it will have been more work to author than needed.
- WilliamEdward 7y agoThis is legitimately a dangerous practise. You are closing off your website from blind people and ethical web scrapers when you do this.
- rpmisms 7y agoClosing off your website from blind people and ethical web scrapers != dangerous. Just a dick move.
- WilliamEdward 7y agowhat if your website offers medical advice? Some people have to maintain things like WebMD.
- rpmisms 7y agoWebMD is not a reliable source of medical information.
- kube-system 7y agoSometimes it’s illegal. I’m sure I’m not the only developer here who has had to write accessible code to fulfill a project’s legal requirement.
- rypskar 7y ago#9 https://www.htmhell.dev/9-cookie-consent-from-hell/ https://www.htmhell.dev/9-cookie-consent-from-hell/ is missing good code. A cookie consent where the only option is OK give zero value. If you don't track users there is no need for the dialog and if you track the users this dialog do not show that tracking is turned off to you click OK
- szczepano 7y agoLooks like someone changed design decision and needed buttons instead of text links in various places and people got bad day implementing those.
- jonny383 7y ago#8 can actually be a very wise way to fallback without <noscript>
- Etheryte 7y agoThe given example no, the answer shown as a solution by the blog author, yes.
- tenryuu 7y agoI like how this site is just bash.org but for HTML snippets
- merb 7y ago> A click event on a div triggers only on click. A click event on a button triggers on click and if the users presses the Enter or Space key. that is not 100% correct. a formular with a submit button will actually trigger on enter. but not a button per se. especially not a <button type="button">.
- basseq 7y agoThis would be more interesting with descriptions of WHY it's bad, and a little bit of moderation. As of this comment, there are 9 entries, and more than half have to do with similar link/button behavior (#8, #5, #4, #2, #1... and also kind of #3). Some of these are also semantically invalid (e.g., #7). That's less a "bad practice" and more "invalid HTML".
- antibland 7y agoFor the button wrapped in a link example [0], which is invalid HTML, many people don't know it's valid to wrap a button inside a form, using the form's action as the destination. Not something I use often, but it's at least a thing worth knowing. <form action="link.html" method="get" target="_blank"> <button type="submit">Link</button> </form> [0] https://www.htmhell.dev/4-link-also-button/ https://www.htmhell.dev/4-link-also-button/
- tabtab 7y agoI find that different browser brands react differently putting BUTTON tags inside of forms. Tread with caution. Internet Explorer versions are usually the biggest bottlenecks.
- dsego 7y agoThese are all really bad. But when my designer designs links as buttons and buttons as links, which am I supposed to use? Then there's the redesigning pages, layouts and widgets every other week, based on our trackers and heat maps. How can I care about the quality of my html, when I know it's all gonna be scrapped next week or month when a new redesign comes in?
- echeese 7y agoIf it leads to a semantically different page, use <a>, if it's used only for javascript-interactivity use <button>. Never use <div> for buttons or links.
- dsego 7y agoIs adding role=button to <a> enough, or should I style a button to look like a link (.btn-link in bootstrap)? One issue with .btn-link is getting the vertical alignment to match any surrounding text.
- tabtab 7y agoIn practice the dichotomy between hyperlink and button is blurry and should be treated as blurry and interchangeable. But HTML doesn't really allow one to blur properly, at least not in all browser brands. To resolve this, it should be easier to make hyperlinks into buttons and buttons into hyperlinks. The difference should be aesthetics only. They are both a "span with an action". The action and styling (button versus hyperlink) should be attribute-based. Examples: <action type="post" look="link">Action 1</action> <action type="post" look="button">Action 2</action> <action type="link" look="button">Action 3</action> <action type="none" look="link" onclick="myJS()">Action 4</action>
- jolmg 7y ago> #7 [...] table layout > yeah, it's on a live production site still running like HN. :)