Skip to content
This repository

placeholder Polyfill Discussion #158

Closed
zachleat opened this Issue March 14, 2012 · 11 comments

5 participants

Zach Leatherman Divya Manian Paul Irish Max West Anselm Hannemann
Zach Leatherman

The HTML5 specification states:

The placeholder attribute represents a short hint (a word or short phrase) intended to aid the user with data entry. A hint could be a sample value or a brief description of the expected format.

The placeholder attribute should not be used as an alternative to a label.

If correctly using the placeholder as the specification states, my opinion is that the usability utility of the polyfill is decreased to the point that it is outweighed by the cost (performance, maintenance, etc). Of course, I'm probably a bit biased in that I've personally witnessed internal applications with hundreds of placeholders on a single page and devs might be only using this on a few fields? Your mileage may also vary depending on your own browser statistics.

More detailed info and discussion here: http://www.zachleat.com/web/placeholder/

Thoughts?

Paul Irish
Owner

I still dont understand the "should not be used as an alternative to a label" as this is precisely how its going to be used 90% of the time.

that said, i do like the idea of letting this degrade.
but i guess it'd be hard to let it, depending on how neccessary the text is (e.g. phone number formatting hints)

Divya Manian
Owner

The idea is to not say "Phone" in the placeholder text, but say "e.g. 206 123 1222".

Zach Leatherman

Timely that Roger Johansson weighed in on this yesterday.
https://twitter.com/rogerjohansson/status/180387208044355584

Paul Irish
Owner

divya, yeah i agree.. You'd have phone: in an external <label> but in this case I wouldn't want the number formatting hint to degrade because it's actually quite important for valid input.

given that.. trying to think of use cases where the placeholder text should be optional.. even supplementary help text seems more important for folks on downlevel browsers.

Zach Leatherman

Sure, but formatting doesn't feel like the right problem for a placeholder to solve. It can help, but isn't a solution. I think it would be better solved by input masks and/or client side validation. So really, it's in this weird middle-ground where it only half-assed solves problems. If it isn't whole-assing anything, which in my humble opinion is the minimum bar for polyfilling.

I see your point though. There isn't one-true-way.

Paul Irish
Owner
Zach Leatherman

I don't think it's strictly a screen reader thing. Certainly there are usability reasons for needing the label text to be viewable as you're typing into the field (or more importantly if the field has a prepopulated value).

Zach Leatherman

Was trying out ChromeVox today and it does read the placeholder value aloud.

Divya Manian
Owner

@zachleat i would be happy if you can do a pull req on this that would explain the use of placeholder attr sufficiently.

Max West

How is a placeholder not a label?

Anselm Hannemann

I know I'm late here but I don't think you can replace a label-element by an placeholder attribute. Both have completely different use-cases and meaning.

label

Use the label element for a description of the following form-element. This describes the semantic meaning of the element (like: "prename").

placeholder

A placeholder attribute is shown when the form field is not filled out and shows sample content and is comparable to a help-wizard: The user sees how to enter the content (e.g.: "Anselm" for prename OR "email@domain.com" for email).

Why it would be a bad idea to replace label element by placeholder:

1. Accessibilty: For example a screenreader user wants to fill out a form. He now doesn't get a description of the field but only (if he's lucky to use a modern screenreader that actually reads placeholder-attr) the content sample. Now imagine this is a custom field. The user won't know what to enter just because of placeholder sample content.

If a disabled user uses a form he goes somehow through the form using tab-key. Entering the field, sample content (placeholder) disappears. Some screenreader might read out placeholder anyway but this is not the default behavior and would only be for blind users. Also the placeholder text is by default light grey. This is low-contrast and not user-friendly for important field descriptions.

2. Abuse: Also I can imagine where people fill the label description into placeholder attribute. This is even worse as you then might have the question "What's your favourite color?" as sample content in placeholder-attr but no real sample content as it should be "blue" here.

Now about the polyfill: If we have polyfills this is a non native technique. That also means it does work somehow different than the proposed solution. In the placeholder-case the placeholder is written into value by jQuery. This means it completely disappears on focus. So if you user the polyfill you need a label to describe the field otherwise we would have a blank field when it's focused. A screenreader (but be aware there are many other a11y UAs!) would read out the predefined value. Still you should not use the placeholder as replacement to label.
So either a normal user or a somehow disabled user will run into problems when you're replacing label-element by placeholder-attribute.
That said, the polyfill would actually work if a label is provided.

Hope that helps around the issues here…

Divya Manian nimbupani closed this February 18, 2013
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.