CHeckbox-attribute.html

From dhtmlkitchen at gmail.com Wed Oct 1 00:18:24 2008 From: dhtmlkitchen at gmail.com (Garrett Smith) Date: Wed, 1 Oct 2008 00:18:24 -0700 Subject: [whatwg] Placeholder option for text input boxes In-Reply-To: <8BDF1F08E9384EFCAA4097748E5491AC@POCZTOWIEC> References: <48E1D73F.10707@googlemail.com>

<8BDF1F08E9384EFCAA4097748E5491AC@POCZTOWIEC> Message-ID: On Tue, Sep 30, 2008 at 11:43 PM, Kristof Zelechovski 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: whatwg-bounces at lists.whatwg.org > [mailto:whatwg-bounces at lists.whatwg.org] On Behalf Of Garrett Smith > Sent: Tuesday, September 30, 2008 8:50 PM > To: whatwg at whatwg.org > 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 >> > > From dhtmlkitchen at gmail.com Wed Oct 1 00:29:56 2008 From: dhtmlkitchen at gmail.com (Garrett Smith) Date: Wed, 1 Oct 2008 00:29:56 -0700 Subject: [whatwg] Safari-compatible In-Reply-To: <03F2921F-C862-4A09-A511-3E9C64485D6D@phroggy.com> References: <6A417693-0C35-4B48-AA64-A06480D48674@phroggy.com> <03F2921F-C862-4A09-A511-3E9C64485D6D@phroggy.com> Message-ID: On Tue, Sep 30, 2008 at 3:46 PM, Andy Lyttle 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 From nils-dagsson-moskopp at dieweltistgarnichtso.net Wed Oct 1 00:31:50 2008 From: nils-dagsson-moskopp at dieweltistgarnichtso.net (Nils Dagsson Moskopp) Date: Wed, 01 Oct 2008 09:31:50 +0200 Subject: [whatwg] native styling for search input boxes In-Reply-To: <31C060EAB1A84D409A337C9C09AE9906@POCZTOWIEC> References: <48E1D73F.10707@googlemail.com>

<1222802086.21677.26.camel@dell.linuxdev.us.dell.com> <31C060EAB1A84D409A337C9C09AE9906@POCZTOWIEC> Message-ID: <1222846310.25022.6.camel@dell.linuxdev.us.dell.com> 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) From nils-dagsson-moskopp at dieweltistgarnichtso.net Wed Oct 1 00:34:08 2008 From: nils-dagsson-moskopp at dieweltistgarnichtso.net (Nils Dagsson Moskopp) Date: Wed, 01 Oct 2008 09:34:08 +0200 Subject: [whatwg] native styling for search input boxes In-Reply-To: <1222846310.25022.6.camel@dell.linuxdev.us.dell.com> References: <48E1D73F.10707@googlemail.com>

<1222802086.21677.26.camel@dell.linuxdev.us.dell.com> <31C060EAB1A84D409A337C9C09AE9906@POCZTOWIEC> <1222846310.25022.6.camel@dell.linuxdev.us.dell.com> Message-ID: <1222846448.25022.8.camel@dell.linuxdev.us.dell.com> 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 From giecrilj at stegny.2a.pl Wed Oct 1 00:45:03 2008 From: giecrilj at stegny.2a.pl (=?US-ASCII?Q?Kristof_Zelechovski?=) Date: Wed, 1 Oct 2008 09:45:03 +0200 Subject: [whatwg] Placeholder option for text input boxes In-Reply-To: References: <48E1D73F.10707@googlemail.com>

<8BDF1F08E9384EFCAA4097748E5491AC@POCZTOWIEC> Message-ID: DOM properties are not becoming obsolete; accessing attributes by properties is. Chris -----Original Message----- From: whatwg-bounces at lists.whatwg.org [mailto:whatwg-bounces at lists.whatwg.org] On Behalf Of Garrett Smith Sent: Wednesday, October 01, 2008 9:18 AM To: Kristof Zelechovski Cc: whatwg at whatwg.org Subject: Re: [whatwg] Placeholder option for text input boxes On Tue, Sep 30, 2008 at 11:43 PM, Kristof Zelechovski 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 From joao.eiras at gmail.com Wed Oct 1 01:06:41 2008 From: joao.eiras at gmail.com (=?ISO-8859-1?Q?Jo=E3o_Eiras?=) Date: Wed, 1 Oct 2008 09:06:41 +0100 Subject: [whatwg] Safari-compatible In-Reply-To: References: <6A417693-0C35-4B48-AA64-A06480D48674@phroggy.com> <03F2921F-C862-4A09-A511-3E9C64485D6D@phroggy.com> Message-ID: > 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 wrote: > On Tue, Sep 30, 2008 at 3:46 PM, Andy Lyttle 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 > From hsivonen at iki.fi Wed Oct 1 02:50:14 2008 From: hsivonen at iki.fi (Henri Sivonen) Date: Wed, 1 Oct 2008 12:50:14 +0300 Subject: [whatwg] native styling for search input boxes In-Reply-To: <1222846310.25022.6.camel@dell.linuxdev.us.dell.com> References: <48E1D73F.10707@googlemail.com>

<1222802086.21677.26.camel@dell.linuxdev.us.dell.com> <31C060EAB1A84D409A337C9C09AE9906@POCZTOWIEC> <1222846310.25022.6.camel@dell.linuxdev.us.dell.com> Message-ID: 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 hsivonen at iki.fi http://hsivonen.iki.fi/ From bhawkeslewis at googlemail.com Wed Oct 1 03:42:18 2008 From: bhawkeslewis at googlemail.com (Benjamin Hawkes-Lewis) Date: Wed, 01 Oct 2008 11:42:18 +0100 Subject: [whatwg] Placeholder option for text input boxes In-Reply-To: References: <48E1D73F.10707@googlemail.com>

