On Tue, Nov 25, 2008 at 2:42 PM, Matthew Paul Thomas <span dir="ltr"><<a href="mailto:mpt@myrealbox.com">mpt@myrealbox.com</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
On Nov 17, 2008, at 10:05 AM, Ian Hickson wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
...<div class="Ih2E3d"><br>
On Mon, 21 May 2007, Stijn Peeters wrote:<br>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
...<div class="Ih2E3d"><br>
It makes sense to clear these values when the field is focused, as the<br>
user will probably want to insert a new value rather than edit the value that is currently in it. Currently this is mostly done through<br>
javascript, which is not necessarily a bad thing, but seeing that<br>
attributes such as autofocus="" have also found their way into the<br>
spec, I suppose this is also inside the scope of Web Forms 2 or HTML5.<br>
As for the attribute name, clearonfocus="" with "clearonfocus" as the<br>
only possible value (indicating the input field or textarea should be<br>
cleared upon focusing it) would probably be most suitable.<br>
</div></blockquote>
...<div class="Ih2E3d"><br>
On Wed, 23 May 2007, Matthew Paul Thomas wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
I don't understand. What use is a default value if you can't edit it?<br>
Why not make the field empty to begin with?<br>
</blockquote>
<br>
On Fri, 25 May 2007, Matthew Paul Thomas wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
No, we already addressed the label use case. I asked specifically about the default value use case.<br>
</blockquote>
<br>
I don't know what you are asking for here.<br>
</div></blockquote>
<br>
I was asking, obviously, what use is a default value if you can't edit it. If an enabled text field had a displayed value= but the value was not actually editable, that would be unpleasantly surprising.</blockquote><div>
<br>I'm still as confused as Ian here. This isn't a default value. You use @value for that. @placeholder can represent a *sample* value, but that is *not* intended to be submitted, and has no need to be editted. It's never expected to be directly useful, but rather just to show the user directly what is expected in the field.<br>
<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">That problem applies just as much to <input placeholder="foo"> as it would have done to <input value="foo" clearonfocus>: depending on whether the placeholder text is greyed out, it would make the field either look like it has a value when it actually doesn't, or look disabled when it actually isn't. It would also hide the label or hint for the field for *precisely* the period when you need it most. I'm not aware of any possible presentation that avoids both (or even one of!) those problems, and previously HTML5 has shied away from expecting browsers to implement things that have no known reasonable presentation.</blockquote>
<div><br>Actually, due to the prevalance of this sort of thing, most people are rather used to gray (and possible italicized) text in an input disappearing when they click into it. It doesn't confuse them at all.<br>
<br>The fact that it *is* relatively widely used, and isn't confusing to the average person, means that the suggested presentation *is* useful.<br><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
I appreciate that Web authors currently go to some scripting lengths to position labels for text fields inside the fields, and I think it's quite appropriate that they should have to go to those lengths, because it makes bad design more difficult. I would rather see, as I've previously suggested, markup for associating form controls with hints outside them in a similar way as labels can be associated now.</blockquote>
<div><br>Actually, it's really not any great length at all. For example, <a href="http://www.kryogenix.org/code/browser/labelify/">http://www.kryogenix.org/code/browser/labelify/</a> is a dead-simple jQuery plugin that does it automagically for you. There are several other variants on the theme (this is just the first I found in a quick search), and I'm certain other js libraries have similar things built for them.<br>
<br>The problem, of course, is that alternative display devices which try to run javascript but display pages or handle user interaction substantially differently may get an extremely messed up result out of any js-based solution. By building it directly into the language the UA can decide precisely how it wants to render and control this sort of thing to be maximally useful to its users.<br>
<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
...<div class="Ih2E3d"><br>
On Tue, 30 Sep 2008, Andy Lyttle wrote:<br></div>
...<div class="Ih2E3d"><br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
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<br>
(especially if their title string is too long to fit inside a small<br>
field)<br>
</blockquote>
<br>
We can't really change the behavior of title="" now, it'd have all kinds of weird unexpected effects on existing pages<br>
...<br></div><div class="Ih2E3d">
On Thu, 2 Oct 2008, Tab Atkins Jr. wrote:<br>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
...<div class="Ih2E3d"><br>
Of course, it's still not in any way semantic. The only difference<br>
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.<br>
</div></blockquote><div class="Ih2E3d">
<br>
I don't see any harm to having this in the language really. We don't<br>
disallow UAs from rendering this after the control.<br></div>
...<br>
</blockquote>
<br>
But they couldn't really do that, it'd have all kinds of weird unexpected effects on pages designed by people using browsers that present it the way the spec suggests.<br>
</blockquote></div><br>This is true, at least for the standard desktop browsers. They'll all standardize on the standard gray text that's already in use, because that's what users are used to and expect.<br>
<br>I still greatly prefer a CSS-based solution over this, but I can live with it.<br><br>~TJ<br>