Re: [whatwg] Placeholder option for text input boxes
Tab Atkins Jr. wrote: I'd suspect that *all* examples where placeholder text is used (definitely all the examples I know of personally) are most semantically served by a label with the text. Iirc, I once saw a nice javascript solution that mutated the DOM to remove the label and use its text as a placeholder. Thus, I think this is best served by a CSS directive that does exactly that. External vs placeholder text is a display issue - semantically, both are labels for the field. I found real example that uses both a label and placeholder text. In the iPhone, the dialog for setting up a new e-mail account, contains four fields, each with a label and an example provided as placeholder text. These are: [Label] [Placeholder] Name:John Appleseed Address: [EMAIL PROTECTED] Password:Required Description: My Email Account -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
Re: [whatwg] Placeholder option for text input boxes
Am Sonntag, den 05.10.2008, 12:20 -0700 schrieb Garrett Smith:
But what if the designer wants to use an image?
input type=search placeholder=ybang.gif
Would display the text:
bang.gif
- not the binary resource of the image. In some cases, designers or
marketing will want an image there. Maybe some ui css would be a
possibility:
placeholder-background: url(bang.gif) no-repeat center;
IMO it'd have to be more like
input:hint
{
background: url(foo.bar);
}
but can we switch over that discussion to CSS WG now ?
Cheers,
Nils
Re: [whatwg] Placeholder option for text input boxes
Am Sonntag, den 05.10.2008, 22:13 +0200 schrieb Nils Dagsson Moskopp:
Am Sonntag, den 05.10.2008, 12:20 -0700 schrieb Garrett Smith:
But what if the designer wants to use an image?
input type=search placeholder=ybang.gif
Would display the text:
bang.gif
- not the binary resource of the image. In some cases, designers or
marketing will want an image there. Maybe some ui css would be a
possibility:
placeholder-background: url(bang.gif) no-repeat center;
IMO it'd have to be more like
input:hint
{
background: url(foo.bar);
}
but can we switch over that discussion to CSS WG now ?
Cheers,
Nils
Disregard that, David Baron's suggestion of a value pseudoattribute
seems even cooler.
Re: [whatwg] Placeholder option for text input boxes
On Sun, Oct 5, 2008 at 1:07 PM, L. David Baron [EMAIL PROTECTED] wrote:
On Sunday 2008-10-05 12:20 -0700, Garrett Smith wrote:
But what if the designer wants to use an image?
input type=search placeholder=ybang.gif
Would display the text:
bang.gif
- not the binary resource of the image. In some cases, designers or
marketing will want an image there. Maybe some ui css would be a
possibility:
placeholder-background: url(bang.gif) no-repeat center;
This could be implemented by browsers so developers could have a
placeholder and, where supported, a placeholder-background.
It seems like this belongs on the selector side of CSS, not the
property side. It's not clear to me why you chose to duplicate only
the background-* properties, but no others.
It fulfills a simple use case. That is, a placeholder as an image.
input type='search' style='placeholder-background: url(bang.gif) no-repeat;'
It does not get in the way of the placeholder attribute or property
(doesn't prevent progress).
What other use case did you have?
I think something more like the following would work better:
input[:value=] { background: url(bang.gif) no-repeat center; }
perhaps with a default of:
input[:value=] { contents: attr(placeholder); }
content:[1]
(The value attribute doesn't dynamically reflect the value of the
input. However, it seems reasonable to want to style based on the
current value; we already have the :checked pseudo-class for that
for some form controls.)
The idea of :value for a property is useful.
The attr is supposed to represent the attribute. If you want to select
a property, a property selector would seem less ambiguous.
content: property(placeholder);
[1]http://www.w3.org/TR/CSS2/generate.html#content
Garrett
-David
--
L. David Baron http://dbaron.org/
Mozilla Corporation http://www.mozilla.com/
Re: [whatwg] Placeholder option for text input boxes
On Sun, Oct 5, 2008 at 1:33 PM, Garrett Smith [EMAIL PROTECTED] wrote:
On Sun, Oct 5, 2008 at 1:07 PM, L. David Baron [EMAIL PROTECTED] wrote:
On Sunday 2008-10-05 12:20 -0700, Garrett Smith wrote:
What other use case did you have?
Were you t hinking of allowing styling of the placeholder text to have
values that would apply only to the placeholder, such as:
{
color: #999;
font-family: Tahoma;
}
?
I think something more like the following would work better:
input[:value=] { background: url(bang.gif) no-repeat center; }
perhaps with a default of:
input[:value=] { contents: attr(placeholder); }
Garrett
-David
--
L. David Baron http://dbaron.org/
Mozilla Corporation http://www.mozilla.com/
Re: [whatwg] Placeholder option for text input boxes
On Sat, Oct 4, 2008 at 9:04 AM, Kristof Zelechovski [EMAIL PROTECTED] wrote: TJ Atkins said: Man, I could *really* see the hint function being viable and quite useful. It offers up a completely new-and-useful semantic, and there's no particular place it should already go. I'd accept this as a new attribute without reservation if it was renamed @hint, so it's absolutely clear what the semantic for it is. ~TJ What happens if a hint and a value are both specified? The value would display. The hint only displays when the input is both empty and not focussed. @value negates the first condition. ~TJ
Re: [whatwg] Placeholder option for text input boxes
Am Samstag, den 04.10.2008, 09:15 -0500 schrieb Tab Atkins Jr.: The hint only displays when the input is both empty and not focussed. Sounds like a job for a new CSS-pseudoclass regarding inputs, doesn't it ? Cheers, Nils
Re: [whatwg] Placeholder option for text input boxes
Does the hint display if the input control gets cleared after loading? IMHO, The hint should not disappear on focus. It should remain until a new value is entered. Chris _ From: Tab Atkins Jr. [mailto:[EMAIL PROTECTED] Sent: Saturday, October 04, 2008 4:15 PM To: Kristof Zelechovski Cc: WHATWG Subject: Re: [whatwg] Placeholder option for text input boxes On Sat, Oct 4, 2008 at 9:04 AM, Kristof Zelechovski [EMAIL PROTECTED] wrote: TJ Atkins said: Man, I could *really* see the hint function being viable and quite useful. It offers up a completely new-and-useful semantic, and there's no particular place it should already go. I'd accept this as a new attribute without reservation if it was renamed @hint, so it's absolutely clear what the semantic for it is. ~TJ What happens if a hint and a value are both specified? The value would display. The hint only displays when the input is both empty and not focussed. @value negates the first condition. ~TJ
Re: [whatwg] Placeholder option for text input boxes
If a date input control is split, only the month should be requested as a SELECT control. Chris -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Adrian Sutton Sent: Friday, October 03, 2008 10:31 PM To: Nils Dagsson Moskopp; whatwg Subject: Re: [whatwg] Placeholder option for text input boxes On 03/10/08 20:56, Nils Dagsson Moskopp [EMAIL PROTECTED] wrote: Am Freitag, den 03.10.2008, 20:41 +0100 schrieb Adrian Sutton: label for=²date²Date: input type=²text² placeholder=²1 Jan 2008² id=²date² //label Wouldn't three comboboxes be more appropriate ? While that's a common solution it's a terribly inefficient and frustrating user interface. Besides, the specific examples aren't as important as the idea that placeholder is an excellent way to provide suggestions and thus distinct from the label of the field. Regards, Adrian Sutton. __
Re: [whatwg] Placeholder option for text input boxes
Am Samstag, den 04.10.2008, 16:34 +0200 schrieb Kristof Zelechovski IMHO, The hint should not disappear on focus. It should remain until a new value is entered. This is a BAD idea for consistency reasons - historically only selected text disappears on input. Cheers, Nils
Re: [whatwg] Placeholder option for text input boxes
IMHO, the hint should be marked when the control gets focus so that it will be clear that the text will disappear. Chris -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Nils Dagsson Moskopp Sent: Saturday, October 04, 2008 4:43 PM To: whatwg Subject: Re: [whatwg] Placeholder option for text input boxes Am Samstag, den 04.10.2008, 16:34 +0200 schrieb Kristof Zelechovski IMHO, The hint should not disappear on focus. It should remain until a new value is entered. This is a BAD idea for consistency reasons - historically only selected text disappears on input. Cheers, Nils
Re: [whatwg] Placeholder option for text input boxes
On 04/10/2008 15:46, Kristof Zelechovski [EMAIL PROTECTED] wrote: IMHO, the hint should be marked when the control gets focus so that it will be clear that the text will disappear. That would be platform and implementation dependant. On OS X the text should without doubt disappear on focus as that's the behavior users would expect. On Linux or Windows they might expect something different. There's no reason the presentation has to be identical in all implementations. Regards, Adrian Sutton __ Adrian Sutton, CTO UK: +44 1 753 27 2229 US: +1 (650) 292 9659 x717 Ephox http://www.ephox.com/ Ephox Blogs http://planet.ephox.com/, Personal Blog http://www.symphonious.net/
Re: [whatwg] Placeholder option for text input boxes
On Oct 4, 2008, at 7:01 AM, Tab Atkins Jr. wrote: On Fri, Oct 3, 2008 at 8:24 PM, Andy Lyttle [EMAIL PROTECTED] wrote: On Oct 3, 2008, at 4:35 PM, Tab Atkins Jr. wrote: Man, I could *really* see the hint function being viable and quite useful. It offers up a completely new-and-useful semantic, and there's no particular place it should already go. I'd accept this as a new attribute without reservation if it was renamed @hint, so it's absolutely clear what the semantic for it is. The only reason to use placeholder instead of hint is that Apple already implemented placeholder. Documentation should explain that placeholder is to be used for hints, not for labels (and people can then ignore the documentation and use it for labels anyway, but at least we tried). Well, we don't really have interop yet, since *only* Webkit implements it currently, and officially only on a single non- standard input type (though it happens to apply to text and similar input types). If we can shift the name over *now*, before FF implements it fully, it would probably be fine. On the other hand, I don't want to be one of those jerks who tries to block a feature solely because they don't like its name. However, it's a proven fact that most people don't look at documentation *ever*, and so having the name provide a perfectly intuitive hint for what the attribute is supposed to do would probably be best. At the very least it would set up some cognitive dissonance for people using it as a label, hopefully. I think placeholder is as good a name as hint; it may sound less semantic but it's more clear that it would result in a tooltip like title would. That being said, it would not be an excessive burden for us to support hint as well as placeholder for compatibility. Regards, Maciej
Re: [whatwg] Placeholder option for text input boxes
On 10/3/08, Adrian Sutton [EMAIL PROTECTED] wrote:
Placeholder ... aids usability
having recently fought with some javascript which tried to enhance my
ability to enter text ('crash' in a keyword chooser using nokia's
webkit based browser on my phone), I'd like to remind people that
someone's usability aid is someone else's nightmare. the problem
there didn't need solving as the browsers we have either support
remembering text-input or have keyboard support or are so slow that
the chooser hangs them
i use quite a few browsers where javascript is disabled and in many of
them, clearing a text field is extremely painful (especially the phone
cases).
my devices aren't powerful enough to support true accessibility
features, but in some ways they want them- especially to turn off all
of these glitzy web features which significantly impede my ability
to get work done.
sometimes enabling a designer to do something is the wrong decision.
google and skype both can convert all numbers they see into very
annoying and generally incorrect tel: links. skype's toolbar can
thankfully be disabled, however the gmail mobile one can't be, which
means I'm stuck with unusable (and unreadable) content.
placeholders are interesting, but will the resources required to
support them be better than telling designers just to make their
label's clearer?
for my devices, I'm going to need a way to disable them and something
tells me that even if we were to standardize on a way to present
placeholders, I'll still be unable to suppress many implemented in
javascript/css.
- this complaint was composed using an n800 because symbian brutally
killed my gmail client and the web browser.
Re: [whatwg] Placeholder option for text input boxes
On 10/4/08, Adrian Sutton [EMAIL PROTECTED] wrote: That would be platform and implementation dependant. On OS X the text should without doubt disappear on focus as that's the behavior users would expect. On Linux or Windows they might expect something different. There's no reason the presentation has to be identical in all implementations. a more helpful implementation would move the hint outside the text field so that users can refer to it while entering their values. at which point you'd hopefully understand that their correct place is in an alternate presentation (in firefox this is viewuse stylesome style). an example from a real intranet application which should not exist. its job is to enable employees to report expenses: (the exact details do not follow as i only encountered this nightmare once) item number (1) description: (_) date: (_!v) type: (_!v) currency: (_!v) cost in currency: _ exchange rate to euros: _ this last field has an error hint when you enter a number incorrectly e.g. because you used too many digits. - it shows you a very long number (something like 99.999) and says your number should have this format. now it helpfully hides the error after a few moments - long before you figure out how your number doesn't correctly match its hint. this might be a useful placeholder however the form prefills a very outdated exchange value. the correct design for this is with a span, probably an aria role and a default stylesheet which hides it. but which can be displayed on request of the user to the user agent. anyone interested in fixing this application is welcome to contact me, helpwanted :) but again, unless all user agents choose this implementation, i'm not sure how creating yet another html bit will do anything but enable more bad web applications like the one i've described. this application was almost certainly not aria friendly and i'd encourage people to seriously consider the actual needs of their users. usually you will probably not find hints that run away to be truly helpful. fwiw, i can't recall whether the hint from this application used a title or a floating div, but either way html enabled bad design and the current proposals which should speak to my real world problem will fail as miserably as the current available dhtml did. whereas a simpler implementation and recommendation to use a span + aria markup would help everyone.
Re: [whatwg] Placeholder option for text input boxes
On Oct 4, 2008, at 3:38 PM, timeless wrote:
On 10/3/08, Adrian Sutton [EMAIL PROTECTED] wrote:
Placeholder ... aids usability
having recently fought with some javascript which tried to enhance my
ability to enter text ('crash' in a keyword chooser using nokia's
webkit based browser on my phone), I'd like to remind people that
someone's usability aid is someone else's nightmare. the problem
there didn't need solving as the browsers we have either support
remembering text-input or have keyboard support or are so slow that
the chooser hangs them
i use quite a few browsers where javascript is disabled and in many of
them, clearing a text field is extremely painful (especially the phone
cases).
The existence of a placeholder attribute in HTML should discourage
web developers from using crazy Javascript hacks that don't work
correctly on a cell phone. In particular, it means NOT faking it
by setting the value of the field to an obnoxious string that doesn't
get cleared. Browser developers such as Nokia can display
placeholder text in whatever way makes the most sense on their
platform, without using JavaScript at all.
Most mobile browsers I've used switch to a text input dialog as soon
as the control is focussed. I would display the placeholder on the
web page the same way any other browser would, but not display it on
the text input dialog. Someone else might choose to go ahead and
display it on the text input dialog as well (above the input field),
with the placeholder text not disappearing while text is being entered.
my devices aren't powerful enough to support true accessibility
features, but in some ways they want them- especially to turn off all
of these glitzy web features which significantly impede my ability
to get work done.
sometimes enabling a designer to do something is the wrong decision.
google and skype both can convert all numbers they see into very
annoying and generally incorrect tel: links. skype's toolbar can
thankfully be disabled, however the gmail mobile one can't be, which
means I'm stuck with unusable (and unreadable) content.
Enabling a designer to use placeholders is a moot point; they're
already doing it, in a non-standard buggy way that breaks on your
phone. We want to give them semantic markup that will behave the way
they want in their browser, while still being perfectly usable on
your phone so they can quit using annoying hacks. Placeholder
shouldn't be glitzy and absolutely should never impede your ability
to get work done; if it does, somebody screwed up their implementation.
placeholders are interesting, but will the resources required to
support them be better than telling designers just to make their
label's clearer?
I don't expect the required resources to be significant, but I'm not
a browser developer...
for my devices, I'm going to need a way to disable them and something
tells me that even if we were to standardize on a way to present
placeholders, I'll still be unable to suppress many implemented in
javascript/css.
This is true. Adding placeholder to HTML doesn't mean web developers
will immediately drop their JS/CSS hacks, because existing browsers
don't support placeholder. But over time, as everybody upgrades
their browsers and developers stop caring about the people still
using older browsers, the problem should slowly fade away.
- this complaint was composed using an n800 because symbian brutally
killed my gmail client and the web browser.
My N75 won't load more than a few pages before the browser stops
working entirely and I have to reboot the phone. Sucktacular.
--
Andy Lyttle
[EMAIL PROTECTED]
Re: [whatwg] Placeholder option for text input boxes
On Sat, Oct 4, 2008 at 7:41 PM, Andy Lyttle [EMAIL PROTECTED] wrote:
On Oct 4, 2008, at 3:38 PM, timeless wrote:
On 10/3/08, Adrian Sutton [EMAIL PROTECTED] wrote:
Placeholder ... aids usability
having recently fought with some javascript which tried to enhance my
ability to enter text ('crash' in a keyword chooser using nokia's
webkit based browser on my phone), I'd like to remind people that
someone's usability aid is someone else's nightmare. the problem
there didn't need solving as the browsers we have either support
remembering text-input or have keyboard support or are so slow that
the chooser hangs them
i use quite a few browsers where javascript is disabled and in many of
them, clearing a text field is extremely painful (especially the phone
cases).
The existence of a placeholder attribute in HTML should discourage web
developers from using crazy Javascript hacks that don't work correctly on a
cell phone. In particular, it means NOT faking it by setting the value of
the field to an obnoxious string that doesn't get cleared. Browser
developers such as Nokia can display placeholder text in whatever way makes
the most sense on their platform, without using JavaScript at all.
Most mobile browsers I've used switch to a text input dialog as soon as the
control is focussed. I would display the placeholder on the web page the
same way any other browser would, but not display it on the text input
dialog. Someone else might choose to go ahead and display it on the text
input dialog as well (above the input field), with the placeholder text not
disappearing while text is being entered.
The great thing about this being a *semantic* issue rather than a display
issue is that browsers are free to do precisely that - display the hint in
whatever way makes the most sense for them and is the most useful for their
users and platform.
~TJ
Re: [whatwg] Placeholder option for text input boxes
I've wrestled with this because its something that our designer has wanted to use all over the place for an application I'm working on. It turns out to be a usability nightmare if not used sparingly. When we used it, it was definitely in place of an actual label, and I think this would be true in most cases. In the cases where an outer label and a placeholder are needed, I think the solution could just be to have two Label elements that point to the same input. From the HTML 4.01 spechttp://www.w3.org/TR/html4/interact/forms.html#edef-LABEL : More than one LABELhttp://www.w3.org/TR/html4/interact/forms.html#edef-LABEL may be associated with the same control by creating multiple references via the for http://www.w3.org/TR/html4/interact/forms.html#adef-for attribute. Then CSS could be used on one of the labels to make it appear as placeholder content. On Thu, Oct 2, 2008 at 7:34 PM, Tab Atkins Jr. [EMAIL PROTECTED] wrote: On Thu, Oct 2, 2008 at 6:27 PM, Brenton Strine [EMAIL PROTECTED]wrote: On Tue, Sep 30, 2008 at 11:36 AM, Andy Lyttle [EMAIL PROTECTED] wrote: [snip] 4) label (moving label textual content into input as placeholder text; currently with Javascript to mutate the DOM, in the future with CSS to present the desired appearance while keeping the DOM stable) Pro: Most semantic. [snip] That depends on what you are using it for. What if you are using it to apply a placeholder that says (optional)? That is not a label at all. There are a lot of uses for the proposed placeholder attribute that just don't fit into any of the other categories. I think a placeholder attribute would be great. Hmm, true. That's definitely a case where the text can't be argued to be a label. Of course, it's still not in any way semantic. The only difference between (optional) being displayed near the input and being displayed *within* the input is one of aesthetics. The meaning of the document isn't changed one iota. This leans me even more toward a CSS solution. I'll just bite the bullet and bring it up to the CSS WG. ~TJ
Re: [whatwg] Placeholder option for text input boxes
On Thu, Oct 2, 2008 at 4:34 PM, Tab Atkins Jr. [EMAIL PROTECTED] wrote: On Thu, Oct 2, 2008 at 6:27 PM, Brenton Strine [EMAIL PROTECTED] wrote: On Tue, Sep 30, 2008 at 11:36 AM, Andy Lyttle [EMAIL PROTECTED] wrote: Of course, it's still not in any way semantic. The only difference between (optional) being displayed near the input and being displayed *within* the input is one of aesthetics. The meaning of the document isn't changed one iota. This leans me even more toward a CSS solution. I'll just bite the bullet and bring it up to the CSS WG. Are you proposing that placeholder could be a positioned object, such as an image? ~TJ
Re: [whatwg] Placeholder option for text input boxes
On Fri, Oct 3, 2008 at 9:32 AM, Garrett Smith [EMAIL PROTECTED]wrote: On Thu, Oct 2, 2008 at 4:34 PM, Tab Atkins Jr. [EMAIL PROTECTED] wrote: On Thu, Oct 2, 2008 at 6:27 PM, Brenton Strine [EMAIL PROTECTED] wrote: On Tue, Sep 30, 2008 at 11:36 AM, Andy Lyttle [EMAIL PROTECTED] wrote: Of course, it's still not in any way semantic. The only difference between (optional) being displayed near the input and being displayed *within* the input is one of aesthetics. The meaning of the document isn't changed one iota. This leans me even more toward a CSS solution. I'll just bite the bullet and bring it up to the CSS WG. Are you proposing that placeholder could be a positioned object, such as an image? Not entirely sure what you're suggesting here, but maybe? My suggestion was put forward up above - I would prefer if the placeholder text was replaced content. You set a CSS rule (haven't decided the best way to handle this yet) that suppresses the display of a label and instead uses the textual content of the label as a placeholder. Using an image as a placeholder is interesting, though. I know that Google custom search does that sometimes. However, I'm fine with leaving that to Javascript for now, as image placeholders aren't an accessibility concern like the placeholder-instead-of-label issue is. As well, it's still a minority technique compared to text placeholders. ~TJ
Re: [whatwg] Placeholder option for text input boxes
On Fri, Oct 3, 2008 at 8:05 AM, Tab Atkins Jr. [EMAIL PROTECTED] wrote: On Fri, Oct 3, 2008 at 9:32 AM, Garrett Smith [EMAIL PROTECTED] wrote: On Thu, Oct 2, 2008 at 4:34 PM, Tab Atkins Jr. [EMAIL PROTECTED] wrote: On Thu, Oct 2, 2008 at 6:27 PM, Brenton Strine [EMAIL PROTECTED] wrote: On Tue, Sep 30, 2008 at 11:36 AM, Andy Lyttle [EMAIL PROTECTED] wrote: iota. This leans me even more toward a CSS solution. I'll just bite the bullet and bring it up to the CSS WG. Are you proposing that placeholder could be a positioned object, such as an image? Not entirely sure what you're suggesting here, but maybe? I feel the same way about what you wrote. (?) My suggestion was put forward up above - I would prefer if the placeholder text was replaced content. You set a CSS rule (haven't decided the best way to handle this yet) that suppresses the display of a label and instead uses the textual content of the label as a placeholder. A label element? Using an image as a placeholder is interesting, though. Designers propose all sorts of things. I know that Google custom search does that sometimes. Google does all sorts of things, too. And Yahoo, too. However, I'm fine with leaving that to Javascript for now, as image placeholders aren't an accessibility concern like the placeholder-instead-of-label issue is. As well, it's still a minority technique compared to text placeholders. ~TJ
Re: [whatwg] Placeholder option for text input boxes
!DOCTYPE HTML
html xmlns=http://www.w3.org/1999/xhtml;
head
style type=text/css
*
{
font-size: 12px;
}
input
{
background-color: white;
margin-left:-1em;
opacity:0.5;
padding:0.5em;
vertical-align: middle;
}
input:focus
{
opacity:1.0;
}
span
{
display:inline-block;
margin-left:0.5em;
height: 2em;
width: 0;
}
/style
/head
body
form
fieldset
legendno placeholder attribute necessary/legend
label for=input
spanamirite?/span
input type=text id=input/
/label
/fieldset
/form
/body
/html
Re: [whatwg] Placeholder option for text input boxes
dear mailing list, please disregard my former submission. (when one enters text and then unfocuses the input becomes garbled due to overlaying the faux placeholder.) cheers, nils
Re: [whatwg] Placeholder option for text input boxes
Russell Leggett wrote: I've wrestled with this because its something that our designer has wanted to use all over the place for an application I'm working on. It turns out to be a usability nightmare if not used sparingly. Why was it a uasability nightmare? Would it still have been a useability nightmare if there had existed a semantic 'placeholder' attribute? / Jonas
Re: [whatwg] Placeholder option for text input boxes
On Fri, Oct 3, 2008 at 10:37 AM, Garrett Smith [EMAIL PROTECTED]wrote: On Fri, Oct 3, 2008 at 8:05 AM, Tab Atkins Jr. [EMAIL PROTECTED] wrote: On Fri, Oct 3, 2008 at 9:32 AM, Garrett Smith [EMAIL PROTECTED] wrote: On Thu, Oct 2, 2008 at 4:34 PM, Tab Atkins Jr. [EMAIL PROTECTED] wrote: On Thu, Oct 2, 2008 at 6:27 PM, Brenton Strine [EMAIL PROTECTED] wrote: On Tue, Sep 30, 2008 at 11:36 AM, Andy Lyttle [EMAIL PROTECTED] wrote: iota. This leans me even more toward a CSS solution. I'll just bite the bullet and bring it up to the CSS WG. Are you proposing that placeholder could be a positioned object, such as an image? Not entirely sure what you're suggesting here, but maybe? I feel the same way about what you wrote. (?) Then I'll expand. I guess you're late to the thread? Not that it's a problem, I just assumed that you'd seen the mail I sent earlier. My suggestion was put forward up above - I would prefer if the placeholder text was replaced content. You set a CSS rule (haven't decided the best way to handle this yet) that suppresses the display of a label and instead uses the textual content of the label as a placeholder. A label element? Yes. My idea is based on the fact that on every current use of placeholder-like functionality I've ever seen, the placeholder text was semantically a label, and was in fact used in place of a label. The majority of suggestions put forth in this thread have the same property - the text that they're packing into @placeholder is semantically a label, and should actually be put there - it's merely a desire to change the display of the label that moves them to put it into @placeholder. Thus, this seems rather straightforwardly a CSS issue. You code up an ordinary, semantic form with label and such, then some CSS rule takes over and suppresses the appearance of the label, but displays the textual content of the label within the input (or textarea). Some searching finally let me find the article where I found this technique put into practice with Javascript. Jeremy Boles produced the example that I first saw, but he appears to have taken down his blog. However, A List Apart Issue #229 covered it as well, and they still have a working page. [1] My idea is that this should be doable through CSS rather than only through Javascript at current. [1]: http://alistapart.com/articles/makingcompactformsmoreaccessible ~TJ
Re: [whatwg] Placeholder option for text input boxes
On Oct 3, 2008, at 10:15 AM, Jonas Sicking wrote: Russell Leggett wrote: I've wrestled with this because its something that our designer has wanted to use all over the place for an application I'm working on. It turns out to be a usability nightmare if not used sparingly. Why was it a uasability nightmare? Would it still have been a useability nightmare if there had existed a semantic 'placeholder' attribute? Or was it because they really should have been using labels, instead of trying to shoehorn all the labels into placeholders that disappear on focus so as soon as you click you can't see what you're supposed to be doing? -- Andy Lyttle [EMAIL PROTECTED]
Re: [whatwg] Placeholder option for text input boxes
On Fri, Oct 3, 2008 at 12:24 PM, Andy Lyttle [EMAIL PROTECTED] wrote: On Oct 3, 2008, at 10:15 AM, Jonas Sicking wrote: Russell Leggett wrote: I've wrestled with this because its something that our designer has wanted to use all over the place for an application I'm working on. It turns out to be a usability nightmare if not used sparingly. Why was it a uasability nightmare? Would it still have been a useability nightmare if there had existed a semantic 'placeholder' attribute? Or was it because they really should have been using labels, instead of trying to shoehorn all the labels into placeholders that disappear on focus so as soon as you click you can't see what you're supposed to be doing? I can't speak for him, but I'm willing to state Bingo for myself. A blog post commenting on the use javascript to turn labels into placeholders technique [1] brought up *exactly* that issue. That's really just an argument to use it sparingly, though - if a semantic way to do this was presented, there'd be no problem with using it for an attractive and compact login form. @Jonas: The question that presents itself is what semantic @placeholder could present that isn't already covered by label. [1]: http://www.simiandesign.com/blog-fu/2005/09/javascript_for.php ~TJ
Re: [whatwg] Placeholder option for text input boxes
On 03/10/08 18:34, Tab Atkins Jr. [EMAIL PROTECTED] wrote: @Jonas: The question that presents itself is what semantic @placeholder could present that isn't already covered by label. Placeholder contains example text really nicely. It¹s quite distinct from the field label, aids usability and is too useful and important to be considered just a display attribute. For example: form fieldset legendAddress/legend label for=nameName: input type=text placeholder=John Doe id=name /label label for=address1Address line 1: input type=text placeholder=1 Infinite Loop id=address1 /label label for=address2Address line 2: input type=text placeholder=Cupertino id=address2 /label /fieldset /form Addresses prove to be an extremely good example because there are so many different formats around the world and people get confused. Dates also matter, eg: label for=²date²Date: input type=²text² placeholder=²1 Jan 2008² id=²date² //label While ideally the server would deal with a huge variety of date formats giving a subtle hint about a format that would work particularly well is very useful and a lot more user-friendly than (DD/MM/YY). I¹m sure there are plenty of other examples of data types that would benefit from an example rather than just a lot of text describing the field. Regards, Adrian Sutton. __ Adrian Sutton, CTO UK: +44 1 753 27 2229 US: +1 (650) 292 9659 x717 Ephox http://www.ephox.com/ Ephox Blogs http://planet.ephox.com/, Personal Blog http://www.symphonious.net/
Re: [whatwg] Placeholder option for text input boxes
Am Freitag, den 03.10.2008, 20:41 +0100 schrieb Adrian Sutton: Addresses prove to be an extremely good example because there are so many different formats around the world and people get confused. Dates also matter, eg: label for=”date”Date: input type=”text” placeholder=”1 Jan 2008” id=”date” //label Wouldn't three comboboxes be more appropriate ? While ideally the server would deal with a huge variety of date formats giving a subtle hint about a format that would work particularly well is very useful and a lot more user-friendly than (DD/MM/YY). I’m sure there are plenty of other examples of data types that would benefit from an example rather than just a lot of text describing the field. Maybe helping with your problem, Xforms comes to mind. http://www.w3.org/TR/2007/REC-xforms-20071029/#datatypes
Re: [whatwg] Placeholder option for text input boxes
On 03/10/08 20:56, Nils Dagsson Moskopp [EMAIL PROTECTED] wrote: Am Freitag, den 03.10.2008, 20:41 +0100 schrieb Adrian Sutton: label for=²date²Date: input type=²text² placeholder=²1 Jan 2008² id=²date² //label Wouldn't three comboboxes be more appropriate ? While that's a common solution it's a terribly inefficient and frustrating user interface. Besides, the specific examples aren't as important as the idea that placeholder is an excellent way to provide suggestions and thus distinct from the label of the field. Regards, Adrian Sutton. __ Adrian Sutton, CTO UK: +44 1 753 27 2229 US: +1 (650) 292 9659 x717 Ephox http://www.ephox.com/ Ephox Blogs http://planet.ephox.com/, Personal Blog http://www.symphonious.net/
Re: [whatwg] Placeholder option for text input boxes
On Oct 3, 2008, at 1:31 PM, Adrian Sutton wrote: On 03/10/08 20:56, Nils Dagsson Moskopp [EMAIL PROTECTED] wrote: Am Freitag, den 03.10.2008, 20:41 +0100 schrieb Adrian Sutton: label for=”date”Date: input type=”text” placeholder=”1 Jan 2008” id=”date” //label Wouldn't three comboboxes be more appropriate ? While that's a common solution it's a terribly inefficient and frustrating user interface. Besides, the specific examples aren't as important as the idea that placeholder is an excellent way to provide suggestions and thus distinct from the label of the field. Exactly, that was my point as well. People have been saying that the only places they've noticed a placeholder being used, it was performing the job of a label, but if it were easy to use (a simple attribute instead of lots of JavaScript hacking), I think it would be used appropriately as a hint more often. Yes, it would also be abused, but what else is new? If we provide a good way to do it right, designers who care about doing it right will do it right, and the ones who don't will continue to do whatever they want. Obviously input type=date kicks ass for this particular example. -- Andy Lyttle [EMAIL PROTECTED]
Re: [whatwg] Placeholder option for text input boxes
Am Freitag, den 03.10.2008, 15:04 -0700 schrieb Andy Lyttle: On Oct 3, 2008, at 1:31 PM, Adrian Sutton wrote: [...] Obviously input type=date kicks ass for this particular example. Why do y'all hate XForms ?
Re: [whatwg] Placeholder option for text input boxes
On Fri, Oct 3, 2008 at 5:04 PM, Andy Lyttle [EMAIL PROTECTED] wrote: On Oct 3, 2008, at 1:31 PM, Adrian Sutton wrote: On 03/10/08 20:56, Nils Dagsson Moskopp [EMAIL PROTECTED] wrote: Am Freitag, den 03.10.2008, 20:41 +0100 schrieb Adrian Sutton: label for=dateDate: input type=text placeholder=1 Jan 2008 id=date //label Wouldn't three comboboxes be more appropriate ? While that's a common solution it's a terribly inefficient and frustrating user interface. Besides, the specific examples aren't as important as the idea that placeholder is an excellent way to provide suggestions and thus distinct from the label of the field. Exactly, that was my point as well. People have been saying that the only places they've noticed a placeholder being used, it was performing the job of a label, but if it were easy to use (a simple attribute instead of lots of JavaScript hacking), I think it would be used appropriately as a hint more often. Yes, it would also be abused, but what else is new? If we provide a good way to do it right, designers who care about doing it right will do it right, and the ones who don't will continue to do whatever they want. Obviously input type=date kicks ass for this particular example. Man, I could *really* see the hint function being viable and quite useful. It offers up a completely new-and-useful semantic, and there's no particular place it should already go. I'd accept this as a new attribute without reservation if it was renamed @hint, so it's absolutely clear what the semantic for it is. We can then delay any questions of generalizing this function with CSS until later, and get this pushed into html5 immediately. For now, people wanting to use hint-like appearance for their labels but stay semantic can just use the established javascript hackery. ~TJ
Re: [whatwg] Placeholder option for text input boxes
INPUT. CHECKED = checked
is equivalent to
INPUT. SETATTRIBUTE checked, checked
as of MSIE7.
Chris
My unit test:
SET L5ELEMS = ME. ELEMENTS
SET A1C = L5ELEMS. NAMEDITEM(ITSTEST)
IF A1C. TAGNAME INPUT THEN STOP
IF A1C. GETATTRIBUTE(type) checkbox THEN STOP
IF A1C. GETATTRIBUTE(checked) THEN STOP
REM A1C. SETATTRIBUTE checked, checked
A1C. CHECKED = checked
IF NOT A1C. GETATTRIBUTE(checked) THEN STOP
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Garrett Smith
Sent: Thursday, October 02, 2008 2:46 AM
To: whatwg
Subject: Re: [whatwg] Placeholder option for text input boxes
IE:
(did not test) - FWIRC, getAttribute('checked') will return the value
|false|, what happens after that, I do not know.
!DOCTYPE html
html lang=en
head
titleCHeckbox-attribute.html/title
/head
body
form action=
input type=checkbox checked=checked id=c
input id=b value='asdf'
/form
pre
script type=text/javascript
var d = document, c = d.getElementById('c');
var b = d.getElementById('b');
b.value = 1;
d.writeln(b.getAttribute('value'):... + b.getAttribute('value'));
c.checked = false;
d.writeln(\nc.checked:. + c.checked);
d.writeln(c.getAttribute('checked'): +c.getAttribute('checked'));
d.writeln(c.setAttribute('checked', 'checked'););
c.setAttribute('checked', 'checked');
d.writeln(c.checked:. + c.checked);
/script
/pre
/body
/html
Re: [whatwg] Placeholder option for text input boxes
Is vbscript defined to have the same dom bindings as jscript?
On 10/2/08, Kristof Zelechovski [EMAIL PROTECTED] wrote:
INPUT. CHECKED = checked
is equivalent to
INPUT. SETATTRIBUTE checked, checked
as of MSIE7.
Chris
My unit test:
SET L5ELEMS = ME. ELEMENTS
SET A1C = L5ELEMS. NAMEDITEM(ITSTEST)
IF A1C. TAGNAME INPUT THEN STOP
IF A1C. GETATTRIBUTE(type) checkbox THEN STOP
IF A1C. GETATTRIBUTE(checked) THEN STOP
REM A1C. SETATTRIBUTE checked, checked
A1C. CHECKED = checked
IF NOT A1C. GETATTRIBUTE(checked) THEN STOP
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Garrett Smith
Sent: Thursday, October 02, 2008 2:46 AM
To: whatwg
Subject: Re: [whatwg] Placeholder option for text input boxes
IE:
(did not test) - FWIRC, getAttribute('checked') will return the value
|false|, what happens after that, I do not know.
!DOCTYPE html
html lang=en
head
titleCHeckbox-attribute.html/title
/head
body
form action=
input type=checkbox checked=checked id=c
input id=b value='asdf'
/form
pre
script type=text/javascript
var d = document, c = d.getElementById('c');
var b = d.getElementById('b');
b.value = 1;
d.writeln(b.getAttribute('value'):... + b.getAttribute('value'));
c.checked = false;
d.writeln(\nc.checked:. + c.checked);
d.writeln(c.getAttribute('checked'): +c.getAttribute('checked'));
d.writeln(c.setAttribute('checked', 'checked'););
c.setAttribute('checked', 'checked');
d.writeln(c.checked:. + c.checked);
/script
/pre
/body
/html
--
Sent from Gmail for mobile | mobile.google.com
Re: [whatwg] Placeholder option for text input boxes
I suppose so, with the following exceptions: * You use WINDOW.IMAGE.CREATE instead of new Image() * You use FOR EACH instead of new Enumerator() * The operator in is not available, although you can use DOM ATTRIBUTES instead * Everything is case-insensitive, except for string literals * The operator TYPENAME is available * [] is unavailable but you can implicitly call the default property of an object * this is ME, null is NOTHING, undefined is EMPTY * WINDOW.EVENT is global * value assignment (without SET) automatically invokes CSTR * exception handling is not available * decode/encodeURL is not available unless you import the JScript engine as well * Function references are not available, except that you can use GETREF to assign dynamic event handlers to properties * Static event handlers are assigned by name after the document is loaded (i.e. only WINDOW_ONLOAD gets called) * Automatic type coercion uses system locale, not C locale Remind me if I forgot something. Chris -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of timeless Sent: Thursday, October 02, 2008 4:22 PM To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: [whatwg] Placeholder option for text input boxes Is vbscript defined to have the same dom bindings as jscript? On 10/2/08, Kristof Zelechovski [EMAIL PROTECTED] wrote: INPUT. CHECKED = checked is equivalent to INPUT. SETATTRIBUTE checked, checked as of MSIE7. Chris My unit test: SET L5ELEMS = ME. ELEMENTS SET A1C = L5ELEMS. NAMEDITEM(ITSTEST) IF A1C. TAGNAME INPUT THEN STOP IF A1C. GETATTRIBUTE(type) checkbox THEN STOP IF A1C. GETATTRIBUTE(checked) THEN STOP REM A1C. SETATTRIBUTE checked, checked A1C. CHECKED = checked IF NOT A1C. GETATTRIBUTE(checked) THEN STOP
Re: [whatwg] Placeholder option for text input boxes
On Thu, Oct 2, 2008 at 6:27 PM, Brenton Strine [EMAIL PROTECTED]wrote: On Tue, Sep 30, 2008 at 11:36 AM, Andy Lyttle [EMAIL PROTECTED] wrote: [snip] 4) label (moving label textual content into input as placeholder text; currently with Javascript to mutate the DOM, in the future with CSS to present the desired appearance while keeping the DOM stable) Pro: Most semantic. [snip] That depends on what you are using it for. What if you are using it to apply a placeholder that says (optional)? That is not a label at all. There are a lot of uses for the proposed placeholder attribute that just don't fit into any of the other categories. I think a placeholder attribute would be great. Hmm, true. That's definitely a case where the text can't be argued to be a label. Of course, it's still not in any way semantic. The only difference between (optional) being displayed near the input and being displayed *within* the input is one of aesthetics. The meaning of the document isn't changed one iota. This leans me even more toward a CSS solution. I'll just bite the bullet and bring it up to the CSS WG. ~TJ
Re: [whatwg] Placeholder option for text input boxes
I would rather test whether a brand new INPUT object of type SEARCH has an
attribute named placeholder. Accessing attributes as properties is
discouraged and considered becoming obsolete; it should not be expected to
work for new attributes.
Chris
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Garrett Smith
Sent: Tuesday, September 30, 2008 8:50 PM
To: [EMAIL PROTECTED]
Subject: [whatwg] Placeholder option for text input boxes
Result:
Safari 3.1 (supports placeholder)
zip.placeholder=undefined
zip.getAttributeNode('placeholder') =Zip Code
Others (do not support placeholder)
zip.placeholder=undefined
zip.getAttributeNode('placeholder') =Zip Code
If a backwards-compatible degradation strategy is to be devised, it
should be as trivial as checking:-
if(!('placeholder' in input)) {
createFallbackPlaceholder();
}
But this will fail in the current implementation in Safari 3.1.
input.getAttribute('placeholder') would not be degradable, as all
modern browsers would return the attribute value, regardless of
whether they support the actual placeholder behavior or not.
Are there any arguments against a |placeholder| property on INPUT?
Pros/cons for a |placeholder| property and attribute on TEXTAREA?
Garrett
~TJ
Re: [whatwg] Placeholder option for text input boxes
Please demonstrate a *valid* example of a placeholder containing a hint. Chris -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Andy Lyttle Sent: Tuesday, September 30, 2008 9:29 PM To: whatwg@lists.whatwg.org Subject: Re: [whatwg] Placeholder option for text input boxes On Sep 30, 2008, at 12:14 PM, Nils Dagsson Moskopp wrote: Am Dienstag, den 30.09.2008, 11:49 -0700 schrieb Garrett Smith: Are there any arguments against a |placeholder| property on INPUT? Missing semantics ? It is a purely presentational attribute. It provides a hint to the user about what input is expected. It's no less semantic than title, which gets used for plenty of non-title- related things. -- Andy Lyttle [EMAIL PROTECTED]
Re: [whatwg] Placeholder option for text input boxes
input.placeholder is merely a notation; notation does not infer any semantics by itself. Chris -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Garrett Smith Sent: Tuesday, September 30, 2008 9:36 PM To: Nils Dagsson Moskopp Cc: whatwg Subject: Re: [whatwg] Placeholder option for text input boxes On Tue, Sep 30, 2008 at 12:14 PM, Nils Dagsson Moskopp [EMAIL PROTECTED] wrote: Am Dienstag, den 30.09.2008, 11:49 -0700 schrieb Garrett Smith: Are there any arguments against a |placeholder| property on INPUT? Missing semantics ? It is a purely presentational attribute. The semantics would be simple property access: input.placeholder - as demonstrated in the example I posted up. Garrett
Re: [whatwg] Placeholder option for text input boxes
On Tue, Sep 30, 2008 at 11:43 PM, Kristof Zelechovski
[EMAIL PROTECTED] wrote:
I would rather test whether a brand new INPUT object of type SEARCH has an
attribute named placeholder. Accessing attributes as properties is
discouraged and considered becoming obsolete; it should not be expected to
work for new attributes.
Can you provide an example or evidence of DOM properties becoming
obsolete (other than safari not supporting input.placeholder)?
Garrett
Chris
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Garrett Smith
Sent: Tuesday, September 30, 2008 8:50 PM
To: [EMAIL PROTECTED]
Subject: [whatwg] Placeholder option for text input boxes
Result:
Safari 3.1 (supports placeholder)
zip.placeholder=undefined
zip.getAttributeNode('placeholder') =Zip Code
Others (do not support placeholder)
zip.placeholder=undefined
zip.getAttributeNode('placeholder') =Zip Code
If a backwards-compatible degradation strategy is to be devised, it
should be as trivial as checking:-
if(!('placeholder' in input)) {
createFallbackPlaceholder();
}
But this will fail in the current implementation in Safari 3.1.
input.getAttribute('placeholder') would not be degradable, as all
modern browsers would return the attribute value, regardless of
whether they support the actual placeholder behavior or not.
Are there any arguments against a |placeholder| property on INPUT?
Pros/cons for a |placeholder| property and attribute on TEXTAREA?
Garrett
~TJ
Re: [whatwg] Placeholder option for text input boxes
DOM properties are not becoming obsolete; accessing attributes by properties is. Chris -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Garrett Smith Sent: Wednesday, October 01, 2008 9:18 AM To: Kristof Zelechovski Cc: [EMAIL PROTECTED] Subject: Re: [whatwg] Placeholder option for text input boxes On Tue, Sep 30, 2008 at 11:43 PM, Kristof Zelechovski [EMAIL PROTECTED] wrote: I would rather test whether a brand new INPUT object of type SEARCH has an attribute named placeholder. Accessing attributes as properties is discouraged and considered becoming obsolete; it should not be expected to work for new attributes. Can you provide an example or evidence of DOM properties becoming obsolete (other than safari not supporting input.placeholder)? Garrett
Re: [whatwg] Placeholder option for text input boxes
Kristof Zelechovski wrote: DOM properties are not becoming obsolete; accessing attributes by properties is. Hmm. Citation? -- Benjamin Hawkes-Lewis
Re: [whatwg] Placeholder option for text input boxes
The attributes are exposed as properties for compatibility with DOM Level 0. This usage is deprecated because it can not be generalized to all possible attribute names, as is required both for XML and potentially for future versions of HTML. We recommend the use of generic methods on the core Element interface for setting, getting and removing attributes. http://www.w3.org/TR/2000/WD-DOM-Level-1-2929/level-one-html.html#ID-64 2250288 -Original Message- From: Benjamin Hawkes-Lewis [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 01, 2008 12:42 PM To: Kristof Zelechovski Cc: 'Garrett Smith'; [EMAIL PROTECTED] Subject: Re: [whatwg] Placeholder option for text input boxes Kristof Zelechovski wrote: DOM properties are not becoming obsolete; accessing attributes by properties is. Hmm. Citation? -- Benjamin Hawkes-Lewis
Re: [whatwg] Placeholder option for text input boxes
This usage is deprecated because it can not be generalized to all possible attribute names We recommend the use of generic methods on the core Element interface for setting, getting and removing attributes. Although I understand your reasoning, I disagree. The DOM does not exist only to wrap the representation of the original document markup. The DOM is a programming API and programmings API should make programs more easy to code nd more performant. Having a get/setAttribute indirection plus type conversions between serialized strings and back to a usable type (number, function) are not friendly at all. The idea of dom properties for attributes is not to find a generic structure for all atributes, but to have support for known attributes with known behavior. Please, don't make such claim again, they are misleading, and clearly not realistic. On Wed, Oct 1, 2008 at 12:39 PM, Kristof Zelechovski [EMAIL PROTECTED] wrote: The attributes are exposed as properties for compatibility with DOM Level 0. This usage is deprecated because it can not be generalized to all possible attribute names, as is required both for XML and potentially for future versions of HTML. We recommend the use of generic methods on the core Element interface for setting, getting and removing attributes. http://www.w3.org/TR/2000/WD-DOM-Level-1-2929/level-one-html.html#ID-64 2250288 -Original Message- From: Benjamin Hawkes-Lewis [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 01, 2008 12:42 PM To: Kristof Zelechovski Cc: 'Garrett Smith'; [EMAIL PROTECTED] Subject: Re: [whatwg] Placeholder option for text input boxes Kristof Zelechovski wrote: DOM properties are not becoming obsolete; accessing attributes by properties is. Hmm. Citation? -- Benjamin Hawkes-Lewis
Re: [whatwg] Placeholder option for text input boxes
João Eiras wrote: This usage is deprecated because it can not be generalized to all possible attribute names We recommend the use of generic methods on the core Element interface for setting, getting and removing attributes. [snip] Please, don't make such claim again, they are misleading, and clearly not realistic. It may or may not be realistic, but when he says it is deprecated Kristof is factually correct. He linked to a Working Draft as a citation, but here's the final DOM Level 1 Recommendation: http://www.w3.org/TR/REC-DOM-Level-1/level-one-html.html#ID-642250288 HTML attributes are exposed as properties on the element object … for compatibility with DOM Level 0. This usage is deprecated because it can not be generalized to all possible attribute names, as is required both for XML and potentially for future versions of HTML. We recommend the use of generic methods on the core Element interface for setting, getting and removing attributes. Of course, the DOM parts of HTML5 (or whatever spec they end up in) could effectively undeprecate this, if desired. -- Benjamin Hawkes-Lewis
Re: [whatwg] Placeholder option for text input boxes
While it is not my reasoning, I rather agree. DOM properties and attributes are different things. Attributes go to the source code, properties do not. Attributes have DOM nodes, properties do not. The idea is to make these sets disjoint. This makes the text verbose; this is a problem for execute-once scratchpad scripts (that can rely of what the implementation gives anyway, and the implementation is likely to provide attributes dressed up as properties) but not for code that is general enough, such as feature support detection. Which attributes return a number directly? Which attributes return a function directly? Chris -Original Message- From: Joao Eiras [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 01, 2008 3:33 PM To: Kristof Zelechovski Cc: [EMAIL PROTECTED] Subject: Re: [whatwg] Placeholder option for text input boxes This usage is deprecated because it can not be generalized to all possible attribute names We recommend the use of generic methods on the core Element interface for setting, getting and removing attributes. Although I understand your reasoning, I disagree. The DOM does not exist only to wrap the representation of the original document markup. The DOM is a programming API and programmings API should make programs more easy to code nd more performant. Having a get/setAttribute indirection plus type conversions between serialized strings and back to a usable type (number, function) are not friendly at all. The idea of dom properties for attributes is not to find a generic structure for all atributes, but to have support for known attributes with known behavior. Please, don't make such claim again, they are misleading, and clearly not realistic.
Re: [whatwg] Placeholder option for text input boxes
Which attributes return a number directly? Which attributes return a function directly? This is already clearly defined in DOM 2 HTML. So following your line of reasoning, the entire DOM 2 HTML spec is deprecated ?
Re: [whatwg] Placeholder option for text input boxes
http://www.w3.org/TR/DOM-Level-2-HTML/html.html#ID-642250288 contains the same deprecating statement. Using e.g. A.tabindex in script code is deprecated. I do not believe it can be performance hit; accessing host objects is expensive per call. Otherwise, Attr.asScalar would be welcome. Chris -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Joao Eiras Sent: Wednesday, October 01, 2008 5:27 PM To: Kristof Zelechovski Cc: [EMAIL PROTECTED] Subject: Re: [whatwg] Placeholder option for text input boxes Which attributes return a number directly? Which attributes return a function directly? This is already clearly defined in DOM 2 HTML. So following your line of reasoning, the entire DOM 2 HTML spec is deprecated ?
Re: [whatwg] Placeholder option for text input boxes
2008/10/1 Kristof Zelechovski [EMAIL PROTECTED]: http://www.w3.org/TR/DOM-Level-2-HTML/html.html#ID-642250288 contains the same deprecating statement. I think it would be really unfortunate if we followed through with this, and I definitely think that input.placeholder should work. The attribute/property symmetry is one of the longest running traditions in web development, and makes programming the DOM with javascript much more pleasant. We shouldn't break with long-established, useful traditions just to make a small minority of cases more consistent. - a
Re: [whatwg] Placeholder option for text input boxes
Please. This thread is not abort how to write JavaScript code in general. It is about how to write the feature detection code. This kind of code should be especially robust and relying on deprecated features does not make it more so. Chris _ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Aaron Boodman Sent: Wednesday, October 01, 2008 6:56 PM To: Kristof Zelechovski Cc: whatwg; Joao Eiras Subject: Re: [whatwg] Placeholder option for text input boxes 2008/10/1 Kristof Zelechovski [EMAIL PROTECTED]: http://www.w3.org/TR/DOM-Level-2-HTML/html.html#ID-642250288 contains the same deprecating statement. I think it would be really unfortunate if we followed through with this, and I definitely think that input.placeholder should work. The attribute/property symmetry is one of the longest running traditions in web development, and makes programming the DOM with javascript much more pleasant. We shouldn't break with long-established, useful traditions just to make a small minority of cases more consistent. - a
Re: [whatwg] Placeholder option for text input boxes
On Wed, Oct 1, 2008 at 10:05 AM, Kristof Zelechovski [EMAIL PROTECTED] wrote: Please. This thread is not abort how to write JavaScript code in general. It is about how to write the feature detection code. This kind of code should be especially robust and relying on deprecated features does not make it more so. Ok, let's separate out the 'how people should program' part from the 'what we will support part'. My opinion is that input.placeholder should be supported, because it is consistent with how everything else works. I don't think that most web developers even know that accessing attributes as properties is deprecated, and would be surprised that setting input.placeholder does nothing. - a
Re: [whatwg] Placeholder option for text input boxes
I never intended to limit what the HTML specification supports in this particular thread. I only wanted to say that Safari is not at fault here and suggest a workaround. Chris -Original Message- From: Aaron Boodman [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 01, 2008 7:27 PM To: Kristof Zelechovski Cc: whatwg; Joao Eiras Subject: Re: [whatwg] Placeholder option for text input boxes On Wed, Oct 1, 2008 at 10:05 AM, Kristof Zelechovski [EMAIL PROTECTED] wrote: Please. This thread is not abort how to write JavaScript code in general. It is about how to write the feature detection code. This kind of code should be especially robust and relying on deprecated features does not make it more so. Ok, let's separate out the 'how people should program' part from the 'what we will support part'. My opinion is that input.placeholder should be supported, because it is consistent with how everything else works. I don't think that most web developers even know that accessing attributes as properties is deprecated, and would be surprised that setting input.placeholder does nothing. - a
Re: [whatwg] Placeholder option for text input boxes
This was Garret's original code; it cannot be used for feature detection, as
explained.
Chris
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Joao Eiras
Sent: Wednesday, October 01, 2008 7:30 PM
To: Aaron Boodman; whatwg@lists.whatwg.org
Subject: Re: [whatwg] Placeholder option for text input boxes
Another thing:
if( 'placeholder' in referencetoInput ){ ... }
can be used for feature detection, else a javascript fallback could be
supplied as the later is the common case.
Re: [whatwg] Placeholder option for text input boxes
Another thing:
if( 'placeholder' in referencetoInput ){ ... }
can be used for feature detection, else a javascript fallback could be
supplied as the later is the common case.
On Wed, Oct 1, 2008 at 6:27 PM, Aaron Boodman [EMAIL PROTECTED] wrote:
On Wed, Oct 1, 2008 at 10:05 AM, Kristof Zelechovski
[EMAIL PROTECTED] wrote:
Please. This thread is not abort how to write JavaScript code in general.
It is about how to write the feature detection code. This kind of code
should be especially robust and relying on deprecated features does not make
it more so.
Ok, let's separate out the 'how people should program' part from the
'what we will support part'. My opinion is that input.placeholder
should be supported, because it is consistent with how everything else
works.
I don't think that most web developers even know that accessing
attributes as properties is deprecated, and would be surprised that
setting input.placeholder does nothing.
- a
Re: [whatwg] Placeholder option for text input boxes
On Oct 1, 2008, at 10:27 AM, Aaron Boodman wrote: On Wed, Oct 1, 2008 at 10:05 AM, Kristof Zelechovski [EMAIL PROTECTED] wrote: Please. This thread is not abort how to write JavaScript code in general. It is about how to write the feature detection code. This kind of code should be especially robust and relying on deprecated features does not make it more so. Ok, let's separate out the 'how people should program' part from the 'what we will support part'. My opinion is that input.placeholder should be supported, because it is consistent with how everything else works. I don't think that most web developers even know that accessing attributes as properties is deprecated, and would be surprised that setting input.placeholder does nothing. We don't have a placeholder property in the interface for HTML input elements, but this is due to oversight and lack of subsequent demand. It was not meant to be a principled stand on the merits of DOM attributes. Personally I think using getAttribute and setAttribute for everything is a painful and error-prone coding style. Regards, Maciej
Re: [whatwg] Placeholder option for text input boxes
On Wed, Oct 1, 2008 at 5:11 PM, Maciej Stachowiak [EMAIL PROTECTED] wrote:
On Oct 1, 2008, at 10:27 AM, Aaron Boodman wrote:
On Wed, Oct 1, 2008 at 10:05 AM, Kristof Zelechovski
[EMAIL PROTECTED] wrote:
Please. This thread is not abort how to write JavaScript code in
general.
It is about how to write the feature detection code. This kind of code
should be especially robust and relying on deprecated features does not
make
it more so.
Ok, let's separate out the 'how people should program' part from the
'what we will support part'. My opinion is that input.placeholder
should be supported, because it is consistent with how everything else
works.
I don't think that most web developers even know that accessing
attributes as properties is deprecated, and would be surprised that
setting input.placeholder does nothing.
We don't have a placeholder property in the interface for HTML input
elements, but this is due to oversight and lack of subsequent demand. It was
not meant to be a principled stand on the merits of DOM attributes.
Personally I think using getAttribute and setAttribute for everything is a
painful and error-prone coding style.
Other INPUT attributes work don't reflect.
Currently, input.setAttribute('placeholder', 'foo'), does update the
visual placeholder text. This is different than say the value
property of an input, which can be set, but won't change the attribute
value:
input value=orig
input.value = new;
input.getAttribute('value'); = orig
The way I would imagine |placeholder| would work (and imagining is
about all I can do at this point) is that |input.placeholder| would be
a DOM property. It wouldn't necessarily reflect[1] the attribute
value; changing input.placeholder would not affect the actual HTML
attribute.
input.getAttribute('placeholder') would return the attribute value as a string.
(in practice browsers return the value null for attributes not
present. Technically, getAttribute is specified to return a
domstring and null is not a string.)
For example of a non-reflecting property, we can look at the |checked|
property of a checkbox. The |checked| property does not reflect the
|checked| attribute. It's a good example of how a non-reflecting
|placeholder| property might work.
The result for the following example:
Safari 3, Firefox 3:
b.getAttribute('value'):...asdf
c.checked:.false
c.getAttribute('checked'): checked
c.setAttribute('checked', 'checked');
c.checked:.false
Opera 9.5,
b.getAttribute('value'):...asdf
c.checked:.false
c.getAttribute('checked'): checked
c.setAttribute('checked', 'checked');
c.checked:.true
IE:
(did not test) - FWIRC, getAttribute('checked') will return the value
|false|, what happens after that, I do not know.
!DOCTYPE html
html lang=en
head
titleCHeckbox-attribute.html/title
/head
body
form action=
input type=checkbox checked=checked id=c
input id=b value='asdf'
/form
pre
script type=text/javascript
var d = document, c = d.getElementById('c');
var b = d.getElementById('b');
b.value = 1;
d.writeln(b.getAttribute('value'):... + b.getAttribute('value'));
c.checked = false;
d.writeln(\nc.checked:. + c.checked);
d.writeln(c.getAttribute('checked'): +c.getAttribute('checked'));
d.writeln(c.setAttribute('checked', 'checked'););
c.setAttribute('checked', 'checked');
d.writeln(c.checked:. + c.checked);
/script
/pre
/body
/html
[1] HTML 5 - Reflecting content attributes in DOM attributes
http://www.whatwg.org/specs/web-apps/current-work/multipage/infrastructure.html#reflect
Do we need a failing test for input.placeholder?
Garrett
Regards,
Maciej
Re: [whatwg] Placeholder option for text input boxes
Benjamin Hawkes-Lewis wrote: Garrett Smith wrote: |placeholder| sounds a little like |alt|. Alt is a property and an attribute on INPUT. How is placeholder content for a form field alternative text? The alt text is for situations where the input can not be displayed at all. For example an input type=image where the image fails to load or the user has disabled. Or you could imagine in theory if the UA supported turning off form controls entirely. The placeholder is content that is displayed along with a rendered form control. Thus placeholder is used along with the form control, alt is used instead of it. / Jonas
Re: [whatwg] Placeholder option for text input boxes
On Tue, Sep 30, 2008 at 4:10 AM, Andy Lyttle [EMAIL PROTECTED] wrote: I do not like this idea at all. That is what LABEL is for, and disappearing it's so kewl text is as annoying as BLINK and BGSOUND. Chris The label tag is great for labels that are displayed outside the input box (in front of, above, etc.). The placeholder attribute is intended more as a hint than a label, and is displayed inside the input box without taking up any additional space on the page. An example might be: label for=whereGet local weather forecast:/label input type=search name=where id=where placeholder=City, State Using the alt attribute has been suggested here, but no implementation uses alt in this way, while placeholder is already supported by one major browser (and since it really isn't alternate text, using alt doesn't make any sense). Another suggestion was to use the title attribute, which is a better idea, but title is generally implemented as a tooltip that doesn't appear until you hover over the element, which is not the desired behavior. It's perfectly legitimate to use a label tag AND title AND placeholder attributes, for three subtly different purposes. Hm. I have a problem with your example. Get local weather forecast isn't a semantic label for the field - it doesn't describe what the field is for. It describes what the *form* is for, and so should be a legend or hn. City, State actually describes the use of the input itself, and should be the label. I'd suspect that *all* examples where placeholder text is used (definitely all the examples I know of personally) are most semantically served by a label with the text. Iirc, I once saw a nice javascript solution that mutated the DOM to remove the label and use its text as a placeholder. Thus, I think this is best served by a CSS directive that does exactly that. External vs placeholder text is a display issue - semantically, both are labels for the field. The only question would be whether to make this a property of label or input... Probably label - targetting input would result in action-at-a-distance. ~TJ
Re: [whatwg] Placeholder option for text input boxes
On Tue, Sep 30, 2008 at 12:37 AM, Benjamin Hawkes-Lewis [EMAIL PROTECTED] wrote: Garrett Smith wrote: |placeholder| sounds a little like |alt|. Alt is a property and an attribute on INPUT. How is placeholder content for a form field alternative text? If and until user enters text, the alternate text is displayed. The confusing part is that successfully rendered inputs would be rendered and still use the alt. The good part is that it would be (or should be) accessible for screen readers. -- Benjamin Hawkes-Lewis
Re: [whatwg] Placeholder option for text input boxes
Am Dienstag, den 30.09.2008, 08:25 -0700 schrieb Garrett Smith: (Nils, did you mean to put this on the list, or is this personal mail?) I meant to put it on the list - didn't it go there ? If and until user enters text, the alternate text is displayed. The confusing part is that successfully rendered inputs would be rendered and still use the alt. The good part is that it would be (or should be) accessible for screen readers. why not just use the title attribute for that ? Like this: input type=text placeholder=zip title=zip ? So when you mouse over the input, the yellow tooltip would pop up. That's annoying. No, I meant to abolish the placeholder attribute alltogether and render the title attribute as greyed-sut inside the search box instead, because * semantically, the title attribute conveys the same information. * it is already there in many pages. Cheers, Nils
Re: [whatwg] Placeholder option for text input boxes
On Sep 30, 2008, at 8:33 AM, Nils Dagsson Moskopp wrote: No, I meant to abolish the placeholder attribute alltogether and render the title attribute as greyed-sut inside the search box instead, because * semantically, the title attribute conveys the same information. * it is already there in many pages. Except that: 1) the title attribute doesn't behave this way on any other element 2) there's no reason it shouldn't be possible to have both a placeholder AND a tooltip 3) anybody who is currently using the title attribute doesn't expect it to be displayed as a placeholder, so we would break things for them (especially if their title string is too long to fit inside a small field) -- Andy Lyttle [EMAIL PROTECTED]
Re: [whatwg] Placeholder option for text input boxes
On Sep 30, 2008, at 7:57 AM, Garrett Smith wrote: If and until user enters text, the alternate text is displayed. The confusing part is that successfully rendered inputs would be rendered and still use the alt. The good part is that it would be (or should be) accessible for screen readers. But alt here as you're describing it doesn't mean the same thing as alt anywhere else. On an image, alt text says this means the same thing as what's supposed to be displayed. A placeholder does NOT mean the same thing as whatever the user is going to enter. On the bright side, doing what you suggest shouldn't break anything because I'm sure nobody's using it. However, I don't think that just because we have an existing property defined that's used on other tags with a different meaning, we should reuse that property for this meaning instead of defining a new property. -- Andy Lyttle [EMAIL PROTECTED]
Re: [whatwg] Placeholder option for text input boxes
On Tue, Sep 30, 2008 at 11:36 AM, Andy Lyttle [EMAIL PROTECTED] wrote: On Sep 30, 2008, at 7:57 AM, Garrett Smith wrote: If and until user enters text, the alternate text is displayed. The confusing part is that successfully rendered inputs would be rendered and still use the alt. The good part is that it would be (or should be) accessible for screen readers. But alt here as you're describing it doesn't mean the same thing as alt anywhere else. On an image, alt text says this means the same thing as what's supposed to be displayed. A placeholder does NOT mean the same thing as whatever the user is going to enter. On the bright side, doing what you suggest shouldn't break anything because I'm sure nobody's using it. However, I don't think that just because we have an existing property defined that's used on other tags with a different meaning, we should reuse that property for this meaning instead of defining a new property. Agreed. Using @alt is a semantic hack. For the benefit of myself and others, I'm going to summarize the four current proposals. 1) @placeholder Pro: Already implemented in one major browser. Is opt-in, so doesn't interfere with existing content at all. Degrades acceptably. Con: Duplicates semantics already present in label, @alt, and @title to some extent. Is essentially a presentational attribute. Not (currently) accessible. Won't be widely usable until all browsers support it (ie, degrades silently rather than usefully). 2) @alt Pro: Presumably accessible to people with screen readers. Probably not currently in use at all, so new function won't disrupt existing content. Con: Semantic hack - it's not alternative content, it's *normal* content, just used to introduce the element. May collide with future uses of @alt if a UI allows form elements to not be displayed (however, no idea how/why this would work) 3) @title Pro: Reasonably semantic. Relatively similar in current usage. Degrades acceptably. Con: Good reasons to allow both placeholder text *and* tooltips. Can break existing content that either expects @title info in a tooltip, or that has @title that is too long to be placed easily in the input. Not accessible. 4) label (moving label textual content into input as placeholder text; currently with Javascript to mutate the DOM, in the future with CSS to present the desired appearance while keeping the DOM stable) Pro: Most semantic. Can be pushed site-wide without having to change page code. Can't break existing content, because it is opt-in (unless this gets put into browser default stylesheets). Accessible (if using CSS solution; probably not accessible if DOM mutation is employed). Degrades well (just stays an ordinary visible label if browser doesn't support the rule). Con: Most complex solution for implementors. Need to push proposal through CSS WG, which can be slower than WHATWG. ~TJ
Re: [whatwg] Placeholder option for text input boxes
Tab Atkins Jr. wrote: 2) @alt Pro: Presumably accessible to people with screen readers. Presumptions are risky. Is there any evidence (by which I mean a test case and a description of how to reproduce behavior with real user agents) that demonstrates that this would be true for INPUT TYPE=TEXT? I can imagine screen readers resorting to checking ALT to repair missing LABEL and TITLE; I'd be surprised if it were common behavior otherwise. Likewise I can imagine users being able to query for ALT, but this hardly seems like a natural interface for accessing placeholder text. 3) @title [snip] Not accessible. There are various accessibility problems @title in existing environments and user agents: http://www.rnib.org.uk/wacblog/articles/too-much-accessibility/too-much-accessibility-title-attributes/ However, implementations could be improved, just as support for placeholder could be implemented. 4) label (moving label textual content into input as placeholder text; currently with Javascript to mutate the DOM, in the future with CSS to present the desired appearance while keeping the DOM stable) Pro: Most semantic. Is it? How is it /more/ semantic than placeholder, which would precisely identify this text as a placeholder? -- Benjamin Hawkes-Lewis
Re: [whatwg] Placeholder option for text input boxes
On Sep 30, 2008, at 7:00 AM, Tab Atkins Jr. wrote: Hm. I have a problem with your example. Get local weather forecast isn't a semantic label for the field - it doesn't describe what the field is for. It describes what the *form* is for, and so should be a legend or hn. City, State actually describes the use of the input itself, and should be the label. Hmm, good call. Let's see if I can do better: label for=hairHair:/label input name=hair id=hair placeholder=Color title=Enter the color of your hairbr label for=eyesEyes:/label input name=eyes id=eyes placeholder=Color title=Enter the color of your eyesbr label for=noseNose:/label input name=nose id=nose placeholder=Shape title=Describe the shape of your nosebr label for=birthplacePlace of Birth:/label input name=birthplace id=birthplace placeholder=City, State title=Enter the city and state where you were bornbr This shows how label AND placeholder AND title could be used for three different purposes. If I were designing the spec from scratch, I might have chosen tooltip and hint instead of title and placeholder respectively, but we have to consider existing implementations. -- Andy Lyttle [EMAIL PROTECTED]
Re: [whatwg] Placeholder option for text input boxes
Benjamin Hawkes-Lewis wrote: Garrett Smith wrote: |placeholder| sounds a little like |alt|. Alt is a property and an attribute on INPUT. How is placeholder content for a form field alternative text? The alt text is for situations where the input can not be displayed at all. For example an input type=image where the image fails to load or the user has disabled. Or you could imagine in theory if the UA supported turning off form controls entirely. The placeholder is content that is displayed along with a rendered form control. Thus placeholder is used along with the form control, alt is used instead of it. / Jonas
Re: [whatwg] Placeholder option for text input boxes
On Tue, Sep 30, 2008 at 12:37 PM, Andy Lyttle [EMAIL PROTECTED] wrote: On Sep 30, 2008, at 7:00 AM, Tab Atkins Jr. wrote: Hm. I have a problem with your example. Get local weather forecast isn't a semantic label for the field - it doesn't describe what the field is for. It describes what the *form* is for, and so should be a legend or hn. City, State actually describes the use of the input itself, and should be the label. Hmm, good call. Let's see if I can do better: label for=hairHair:/label input name=hair id=hair placeholder=Color title=Enter the color of your hairbr label for=eyesEyes:/label input name=eyes id=eyes placeholder=Color title=Enter the color of your eyesbr label for=noseNose:/label input name=nose id=nose placeholder=Shape title=Describe the shape of your nosebr label for=birthplacePlace of Birth:/label input name=birthplace id=birthplace placeholder=City, State title=Enter the city and state where you were bornbr This shows how label AND placeholder AND title could be used for three different purposes. If I were designing the spec from scratch, I might have chosen tooltip and hint instead of title and placeholder respectively, but we have to consider existing implementations. Eh, I'll still complain. ^_^ While all of your labels *would* be appropriate by themselves, the fact that you have to clarify them means they're not accurate enough for your purposes. One must also consider the needs of people who are using browsers without the ability to render this placeholder text. They'll put long in hair, two in eyes, and yes in nose because they can't see the placeholder and are using their keyboard to navigate through your form (and thus won't see the tooltips either). Of course, the aesthetics of splitting the description between the label and the placeholder text can't always be denied. Semantically, though, you're still using your labels as headers in this situation, and then providing the actual labels as placeholder text, and it would *still* be best semantically to either mark it up explicitly as such (move Hair:/Nose:/etc to a legend or hn and then labeling the fields with Color:, Shape, etc) or collapse the hierarchy and combine ( Hair: becomes Hair color:, etc.). Am I being anal and a little contrived about semantics to support my point? Of course, but that doesn't make my point invalid. ^_^ After all, what if you wanted hair length as well as color? You'd be forced to move to one of the two solutions - either promoting Hair to a full legend/hn in the form and using Color: and Length as labels or collapsing the label/placeholder dichotomy with Hair color and Hair length both as labels or both as placeholders. ~TJ
Re: [whatwg] Placeholder option for text input boxes
Am Dienstag, den 30.09.2008, 12:04 -0500 schrieb Tab Atkins Jr.: 4) label (moving label textual content into input as placeholder text; currently with Javascript to mutate the DOM, in the future with CSS to present the desired appearance while keeping the DOM stable) Pro: Most semantic. Can be pushed site-wide without having to change page code. Can't break existing content, because it is opt-in (unless this gets put into browser default stylesheets). Accessible (if using CSS solution; probably not accessible if DOM mutation is employed). Degrades well (just stays an ordinary visible label if browser doesn't support the rule). Wow. I'll now deny ever mentioning @title ! Con: Most complex solution for implementors. Need to push proposal through CSS WG, which can be slower than WHATWG. Since it's a purely presentational thing, that seems the way to go ! AFAIK, Development of CSS 3 will continue until 2011. Cheers, Nils
Re: [whatwg] Placeholder option for text input boxes
Pros/cons for a |placeholder| property and attribute on TEXTAREA? As I understand it, it was sort of an accident that Safari supports placeholder on anything other than search fields, but there's no reason it shouldn't apply to all text input fields including textarea. I've just filed https://bugs.webkit.org/show_bug.cgi?id=21248 -- Andy Lyttle [EMAIL PROTECTED]
Re: [whatwg] Placeholder option for text input boxes
On Tue, Sep 30, 2008 at 1:46 PM, Andy Lyttle [EMAIL PROTECTED] wrote: On Sep 30, 2008, at 10:54 AM, Tab Atkins Jr. wrote: Of course, the aesthetics of splitting the description between the label and the placeholder text can't always be denied. Semantically, though, you're still using your labels as headers in this situation, and then providing the actual labels as placeholder text, and it would *still* be best semantically to either mark it up explicitly as such (move Hair:/Nose:/etc to a legend or hn and then labeling the fields with Color:, Shape, etc) or collapse the hierarchy and combine ( Hair: becomes Hair color:, etc.). Legend is supposed to label a fieldset, not an individual field. fieldset legendFacial Features/legend label for=eyesEyes:/label input name=eyes id=eyes placeholder=Color title=Enter the color of your eyesbr label for=noseNose:/label input name=nose id=nose placeholder=Shape title=Describe the shape of your nose /fieldset fieldset legendBirth Information/legend label for=dobDate of Birth:/label input name=dob id=dob type=date title=Enter the date you were bornbr label for=birthplacePlace of Birth:/label input name=birthplace id=birthplace placeholder=City, State title=Enter the city and state where you were born /fieldset Is this (the splitting of necessary descriptive information between label and placeholder text) sufficiently widespread enough to justify designing toward it? In every use of placeholder text *I've* seen in the wild, it was *only* used as a label *replacement*, not an augment. Frex, a forum I frequent has username and password fields shoved away very compactly into an infobar at the top of the screen, and uses placeholder text to indicate what they are for. You've provided cases where it *could* be useful, but in each of these it would be just as useful to the user to have that information in the label itself. It's really just the designer's aesthetic concerns that dictate it must be separated. Obviously this entire discussion is about mere aesthetics ultimately, but if a qualitatively better answer will solve 90% of use cases with greater ease, accessibility, and less coding, we should probably go with it. I'm arguing that a CSS-based packing of the label text into the input is just such an answer.
Re: [whatwg] Placeholder option for text input boxes
Am Dienstag, den 30.09.2008, 11:49 -0700 schrieb Garrett Smith: Are there any arguments against a |placeholder| property on INPUT? Missing semantics ? It is a purely presentational attribute. Cheers, Nils
Re: [whatwg] Placeholder option for text input boxes
On Sep 30, 2008, at 12:14 PM, Nils Dagsson Moskopp wrote: Am Dienstag, den 30.09.2008, 11:49 -0700 schrieb Garrett Smith: Are there any arguments against a |placeholder| property on INPUT? Missing semantics ? It is a purely presentational attribute. It provides a hint to the user about what input is expected. It's no less semantic than title, which gets used for plenty of non-title- related things. -- Andy Lyttle [EMAIL PROTECTED]
Re: [whatwg] Placeholder option for text input boxes
On Tue, Sep 30, 2008 at 12:14 PM, Nils Dagsson Moskopp [EMAIL PROTECTED] wrote: Am Dienstag, den 30.09.2008, 11:49 -0700 schrieb Garrett Smith: Are there any arguments against a |placeholder| property on INPUT? Missing semantics ? It is a purely presentational attribute. The semantics would be simple property access: input.placeholder - as demonstrated in the example I posted up. Garrett Cheers, Nils
Re: [whatwg] Placeholder option for text input boxes
Tab Atkins Jr.: 1) @placeholder Con: Duplicates semantics already present in label, (...) That could be circumvented by combining the two: labelFoo input type=text placeholder/label yielded [Foo ] whereas labelFoo input type=text placeholder=Bar/label resulted in [Bar ]. A similar observation as for |results|, concerning binary attributes, applies. Also I think the (textual) content of |label| is too hard to push into a placeholder text, because it may include all kinds of markup and style that it should or should not retain. 2) @alt Non-interactive UAs might choose to use |alt| instead of rendering form controls.