<8BDF1F08E9384EFCAA4097748E5491AC@POCZTOWIEC> Message-ID: <48E3540A.6020409@googlemail.com> Kristof Zelechovski wrote: > DOM properties are not becoming obsolete; accessing attributes by properties > is. Hmm. Citation? -- Benjamin Hawkes-Lewis From giecrilj at stegny.2a.pl Wed Oct 1 04:39:29 2008 From: giecrilj at stegny.2a.pl (=?US-ASCII?Q?Kristof_Zelechovski?=) Date: Wed, 1 Oct 2008 13:39:29 +0200 Subject: [whatwg] Placeholder option for text input boxes In-Reply-To: <48E3540A.6020409@googlemail.com> References: <48E1D73F.10707@googlemail.com>

<8BDF1F08E9384EFCAA4097748E5491AC@POCZTOWIEC> <48E3540A.6020409@googlemail.com> Message-ID: <95163DE11B4047A28B8D7BF9D57DC8DC@POCZTOWIEC> 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. -----Original Message----- From: Benjamin Hawkes-Lewis [mailto:bhawkeslewis at googlemail.com] Sent: Wednesday, October 01, 2008 12:42 PM To: Kristof Zelechovski Cc: 'Garrett Smith'; whatwg at whatwg.org 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 From joao.eiras at gmail.com Wed Oct 1 06:32:42 2008 From: joao.eiras at gmail.com (=?ISO-8859-1?Q?Jo=E3o_Eiras?=) Date: Wed, 1 Oct 2008 14:32:42 +0100 Subject: [whatwg] Placeholder option for text input boxes In-Reply-To: <95163DE11B4047A28B8D7BF9D57DC8DC@POCZTOWIEC> References:

<8BDF1F08E9384EFCAA4097748E5491AC@POCZTOWIEC> <48E3540A.6020409@googlemail.com> <95163DE11B4047A28B8D7BF9D57DC8DC@POCZTOWIEC> Message-ID: > 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 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. > 2250288> > > -----Original Message----- > From: Benjamin Hawkes-Lewis [mailto:bhawkeslewis at googlemail.com] > Sent: Wednesday, October 01, 2008 12:42 PM > To: Kristof Zelechovski > Cc: 'Garrett Smith'; whatwg at whatwg.org > 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 > > From bhawkeslewis at googlemail.com Wed Oct 1 06:53:00 2008 From: bhawkeslewis at googlemail.com (Benjamin Hawkes-Lewis) Date: Wed, 01 Oct 2008 14:53:00 +0100 Subject: [whatwg] Placeholder option for text input boxes In-Reply-To: References:

<8BDF1F08E9384EFCAA4097748E5491AC@POCZTOWIEC> <48E3540A.6020409@googlemail.com> <95163DE11B4047A28B8D7BF9D57DC8DC@POCZTOWIEC> Message-ID: <48E380BC.1020600@googlemail.com> 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 From giecrilj at stegny.2a.pl Wed Oct 1 07:04:12 2008 From: giecrilj at stegny.2a.pl (=?US-ASCII?Q?Kristof_Zelechovski?=) Date: Wed, 1 Oct 2008 16:04:12 +0200 Subject: [whatwg] Placeholder option for text input boxes In-Reply-To: References:

<8BDF1F08E9384EFCAA4097748E5491AC@POCZTOWIEC> <48E3540A.6020409@googlemail.com> <95163DE11B4047A28B8D7BF9D57DC8DC@POCZTOWIEC> Message-ID: <47E9A3A7E8FB43179E6082A0F9C37F4B@POCZTOWIEC> 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:joao.eiras at gmail.com] Sent: Wednesday, October 01, 2008 3:33 PM To: Kristof Zelechovski Cc: whatwg at whatwg.org 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. From mikko.rantalainen at peda.net Wed Oct 1 07:55:53 2008 From: mikko.rantalainen at peda.net (Mikko Rantalainen) Date: Wed, 01 Oct 2008 17:55:53 +0300 Subject: [whatwg] native styling for search input boxes In-Reply-To: <1222846310.25022.6.camel@dell.linuxdev.us.dell.com> References: <48E1D73F.10707@googlemail.com>

