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] Safari-compatible input type=search
Binoculars are more appropriate because they can be used to look around whereas a magnifying glass cannot. Chris -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Christoph Päper Sent: Tuesday, September 30, 2008 11:55 PM To: WHAT working group Subject: Re: [whatwg] Safari-compatible input type=search The magnifying glass was a particularly poor choice by Apple[1], because icons featuring one usually represent zooming (in). Binoculars are (for some reason) more common as symbols for searches. Eyes and spectacles OTOH most often represent visibility.
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] Safari-compatible input type=search
On Tue, Sep 30, 2008 at 3:46 PM, Andy Lyttle [EMAIL PROTECTED] wrote: On Sep 30, 2008, at 2:55 PM, Christoph Päper wrote: Anyhow, the appearance of this or other types of |input| should not be specified by HTML5 / WF2+. Of course browsers could choose what the icon should look like; Would it be desirable to allow the icon to be specified in css? -- Andy Lyttle
Re: [whatwg] native styling for search input boxes
the look of the input field could be styled just by a value of search for the CSS appearance. that would have to go through CSS3 WG, but would probabvy be the cleanest approach. http://www.w3.org/TR/css3-ui/#system (i hope this puts an end to input styling discussions)
Re: [whatwg] native styling for search input boxes
Am Mittwoch, den 01.10.2008, 09:31 +0200 schrieb Nils Dagsson Moskopp: the look of the input field could be styled just by a value of search for the CSS appearance. that would have to go through CSS3 WG, but would probabvy be the cleanest approach. http://www.w3.org/TR/css3-ui/#system sorry, correct link was http://www.w3.org/TR/css3-ui/#appearance0 Cheers, Nils
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] Safari-compatible input type=search
Would it be desirable to allow the icon to be specified in css? That's up to the author/user agent, and currently you can have a small icon in the background of an edit field with regular css. On Wed, Oct 1, 2008 at 8:29 AM, Garrett Smith [EMAIL PROTECTED] wrote: On Tue, Sep 30, 2008 at 3:46 PM, Andy Lyttle [EMAIL PROTECTED] wrote: On Sep 30, 2008, at 2:55 PM, Christoph Päper wrote: Anyhow, the appearance of this or other types of |input| should not be specified by HTML5 / WF2+. Of course browsers could choose what the icon should look like; Would it be desirable to allow the icon to be specified in css? -- Andy Lyttle
Re: [whatwg] native styling for search input boxes
On Oct 1, 2008, at 10:31, Nils Dagsson Moskopp wrote: the look of the input field could be styled just by a value of search for the CSS appearance. that would have to go through CSS3 WG, but would probabvy be the cleanest approach. The PFWG of the W3C has deemed it necessary to have an ARIA role for search. This suggests that a box being a search box is not just a Mac OS X widget style thing but also sensitive to accessibility semantics. -- Henri Sivonen [EMAIL PROTECTED] http://hsivonen.iki.fi/
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] native styling for search input boxes
Nils Dagsson Moskopp wrote: the look of the input field could be styled just by a value of search for the CSS appearance. that would have to go through CSS3 WG, but would probabvy be the cleanest approach. http://www.w3.org/TR/css3-ui/#system See also: http://lipidity.com/apple/iphone-webkit-css-3 -webkit-appearance: searchfield; It works already in Safari. Perhaps we need behavior: searchfield; in addition? -- Mikko signature.asc Description: OpenPGP digital signature
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] native styling for search input boxes
On Oct 1, 2008, at 12:31 AM, Nils Dagsson Moskopp wrote: the look of the input field could be styled just by a value of search for the CSS appearance. that would have to go through CSS3 WG, but would probabvy be the cleanest approach. http://www.w3.org/TR/css3-ui/#system (i hope this puts an end to input styling discussions) The status of being a search field is semantic, not just presentational. User agents and assistive technologies could use the knowledge that a field is a search field in all sorts of helpful ways. Indeed, the semantics would be useful even without the special presentation, but the special presentation gives authors an extra incentive to get it right. Regards, Maciej
Re: [whatwg] native styling for search input boxes
Please give some examples how the special status of a search field can be used by user agents, presentation aside. (I am not trying to challenge Matthew's argument, I am just interested). Chris -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Maciej Stachowiak Sent: Wednesday, October 01, 2008 6:58 PM To: Nils Dagsson Moskopp Cc: whatwg Subject: Re: [whatwg] native styling for search input boxes On Oct 1, 2008, at 12:31 AM, Nils Dagsson Moskopp wrote: the look of the input field could be styled just by a value of search for the CSS appearance. that would have to go through CSS3 WG, but would probabvy be the cleanest approach. http://www.w3.org/TR/css3-ui/#system (i hope this puts an end to input styling discussions) The status of being a search field is semantic, not just presentational. User agents and assistive technologies could use the knowledge that a field is a search field in all sorts of helpful ways. Indeed, the semantics would be useful even without the special presentation, but the special presentation gives authors an extra incentive to get it right. Regards, Maciej
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] native styling for search input boxes
Am Mittwoch, den 01.10.2008, 09:58 -0700 schrieb Maciej Stachowiak: On Oct 1, 2008, at 12:31 AM, Nils Dagsson Moskopp wrote: the look of the input field could be styled just by a value of search for the CSS appearance. that would have to go through CSS3 WG, but would probabvy be the cleanest approach. http://www.w3.org/TR/css3-ui/#system (i hope this puts an end to input styling discussions) The status of being a search field is semantic, not just presentational. 100% agree. But the status of /looking like an OS native widget/ is purely presentational and CSS 3 has a fitting property for that. Semantics and presentation can and IMO should be decoupled. User agents and assistive technologies could use the knowledge that a field is a search field in all sorts of helpful ways. What exactly were you imagining ? In the end, it's a text field like any other. Indeed, the semantics would be useful even without the special presentation, but the special presentation gives authors an extra incentive to get it right. If giving authors in extra incentive to get it right was the scope of any spec discussed here, SGML serializations would not exist and validators would give out free candy. Greetings, Nils
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] native styling for search input boxes
Kristof Zelechovski wrote: Please give some examples how the special status of a search field can be used by user agents, presentation aside. Searching is one of the most common user activities on the web. Designating a field as a search field makes this task easier in two ways: 1. User agents can make it especially easy to locate (e.g. visually distinctive magnifying glass icon) and navigate to (e.g. keyboard shortcut to take you to the next search form). 2. User agents can provide consistent functionality (e.g. autocompletion). Consistent interfaces have a usability bonus. It's worth thinking about the relative (potential) usability benefits of designating a search area (the current ARIA approach with, say, DIV ROLE=SEARCH, mentioned by Henri) versus an individual search field (the INPUT TYPE=SEARCH approach). I was initially going to say that INPUT TYPE=SEARCH might fail to make search fields preceding the INPUT (for instance, a search category SELECT) easily discoverable and navigable. However, a good implementation might set keyboard focus to the first field of the next form featuring TYPE=SEARCH rather than just the INPUT in question. But ROLE=SEARCH could maybe help users: a) Skip the whole search area. b) Discovers instructions preceding the FORM. c) Differentiate forms that have search _and_ other functionality from forms that only do search. Conversely, INPUT TYPE=SEARCH holds all the cards when it comes to the look and feel and functionality of the individual field. So I'm of two minds. :) -- Benjamin Hawkes-Lewis
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] native styling for search input boxes
On Wed, Oct 1, 2008 at 1:04 PM, Kristof Zelechovski [EMAIL PROTECTED] wrote: Please give some examples how the special status of a search field can be used by user agents, presentation aside. (I am not trying to challenge Matthew's argument, I am just interested). Chris Firefox, IE8, and several other browsers allows for search provider autodiscovery. When they encounter a site with a specific link tag, their searchbox dropdown lights up, denoting that the site can be added as a permanent search target. http://www.rebron.org/2006/06/01/search-discovery-in-firefox-20/ http://msdn.microsoft.com/en-us/library/cc848862(VS.85).aspx A special search field could also integrate with this facility in a more automatic and natural way. Any site with marked-up search field could be considered a search provider. Regards, Leons Petrazickis http://lpetr.org/blog/
Re: [whatwg] native styling for search input boxes
On Oct 1, 2008, at 10:04 AM, Kristof Zelechovski wrote: Please give some examples how the special status of a search field can be used by user agents, presentation aside. (I am not trying to challenge Matthew's argument, I am just interested). By Matthew did you mean me? - Maciej Chris -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Maciej Stachowiak Sent: Wednesday, October 01, 2008 6:58 PM To: Nils Dagsson Moskopp Cc: whatwg Subject: Re: [whatwg] native styling for search input boxes On Oct 1, 2008, at 12:31 AM, Nils Dagsson Moskopp wrote: the look of the input field could be styled just by a value of search for the CSS appearance. that would have to go through CSS3 WG, but would probabvy be the cleanest approach. http://www.w3.org/TR/css3-ui/#system (i hope this puts an end to input styling discussions) The status of being a search field is semantic, not just presentational. User agents and assistive technologies could use the knowledge that a field is a search field in all sorts of helpful ways. Indeed, the semantics would be useful even without the special presentation, but the special presentation gives authors an extra incentive to get it right. Regards, Maciej
Re: [whatwg] native styling for search input boxes
On Oct 1, 2008, at 10:14 AM, Nils Dagsson Moskopp wrote: Am Mittwoch, den 01.10.2008, 09:58 -0700 schrieb Maciej Stachowiak: On Oct 1, 2008, at 12:31 AM, Nils Dagsson Moskopp wrote: the look of the input field could be styled just by a value of search for the CSS appearance. that would have to go through CSS3 WG, but would probabvy be the cleanest approach. http://www.w3.org/TR/css3-ui/#system (i hope this puts an end to input styling discussions) The status of being a search field is semantic, not just presentational. 100% agree. But the status of /looking like an OS native widget/ is purely presentational and CSS 3 has a fitting property for that. Semantics and presentation can and IMO should be decoupled. There is behavior as well as appearance involved. It differs from input type=text in much the same way that input type=password does. User agents and assistive technologies could use the knowledge that a field is a search field in all sorts of helpful ways. What exactly were you imagining ? In the end, it's a text field like any other. For example, Chrome will keep track of search fields that the user has used on various pages. I assume they currently use a heuristic, this would be a clear signal of search-fieldness. (I do not speak for the Chrome team here and I do not know if they would want to use it. Indeed, the semantics would be useful even without the special presentation, but the special presentation gives authors an extra incentive to get it right. If giving authors in extra incentive to get it right was the scope of any spec discussed here, SGML serializations would not exist and validators would give out free candy. On the contrary, features of HTML5 like meter and time exist to give authors an extra incentive to get it right. Regards, Maciej
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
