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 m...@degeneration.co.uk 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 mark
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 mark and span then? I mean, does the mark element provide anything that span 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] 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 input type=email. type=address would be very confusing (see what people think about the address 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 input). In the multiple case, I'm fine with either [type=emails] or [type=email][multiple=multiple]. aolMe too./aol Are there any other situations where adding a multiple attribute could work similarly, other than select? -- Andy Lyttle [EMAIL PROTECTED]
Re: [whatwg] Add 'type' attribute to mark
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! span class=footnoteLa/span -- Andy Lyttle [EMAIL PROTECTED]
Re: [whatwg] [WF2] select required
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 select being a non-option (as it were). select 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 option in a select 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 select. I suggest that the placeholder attribute should indeed apply to select, and the behavior should be similar to the current practice of using the first option. 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] [WF2] select required
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 option 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] 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] input type=hidden outside phrasing content
table tr input type=hidden ... td/td /tr /table 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 input inside the td, which worked well enough but if putting it directly inside the tr were valid I probably would have done that. -- Andy Lyttle [EMAIL PROTECTED]
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
That seems sort of weird though. You're fine with putting the input type=text within the td, but you'd prefer *not* to do the same with the input type=hidden? 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 tr. Only because within the td I already had the value expressed as plain text. I ended up with something like tdinput type=hidden value=FooFoo/td (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: table tr input type=hidden ... td/td /tr /table 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 input inside the td, which worked well enough but if putting it directly inside the tr were valid I probably would have done that. That seems sort of weird though. You're fine with putting the input type=text within the td, but you'd prefer *not* to do the same with the input type=hidden? 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 tr. ~TJ
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 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] 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: label for=”date”Date: input type=”text” placeholder=”1 Jan 2008” id=”date” //label 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 input type=date kicks ass for this particular example. -- 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]
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] Safari-compatible input type=search
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 input type=search 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] Safari-compatible input type=search
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] 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 label for the field - it doesn't describe what the field is for. It describes what the *form* is for, and so should be a legend or hn. City, State actually describes the use of the input itself, and should be the label. Hmm, good call. Let's see if I can do better: label for=hairHair:/label input name=hair id=hair placeholder=Color title=Enter the color of your hairbr label for=eyesEyes:/label input name=eyes id=eyes placeholder=Color title=Enter the color of your eyesbr label for=noseNose:/label input name=nose id=nose placeholder=Shape title=Describe the shape of your nosebr label for=birthplacePlace of Birth:/label input name=birthplace id=birthplace placeholder=City, State title=Enter the city and state where you were bornbr 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 input type=search
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
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] 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] Safari-compatible input type=search
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]