<1222802086.21677.26.camel@dell.linuxdev.us.dell.com> <31C060EAB1A84D409A337C9C09AE9906@POCZTOWIEC> <1222846310.25022.6.camel@dell.linuxdev.us.dell.com> Message-ID: <48E38F79.1040402@peda.net> 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 254 bytes Desc: OpenPGP digital signature URL: From joao.eiras at gmail.com Wed Oct 1 08:27:00 2008 From: joao.eiras at gmail.com (=?ISO-8859-1?Q?Jo=E3o_Eiras?=) Date: Wed, 1 Oct 2008 16:27:00 +0100 Subject: [whatwg] Placeholder option for text input boxes In-Reply-To: <47E9A3A7E8FB43179E6082A0F9C37F4B@POCZTOWIEC> References: <8BDF1F08E9384EFCAA4097748E5491AC@POCZTOWIEC> <48E3540A.6020409@googlemail.com> <95163DE11B4047A28B8D7BF9D57DC8DC@POCZTOWIEC> <47E9A3A7E8FB43179E6082A0F9C37F4B@POCZTOWIEC> Message-ID: > 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 ? From giecrilj at stegny.2a.pl Wed Oct 1 08:48:40 2008 From: giecrilj at stegny.2a.pl (=?US-ASCII?Q?Kristof_Zelechovski?=) Date: Wed, 1 Oct 2008 17:48:40 +0200 Subject: [whatwg] Placeholder option for text input boxes In-Reply-To: References: <8BDF1F08E9384EFCAA4097748E5491AC@POCZTOWIEC><48E3540A.6020409@googlemail.com><95163DE11B4047A28B8D7BF9D57DC8DC@POCZTOWIEC><47E9A3A7E8FB43179E6082A0F9C37F4B@POCZTOWIEC> Message-ID: 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: whatwg-bounces at lists.whatwg.org [mailto:whatwg-bounces at lists.whatwg.org] On Behalf Of Joao Eiras Sent: Wednesday, October 01, 2008 5:27 PM To: Kristof Zelechovski Cc: whatwg at whatwg.org 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 ? From aa at google.com Wed Oct 1 09:55:41 2008 From: aa at google.com (Aaron Boodman) Date: Wed, 1 Oct 2008 09:55:41 -0700 Subject: [whatwg] Placeholder option for text input boxes In-Reply-To: References: <8BDF1F08E9384EFCAA4097748E5491AC@POCZTOWIEC> <48E3540A.6020409@googlemail.com> <95163DE11B4047A28B8D7BF9D57DC8DC@POCZTOWIEC> <47E9A3A7E8FB43179E6082A0F9C37F4B@POCZTOWIEC> Message-ID: <278fd46c0810010955l698fe7b7kc2681d9c262b2f44@mail.gmail.com> 2008/10/1 Kristof Zelechovski : > 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From mjs at apple.com Wed Oct 1 09:58:23 2008 From: mjs at apple.com (Maciej Stachowiak) Date: Wed, 01 Oct 2008 09:58:23 -0700 Subject: [whatwg] native styling for search input boxes In-Reply-To: <1222846310.25022.6.camel@dell.linuxdev.us.dell.com> References: <48E1D73F.10707@googlemail.com>

<1222802086.21677.26.camel@dell.linuxdev.us.dell.com> <31C060EAB1A84D409A337C9C09AE9906@POCZTOWIEC> <1222846310.25022.6.camel@dell.linuxdev.us.dell.com> Message-ID: 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 From giecrilj at stegny.2a.pl Wed Oct 1 10:04:33 2008 From: giecrilj at stegny.2a.pl (=?US-ASCII?Q?Kristof_Zelechovski?=) Date: Wed, 1 Oct 2008 19:04:33 +0200 Subject: [whatwg] native styling for search input boxes In-Reply-To: References: <48E1D73F.10707@googlemail.com>

<1222802086.21677.26.camel@dell.linuxdev.us.dell.com><31C060EAB1A84D409A337C9C09AE9906@POCZTOWIEC><1222846310.25022.6.camel@dell.linuxdev.us.dell.com> Message-ID: <4EB0A04D954A4D828CB1CE2C07A7634E@POCZTOWIEC> 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: whatwg-bounces at lists.whatwg.org [mailto:whatwg-bounces at lists.whatwg.org] 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 From giecrilj at stegny.2a.pl Wed Oct 1 10:05:45 2008 From: giecrilj at stegny.2a.pl (=?US-ASCII?Q?Kristof_Zelechovski?=) Date: Wed, 1 Oct 2008 19:05:45 +0200 Subject: [whatwg] Placeholder option for text input boxes In-Reply-To: <278fd46c0810010955l698fe7b7kc2681d9c262b2f44@mail.gmail.com> References: <8BDF1F08E9384EFCAA4097748E5491AC@POCZTOWIEC><48E3540A.6020409@googlemail.com><95163DE11B4047A28B8D7BF9D57DC8DC@POCZTOWIEC><47E9A3A7E8FB43179E6082A0F9C37F4B@POCZTOWIEC> <278fd46c0810010955l698fe7b7kc2681d9c262b2f44@mail.gmail.com> Message-ID: <89208CCDE4E44F15B929850E2FF62D64@POCZTOWIEC> 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: whatwg-bounces at lists.whatwg.org [mailto:whatwg-bounces at lists.whatwg.org] 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 : > 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From nils-dagsson-moskopp at dieweltistgarnichtso.net Wed Oct 1 10:14:33 2008 From: nils-dagsson-moskopp at dieweltistgarnichtso.net (Nils Dagsson Moskopp) Date: Wed, 01 Oct 2008 19:14:33 +0200 Subject: [whatwg] native styling for search input boxes In-Reply-To: References: <48E1D73F.10707@googlemail.com>

