Hacker News new | past | comments | ask | show | jobs | submit login
A few HTML tips (hacks.mozilla.org)
501 points by nachtigall on Aug 24, 2016 | hide | past | web | favorite | 174 comments



One 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

All of the other cool new input types appear to be on the way in the modern browsers (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?


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


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


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


I would agree most React workarounds are code smells. At one point I had to advise a teammate to not use jQuery to attach event listeners to DOM elements created by React.

My major issue is that everything is a component. Which means it's hard to delineate between View and Logic (Models/Controller) code. React rightfully called itself View only. But in classic JS fashion, the community Frankenstiened it into a full framework. Before someone says it, I think stateless functional components are a bad solution to the logic/view separation.

Also I don't think React has figured out a good solution for styling yet. The two major camps seem to be inline styles or css classes. We went with css classes so we could use css "frameworks." But I think both methods have their cons.


I agree totally.

I have an app of a few hundred components and sometimes there's a lot of heavy business logic that feels wrong to have in a component.

I also have this ugly mess of scss that don't live with the components.

What I'd like to see is a component gets to define it's own structure and default look and feel. So styles in the component. Then you can give it class information if you're giving it your own styling or customization.

I would love to be able to package an entire calendar widget, for example, into a module that is only .JSX files. And know that no matter where I import it, by default it'll look and behave in a sane manner.


Using classes as overrides is like how Bootstrap is (was?) customized. Bootstrap had default css classes that applied a default style. To override it, you would create your own css classes with custom attributes targeting the same classes, but with higher specificity [1]. You are still using styling here.

Styling can get very verbose. That would just clog up the .JSX file. CSS will be its own entity from React or any templating engine for the foreseeable. Moving it into its own file helps with code organization. The only sane way to link them right now is css classes. Althought the argument for inline versus class css extends beyond the React world.

But you have to do things like prefixing to make sure your css

[1] https://developer.mozilla.org/en-US/docs/Web/CSS/Specificity


Seems that Firefox are planning to support it. Latest discussion on Bugzilla was in May of this year (https://bugzilla.mozilla.org/show_bug.cgi?id=888320) where they were discussing implementation details.

No news from Safari.


They're available on mobile Firefox and Safari (well partially on the latter) but not the desktop versions. I wonder if it's because they're not implemented at the OS level?


Those are on their way to Firefox. I remember seeing them in someone's intern presentation this year. I'll try to dig up the video in a bit.


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


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


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


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


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


Well, 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

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.


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


Stallman isn't a group of people though, he's one very very extreme case that frankly doesn't matter in the big picture of web accessibility and it probably isn't going to hurt anyone if he can't see every bit of your site as perfectly as everyone else.


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


We can use SVG images/sprites with an alt="" attribute.


While that is probably 'better' how in practice does it matter. SVG (esp with sprints) vs icon font are basically the same. Both are ways of embedding multiple vector images in one resource that you attribute meaning to using `title` attributes. In practice they will behave pretty much exactly the same.


There are still some issues with that – for example, it's easier to change attributes like text colour when using an icon font, something that becomes substantially more awkward with SVG. This is appropriate for things like buttons and other elements with hover effects.


Just inherit the colour, in the spritesheet use:

  fill: currentColor;
Same with stroke. Works great.


If you must use a magic font, why not use ligatures to replace words?


Somehow most web developers care a lot more about the ~3% of users that use IE 10 or lower than about the ~4% of users that are legally blind and can't use a graphical browser.

I can only hope that his is mostly ignorance.


> Somehow most web developers care a lot more about the ~3% of users that use IE 10 or lower than about the ~4% of users that are legally blind and can't use a graphical browser.

It's only correct to infer that web developers care less if the cost of supporting either is the same.

(Also many legally blind people use graphical browsers; legally blind is not the same as "unable to see anything").


I readily confess I don't know many legally blind users, but the handful I do know all use graphical browsers with screen readers.

Is that not typical?

(That said, if you're using webfonts for icons you should be using the unicode Private Use Area.)


Well there's also the fact that 100% of those 3% are definitely online loading website while the same can't be said for the 4% legally blind.


I tend to disregard the entire <7% (assuming overlap).


I like the idea of making a commitment to accessibility, simplicity, and universality.

<svg> may not work for people like me who disable javascript. It introduces potential security issues (in my understanding). It's complex, meaning it's hard to guess how it will interact with tools that want to access the page (like for visually impaired or for other purposes).

I don't like these things, so I'll try to make a stand and not use it. Of course, I only have that luxury because I don't make websites for a living.


> "<svg> may not work for people like me who disable javascript. It introduces potential security issues"

SVG works for me with JS disabled (using Firefox on OS-X). Do you have any pointers on when/why SVG wouldn't work without JS?


I looked into it further and I think I'm mostly wrong about <svg>. You can embed javascript into it, but if you don't, then as far as I can tell it works fine for me. Sorry!


That makes sense…and I think that's where the potential security vulnerability comes into play - if you allow untrusted users to upload SVGs, then they could potentially be uploading javascript to your site, offering a vector for XSS. As far as I can tell, adding your own SVGs to your site doesn't open up any novel security issues.


svg is no more accessible or simple than an icon font.

You have the same resources and APIs (can you call HTML attributes an 'API'?) available to make the usage of icon fonts friendly for screen readers.


SVG is considered more accessible because it's an image, not text. 'f' doesn't mean aeroplane (even though it looks like an aeroplane in a 2010-style graphical font) but img alt="plane" does.


That's an argument for not using an icon font which remaps normal characters but the most common ones use private-use characters which are ignored by screen readers. In which case are these not equally accessible?

    <i class="fa fa-globe" aria-label="Picture of a globe"></i>
    <img svg="globe.svg" alt="Picture of a globe">
Accessibility is more about process and testing than any particular technology since they all can be done poorly.


Apologies if this is a massively ignorant question, but isn't the <i> tag an inline text span? In which case, isn't it wrong to have it be empty?

    The i element represents a span of text offset from its
    surrounding content without conveying any extra emphasis or
    importance, and for which the conventional typographic
    presentation is italic text; for example, a taxonomic
    designation, a technical term, an idiomatic phrase from
    another language, a thought, or a ship name.

http://www.w3.org/TR/html-markup/i.html

Using it without text strikes me as a hack, and one that is hostile to usability, among other problems. I understand why it would work, but it's abusing the technology as far as I can tell.

Since I've seen this in at least two comments now, can somebody explain to me why it's not considered an anti-pattern in 2016?

[edit: formatting]


I would agree with that – it's a convention which the FontAwesome project uses for reasons I haven't looked into (I'm assuming not wanting to type 6 more characters).

I use <span> on all of my projects.


Yes but shouldn't a <span> also always have content? Am I missing something here?


There's nothing that requires it to have content, no. Absent other styles, an empty <span> would be invisible and have no effect though.


It has text content, merely inserted by CSS `content` instead of living in the HTML itself.


Your mailbox icon 'ſ' will be read aloud as 'latin small letter long s' or 'esss' if you're lucky.

But I can't really tell if you're actually saying that the ability for web pages to be read aloud coherently is 'a use case that's not worth worrying about'.


Attributes can be added to make screen readers ignore certain html elements like icons for exactly this reason.

    <i class="fa fa-pizza" aria-hidden="true"></i>


This is a good point. There is additionally ligatures used by the Google material icons. These let you put an actual textual representation of the icon and only replace it with an icon if the browser supports it: http://google.github.io/material-design-icons/


Why FA insists on abusing the Italics tag (repurposing it as "Icon") instead of leveraging the appropriate <span> is...specious at best.


The <i> tag in modern HTML does not mean "italics", though the examples given to illustrate its new semantics are all things conventionally set in italics.

"The i element represents a span of text in an alternate voice or mood, or otherwise offset from the normal prose in a manner indicating a different quality of text, such as a taxonomic designation, a technical term, an idiomatic phrase from another language, transliteration, a thought, or a ship name in Western texts." [0]

Its use for text-as-icon is arguably, despite obviously not being a use classically set in italics, within the defined semantics of the <i> tag.

EDIT: Though FAs use isn't actually text-as-icon, it uses empty tag as an icon. That's not consistent with the semantics of the tag.

[0] https://html.spec.whatwg.org/multipage/semantics.html#the-i-...


<i> is not the "Italics tag":

In earlier versions of the HTML specification, the <i> tag was merely a presentational element used to display text in italics, much like the <b> tag was used to display text in bold letters. This is no longer true, as these tags now define semantics rather than typographic appearance.

https://developer.mozilla.org/en-US/docs/Web/HTML/Element/i


You can use whatever <element> you want with FA. It's the class names that are important.


Or, y'know, one could just use an image instead of abusing HTML:

    <img src="pizza.png" alt="" />


Except that would require multiple web requests unless you were using an image sprite. Font Awesome and Glyphicons solve this by using a font file or sprite.

I do wish they didn't overwrite the traditional <i> tag, but I guess we're supposed to be using <em> for semantic HTML.


> Except that would require multiple web requests unless you were using an image sprite.

So … it can be made to work with a single request then.


Yup, and Glyphicons does that.


Unless you need to think about accessibility, which is a usecase many need to deal with.


Hear, 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).


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


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


Are 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


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


Compounding mistakes doesn't make it right.


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


GitHub recently switched to SVG and claimed the opposite: https://github.com/blog/2112-delivering-octicons-with-svg

Was their font just poorly designed?


That could be the case. Also, it may depend on the particular browser they used.


Web Fonts abuse HTML: they take text and give it a different meaning. The letter 'a' does not indicate a daisy with pink petals; it is the letter 'a,' the English word 'a' and so forth.

Think for a moment about what Web Font users do: sprinkle garbage throughout their pages; run JavaScript to dynamically load stuff (and possible destroy the privacy and/or security of the client); dynamically update the page — all when a simple, semantic image could have done the trick.

It's kinda insane, like rendering a page by loading JavaScript to slowly append characters to the DOM.


That's just inaccurate – AFAIK all modern icon fonts make use of the Unicode PUA, which is specifically intended for this sort of application. The characters used have no semantic meaning beyond what the application, including its fonts, intend.


> That's just inaccurate – AFAIK all modern icon fonts make use of the Unicode PUA, which is specifically intended for this sort of application.

Why, then, does one see all sorts of strange characters on web pages which use icon fonts?


Problem is we should be using ligatures not single letters. Guilty of the error as well. But it can be done e.g. http://webdesign.tutsplus.com/articles/your-logo-as-a-web-fo...


aria-hidden="true"


You'd rather see SVG XML?


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


Screen readers, scrapers/crawlers, future readers (will your page be readable in 1000 years?), archiving...


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


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


You're absolutely right, of course. I'm not even sure why I thought that made sense when I said it; thanks for catching the oversight.


Thank you for responding so nicely!

As to why you wrote it — heh, we've all been there.


Anyone remembers Dan Cederholm (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 :(


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


Is it common these days to nest inputs in labels? As a comparison, bootstrap doesn't, 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.


With checkboxes, nesting the input inside the label makes the label clickable. It provides a larger target for checking, unchecking.

Edit, to add: To avoid nesting you can use the for attribute. More info on the following link addressing checkboxes and input nesting, in general:

http://stackoverflow.com/a/6293626


The `for` attribute (`htmlFor` in jsx) will also allow the same kind of behavior:

    <label for="coolInput">Click me:</label>
    <input type="checkbox" id="coolInput" />
Edit: You edited while I was typing this out and added info about the `for` ;)


This certainly works but margins are still a dead-zone around inputs. Nesting the inputs can give you larger touch targets which is often preferable.

http://codepen.io/anon/pen/qNzOYW


I don't think the article is even advocating for nested vs. not-nested inputs with labels, the author just picked nested to use in the example. The point of the example was to have a <label>. There's no reason to go to war over nested vs. not-nested.

The only exceptions to "each input must have a label" are inputs of type "hidden" and ones that make button controls so the value attribute effectively labels the control.


It has one distinct advantage: you don't have to generate the id and for attributes, which isn't always the most convenient.


There's another disadvantage to using for: the space between the label and the input isn't clickable.

This matters more for touch screens, but I suspect most of the web is accessed at least sometimes through touch screens.


Nesting inputs inside of the label is accepted practice. The w3c wiki site even provides an example.

w3.org: The label element may contain at most one descendant input element, button element, select element, or textarea element.

You just have to be a bit careful with it concerning screen readers.

EDIT: besides, there are CSS reasons for wrapping the input with a label.


Maybe 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


If you use the for attribute clicking on the label will focus the related input.


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


> Is it common these days to nest inputs in labels?

Been developing websites for almost 15 years now, and I recall this always being a common thing to do.

> To me that's conceptually as well as semantically broken, the two are separate things why is the input inside the label?

I agree that it's conceptually broken, but it is not semantically broken -- since the HTML5 spec and screen readers all recognize this as an equally valid way to define a label on an input.

So they're both equally "correct", just a trade-off of ease-of-styling (for some designs) vs. saving a few bytes and mental overhead of assigning for/id attributes to them.



Only with checkboxes, not with other types of input which are shown in the article (e.g. text, tel, email).


So Bootstrap is internally as well as externally inconsistent?


I would call it pragmatic, as it makes the CSS easier when you want to put a custom checkbox design. Either way, it doesn't seem to be doing them any harm.


I'd thought that was the only way to get clicking on a checkbox label to trigger the checkbox click (unlike other inputs where you could simply use a for label).


The for attribute on labels work for checkboxes.


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


Consider automated TOC generation. If you use the h* tags as they're designed to be used, it's trivial to produce a table of contents for even a very complex document by simply extracting and numbering the headers, and hyperlinking it is almost as easy.

Consider screen readers and other accessibility technologies. If you use the h* tags as they're designed to be used, it is very easy for someone who cannot see your document to navigate within it by moving from header to header, and to navigate within sections by moving from subheader to subheader.

These are two examples of automatically extracting semantic information from an HTML document in order to enable new ways of interacting with its content. Such methods can only work if the semantic information is there to begin with. Using standard header tags in the standard fashion is a good, simple way to include such information. It is not the only way, but it is by far the most widely understood way, and you do both yourself and your readers a favor by not requiring the use of special-case exceptions to parse your content.

Of course, if your purpose is not to publish content, then this may not be a major concern for you. Perhaps you're building one of those modern-style marketing sites where the presentation is excruciatingly visual, the standard interaction methods are unnecessarily hijacked, and the content is minimally existent. In that case, I wouldn't worry so hard about it. But if you're publishing something that's got some meat to it, this is a standard worth following.


Also, WRT screen reader users, like sighted users, they often scan the document by skimming the headings, links, etc. Screen reading software will pull these out into separately scannable lists available for the user to skim through outside of the context of the surrounding content. Having out of order heading creates a document outline that is confusing. This is why it's also important to write good linked text as scanning 20 links that all say "read more" is useless.


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


A simpler way to say "more semantically correct" is "correct." Please don't trivialize the importance of semantics. Proper semantic representation makes documents more accessible.


I 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?


Take a look at 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.


Sorry, I should've provided a reference for you. The link throwanem posted is a good introduction with an interactive demonstration.


Do you have any documentation for this? This part of the article is what stood out for me, too.


The relevant section of the standard: https://www.w3.org/TR/html5/sections.html#the-h1,-h2,-h3,-h4... - https://www.w3.org/TR/html5/sections.html#headings-and-secti... expands on this somewhat further.

For a considerably more detailed treatment with special attention to concerns around accessibility and some information on other document elements with similar significance, take a look at http://accessiblehtmlheadings.com/ .


I see. For the longest time I've been using <h2> as a sub-title. I guess I'll have to stop that. Thanks!


You are most welcome!


Sorry again, I should've provided a reference for you. The link throwanem posted is very good.


I think it also make the HTML easier to read.


It's helpful to other computers reading your website. This can be anything from a screen reader to a search engine crawler to a script like Readability for extracting the readable sections of a website to a document.


I know this is tangential, but Pandoc and Markdown in general benefit greatly from it.


Isn't it because of the way screenreaders prioritize which headings to read based on the #? Eg read H1, then H2's, etc.


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


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


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


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


Knowing which things are paragraphs would also make implementing things like Readability easier.


I'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


Nice point here, despite its gray color.

Paragraph is an atomic entity (irl), not a block of things. Inserting elements into paragraph is like inserting into an image; nonsense in many cases. If you want to apply css to some paragraphs, just put some divs/spans in there.


Can 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?


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


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

Placeholders don't disappear if you just focus input, only when you type first character.


Placeholders disappear in IE.


I think we all know the root of that problem.


In this case IE actually follows the specification:

https://www.w3.org/TR/html5/forms.html#the-placeholder-attri...

> "User agents should present this hint to the user, after having stripped line breaks from it, when the element's value is the empty string and the control is not focused"


Then the specification is wrong, needs to be updated.


It's great, though, how you immediately jumped on Microsoft without even bothering to check whether what they did was correct or not, though.

IE's been as up-to-date as any other browser for like 5-6 years now. Let the hate go already.


Yes, I am now saying the behavior is wrong and goes against user experience. Since IE is going by specifications then I agree my dislike for it in this instance is likely misdirected. On the other hand, it seems the other browsers saw the spec and rightfully disagreed with this behavior; so I'm back to disliking IE.


> On the other hand, it seems the other browsers saw the spec and rightfully disagreed with this behavior

The w3 spec almost certainly postdates the browser vendors decision on what they would implement (and probably the actual implementation -- all the meaningful work on HTML goes on in the WHATWG living standard, the W3 spec is a frozen backward-looking interpretation of that, but even the WHATWG spec is probably a result of the vendor's decision on what to implement, rather than the decisions being based on the spec.) It probably says what it says precisely because that is the level of commonality of behavior between major vendors, with non-Microsoft vendors also displaying the placeholder when the field is empty but focused.

EDIT: Note also that the WHATWG spec, at least, specifies additional behavior if the user agent does not normally display the value when focused ("If a user agent normally doesn't show this hint to the user when the control is focused, then the user agent should nonetheless show the hint for the control if it was focused as a result of the autofocus attribute, since in that case the user will not have had an opportunity to examine the control before focusing it.") [0]

[0] https://html.spec.whatwg.org/multipage/forms.html#attr-input...


The behavior is implementation specific. It differs between browsers.


Wouldn't the type attribute on the input indicate to the phone/browser/etc what's to be expected? Perhaps with a title attribute added?

I'm okay with it, and I'll do it from now on. Just seems kinda weird to start displaying things based on accessibility. I thought that all played out behind the scenes (in things like the alt attr for images)


For usability and accessibility, yes, it's best to put visible labels alongside the input. See http://www.uxmatters.com/mt/archives/2006/07/label-placement....

That said, designers often dislike labels. Float labels are about the best compromise I've seen - https://css-tricks.com/float-labels-css/. You can see them in action on Digital Ocean.


Accessibility is not just about screen readers. Consider, just as an example, color blindness. Choosing the right set of colors to make your site accessible to color blind people is hugely important but it will definitely change the look of your site.

Probably the most common issue is to use green and red colors for some kind of status without also using text and/or symbols.


Yes, I agree completely. Other groups include those with learning difficulties, restricted motor skills and partial-sight. It's a big issue to fit into a small HN comment.


It'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/


it'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/


How limited is your viewport? I still have an old HTC Incredible 2 at home that I use for testing. Though not the smallest, it's only 320x533 (portrait). I'm used to a much larger viewport, and viewing forms with those dimensions are fine. Just ensure that your form fields aren't microscopic. Using the placeholder for explanation also removes the explanations when focusing on the field. A label is permanent.


I suspect that the correct thing to do for usability in those cases is use a label for the field with visibility: hidden.


If it is not brain dead obvious (to others, not the designer) what needs to be entered into each field without any prompting then you need labels.

Do this: Remove all the placeholders. Now ask someone else to fill in the form. If they don't know what to do you need labels, not placeholders.


If your viewport can't afford two lines for the label + input, you may need to work on some really different UI.


I think it can definitely be a challenge sometimes: go to youtube.com and look at their search input (says "Search" in a placeholder). There's no way they can put the label above the search box, it would almost double the size of their header. So they'd have to put the Search label to the left or something.


Search boxes are a special case. There is one input and the form submit button is usually adjacent to the input and clearly marked with a search glyph or the word search. One a search form has multiple fields it tends to use the labels e.g. google's advanced search forms.


Question: 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?


I have seen no evidence to suggest that search engines care about HTML5 semantic tags. While the tags may be one particular signal, their algorithms use a lot of signals, so don't rely on markup alone. I suspect if they did give them any value, they would quickly be abused by the black-hats, so they don't bother.

As always, do what's right for your (human) users, and you will eventually get the SEO benefit.


Agree with your overall sentiment, but should clarify this:

> I have seen no evidence to suggest that search engines care about HTML5 semantic tags

I think you mean "HTML5 sectioning elements" (header, footer, section, article, aside, main). Because search engines absolutely positively do care about proper "semantic" use of other tags (especially h1...h6).


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


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


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


I wonder if Google should put some time/effort into making a better (ideally free to use) screen reader? They seem to have pretty advanced technology for finding the human-relevant parts of a web page.


Do you have any references to this?


The first no-brainer that springs to mind is <nav> so that search engines can tell words related to the current page apart from words related to pages you might navigate to.


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


I'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?


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


Put offscreen text inside.


Or add an aria-label property to the link.


Slightly off-topic, but:

> Couldn’t be much more from the hearth<br>

Couldn’t be much more from the heart.


I had to pull out the CD and double-check, because I thought so, too. You're right, he very distinctly pronounces the final "t".


That 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?


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


<p></p> is start and end of a paragraph.


use more <p></p>.


I wish safari supports currency keypad with decimal in HTML5. It's working for android but not for iOS ;-(


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


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


Best 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?


I was specifically talking about "symbol" and "use" - which have very limited CSS support.


Everyone know these things. What's the big deal?


I learned something new. It's not a big deal, but I'm glad it was posted nonetheless.


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


[flagged]


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


What a pain


Some of us are comfortable enough to admit silly little faults.


A quick peruse of the web will show that knowledge of these tips is far from widespread.


everybody may not know.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: