On Nov 17, 2008, at 10:05 AM, Ian Hickson wrote:
...
On Mon, 21 May 2007, Stijn Peeters wrote:
...
It makes sense to clear these values when the field is focused, as the
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
javascript, which is not necessarily a bad thing, but seeing that
attributes such as autofocus="" have also found their way into the
spec, I suppose this is also inside the scope of Web Forms 2 or HTML5.
As for the attribute name, clearonfocus="" with "clearonfocus" as the
only possible value (indicating the input field or textarea should be
cleared upon focusing it) would probably be most suitable.
...
On Wed, 23 May 2007, Matthew Paul Thomas wrote:
I don't understand. What use is a default value if you can't edit it?
Why not make the field empty to begin with?
On Fri, 25 May 2007, Matthew Paul Thomas wrote:
No, we already addressed the label use case. I asked specifically
about the default value use case.
I don't know what you are asking for here.
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.
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.
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.
...
On Tue, 30 Sep 2008, Andy Lyttle wrote:
...
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)
We can't really change the behavior of title="" now, it'd have all
kinds of weird unexpected effects on existing pages
...
On Thu, 2 Oct 2008, Tab Atkins Jr. 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 don't see any harm to having this in the language really. We don't
disallow UAs from rendering this after the control.
...
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.
Cheers
--
Matthew Paul Thomas
http://mpt.net.nz/