<1222802086.21677.26.camel@dell.linuxdev.us.dell.com> <31C060EAB1A84D409A337C9C09AE9906@POCZTOWIEC> <1222846310.25022.6.camel@dell.linuxdev.us.dell.com> Message-ID: <1222881273.25022.21.camel@dell.linuxdev.us.dell.com> 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 From aa at google.com Wed Oct 1 10:27:01 2008 From: aa at google.com (Aaron Boodman) Date: Wed, 1 Oct 2008 10:27:01 -0700 Subject: [whatwg] Placeholder option for text input boxes In-Reply-To: <89208CCDE4E44F15B929850E2FF62D64@POCZTOWIEC> References: <48E3540A.6020409@googlemail.com> <95163DE11B4047A28B8D7BF9D57DC8DC@POCZTOWIEC> <47E9A3A7E8FB43179E6082A0F9C37F4B@POCZTOWIEC> <278fd46c0810010955l698fe7b7kc2681d9c262b2f44@mail.gmail.com> <89208CCDE4E44F15B929850E2FF62D64@POCZTOWIEC> Message-ID: <278fd46c0810011027o1e5bcd1do10176a4a9097f450@mail.gmail.com> On Wed, Oct 1, 2008 at 10:05 AM, Kristof Zelechovski 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 From bhawkeslewis at googlemail.com Wed Oct 1 10:29:34 2008 From: bhawkeslewis at googlemail.com (Benjamin Hawkes-Lewis) Date: Wed, 01 Oct 2008 18:29:34 +0100 Subject: [whatwg] native styling for search input boxes In-Reply-To: <4EB0A04D954A4D828CB1CE2C07A7634E@POCZTOWIEC> References: <48E1D73F.10707@googlemail.com>

<1222802086.21677.26.camel@dell.linuxdev.us.dell.com><31C060EAB1A84D409A337C9C09AE9906@POCZTOWIEC><1222846310.25022.6.camel@dell.linuxdev.us.dell.com> <4EB0A04D954A4D828CB1CE2C07A7634E@POCZTOWIEC> Message-ID: <48E3B37E.5070305@googlemail.com> 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 From joao.eiras at gmail.com Wed Oct 1 10:29:52 2008 From: joao.eiras at gmail.com (=?ISO-8859-1?Q?Jo=E3o_Eiras?=) Date: Wed, 1 Oct 2008 18:29:52 +0100 Subject: [whatwg] Placeholder option for text input boxes In-Reply-To: <278fd46c0810011027o1e5bcd1do10176a4a9097f450@mail.gmail.com> References: <48E3540A.6020409@googlemail.com> <95163DE11B4047A28B8D7BF9D57DC8DC@POCZTOWIEC> <47E9A3A7E8FB43179E6082A0F9C37F4B@POCZTOWIEC> <278fd46c0810010955l698fe7b7kc2681d9c262b2f44@mail.gmail.com> <89208CCDE4E44F15B929850E2FF62D64@POCZTOWIEC> <278fd46c0810011027o1e5bcd1do10176a4a9097f450@mail.gmail.com> Message-ID: 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 wrote: > On Wed, Oct 1, 2008 at 10:05 AM, Kristof Zelechovski > 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 > From giecrilj at stegny.2a.pl Wed Oct 1 10:45:48 2008 From: giecrilj at stegny.2a.pl (=?US-ASCII?Q?Kristof_Zelechovski?=) Date: Wed, 1 Oct 2008 19:45:48 +0200 Subject: [whatwg] Placeholder option for text input boxes In-Reply-To: <278fd46c0810011027o1e5bcd1do10176a4a9097f450@mail.gmail.com> References: <48E3540A.6020409@googlemail.com> <95163DE11B4047A28B8D7BF9D57DC8DC@POCZTOWIEC> <47E9A3A7E8FB43179E6082A0F9C37F4B@POCZTOWIEC> <278fd46c0810010955l698fe7b7kc2681d9c262b2f44@mail.gmail.com> <89208CCDE4E44F15B929850E2FF62D64@POCZTOWIEC> <278fd46c0810011027o1e5bcd1do10176a4a9097f450@mail.gmail.com> Message-ID: <97BCFFE7ED37454281E009E01FC9A7EE@POCZTOWIEC> 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:aa at google.com] 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 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 From giecrilj at stegny.2a.pl Wed Oct 1 10:47:21 2008 From: giecrilj at stegny.2a.pl (=?US-ASCII?Q?Kristof_Zelechovski?=) Date: Wed, 1 Oct 2008 19:47:21 +0200 Subject: [whatwg] Placeholder option for text input boxes In-Reply-To: References: <48E3540A.6020409@googlemail.com><95163DE11B4047A28B8D7BF9D57DC8DC@POCZTOWIEC><47E9A3A7E8FB43179E6082A0F9C37F4B@POCZTOWIEC><278fd46c0810010955l698fe7b7kc2681d9c262b2f44@mail.gmail.com><89208CCDE4E44F15B929850E2FF62D64@POCZTOWIEC><278fd46c0810011027o1e5bcd1do10176a4a9097f450@mail.gmail.com> Message-ID: <3CB5F5AFAEFD466E9B9F860E86F1A9EA@POCZTOWIEC> This was Garret's original code; it cannot be used for feature detection, as explained. Chris -----Original Message----- From: whatwg-bounces at lists.whatwg.org [mailto:whatwg-bounces at lists.whatwg.org] On Behalf Of Joao Eiras Sent: Wednesday, October 01, 2008 7:30 PM To: Aaron Boodman; whatwg at 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. From leons.petrazickis at gmail.com Wed Oct 1 12:57:16 2008 From: leons.petrazickis at gmail.com (Leons Petrazickis) Date: Wed, 1 Oct 2008 15:57:16 -0400 Subject: [whatwg] native styling for search input boxes In-Reply-To: <4EB0A04D954A4D828CB1CE2C07A7634E@POCZTOWIEC> References: <1222802086.21677.26.camel@dell.linuxdev.us.dell.com> <31C060EAB1A84D409A337C9C09AE9906@POCZTOWIEC> <1222846310.25022.6.camel@dell.linuxdev.us.dell.com> <4EB0A04D954A4D828CB1CE2C07A7634E@POCZTOWIEC> Message-ID: <5b04ec2d0810011257n4da521dcvc82d0f4863790b01@mail.gmail.com> On Wed, Oct 1, 2008 at 1:04 PM, 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). > Chris Firefox, IE8, and several other browsers allows for search provider autodiscovery. When they encounter a site with a specific 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/ From mjs at apple.com Wed Oct 1 17:06:39 2008 From: mjs at apple.com (Maciej Stachowiak) Date: Wed, 01 Oct 2008 17:06:39 -0700 Subject: [whatwg] native styling for search input boxes In-Reply-To: <4EB0A04D954A4D828CB1CE2C07A7634E@POCZTOWIEC> References: <48E1D73F.10707@googlemail.com>

