Re: [whatwg] salvaging work while navigating away from a web app -- onunload="confirm('save before quitting?')
On Sun, Dec 14, 2008 at 10:30 PM, Martin Atkins wrote: An alternative from Opera: The confirm dialog is whole-browser-modal, but it has a checkbox captioned "Stop executing scripts on this page" which allows you to forcefully kill off a script that's repeatedly displaying dialogs as in the example that prompted this message. neither of these bother me. and i'm certainly in favor of adding a stop option to the dialogs for firefox. it's definitely managable. today some of our dialogs get an extra 'debug script' button under certain conditions. The only concern I have is that someone from UE/UI will complain that such a button will confuse people, as it becomes trivial for a user to break any web site and not necessarily understand that what they did was the cause. However, that's a bridge I'm willing to try to cross. I think enabling the button only after multiple repeated dialogs would be a reasonable compromise, perhaps with an "Are you sure?" confirmation. -- Andy Lyttle wha...@phroggy.com
Re: [whatwg] Add 'type' attribute to
On Oct 31, 2008, at 7:57 PM, Ian Hickson wrote: That's what the "class" attribute is for. What's the difference then between and then? I mean, does the element provide anything that with an appropriate class wouldn't? A default style when there's no CSS support, support in accessibility tools, the ability for search engines to understand what's going on, easier round-tripping between editors, simpler rules in CSS and other selector-like environments, etc. The usual benefits of semantics. Are we talking about assigning particular meanings to certain class names? Or are we saying "this is for semantic purposes, but do whatever you want with it, because nobody will see it except UAs that are applying CSS rules and users who view the HTML source code"? If the former, it's a terrible idea because developers have been working with the assumption that there are no reserved keywords so there are bound to be conflicts. If the latter... it doesn't really mean anything, does it? By the way, I gave a ridiculous example earlier of why defining class="footnote" to have semantic meaning would be bad; I got really bored and fleshed out that example: http://phroggy.com/musicalfeet/ -- Andy Lyttle [EMAIL PROTECTED]
Re: [whatwg] Add 'type' attribute to
On Oct 31, 2008, at 11:06 AM, Pentasis wrote: I would never opt for using "class" for anything other than CSS styling. The reason for this being that I feel that neither "id" nor "class" should contain keywords, but only author defined words. For me a "type" or "role" attribute would be like an "id" or "class" only it would contain keywords and be not style-related but content related. Also, because authors have assumed that they had full reign over id and class names, there are bound to be conflicts if we now define certain keywords to have semantic meaning (which could correspond to presentational behavior). Breaking backwards compatibility when we add new features is certainly undesirable. Musical feet! La -- Andy Lyttle [EMAIL PROTECTED]
Re: [whatwg] Web forms 2, input type suggestions (Michael A. Puls II)
On Oct 30, 2008, at 2:19 PM, Tab Atkins Jr. wrote: I have no problem with . type=address would be very confusing (see what people think about the element today!), and worse, can legitimately be thought to be for inputting physical addresses. No one will ever think that type=email is for composing an email - it's a single piece of information (composing an email requires several) and it's in the input family which is for small pieces of information (an entire email is much larger than the natural size of an ). In the multiple case, I'm fine with either [type="emails"] or [type="email"][multiple="multiple"]. Me too. Are there any other situations where adding a "multiple" attribute could work similarly, other than ? -- Andy Lyttle [EMAIL PROTECTED]
Re: [whatwg] [WF2]
On Oct 24, 2008, at 8:23 AM, Tab Atkins Jr. wrote: So, pulling it all together, my proposal for a hinting ability on is thus: can have a @hint attribute, which takes a text value. If there is no , then this hint is initially displayed in the 's collapsed state. As soon as an option is selected, though (or if an had @selected initially), the hint disappears and the selected 's text is instead displayed in the 's collapsed state. When @hint is supplied, a conforming UA will not allow the form to be submitted until an option is selected (again, an with @selected specified counts here), indicating in some way that a value in the must be chosen (the exact method UAs use to indicate this to users is left undefined, but should be similar to how the UA alerts a user that an with @required is empty and must be filled). For fallback, authors should provide an empty (or one containing only whitespace) with an appropriate default @value as the 's first child. If s are used, this should come before them. Conforming UAs will not display this . In legacy UAs, this will cause the to initially display as blank in the collapsed state, and will submit the author- supplied default value as the value of the control if the user does not make a proper selection. This sound good? Almost! The only problem is, I might want the text of my "blank" option to be something other than whitespace, for example "(none)", "None of the above" (it could be the last option instead of the first), etc. Remember that in a case where the initial state is some other selected, we want the user to be able to choose the "blank" option, and "(none)" is much clearer in the expanded menu than whitespace, which may not be recognized as being a selectable choice. Reserving value="" to indicate which option is the "blank" one would solve this problem (while presenting more). :-) -- Andy Lyttle [EMAIL PROTECTED]
Re: [whatwg] [WF2]
On Oct 23, 2008, at 12:19 PM, Tab Atkins Jr. wrote: Ultimately the display of the hint is, and should be, up to the UA, so that non-full-featured devices can display things in a maximally helpful way to the user. Within the context of a standard browser on an ordinary computer, though, the correct display seems relatively clear. When the select is collapsed, the hint should show until the user selects something. After the user selects something, the hint will never again display in the collapsed state. I'm not sure if it's necessary for the hint to display in the expanded state. If it is, though, then it should always be the first item in the list, and it should be nonselectable, similar to how column groups display currently. 1) If the user clicks to open the menu, then clicks away or presses Esc without making a selection, does that count as a selection for purposes of making the placeholder not appear again? 2) If the user never selects something, they'll never see anything but the placeholder. That means they won't see the text associated with whatever option is selected by default. In many cases, the default option will be some sort of blank* value to indicate that the user has not made a selection; the current practice serves both purposes at the same time (having a blank value to indicate no selection, and setting the text of that option to a placeholder/ hint). A placeholder option would replace one of these purposes, but not both; authors would still need to have a default option that indicates non-selection. * By blank, I mean something unique that the script that will process the form knows means a non-selection. I normally use value=""> for this purpose, but it could be any value the author devises. In other cases, there must always be something selected; a non- selection shouldn't be possible. An example might be the "country" field on an address form, which defaults to the most likely choice (e.g. United States for sites that expect most of their audience to be American). The user shouldn't be permitted to select a non- value. How should the placeholder text be displayed? It seems clear to me that it should NOT appear on the collapsed menu at all, but should appear at the top of the expanded menu. There are other cases where having a blank option is appropriate, but the default may be something else. The user can explicitly change the selection to a blank option. How should the placeholder behave in each of these cases? I realize these are display issues rather than semantic issues, but I think it's appropriate to discuss them. -- Andy Lyttle [EMAIL PROTECTED]
Re: [whatwg] [WF2]
On Oct 23, 2008, at 5:31 AM, Ian Hickson wrote: This use case is definitely something we want to consider, but I don't think it's about required="". It's about an option in the being a non-option (as it were). by definition can't have nothing selected. That's what it means. The issue about a placeholder value is listed as an open issue in the spec, and will probably be addressed at some future point. This is an interesting point I hadn't considered. It's *very* common to use the first in a as a non-choice such as "Choose one...", setting the value to something unique (often "" but it could be something else if "" is a valid choice) so it can be treated as a non-selection. This serves *precisely* the same purpose as the placeholder attribute on text input fields, which I had assumed wouldn't be valid for . I suggest that the placeholder attribute should indeed apply to , and the behavior should be similar to the current practice of using the first . In particular, the placeholder should appear both on the collapsed menu, and at the top of the open menu, although it should not be selectable. But the question is, when the menu is collapsed, when should the placeholder be displayed instead of one of the options? Any time the value is ""? Only until the user selects something? Somebody smarter than me, please figure this out. :-) -- Andy Lyttle [EMAIL PROTECTED]
Re: [whatwg] fixing the authentication problem
This is similar to the SSH model; the first time you connect, you're expected to manually check by some means that you're connecting to the right server. On subsequent connections, you won't be bothered unless the key changes. I'll concede that in most cases no-one actually verifies the key in the first connection case, but at least this requires an attacker to intercept your *first* connection from a particular client, rather than just any connection. I may not verify the key manually, but if my first connection to a particular server is made over a local network that I trust to be secure, then I can trust the key my SSH client has saved. This is not at all an uncommon situation: I set up a new server, I plug my laptop into the local LAN, I log in to make sure everything works. Later, when I'm sitting in a restaurant waiting for lunch and my laptop is connected to an untrusted public wifi network, I know the key my SSH client saved is legitimate. This wouldn't be common with HTTP. -- Andy Lyttle [EMAIL PROTECTED]
Re: [whatwg] fixing the authentication problem
4. The need for a dedicated IP address, instead of using name-based virtual hosts. That and #1 are the reasons I don't use it more. -- Andy Lyttle [EMAIL PROTECTED] On Oct 21, 2008, at 7:48 AM, Aaron Swartz wrote: Some major web services redirect the user to an SSL server for the login transaction, but SSL is too expensive for the vast majority of services. The issue is not SSL being expensive: the only expensive part is There are three costs to SSL: 1. Purchasing a signed cert. 2. Configuring the web server. 3. The CPU time necessary to do the encryption. 1 could be fixed by less paranoid UAs, 2 could be fixed with better software and SNI, and 3 could be fixed by better hardware. But, realistically, I don't see any of these things happening. What's the actual difference between this and https? Both mechanisms are using public-key encryption to protect the communications; the The difference is that this would work practically. Server authors typically can't configure, but they typically can install an encryption library. Support will get built into web applications and web application frameworks (disclosure: I'm the author of a web application framework) and the Web will be more secure.
Re: [whatwg] input type=hidden outside phrasing content
That seems sort of weird though. You're fine with putting the within the , but you'd prefer *not* to do the same with the ? It seems much more reasonable to just put it in the exact same place. At any rate, it certainly doesn't seem like a compelling reason to change the content model of . Only because within the I already had the value expressed as plain text. I ended up with something like value="Foo">Foo (except it was uglier). I can't think of a specific example, but I know there's been something similar I wanted to do in the past that was similar that turned out uglier than this. I'm not saying it's a compelling reason, just that wanting to do it isn't completely insane. :-) -- Andy Lyttle [EMAIL PROTECTED] On Oct 16, 2008, at 3:07 PM, Tab Atkins Jr. wrote: On Thu, Oct 16, 2008 at 4:59 PM, Andy Lyttle <[EMAIL PROTECTED]> wrote: This is something I wanted to do recently. I was building HTML in a Perl script, adding table rows in a loop, and I wanted some rows to contain text field with user-editable value, while for other rows I wanted the value to be displayed but not editable (and I didn't want to use a disabled text input, I wanted the value displayed as plain text and use a hidden input with the value preset). I believe I wound up putting the inside the , which worked well enough but if putting it directly inside the were valid I probably would have done that. That seems sort of weird though. You're fine with putting the within the , but you'd prefer *not* to do the same with the ? It seems much more reasonable to just put it in the exact same place. At any rate, it certainly doesn't seem like a compelling reason to change the content model of . ~TJ
Re: [whatwg] Color attributes
"While the first item's length in segments is greater than 2 and the first character in each item in segments is a U+0030 DIGIT ZERO character, remove the first character from each item in segments." Does this mean, if the length of the first item in segments is greater than 2 then loop through each item in segments, and if the first character is 0 then remove it? Or does it mean, if the length of the first item in segments is greater than 2 and the first character of every item in segments is 0, then loop through each item and delete the first character, but if the first character of any item is not 0 then leave the whole thing alone? I'm assuming you meant #1, but your wording isn't perfectly clear. Has it occurred to you that while your algorithm makes the string "foo" return an error, the string "l33tsp34k" is converted to a dark purple? -- Andy Lyttle [EMAIL PROTECTED] On Oct 16, 2008, at 4:46 AM, Simon Pieters wrote: On Thu, 05 Jul 2007 23:43:55 +0200, Simon Pieters <[EMAIL PROTECTED]> wrote: Color attributes in HTML have special processing. It seems that some pages use three-digit notation and expect it to work as in CSS. I've made the algorithm do that and I've drafted up a spec for this: http://simon.html5.org/specs/html-color-attributes -- Simon Pieters Opera Software
Re: [whatwg] input type=hidden outside phrasing content
This is something I wanted to do recently. I was building HTML in a Perl script, adding table rows in a loop, and I wanted some rows to contain text field with user-editable value, while for other rows I wanted the value to be displayed but not editable (and I didn't want to use a disabled text input, I wanted the value displayed as plain text and use a hidden input with the value preset). I believe I wound up putting the inside the , which worked well enough but if putting it directly inside the were valid I probably would have done that. -- Andy Lyttle [EMAIL PROTECTED]
Re: [whatwg] video tag : loop for ever
On Oct 15, 2008, at 8:38 AM, João Eiras wrote: Why not just assuming that playcount="0" means loops forever ? This was exactly my thought. If playcount="5" causes the video to be played 5 times, what should the result of each of these be? playcount="1" playcount="0" playcount="-5" playcount="foobar" Is there any possible usefulness whatsoever in making playcount="0" not play the video at all? If not, I don't see a good reason not to use that to mean infinite looping. Either that, or some keyword, but I don't know what it should be. "infinite" and "forever" come to mind. -- Andy Lyttle [EMAIL PROTECTED]
Re: [whatwg] Video : Slow motion, fast forward effects
Me too. As I understand it, the intention was that because some players can't support it, all players should be forbidden to do it because web developers might somehow come to rely on it not working. I'm having trouble imagining how that could be a significant problem, and mandating that behavior in the spec seems very weird. A note in the spec explaining that you should mute it if you really want it to not play sounds like a much better way to go. Is there any situation where muting it like that won't elegantly solve this problem? -- Andy Lyttle [EMAIL PROTECTED] On Oct 14, 2008, at 11:28 AM, Peter Kasting wrote: On Tue, Oct 14, 2008 at 8:00 AM, Eric Carlson <[EMAIL PROTECTED]> wrote: Some media formats and/or engines may not support reverse playback, but I think it is a mistake for the spec to mandate this behavior. Why is reverse playback different from other situations described in the spec where different UAs/ media formats will result in different behavior, eg. pitch adjusted audio, negotiation with a server to achieve the appropriate playback rate, etc? I think the current sentence that talks about audio playback rate: When the playbackRate is so low or so high that the user agent cannot play audio usefully, the corresponding audio must not play. could be modified to include reverse playback as well: When the playbackRate is such that the user agent cannot play audio usefully (eg. too low, too high, negative when the format or engine does not support reverse playback), the corresponding audio must not play. Agree wholeheartedly. Mandating silence during reverse playback seems bizarre in the abstract, unnecessary if authors have a way to mute, and potentially detrimental to future applications which may _want_ to be able to do this in a controlled fashion (e.g. a virtual turntable application). PK
Re: [whatwg] Placeholder option for text input boxes
On Oct 4, 2008, at 3:38 PM, timeless wrote:
On 10/3/08, Adrian Sutton <[EMAIL PROTECTED]> wrote:
Placeholder ... aids usability
having recently fought with some javascript which tried to enhance my
ability to enter text ('crash' in a keyword chooser using nokia's
webkit based browser on my phone), I'd like to remind people that
someone's "usability" aid is someone else's nightmare. the problem
there didn't need solving as the browsers we have either support
remembering text-input or have keyboard support or are so slow that
the chooser hangs them
i use quite a few browsers where javascript is disabled and in many of
them, clearing a text field is extremely painful (especially the phone
cases).
The existence of a "placeholder" attribute in HTML should discourage
web developers from using crazy Javascript hacks that don't work
correctly on a cell phone. In particular, it means NOT "faking it"
by setting the value of the field to an obnoxious string that doesn't
get cleared. Browser developers such as Nokia can display
placeholder text in whatever way makes the most sense on their
platform, without using JavaScript at all.
Most mobile browsers I've used switch to a text input dialog as soon
as the control is focussed. I would display the placeholder on the
web page the same way any other browser would, but not display it on
the text input dialog. Someone else might choose to go ahead and
display it on the text input dialog as well (above the input field),
with the placeholder text not disappearing while text is being entered.
my devices aren't powerful enough to support true accessibility
features, but in some ways they want them- especially to turn off all
of these glitzy web "features" which significantly impede my ability
to get work done.
sometimes enabling a designer to do something is the wrong decision.
google and skype both can convert all numbers they see into very
annoying and generally incorrect tel: links. skype's toolbar can
thankfully be disabled, however the gmail mobile one can't be, which
means I'm stuck with unusable (and unreadable) content.
Enabling a designer to use placeholders is a moot point; they're
already doing it, in a non-standard buggy way that breaks on your
phone. We want to give them semantic markup that will behave the way
they want in their browser, while still being perfectly usable on
your phone so they can quit using annoying hacks. Placeholder
shouldn't be "glitzy" and absolutely should never impede your ability
to get work done; if it does, somebody screwed up their implementation.
placeholders are interesting, but will the resources required to
support them be better than telling designers just to make their
label's clearer?
I don't expect the required resources to be significant, but I'm not
a browser developer...
for my devices, I'm going to need a way to disable them and something
tells me that even if we were to standardize on a way to present
placeholders, I'll still be unable to suppress many implemented in
javascript/css.
This is true. Adding placeholder to HTML doesn't mean web developers
will immediately drop their JS/CSS hacks, because existing browsers
don't support placeholder. But over time, as everybody upgrades
their browsers and developers stop caring about the people still
using older browsers, the problem should slowly fade away.
- this complaint was composed using an n800 because symbian brutally
killed my gmail client and the web browser.
My N75 won't load more than a few pages before the browser stops
working entirely and I have to reboot the phone. Sucktacular.
--
Andy Lyttle
[EMAIL PROTECTED]
Re: [whatwg] Placeholder option for text input boxes
On Oct 3, 2008, at 4:35 PM, Tab Atkins Jr. wrote: Man, I could *really* see the "hint" function being viable and quite useful. It offers up a completely new-and-useful semantic, and there's no particular place it should already go. I'd accept this as a new attribute without reservation if it was renamed @hint, so it's absolutely clear what the semantic for it is. The only reason to use placeholder instead of hint is that Apple already implemented placeholder. Documentation should explain that placeholder is to be used for hints, not for labels (and people can then ignore the documentation and use it for labels anyway, but at least we tried). -- Andy Lyttle [EMAIL PROTECTED]
Re: [whatwg] Placeholder option for text input boxes
On Oct 3, 2008, at 1:31 PM, Adrian Sutton wrote: On 03/10/08 20:56, "Nils Dagsson Moskopp" <[EMAIL PROTECTED]> wrote: Am Freitag, den 03.10.2008, 20:41 +0100 schrieb Adrian Sutton: Date: Wouldn't three comboboxes be more appropriate ? While that's a common solution it's a terribly inefficient and frustrating user interface. Besides, the specific examples aren't as important as the idea that placeholder is an excellent way to provide suggestions and thus distinct from the label of the field. Exactly, that was my point as well. People have been saying that the only places they've noticed a placeholder being used, it was performing the job of a label, but if it were easy to use (a simple attribute instead of lots of JavaScript hacking), I think it would be used appropriately as a hint more often. Yes, it would also be abused, but what else is new? If we provide a good way to do it right, designers who care about doing it right will do it right, and the ones who don't will continue to do whatever they want. Obviously kicks ass for this particular example. -- Andy Lyttle [EMAIL PROTECTED]
Re: [whatwg] Placeholder option for text input boxes
On Oct 3, 2008, at 10:15 AM, Jonas Sicking wrote: Russell Leggett wrote: I've wrestled with this because its something that our designer has wanted to use all over the place for an application I'm working on. It turns out to be a usability nightmare if not used sparingly. Why was it a uasability nightmare? Would it still have been a useability nightmare if there had existed a semantic 'placeholder' attribute? Or was it because they really should have been using labels, instead of trying to shoehorn all the labels into placeholders that disappear on focus so as soon as you click you can't see what you're supposed to be doing? -- Andy Lyttle [EMAIL PROTECTED]
Re: [whatwg] Safari-compatible
On Sep 30, 2008, at 2:55 PM, Christoph Päper wrote: 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. 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; binoculars aren't a bad choice (although I think you're wrong about them being more common than a magnifying glass these days). The key is that the browser gives some sort of non-text indication to the user about the purpose of the field, in a platform-appropriate way. -- Andy Lyttle [EMAIL PROTECTED]
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
Pros/cons for a |placeholder| property and attribute on TEXTAREA? As I understand it, it was sort of an accident that Safari supports placeholder on anything other than search fields, but there's no reason it shouldn't apply to all text input fields including textarea. I've just filed https://bugs.webkit.org/show_bug.cgi?id=21248 -- Andy Lyttle [EMAIL PROTECTED]
Re: [whatwg] Safari-compatible
On Sep 30, 2008, at 10:23 AM, Kristof Zelechovski wrote: I am not against INPUT[type=search]; I am against INPUT[results=10] because I cannot see how it can be reasonably preset. Yeah, that's weird. I think if I designed it myself, I would have made the presence of autosave (instead of results) trigger the magnifying glass icon, used a sensible default for the number of items in the search history (maybe 10 or 20), used something like historylength to override it, and make setting historylength=0 disable the menu (leaving the icon). Something like that. But that's not how Apple did it, and we should be compatible with them. Is this control for simple search only or is it designed to be used in an advanced search interface? Should it be unique within a form? Excellent question! I imagine it should be unique within a form. Whether it's appropriate for an advanced search interface would depend on the interface; if there's one input that's an obvious choice for type="search" then go ahead and use it, otherwise it might be better to stick with type="text". Hopefully someone more qualified than I can provide a better answer. -- Andy Lyttle [EMAIL PROTECTED]
Re: [whatwg] Placeholder option for text input boxes
On Sep 30, 2008, at 10:54 AM, Tab Atkins Jr. wrote: Eh, I'll still complain. ^_^ While all of your labels *would* be appropriate by themselves, the fact that you have to clarify them means they're not accurate enough for your purposes. Hey, I never said this was an example of good design - it's just an example of using labels for something that shouldn't be rendered as a placeholder, while also using placeholders. One must also consider the needs of people who are using browsers without the ability to render this placeholder text. They'll put "long" in hair, "two" in eyes, and "yes" in nose because they can't see the placeholder and are using their keyboard to navigate through your form (and thus won't see the tooltips either). Hopefully the site will designed well enough that the form is usable without the placeholder text or tooltips. For example, there could be instructions outside of the form that explain what is expected, with the placeholder serving as a subtle reminder to improve usability. As for accessibility, the goal is to mark it semantically so user agents have the opportunity to render it however is appropriate for their users, instead of the current JavaScript hacks that force a particular implementation. Safari is (AFAIK) the only user agent that currently implements placeholder; there's no reason to assume non-graphical user agents won't implement it in the same timeframe that other graphical user agents do. Of course, the aesthetics of splitting the description between the and the placeholder text can't always be denied. Semantically, though, you're still using your s as headers in this situation, and then providing the actual labels as placeholder text, and it would *still* be best semantically to either mark it up explicitly as such (move "Hair:"/"Nose:"/etc to a or and then ing the fields with "Color:", "Shape", etc) or collapse the hierarchy and combine ( "Hair:" becomes "Hair color:", etc.). Legend is supposed to label a fieldset, not an individual field. Facial Features Eyes: Nose: Birth Information Date of Birth: Place of Birth: Am I being anal and a little contrived about semantics to support my point? Of course, but that doesn't make my point invalid. ^_^ After all, what if you wanted hair length as well as color? You'd be forced to move to one of the two solutions - either promoting "Hair" to a full / in the and using "Color:" and "Length" as s or collapsing the label/placeholder dichotomy with "Hair color" and "Hair length" both as s or both as placeholders. Of course! If I wanted both hair color and hair length, it would be inappropriate to label both of them "Hair", and if I labeled them "Hair Color" and "Hair Length", then I wouldn't use "Color" as a placeholder (although I might use "Inches"). -- Andy Lyttle [EMAIL PROTECTED]
Re: [whatwg] Placeholder option for text input boxes
On Sep 30, 2008, at 7:00 AM, Tab Atkins Jr. wrote: Hm. I have a problem with your example. "Get local weather forecast" isn't a semantic for the field - it doesn't describe what the field is for. It describes what the *form* is for, and so should be a or . "City, State" actually describes the use of the itself, and should be the label. Hmm, good call. Let's see if I can do better: Hair: Eyes: Nose: Place of Birth: title="Enter the city and state where you were born"> This shows how label AND placeholder AND title could be used for three different purposes. If I were designing the spec from scratch, I might have chosen "tooltip" and "hint" instead of "title" and "placeholder" respectively, but we have to consider existing implementations. -- Andy Lyttle [EMAIL PROTECTED]
Re: [whatwg] Safari-compatible
On Sep 30, 2008, at 7:40 AM, Nils Dagsson Moskopp wrote: I assume that this should be based on the search elements ID attribute, am I right ? Because common UA behaviour already is to cache entries (based on ID) ... so what unsolved problem is solved there ? If I have a form on my site, using a particular autosave string for a search field, you can create a form on your site that submits to the same CGI URL, with a search field that uses the same autosave string, and browsers will know that they should share the search history between both forms. This is not a security problem, because the history list is not accessible to you (or me). I don't see this feature getting a lot of use, but Apple has already implemented it, and I don't see a compelling reason not to support it. And who knows, if it's supported, maybe someone will think of some clever use for it that I haven't thought of, that couldn't have been done well without this feature. -- Andy Lyttle [EMAIL PROTECTED]
Re: [whatwg] Safari-compatible
On Sep 30, 2008, at 7:18 AM, Kristof Zelechovski wrote: How can the Web designer know how many recent search terms the user would like to keep handy at the search box? The same way the web designer knows anything else: taking an educated guess at what would be most appropriate for their users. Personally, I would have done it a little differently and called this property something other than "results", but Apple has already done it, and there is value in staying compatible with them. What if autosave strings clash, or get deliberately stepped upon? You can avoid clashing by using reverse-FQDN notation, e.g. autosave="com.phroggy.weblog.search", or using your company name or other trademark. It is OK for them to be deliberately stepped upon - this is actually a design feature. If you want to make a search field on your site that searches my site (submitting to the same CGI that my form submits to), you can specify the same autosave string that I use, and search history will be shared between both forms. There is no security problem, because the search history list is not accessible to you (or me) unless the user explicitly chooses an item from it (which you can't distinguish from pasting in a string from elsewhere). I think it is a user preference + browser QoI and Web sites should not try to outsmart it. The whole point of this is to provide sensible markup that the browser can use to figure out the best way to handle it. Browsers aren't obligated to handle search history at all if the user doesn't want them to. Using gives users MORE choice about how the browser should behave, by providing more information about what the web designer was trying to do, instead of using CSS and JavaScript hacks to implement a specific behavior that may not be desirable to some users. Marking a box as a search box is already there (ISINDEX, deprecated). Nobody uses that, and it's not a form element. We could resurrect it, but I don't see a compelling reason to do so. -- Andy Lyttle [EMAIL PROTECTED]
Re: [whatwg] Placeholder option for text input boxes
On Sep 30, 2008, at 7:57 AM, Garrett Smith wrote: If and until user enters text, the "alternate" text is displayed. The confusing part is that successfully rendered inputs would be rendered and still use the alt. The good part is that it would be (or should be) accessible for screen readers. But alt here as you're describing it doesn't mean the same thing as alt anywhere else. On an image, alt text says "this means the same thing as what's supposed to be displayed." A placeholder does NOT mean the same thing as whatever the user is going to enter. On the bright side, doing what you suggest shouldn't break anything because I'm sure nobody's using it. However, I don't think that just because we have an existing property defined that's used on other tags with a different meaning, we should reuse that property for this meaning instead of defining a new property. -- Andy Lyttle [EMAIL PROTECTED]
Re: [whatwg] Placeholder option for text input boxes
On Sep 30, 2008, at 8:33 AM, Nils Dagsson Moskopp wrote: No, I meant to abolish the placeholder attribute alltogether and render the title attribute as greyed-sut inside the search box instead, because * semantically, the title attribute conveys the same information. * it is already there in many pages. Except that: 1) the title attribute doesn't behave this way on any other element 2) there's no reason it shouldn't be possible to have both a placeholder AND a tooltip 3) anybody who is currently using the title attribute doesn't expect it to be displayed as a placeholder, so we would break things for them (especially if their title string is too long to fit inside a small field) -- Andy Lyttle [EMAIL PROTECTED]
[whatwg] Safari-compatible
I would like Apple's adopted as an official standard, maintaining Safari compatibility. Attributes are: onsearch="foo();" - JavaScript function called when the user initiates a search incremental - if present, onsearch fires on every keypress, and on clicking the cancel button; otherwise onsearch fires when pressing Enter results - if present, shows a little magnifying glass icon, which helps to visually identify the field as a search box results=10 - the magnifying glass functions as a drop-down menu containing a history of the last (whatever number) search terms autosave="foo" - define a unique name to identify the search history (so the same history may be shared across multiple search boxes, even across different domains) All other attributes of are also supported, including placeholder. Apple's implementation adds a cancel (x) button which appears whenever text has been typed into the box; clicking the cancel button clears the text without removing focus. They also use rounded corners to make search boxes visually distinct from plain text boxes. Web sites are already implementing some of this functionality through JavaScript, CSS and graphics. Examples of Apple's visual appearance (rounded corners and magnifying glass): http://www.apple.com/ http://www.filemaker.com/ http://www.britannica.com/ (but doesn't hide the cancel button when value="") Other examples of search fields with a variety of non-square corners: http://www.cnet.com/ http://www.myspace.com/ http://wordpress.com/ http://www.target.com/ http://www.lenovo.com/us/en/index.html Examples of incremental search functionality using AJAX: http://www.apple.com/ http://www.adobe.com/ At first glance it looks like onsearch (when combined with incremental) is identical to oninput, but onsearch fires after a slight delay, so that if the user rapidly types multiple characters, the search doesn't begin until after a sufficient pause in typing. For AJAX queries (or CPU-intensive client-side processing), this behavior is much better than using oninput, which fires for every single keystroke. Of course the behavior of onsearch could be emulated through JavaScript, but having onsearch eliminates the need to reinvent that wheel. I really like having a little magnifying glass icon that I don't have to draw myself (or steal from somewhere) and then use crazy CSS tricks to get it to look like it's inside the search box. The implementation can be platform-specific of course; for example on Windows the magnifying glass might look like this: http://justaddwater.dk/wp-content/uploads/2006/01/vista%20search.jpg and that could be replaced by a cancel button when you start typing: http://www.tech2.com/media/images/img_3781_vista_search.jpg Safari has supported these features for some time, and we should not break compatibility with them: http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2007-May/011368.html Google has said they'd like to be compatible with Safari: http://code.google.com/p/chromium/issues/detail?id=17#c9 The main thing is, if these features were standardized, more sites would use them instead of trying to come up with something clever on their own, which would lead to more consistency across sites and a better user experience. Comments? -- Andy Lyttle [EMAIL PROTECTED]
Re: [whatwg] Placeholder option for text input boxes
I do not like this idea at all. That is what LABEL is for, and disappearing "it's so kewl" text is as annoying as BLINK and BGSOUND. Chris The tag is great for labels that are displayed outside the input box (in front of, above, etc.). The placeholder attribute is intended more as a hint than a label, and is displayed inside the input box without taking up any additional space on the page. An example might be: Get local weather forecast: Using the "alt" attribute has been suggested here, but no implementation uses "alt" in this way, while "placeholder" is already supported by one major browser (and since it really isn't alternate text, using "alt" doesn't make any sense). Another suggestion was to use the "title" attribute, which is a better idea, but "title" is generally implemented as a tooltip that doesn't appear until you hover over the element, which is not the desired behavior. It's perfectly legitimate to use a tag AND title AND placeholder attributes, for three subtly different purposes. You may find the behavior annoying, but hundreds if not thousands of popular sites are attempting to implement this behavior (via JavaScript and CSS) right now, and many of them are doing it badly. If it turns out to be just an annoying fad like was, then usage will fade away, for the same reason that we don't see much blinking text anymore even though "text-decoration: blink;" is still fully supported CSS. -- Andy Lyttle [EMAIL PROTECTED]
[whatwg] Placeholder option for text input boxes
Hi all! I would like to see Apple's adopted as an official standard, but there's one particular feature that would be easy to adopt without supporting the rest, and that's the "placeholder" option. Currently, lots of sites are implementing placeholder text through a combination of creative CSS and JavaScript hacking, but each site has to reinvent the wheel, and very often the wheel gets reinvented badly (examples below). Making it a standard feature of HTML would eliminate the need for all the extra scripting and improve accessibility, and consistent behavior would make a better user experience. The desired behavior is for the placeholder text to appear in the field with a gray color when the field is not focused and the value is empty. Of course the meaning of "gray" is up to the browser. The placeholder option was originally intended for search fields, but it's useful for other input types as well, and Safari already supports it on all text input fields. The HTML simply looks like: Here are a bunch of examples of sites that currently use JavaScript and CSS tricks in an attempt to simulate this behavior, to varying degrees of success: These use black placeholder text that disappears on focus but does not reappear on blur: http://www.bestbuy.com/ top left, "Keyword or Item #" http://www.blockbuster.com/ top right corner, "Movies, Actors, Directors" http://www.cisco.com/ top right corner, "Search" ...and countless others (army.mil, navy.mil, af.mil, weather.com, weather.gov, kfc.com, dennys.com, napaonline.com, etc.) These use gray placeholder text which reappears on blur, but text entered by the user is also gray: http://www.myspace.com/ on the right, "Find Friends on MySpace" box http://wordpress.com/ top right corner, "Search WordPress.com Blogs" These use gray placeholder text, but text entered by the user is also gray, and the placeholder does not reappear on blur: http://www.fedex.com/us/ top center, "Search" http://www.cnet.com/ top center, "Search" http://www.safeway.com/ top right, "Enter Keyword" These use black user-entered text and gray placeholder text that reappears on blur, but user-entered text turns gray on blur too: http://www.mapquest.com/ top right corner, "Search the Web" http://digg.com/ top right corner, "Search Digg..." http://www.gateway.com/ top right corner, "Search" (gray text is also italic) This uses black user-entered text and gray placeholder text, but the placeholder text does not reappear on blur and user-entered text disappears on focus: http://www.lenovo.com/us/en/index.html top right corner These behave as I would expect, with black user-entered text and gray placeholder text that reappears on blur: http://www.mapquest.com/beta left side, "Find a Business" http://www.mcafee.com/us/ top right corner, "Search" http://www.britannica.com/ top center, "Search Site..." (also has a cancel button) http://www.filemaker.com/ top center, "Search FileMaker.com" (also has a cancel button) http://www.apple.com/ top right corner, "Search" (also has a cancel button, uses AJAX for live searching) These use black placeholder text, but otherwise behave as expected: http://www.adobe.com/ top right corner, "Search Adobe.com..." (uses AJAX for live searching) http://www.nbc.com/ top left corner, "search" https://www.cia.gov/ top right corner, "Search" http://us.blizzard.com/support/ top center, "Enter a word, phrase or solution ID" As you can see, that's seven different behaviors, some of which are clearly not ideal, and all of which require JavaScript, which takes time to implement, test in multiple browsers, and debug. Supporting the placeholder attribute (which is already implemented in one major browser) would solve all of these problems. Comments? -- Andy Lyttle [EMAIL PROTECTED]
