16 ms·
A few HTML tips
- wtbob 10y agoWeb Fonts for images are a true anti-pattern. It's actually almost funny how many pages are full of ſ and so forth, because they assume that folks are using a graphical browser running JavaScript.
- tajen 10y agoSome day we should deprecate browsing the web with HTML 1.0 tools, apart from web crawlers who know what they are doing. Sticking with that is akin to sticking to horses on the road: It has its advantages, but you can require everyone to build horse-friendly roads for you in 2016. At least horse riders aren't vocal about their bad experience.
- ffggvv 10y agoScreen readers, scrapers/crawlers, future readers (will your page be readable in 1000 years?), archiving...
- throwanem 10y ago> will your page be readable in 1000 years? In entire fairness, the evolution of language may well make this impossible, or nearly so, regardless of how you structure your content. It's not unreasonable to shoot for 100 years, though.
- zeveb 10y ago> In entire fairness, the evolution of language may well make this impossible, or nearly so, regardless of how you structure your content. Are you aware that we're completely able to read documents from thousands of years ago? C.f. Caesar's Bellum Gallicum, which is about 2,050 years old.
- madeofpalk 10y agoI don't think there's anything wrong with assuming people are running a graphical browser. We're at the point where, depending on your exact industry/usecase, earlier IE versions are less than 1% for a lot of 'mainstream' sites. The amount of people who aren't able to render a custom web font, let alone a non-graphical browser, would be in the extreme minority. IMHO, that is not a use case that's not worth worrying about.
- johannes1234321 10y agoWell, of course there are those who are weird, like Mr. Stallman: > I generally do not connect to web sites from my own machine, aside from a few sites I have some special relationship with. I usually fetch web pages from other sites by sending mail to a program (see git://git.gnu.org /womb/hacks.git) that fetches them, much like wget, and then mails them back to me. Then I look at them using a web browser, unless it is easy to see the text in the HTML page directly. I usually try lynx first, then a graphical browser if the page needs it (using konqueror, which won't fetch from other sites in such a situation). https://stallman.org/stallman-computing.html https://stallman.org/stallman-computing.html But there are other groups of people for which this is relevant: Blind or otherwise visually impaired people depending on screen readers or similar. Those don't have a good choice and abusing text there makes the experience unbearable.
- blowski 10y agoI received an accessibility report for a website made by a big reputable accessibility agency, and they had no problem with us using Font Awesome. It's ignored by screen readers, unless you put a title attribute, which you can do if the icon is more than decorative. That said, I use NoScript with 'Forbid Font-Face' enabled, so a lot of the time I see squiggles instead of icons. But that's my choice, and I'm almost certainly in the minority, so I'm not angry about sites that use fonts instead. SVG probably will come to replace font icons, but for now, they've been really helpful for a lot of small sites.
- madeofpalk 10y agoI don't understand this. Most icon fonts use PUA codepoints to avoid issues with screen readers. If you're not going to use icon fonts, what are you going to use? Images? CSS Backgrounds? Inline SVGs? Screen readers can't read any of them. Thankfully there are ways to make all of these accessible, with things like ARIA attributes.
- gpvos 10y agoHear, hear. Web fonts are fine when used as fonts. They are not fine when used as images (unless the image corresponds to an actual Unicode character).
- deleted 10y ago[deleted]
- Zardoz84 10y agoaria-hidden="true"
- YngwieMalware 10y agoFrom a design perspective font icons are a very good solution when compared to sprite sheets or SVG. They are scalable, they load a single time, and contain nearly every iconic type of symbol you could want in a UI. That's not an anti-pattern.
- wtbob 10y ago> They are scalable, they load a single time, and contain nearly every iconic type of symbol you could want in a UI. An SVG is scalable, cacheable and can contain any vector art you could wish for. And it doesn't use characters to represent images.
- recursive 10y agoAre you aware of any of the recent actions of the Unicode consortium? You can start here. http://www.unicode.org/emoji/charts/emoji-released.html http://www.unicode.org/emoji/charts/emoji-released.html
- gpvos 10y agoCompounding mistakes doesn't make it right.
- wongarsu 10y agoEmoji are almost exclusively used embedded in regular text. Emoji work similar to our regular alphabet, only that they are typically used to express emotions and abstract concepts that are harder to express in regular words. Since we have regular text and emojis used in the same context (and often as part of the same sentence) it makes sense for unicode to support both. This is fundamentally different from icon fonts. twitter icon or mailbox icon are not meant to be used inside of text, so they have no business in fonts.
- amelius 10y ago> An SVG is scalable But fonts have hinting, so they look nice at low sizes and low resolutions. This is something that SVG is still missing.
- paulddraper 10y agoYou'd rather see SVG XML?
- mattmanser 10y agoIs it common these days to nest inputs in labels? As a comparison, bootstrap doesn't, http://getbootstrap.com/css/#forms http://getbootstrap.com/css/#forms. To me that's conceptually as well as semantically broken, the two are separate things why is the input inside the label? He's saying make everything semantic, and then semantically breaking forms. Also if you have any inputs that don't have a label for whatever reason you either have to wrap them in them any way to get CSS to work or make sure you never rely on the input being nested in the label in your CSS. And having them apart also makes it easier to design responsively if you want a side-by-side design for desktop vs a stacked design for mobile. Saves having to add a for tag I guess. I guess a lot of that article is opinion though, so you're always going to get people objecting to one point or another, though a lot of it seems sensible advice.
- progval 10y agoMaybe it's to increase the area where a click transfers the focus to the <input>? Skype Web puts a whole <form> in a <label>, I guess it is for that reason
- realityking 10y agoIf you use the for attribute clicking on the label will focus the related input.
- mook 10y agoBut that means there may be an area between the label and the input element (depending on margins and so forth) which is not clickable. Having the label separate makes sense if it's all in a table-like structure, though.
- IgorPartola 10y agoIt has one distinct advantage: you don't have to generate the id and for attributes, which isn't always the most convenient.
- deleted 10y ago
- DanielBMarkham 10y agoCan anybody tell me how legit the placeholders recommendation is? I understand it's not accessible, but on a limited viewport, having the text tell the user what you want seems like a no-brainer. And I see it a lot. Isn't there some other way to provide accessibility?
- grahamel 10y agoit's not just accessibility it's also keeping the form usable. As the placeholder text goes when you type in the input you loose the reference to that input, so the only way to check if you're typing in the right box is to clear the input. See https://www.nngroup.com/articles/form-design-placeholders/ https://www.nngroup.com/articles/form-design-placeholders/
- cdubzzz 10y agoI suspect that the correct thing to do for usability in those cases is use a label for the field with visibility: hidden.
- firasd 10y agoIt's useful from a minimal design perspective but I've started to avoid using placeholders after seeing this article[1], instead trying to put the field name, example text or caption, etc outside the input. [1] https://www.nngroup.com/articles/form-design-placeholders/ https://www.nngroup.com/articles/form-design-placeholders/
- dizzystar 10y agoThe recommendation is totally legit, even ignoring accessibility concerns (which are true). I can't tell you how many times I've tabbed onto the next field and had to tab off just to see the value I was supposed to be putting in. It gets worse when this is in JS and for whatever reason, the field name doesn't reappear, or better yet, when the suggestion doesn't disappear and I have to manually erase it. It gets even more confusing when there is a suggested format, like date, you have to manually enter. Was it mm/dd/yy or mm/dd/yyyy? All of that should be above the form input. Using nothing but place holders is a serious pet peeve of mine on all levels. Please don't, just don't do it. I don't understand what benefit is has. I suppose it works fine if you have users that only use mouse clicks, but it is mayhem for people who use key commands.
- 56k 10y agoEveryone know these things. What's the big deal?
- ferrari8608 10y agoI learned something new. It's not a big deal, but I'm glad it was posted nonetheless.
- strictnein 10y agoMe too. I've been doing web dev for 10+ years and I've never wrapped an input in a label tag. Always used the for attribute. Didn't even cross my mind it could be done differently.
- 56k 10y agoJesus Christ...
- strictnein 10y agoSome of us are comfortable enough to admit silly little faults.
- dang 10y agoWe've banned this account for repeatedly posting uncivil and unsubstantive comments to HN. If you don't want it to be banned, you're welcome to email hn@ycombinator.com. We unban accounts when people give us reason to believe they'll follow the rules in the future.
- msl09 10y agoI can see the value of almost all of those recommendations but I don't understand the value of using the correct header sequence or tagging subheaders. I don't see anything in the linked W3C article that explains why I should use one idiom over another.
- YngwieMalware 10y agoA lot of it is semantics. A bunch of HTML5 is semantic vs. actually having different behavior. <header> behaves no differently than <div id="header"> but is more semantically correct.
- FroshKiller 10y agoA simpler way to say "more semantically correct" is "correct." Please don't trivialize the importance of semantics. Proper semantic representation makes documents more accessible.
- cloverich 10y agoI don't find the header, article, section, etc tags to be sufficiently clear that they are always used in the same way by different people. But maybe I'm missing something -- how do they improve accessibility?
- throwanem 10y agoTake a look at http://accessiblehtmlheadings.com/ http://accessiblehtmlheadings.com/ for a pretty solid introduction. The tl;dr: is that, used properly, they enable screen readers and similar to identify document structure and make it more easily navigable.
- FroshKiller 10y agoSorry, I should've provided a reference for you. The link throwanem posted is a good introduction with an interactive demonstration.
- 10y ago
- adregan 10y agoOne thing I remembered while reading the section on telephone inputs—what happened to all the HTML5 date and time input types? http://caniuse.com/#search=Date%20and%20time%20input%20types http://caniuse.com/#search=Date%20and%20time%20input%20types All of the other cool new input types appear to be on the way in the modern browsers (http://caniuse.com/#search=input%20type http://caniuse.com/#search=input%20type), but Safari and Firefox don't appear to be budging at all. I would prefer to use the native date pickers across devices, but I feel like I have been waiting on those elements to land for years now. Did I miss something?
- cmg 10y agoA few (maybe 3) years ago I developed an in-house calendaring webapp and aimed to use the date/time/datetime fields on it. Unfortunately the client couldn't guarantee browser consistency across their offices, and of course mobile was a concern as well. I don't remember the details and wish I'd written it up, but the inconsistencies across browsers about required values, bounds - not to mention trying to do "trivial" things invalidating Saturdays and Sundays - were astounding. datetime-local helped a bit, but wasn't fully supported in IE. I spent 4 days working on that, then spent an hour ripping my code apart and adding moment.js and the jQuery UI Datepicker widget. At least it worked.
- dexwiz 10y ago+1 for moment.js. Of all the npm modules I have used in the last year, none have been cleaner than moment. It has great docs, all the features you need, and just "works." I am constantly having to come up with workarounds for React, Sequelize, whatever, but momentjs never seems to force me into an awkward position.
- Waterluvian 10y agoI'm curious abiut generally speaking what workarounds you're doing in react. Every workaround I've had to do, eventually revealed itself as a code smell or antipattern. Obviously they are there; no view library is perfect. But I have yet to see what one loons like.
- ravenstine 10y agoFunny how they answered a question about paragraph tags that I was wondering yesterday. Most answers to the "p vs br" question seem to be "do whatever you want", but the recommendation in the article seems most correct to me, since p tags are for the parser(in case it needs to know what the paragraphs of the body content are) while breaks are presentational.
- ianbicking 10y agoI think the bigger concern is that br tags don't fit the general box model. You can have CSS like p {margin-top: 2em}, but br is more like a newline, tied to the text flow itself. Which, as noted in the article, is okay if you are trying to just affect text flow, as in a poem with explicit line breaks. But actually trying to understand "what is a paragraph" using the semantic markup is probably a fool's game. What IS a paragraph anyway? There's not many automated tools that could make any use of that very semantic definition.
- acbabis 10y agoScreen-readers can iterate and skip paragraphs. If you have an article and you group your sentences in paragraphs, the document is easier to navigate. Paragraphs would also be helpful if you wanted to write a script to export an HTML document to LaTex/Word/ect as those will automatically indent paragraphs for you.
- wtetzner 10y agoKnowing which things are paragraphs would also make implementing things like Readability easier.
- greggman 10y agoI'm curious if you should use p at all. Unlike most other tags p doesn't not enclose block elements. So easy to break. Soooo many bugs related to starting with a paragraph, embedding something inside it, not realizing the content past whatever was embedded is no longer in any paragraph
- lllorddino 10y agoThat feeling when the first paragraph of an article points out something you've been doing wrong all along :D. I use <br> in between paragraphs and it looks horrible, what should I be using instead?
- cmg 10y agoHTML paragraphs have a default margin on the top and bottom. In Safari/Chrome at least, it's 1em. Use/modify that. I often add #whatever-container p:first-of-type { margin-top: 0; } to remove the top margin on the first paragraph of a container to line things up properly.
- deleted 10y ago[deleted]
- reitanqild 10y ago<p></p> is start and end of a paragraph.
- zobby 10y agouse <br/> like you use <img/>
- bits_stib 10y agouse more <p></p>.
- zobby 10y agoI crawled the articel, full of obvious then crashed on the svg line. You can't just ditch IE8 away. Then bloating your source code with graphic code is a bad idea. 0/10 won't do it again
- sirtastic 10y agoQuestion: Can anyone comment on how important HTML taxonomy in terms of SEO (disregarding accessibility). Will the use of <header> and <article> make any difference in how a page is indexed and ranked directly or indirectly? One indirect way I can see SEO benefiting is via sharing. Facebook crawling will have an easy time grabbing the <h1>Title</h1> along with whatever comes first in <p>for an excerpt</p>. Is there any no-brainer reasons or supporting evidence proper taxonomy helps rankings?
- stan_rogers 10y agoDon't disregard accessibility. Think of the search engine crawler as a disabled user. The ARIA roles (and many HTML elements have good, sensible defaults) carry a lot of information that a search engine can use as easily as a screen reader can. Good a11y is good SEO.
- pabloarteel 10y agoDo you have any references to this?
- retor 10y agoThing is that wcag recommends following defined web standards, but no screen reader I tried could handle html5 style of relative h-tags, like multiple h1 tags. So if you want to adher to wcag rules, and support screen reader, you need to stick to html4. This will probably change, but in order for us to support screen readers, we ended up with some badly written html5. As for SEO, my experience is that the big crawlers handle html5 better than screen readers, and that atleast Google puts more emphasis on font size as a measure for the pages h1. "If it looks like the pages heading, people will see it as the h1, so we should consider this a better cue than tags the users don't see" sort of logic.
- stan_rogers 10y agoOutlines are still broken in browsers, yes (so multiple nested-level <h1>s ain't gonna work in <main>), but things like the banner and nav roles work just fine and come free with the appropriate tags.
- nailer 10y agoSlightly off-topic, but: > Couldn’t be much more from the hearth<br> Couldn’t be much more from the heart.
- clifanatic 10y agoI had to pull out the CD and double-check, because I thought so, too. You're right, he very distinctly pronounces the final "t".
- intrasight 10y ago> There are some CSS limitations though: when using SVG this way, with <use> linking to a <symbol>, the image gets injected in Shadow DOM and we lose some CSS capabilities. Which is why SVG "symbol" and "use" are best avoided. Your client will inevitably ask you to style an icon and you won't be able to. Avoid the shadow DOM and you'll have full CSS capabilities.
- sago 10y agoBest avoided for what? At worst, SVG is as styleable as any graphic or font, at best much more so. You shouldn't use SVG for things with first-class support in HTML, sure, but for anything else it is a good solution, afaict. Can you give a counter-example?
- intrasight 10y agoI was specifically talking about "symbol" and "use" - which have very limited CSS support.
- xienze 10y ago> Your client will inevitably ask you to style an icon and you won't be able to. It's not that you can't style it, it's that you can only style _the entire image_. Which means it's a perfectly good replacement for icon fonts since "styling" an icon font is limited to changing the size and color. You can do that and more with an SVG included via <use>.
- pjungwir 10y agoI'm curious if there is any good solution to use sprite sheets with background-image, possibly with a hover effect, and still get the accessibility benefits of alt tags? For instance: <a class="fb sprite" href="..."> </a> .sprite { background-image: url("/sprites.png"); background-repeat: no-repeat; } .sprite.fb { background-position: -4px, -4px; width: 42px; height: 42px; } .sprite.fb:hover { background-position: -4px, -54px; } What would you do to make that accessible? I did some Googling about this a few weeks ago, and it seemed to be a topic of "ongoing research." None of the solutions I could find were very appealing. So, any suggestions?
- nanodeath 10y agoPut offscreen text inside.
- steveax 10y agoOr add an aria-label property to the link.
- Nadya 10y agoNot the best solution - but the solution I've used in the past: `<a href="/" target="_blank" title="Facebook"><img class="sprite fb" src="/images/spacer.gif" alt="Text" background-image:url('/images/sprites.png')></a>` I don't exactly like it but haven't come across a better solution.
- rimantas 10y agoAnyone remembers Dan Cederholm (http://www.simplebits.com/ http://www.simplebits.com/) and his excellent books "Web Standards Solutions" and "Bulletproof Web Design"? He even had a series of exercises like this on his blog. Oh, the gone days of the web which was a web and not some misfit wannabe app engine :(
- spicyj 10y agoSpeaking as someone partially responsible for turning the web into "some misfit wannabe app engine :(", yes – those were some of my favorite books when they were released.
- jonespen 10y agoA note regarding alt attributes on img: they should almost always be empty. Please don't just fill it with the related title or heading, as it just creates a lot of unnecessary text for screen readers. More: http://www.456bereastreet.com/archive/200811/writing_good_alt_text/ http://www.456bereastreet.com/archive/200811/writing_good_al...
- donjh 10y agoI found the section on SVG sprites particularly interesting. Here's a Webpack plugin to generate SVG spritesheets from individual assets: https://github.com/mrsum/webpack-svgstore-plugin https://github.com/mrsum/webpack-svgstore-plugin.
- perlwle 10y agoI wish safari supports currency keypad with decimal in HTML5. It's working for android but not for iOS ;-(
- megous 10y agoI wish for icon fonts to die. I don't mind website designers defining what fonts to use. That choice is almost always something I don't want, unless it's serif or sans-serif. I can override that choice with my own, which is better for me. Having the same font on every website increases readability and pleasure of using the web. Browsers allow for this in the user visible configuration, perhaps for this reason. Also, security. I don't trust random fonts from the internet, to not be malicious, so I disable them all. If I choose readability and security, use a normal browser feature to do this, by disabling website enforced font choice, the website should not break. Icon fonts are definitely a hack. There's no fallback to anything sensible when the font can't be used. It just breaks, and the website is unusable. At least use a title attribute, so that when hovering over some random character I can see what the supposed icon I never saw stands for. Especially when used for icon only navigational controls. And this is not even related to accessibility.
- megous 10y agoPerhaps designers assume that they are in full control of their website appearance, and don't include into consideration user's choices, enabled by various browser options/configurations.
- jasonthevillain 10y agoThey were a hack! They came about because legacy browsers didn't support SVG. Of course, IE8 is dead, so I can't think of a reason to stick with them.