<1222802086.21677.26.camel@dell.linuxdev.us.dell.com> <31C060EAB1A84D409A337C9C09AE9906@POCZTOWIEC> <1222846310.25022.6.camel@dell.linuxdev.us.dell.com> <4EB0A04D954A4D828CB1CE2C07A7634E@POCZTOWIEC> Message-ID: <8378B056-3BCF-41F6-AE0C-7F5632E3E931@apple.com> 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: whatwg-bounces at lists.whatwg.org > [mailto:whatwg-bounces at lists.whatwg.org] 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 > From mjs at apple.com Wed Oct 1 17:09:35 2008 From: mjs at apple.com (Maciej Stachowiak) Date: Wed, 01 Oct 2008 17:09:35 -0700 Subject: [whatwg] native styling for search input boxes In-Reply-To: <1222881273.25022.21.camel@dell.linuxdev.us.dell.com> References: <48E1D73F.10707@googlemail.com>

<1222802086.21677.26.camel@dell.linuxdev.us.dell.com> <31C060EAB1A84D409A337C9C09AE9906@POCZTOWIEC> <1222846310.25022.6.camel@dell.linuxdev.us.dell.com> <1222881273.25022.21.camel@dell.linuxdev.us.dell.com> Message-ID: <94456144-F2D8-4F63-A5A1-23C8021864ED@apple.com> 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 in much the same way that 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 and exist to give authors an extra incentive to get it right. Regards, Maciej From mjs at apple.com Wed Oct 1 17:11:28 2008 From: mjs at apple.com (Maciej Stachowiak) Date: Wed, 01 Oct 2008 17:11:28 -0700 Subject: [whatwg] Placeholder option for text input boxes In-Reply-To: <278fd46c0810011027o1e5bcd1do10176a4a9097f450@mail.gmail.com> References: <48E3540A.6020409@googlemail.com> <95163DE11B4047A28B8D7BF9D57DC8DC@POCZTOWIEC> <47E9A3A7E8FB43179E6082A0F9C37F4B@POCZTOWIEC> <278fd46c0810010955l698fe7b7kc2681d9c262b2f44@mail.gmail.com> <89208CCDE4E44F15B929850E2FF62D64@POCZTOWIEC> <278fd46c0810011027o1e5bcd1do10176a4a9097f450@mail.gmail.com> Message-ID: <1BB057AD-D38C-4BEB-8C20-BB3B5D19F6FF@apple.com> On Oct 1, 2008, at 10:27 AM, Aaron Boodman wrote: > On Wed, Oct 1, 2008 at 10:05 AM, Kristof Zelechovski > 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 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 From dhtmlkitchen at gmail.com Wed Oct 1 17:45:35 2008 From: dhtmlkitchen at gmail.com (Garrett Smith) Date: Wed, 1 Oct 2008 17:45:35 -0700 Subject: [whatwg] Placeholder option for text input boxes In-Reply-To: <1BB057AD-D38C-4BEB-8C20-BB3B5D19F6FF@apple.com> References: <95163DE11B4047A28B8D7BF9D57DC8DC@POCZTOWIEC> <47E9A3A7E8FB43179E6082A0F9C37F4B@POCZTOWIEC> <278fd46c0810010955l698fe7b7kc2681d9c262b2f44@mail.gmail.com> <89208CCDE4E44F15B929850E2FF62D64@POCZTOWIEC> <278fd46c0810011027o1e5bcd1do10176a4a9097f450@mail.gmail.com> <1BB057AD-D38C-4BEB-8C20-BB3B5D19F6FF@apple.com> Message-ID: On Wed, Oct 1, 2008 at 5:11 PM, Maciej Stachowiak wrote: > > On Oct 1, 2008, at 10:27 AM, Aaron Boodman wrote: > >> On Wed, Oct 1, 2008 at 10:05 AM, Kristof Zelechovski >> 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 > 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 = "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. CHeckbox-attribute.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 > > From dhtmlkitchen at gmail.com Wed Oct 1 18:02:01 2008 From: dhtmlkitchen at gmail.com (Garrett Smith) Date: Wed, 1 Oct 2008 18:02:01 -0700 Subject: [whatwg] Placeholder option for text input boxes In-Reply-To: References: <47E9A3A7E8FB43179E6082A0F9C37F4B@POCZTOWIEC> <278fd46c0810010955l698fe7b7kc2681d9c262b2f44@mail.gmail.com> <89208CCDE4E44F15B929850E2FF62D64@POCZTOWIEC> <278fd46c0810011027o1e5bcd1do10176a4a9097f450@mail.gmail.com> <1BB057AD-D38C-4BEB-8C20-BB3B5D19F6FF@apple.com> Message-ID: On Wed, Oct 1, 2008 at 5:45 PM, Garrett Smith wrote: > On Wed, Oct 1, 2008 at 5:11 PM, Maciej Stachowiak wrote: >> >> On Oct 1, 2008, at 10:27 AM, Aaron Boodman wrote: >> >>> On Wed, Oct 1, 2008 at 10:05 AM, Kristof Zelechovski >>> wrote: >>>> > > Other INPUT attributes work don't reflect. > (Other INPUT attributes don't reflect.) Please bear with my typos and grammatical errors (mostly caused by editing). > 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: > That's actually a poor comparison: setAttribute('placeholder', 'new') to getAttribute('value'); Doesn't really prove anything. Setting attributes may or may not have the desired side effects depending on the browser (the example below shows this to be true). http://asymptotia.com/wp-images/2008/02/knut_polar_bear_cub.jpg Garrett > > Garrett > >> Regards, >> Maciej >> >> > From whatwg at adambarth.com Wed Oct 1 22:08:05 2008 From: whatwg at adambarth.com (Adam Barth) Date: Wed, 1 Oct 2008 22:08:05 -0700 Subject: [whatwg] native styling for search input boxes In-Reply-To: <94456144-F2D8-4F63-A5A1-23C8021864ED@apple.com> References: <1222802086.21677.26.camel@dell.linuxdev.us.dell.com> <31C060EAB1A84D409A337C9C09AE9906@POCZTOWIEC> <1222846310.25022.6.camel@dell.linuxdev.us.dell.com> <1222881273.25022.21.camel@dell.linuxdev.us.dell.com> <94456144-F2D8-4F63-A5A1-23C8021864ED@apple.com> Message-ID: <7789133a0810012208q6930baf8xc82a252ebac6af37@mail.gmail.com> On Wed, Oct 1, 2008 at 5:09 PM, Maciej Stachowiak wrote: > 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. I think they use OpenSearch metadata for this feature. Adam From giecrilj at stegny.2a.pl Thu Oct 2 01:14:53 2008 From: giecrilj at stegny.2a.pl (=?us-ascii?Q?Kristof_Zelechovski?=) Date: Thu, 2 Oct 2008 10:14:53 +0200 Subject: [whatwg] native styling for search input boxes In-Reply-To: <94456144-F2D8-4F63-A5A1-23C8021864ED@apple.com> References: <48E1D73F.10707@googlemail.com>

<1222802086.21677.26.camel@dell.linuxdev.us.dell.com><31C060EAB1A84D409A337C9C09AE9906@POCZTOWIEC><1222846310.25022.6.camel@dell.linuxdev.us.dell.com><1222881273.25022.21.camel@dell.linuxdev.us.dell.com> <94456144-F2D8-4F63-A5A1-23C8021864ED@apple.com> Message-ID: I hoped to see an example of an actual semantic improvement of introducing INPUT[type=SEARCH]. Maciej described a conceptual improvement for the ideal world; in the real world, the developers will have to use the heuristics anyway because there are search fields in the wild not marked as such and most of them will remain that way of course. Please describe how the potential presence of INPUT[type=SEARCH] will improve the user experience (ignoring presentation) based on the assumption that the present heuristics will be used anyway. Chris -----Original Message----- From: whatwg-bounces at lists.whatwg.org [mailto:whatwg-bounces at lists.whatwg.org] On Behalf Of Maciej Stachowiak Sent: Thursday, October 02, 2008 2:10 AM To: Nils Dagsson Moskopp Cc: whatwg Subject: Re: [whatwg] native styling for search input boxes >> 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. From giecrilj at stegny.2a.pl Thu Oct 2 01:53:41 2008 From: giecrilj at stegny.2a.pl (=?us-ascii?Q?Kristof_Zelechovski?=) Date: Thu, 2 Oct 2008 10:53:41 +0200 Subject: [whatwg] Placeholder option for text input boxes In-Reply-To: References: <95163DE11B4047A28B8D7BF9D57DC8DC@POCZTOWIEC><47E9A3A7E8FB43179E6082A0F9C37F4B@POCZTOWIEC><278fd46c0810010955l698fe7b7kc2681d9c262b2f44@mail.gmail.com><89208CCDE4E44F15B929850E2FF62D64@POCZTOWIEC><278fd46c0810011027o1e5bcd1do10176a4a9097f450@mail.gmail.com><1BB057AD-D38C-4BEB-8C20-BB3B5D19F6FF@apple.com> Message-ID: <58E5478494EC4810933502437C33777D@POCZTOWIEC> 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: whatwg-bounces at lists.whatwg.org [mailto:whatwg-bounces at lists.whatwg.org] 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. CHeckbox-attribute.html

From bhawkeslewis at googlemail.com Thu Oct 2 02:28:57 2008 From: bhawkeslewis at googlemail.com (Benjamin Hawkes-Lewis) Date: Thu, 02 Oct 2008 10:28:57 +0100 Subject: [whatwg] native styling for search input boxes In-Reply-To: References: <48E1D73F.10707@googlemail.com>

<1222802086.21677.26.camel@dell.linuxdev.us.dell.com><31C060EAB1A84D409A337C9C09AE9906@POCZTOWIEC><1222846310.25022.6.camel@dell.linuxdev.us.dell.com><1222881273.25022.21.camel@dell.linuxdev.us.dell.com> <94456144-F2D8-4F63-A5A1-23C8021864ED@apple.com> Message-ID: <48E49459.1020200@googlemail.com> Kristof Zelechovski wrote: > I hoped to see an example of an actual semantic improvement of introducing > INPUT[type=SEARCH]. Maciej described a conceptual improvement for the ideal > world; in the real world, the developers will have to use the heuristics > anyway because there are search fields in the wild not marked as such and > most of them will remain that way of course. If HTML5 assumes user agents should rely on heuristics to detect Search fields, it should specify those heuristics (rather than forcing user-agents to reverse engineer them). Do you have an algorithm you would like to propose? When it triggers a different interface and functionality in popular browsers, explicit markup is unlikely to be accidental and relying on explicit markup is preferable to heuristics alone. Hence the existence of semantic markup (heading elements, microformats, etc.). -- Benjamin Hawkes-Lewis From giecrilj at stegny.2a.pl Thu Oct 2 02:34:02 2008 From: giecrilj at stegny.2a.pl (=?us-ascii?Q?Kristof_Zelechovski?=) Date: Thu, 2 Oct 2008 11:34:02 +0200 Subject: [whatwg] native styling for search input boxes In-Reply-To: <48E49459.1020200@googlemail.com> References: <48E1D73F.10707@googlemail.com>

<1222802086.21677.26.camel@dell.linuxdev.us.dell.com><31C060EAB1A84D409A337C9C09AE9906@POCZTOWIEC><1222846310.25022.6.camel@dell.linuxdev.us.dell.com><1222881273.25022.21.camel@dell.linuxdev.us.dell.com> <94456144-F2D8-4F63-A5A1-23C8021864ED@apple.com> <48E49459.1020200@googlemail.com> Message-ID: <8119A86C80E143E29C1C6EFDB4FA9B78@POCZTOWIEC> This amounts to saying that while it is not clear that Safari will actually benefit from this innovation, other browsers probably can, albeit in a limited way. Good point. Chris -----Original Message----- From: Benjamin Hawkes-Lewis [mailto:bhawkeslewis at googlemail.com] Sent: Thursday, October 02, 2008 11:29 AM To: Kristof Zelechovski Cc: 'Maciej Stachowiak'; 'Nils Dagsson Moskopp'; 'whatwg' Subject: Re: [whatwg] native styling for search input boxes Kristof Zelechovski wrote: > I hoped to see an example of an actual semantic improvement of introducing > INPUT[type=SEARCH]. Maciej described a conceptual improvement for the ideal > world; in the real world, the developers will have to use the heuristics > anyway because there are search fields in the wild not marked as such and > most of them will remain that way of course. If HTML5 assumes user agents should rely on heuristics to detect Search fields, it should specify those heuristics (rather than forcing user-agents to reverse engineer them). Do you have an algorithm you would like to propose? When it triggers a different interface and functionality in popular browsers, explicit markup is unlikely to be accidental and relying on explicit markup is preferable to heuristics alone. Hence the existence of semantic markup (heading elements, microformats, etc.). -- Benjamin Hawkes-Lewis From timeless at gmail.com Thu Oct 2 07:22:19 2008 From: timeless at gmail.com (timeless) Date: Thu, 2 Oct 2008 17:22:19 +0300 Subject: [whatwg] Placeholder option for text input boxes In-Reply-To: <58E5478494EC4810933502437C33777D@POCZTOWIEC> References: <47E9A3A7E8FB43179E6082A0F9C37F4B@POCZTOWIEC> <278fd46c0810010955l698fe7b7kc2681d9c262b2f44@mail.gmail.com> <89208CCDE4E44F15B929850E2FF62D64@POCZTOWIEC> <278fd46c0810011027o1e5bcd1do10176a4a9097f450@mail.gmail.com> <1BB057AD-D38C-4BEB-8C20-BB3B5D19F6FF@apple.com> <58E5478494EC4810933502437C33777D@POCZTOWIEC> Message-ID: <26b395e60810020722l711f131fwa25e3f9b0488cdc6@mail.gmail.com> Is vbscript defined to have the same dom bindings as jscript? On 10/2/08, Kristof Zelechovski 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: whatwg-bounces at lists.whatwg.org > [mailto:whatwg-bounces at lists.whatwg.org] 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. > > > > > CHeckbox-attribute.html > > > >

> 
>

> > > > > -- Sent from Gmail for mobile | mobile.google.com From giecrilj at stegny.2a.pl Thu Oct 2 09:39:17 2008 From: giecrilj at stegny.2a.pl (=?us-ascii?Q?Kristof_Zelechovski?=) Date: Thu, 2 Oct 2008 18:39:17 +0200 Subject: [whatwg] Placeholder option for text input boxes In-Reply-To: <26b395e60810020722l711f131fwa25e3f9b0488cdc6@mail.gmail.com> References: <47E9A3A7E8FB43179E6082A0F9C37F4B@POCZTOWIEC> <278fd46c0810010955l698fe7b7kc2681d9c262b2f44@mail.gmail.com> <89208CCDE4E44F15B929850E2FF62D64@POCZTOWIEC> <278fd46c0810011027o1e5bcd1do10176a4a9097f450@mail.gmail.com> <1BB057AD-D38C-4BEB-8C20-BB3B5D19F6FF@apple.com> <58E5478494EC4810933502437C33777D@POCZTOWIEC> <26b395e60810020722l711f131fwa25e3f9b0488cdc6@mail.gmail.com> Message-ID: 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: timeless.bmo1 at gmail.com [mailto:timeless.bmo1 at gmail.com] On Behalf Of timeless Sent: Thursday, October 02, 2008 4:22 PM To: giecrilj at stegny.2a.pl; whatwg at whatwg.org 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 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 > From mjs at apple.com Thu Oct 2 12:07:14 2008 From: mjs at apple.com (Maciej Stachowiak) Date: Thu, 02 Oct 2008 12:07:14 -0700 Subject: [whatwg] native styling for search input boxes In-Reply-To: References: <48E1D73F.10707@googlemail.com>

<1222802086.21677.26.camel@dell.linuxdev.us.dell.com> <31C060EAB1A84D409A337C9C09AE9906@POCZTOWIEC> <1222846310.25022.6.camel@dell.linuxdev.us.dell.com> <1222881273.25022.21.camel@dell.linuxdev.us.dell.com> <94456144-F2D8-4F63-A5A1-23C8021864ED@apple.com> Message-ID: On Oct 2, 2008, at 1:14 AM, Kristof Zelechovski wrote: > I hoped to see an example of an actual semantic improvement of > introducing > INPUT[type=SEARCH]. Maciej described a conceptual improvement for > the ideal > world; in the real world, the developers will have to use the > heuristics > anyway because there are search fields in the wild not marked as > such and > most of them will remain that way of course. Please describe how the > potential presence of INPUT[type=SEARCH] will improve the user > experience > (ignoring presentation) based on the assumption that the present > heuristics > will be used anyway. According to the Chrome developer who spoke up here, Chrome currently uses OpenSearch metadata. If many search fields used , then user agents could identify them without the need for OpenSearch metadata. I would imagine many smaller sites with a site-scope search box would not have such metadata but could easily adopt . Regards, Maciej > > Chris > > -----Original Message----- > From: whatwg-bounces at lists.whatwg.org > [mailto:whatwg-bounces at lists.whatwg.org] On Behalf Of Maciej > Stachowiak > Sent: Thursday, October 02, 2008 2:10 AM > To: Nils Dagsson Moskopp > Cc: whatwg > Subject: Re: [whatwg] native styling for search input boxes > > >>> 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. > > > From Brenton.Strine at citrix.com Thu Oct 2 16:27:20 2008 From: Brenton.Strine at citrix.com (Brenton Strine) Date: Thu, 2 Oct 2008 16:27:20 -0700 Subject: [whatwg] Placeholder option for text input boxes In-Reply-To: References: <48E1D73F.10707@googlemail.com>

Message-ID: On Tue, Sep 30, 2008 at 11:36 AM, Andy Lyttle wrote: [snip] > 4) (moving label textual content into 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. Brenton Strine From jackalmage at gmail.com Thu Oct 2 16:34:31 2008 From: jackalmage at gmail.com (Tab Atkins Jr.) Date: Thu, 2 Oct 2008 18:34:31 -0500 Subject: [whatwg] Placeholder option for text input boxes In-Reply-To: References: <48E1D73F.10707@googlemail.com>

Message-ID: On Thu, Oct 2, 2008 at 6:27 PM, Brenton Strine wrote: > On Tue, Sep 30, 2008 at 11:36 AM, Andy Lyttle wrote: > [snip] > > 4) (moving label textual content into 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From russell.leggett at gmail.com Fri Oct 3 07:06:11 2008 From: russell.leggett at gmail.com (Russell Leggett) Date: Fri, 3 Oct 2008 10:06:11 -0400 Subject: [whatwg] Placeholder option for text input boxes In-Reply-To: References: <48E1D73F.10707@googlemail.com>

Message-ID: <680cacd10810030706hf1eb55i15358e0ecc89224b@mail.gmail.com> 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 spec : > More than one LABEL may > be associated with the same control by creating multiple references via the > 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. wrote: > On Thu, Oct 2, 2008 at 6:27 PM, Brenton Strine wrote: > >> On Tue, Sep 30, 2008 at 11:36 AM, Andy Lyttle wrote: >> [snip] >> > 4) (moving label textual content into 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dhtmlkitchen at gmail.com Fri Oct 3 07:32:11 2008 From: dhtmlkitchen at gmail.com (Garrett Smith) Date: Fri, 3 Oct 2008 07:32:11 -0700 Subject: [whatwg] Placeholder option for text input boxes In-Reply-To: References: <48E1D73F.10707@googlemail.com>

Message-ID: On Thu, Oct 2, 2008 at 4:34 PM, Tab Atkins Jr. wrote: > On Thu, Oct 2, 2008 at 6:27 PM, Brenton Strine > wrote: >> >> On Tue, Sep 30, 2008 at 11:36 AM, Andy Lyttle 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 > From jackalmage at gmail.com Fri Oct 3 08:05:01 2008 From: jackalmage at gmail.com (Tab Atkins Jr.) Date: Fri, 3 Oct 2008 10:05:01 -0500 Subject: [whatwg] Placeholder option for text input boxes In-Reply-To: References: <48E1D73F.10707@googlemail.com>

Message-ID: On Fri, Oct 3, 2008 at 9:32 AM, Garrett Smith wrote: > On Thu, Oct 2, 2008 at 4:34 PM, Tab Atkins Jr. > wrote: > > On Thu, Oct 2, 2008 at 6:27 PM, Brenton Strine < > Brenton.Strine at citrix.com> > > wrote: > >> > >> On Tue, Sep 30, 2008 at 11:36 AM, Andy Lyttle > 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From dhtmlkitchen at gmail.com Fri Oct 3 08:37:42 2008 From: dhtmlkitchen at gmail.com (Garrett Smith) Date: Fri, 3 Oct 2008 08:37:42 -0700 Subject: [whatwg] Placeholder option for text input boxes In-Reply-To: References: <48E1D73F.10707@googlemail.com>

Message-ID: On Fri, Oct 3, 2008 at 8:05 AM, Tab Atkins Jr.