Re: [whatwg] IPv4 parsing
On Wed, Jun 24, 2015 at 3:46 AM, timeless timel...@gmail.com wrote: The trailing dot actually had meaning, but in my periodic testing most commerce websites didn't handle it well. It didn't help that browsers never favored adding it. On a somewhat (user) hostile network, http://discover.com/ might go to http://discover.com.example.com/ this probably isn't what the user wanted (it certainly wasn't what I wanted when I tested), but using http://discover.com./ got unfortunate redirects or unhappy responses from the remote server. That's all relevant for trailing dots on hostnames; I think the context here is trailing dots on IP addresses, which I don't think have the same meaning, since force this to be treated as a FQDN doesn't really mean anything when you're not doing DNS resolution. I believe for non-IP hostnames, Chrome should be respecting the trailing dot. For IPs, losing the trailing dot seems OK to me. PK
Re: [whatwg] IPv4 parsing
On Wed, Jun 24, 2015 at 9:37 AM, Tab Atkins Jr. jackalm...@gmail.com wrote: On Wed, Jun 24, 2015 at 9:23 AM, Anne van Kesteren ann...@annevk.nl wrote: On Wed, Jun 24, 2015 at 9:06 AM, Tab Atkins Jr. jackalm...@gmail.com wrote: You swap between 0.0.0.66 and 66.0.0.0 in your OP. Actually, the input URL in that case is different. 0x42.0. != 0x42. Well *that's* confusing. ^_^ Def spec this in detail, please. How Chrome's omnibox handles this (which I think is compliant with most other places): If there are no dots in the middle of the expression, the number is converted to powers-of-256 format and leading 0s are prepended to reach four octets: 66 = 0.0.0.66 256 = 0.0.1.0 If there are dots in the middle, the number after the last dot is treated as above, while the numbers before the dots must satisfy 0 = n = 255 and are placed into the highest octets in order: 1.66 = 1.0.0.66 1.256 = 1.0.1.0 1.2.66 = 1.2.0.66 1.256.66 = invalid PK
Re: [whatwg] PSA: Chrome ignoring autocomplete=off for Autofill data
On Thu, Nov 13, 2014 at 9:03 PM, Roger Hågensen resca...@emsai.net wrote: This is getting more off topic but... have you ever typed wrong and now the autocomplete keeps listing your wrong spelling every time? And the only way to fix it is to nuke all your data, there is no way to edit/control the auto suggest data in a browser. I believe most browsers support shift-deleting entries from the autofill dropdown. PK
Re: [whatwg] New feature: better integration with browser find interface
On Tue, Oct 28, 2014 at 10:59 AM, Ian Hickson i...@hixie.ch wrote: - telling UA that it should retry the search because content has been changed/rendered/modified The last is important because for web application which dynamically render the content, after search has already find matches on the page, if content is changed, browsers do not retry the search. This is the most evident with browsers which allow highlight all feature, like Google Chrome. This is just a bug in the browsers. If browsers had to retry open finds every time the page content changed, then leaving one's find bar open could have very large negative performance effects, even if the browser focused only on the modified pieces of the page. Is there an implementation idea I'm missing for how browsers could fix this bug in a performant way? Otherwise I can't see us doing what it seems like you want. PK
Re: [whatwg] Password managers ignoring autocomplete='off' harming security
On Wed, Oct 1, 2014 at 4:11 PM, Dan Poltawski d...@moodle.com wrote: The data in those fields are stored in plain text and shared between multiple teachers (multiple accounts), so when another teacher comes along - they could access it. There is a scale of severity of the data in there - from real passwords to external systems to a shared 'enrolment key' which is a passphrase which might be shared with some students but not others. So, you're doing both of the following? * Using a password field for (sometimes) things that aren't passwords * Storing (potentially) sensitive data in the clear yourself, and sending it (again, in the clear) to other accounts/machines Unless I'm misunderstanding your description of your application, these sound like undesirable practices, which are themselves at the root of your users' lack of security, and the browsers' behaviors are merely illustrating this? PK
Re: [whatwg] Password managers ignoring autocomplete='off' harming security
On Wed, Oct 1, 2014 at 4:34 PM, Gavin Sharp ga...@gavinsharp.com wrote: That browsers now automatically go fill in sensitive data (passwords) into these password fields is the issue, because people might not notice that happening and then submit the form. OK, but how does that cycle get started? I could be wrong, but I believe in Chrome that we won't autofill your password from site X into a password field on unrelated site Y. You have to have explicitly used that password on site Y to fill it in the future. So if people are getting sensitive data, that was never supposed to be in these fields to begin with, filled into the fields, how is that happening? Are browsers being aggressive about attempting to fill data from one site into another? Does this happen across browsers? PK
Re: [whatwg] Password managers ignoring autocomplete='off' harming security
On Wed, Oct 1, 2014 at 6:12 PM, Dan Poltawski d...@moodle.com wrote: Note a more traditional example of this which might affect more sites is something like a 'create new user' form where the password would be erroneously set to the password of the user who is creating the accounts. I know the Chrome password folks considered that specific case, but I'll have to let them speak to how they addressed it. PK
Re: [whatwg] Adding features needed for WebGL to ImageBitmap
On Wed, Jul 10, 2013 at 5:07 PM, Ian Hickson i...@hixie.ch wrote: (The other two options don't make much sense to me even for GL. If you don't want a color space, don't set one. If you don't want an alpha channel, don't set one. You control the image, after all.) I only have a small amount of graphics experience, but I don't think that latter comment is right, at least. At least for the alpha channel, as Gregg already wrote, a lot of GL algorithms use that data for something per-pixel that's not alpha (generally some other kind of per-pixel map). It's not appropriate for the browser to assume that it's safe to muck with the values there. Fixing this by instead trying to pass these values separate from the rest of the pixel data is inefficient as well as just weird from the perspective of anyone with significant experience in using these sorts of algorithms. PK
Re: [whatwg] URL: relative file URL starting with c: quirk
On Tue, Jul 9, 2013 at 10:57 AM, Anne van Kesteren ann...@annevk.nl wrote: On Mon, Jul 8, 2013 at 6:23 PM, Peter Kasting pkast...@google.com wrote: Given how unlikely it is that someone will have registered a scheme handler for the one-character drive letters, the Chrome/IE behavior seems more forgiving and more likely what the author wants, to me. But it also forks the semantics of generic URLs, or at least when the base URL happens to be a file URL. Those kind of exceptions are not exactly ideal. In particular treating an absolute URL as a relative URL under certain circumstances seems bad. I don't see this as a security risk, and if the behavior is desirable, it seems fairly well-scoped in terms of specifying it. PK
Re: [whatwg] URL: relative file URL starting with c: quirk
On Thu, Jul 4, 2013 at 5:24 AM, Anne van Kesteren ann...@annevk.nl wrote: Both Chromium and Internet Explorer treat a href=c:/test.../a in a file served from e.g. file:///C:/Users/Anne%20van%20Kesteren/Desktop/file.html in a special way. The resolved URL becomes file:///c:/test (uppercase C in Chromium) rather than c:/test (note that c: is a valid URL scheme) as it does in Gecko. Is there a good reason to preserve this quirk? Given how unlikely it is that someone will have registered a scheme handler for the one-character drive letters, the Chrome/IE behavior seems more forgiving and more likely what the author wants, to me. PK
Re: [whatwg] URL: file URL C| quirk
On Thu, Jul 4, 2013 at 5:18 AM, Anne van Kesteren ann...@annevk.nl wrote: Both Gecko and Chromium have a quirk with C| and similar patterns (drive letter followed by |). They treat it similarly to C:. However, Internet Explorer does not do this. Should we remove this quirk? I searched for file URL drive letter pipe on Google and found a variety of comments about programs/libraries that output URLs with a pipe instead of a colon after a drive letter name. It sounds like there are likely compatibility issues connected to this quirk. PK
Re: [whatwg] Autocomplete and autofill features and feedback thereon
On Mon, Dec 10, 2012 at 9:01 PM, Ilya Sherman isher...@chromium.org wrote: However, since I'm not aware of any browsers that currently support or are planning to add support for autofilling bank account numbers, and I'm only aware of a handful of websites that request them, I'm ok with punting on this for now. If someone else has done the research and thinks it would be valuable to add this type to the spec, please do post here. As a user this would be fantastic. Filed https://code.google.com/p/chromium/issues/detail?id=165410 . Only a handful of sites maybe true in percentage terms relative to the number of websites that support credit card numbers, but it certainly isn't true in absolute terms. My bank account and routing numbers are in a huge variety of sites, for example all my utilities, credit cards, Paypal and other payment systems, Amazon, my employer's payroll site, etc. PK
Re: [whatwg] Improving autocomplete
On Wed, Nov 21, 2012 at 9:00 AM, Mounir Lamouri mou...@lamouri.fr wrote: I feel like the real use case is when a user wants to make custom with a web site for the first time. It might be indeed harder to get a good transformation ration if the user has to write all those information. However, I doubt we should add such a scary feature for that use case. On the contrary, as a user I find that case extremely compelling. Maybe I'm too easily frustrated, but it's intensely annoying when I have to fill out all my personal information yet again just because I've gone to some new site to buy something. This is far harder on mobile because typing is just a huge pain there and the screen is small enough that I can only see a few fields at once. Existing UA autofill is nice but pages often defeat it due to the sorts of problems described in the original root post. It's already the case that Chrome can autofill my credit card number into a form that asks for it, so I'm not totally sure why the proposed capabilities here are viewed as new and scary. It seems like we're just trying to expose a slightly nicer event system for letting authors interact with the existing UA feature set. I totally agree that we should think hard about privacy and security issues with form autofilling. It's just that I think we're already in a world where we have to think about those concerns (indeed, have been so for awhile), and the specific proposals here don't really amount to a systematic difference in that respect. PK
Re: [whatwg] Improving autocomplete
On Wed, Nov 21, 2012 at 5:11 PM, Nils Dagsson Moskopp n...@dieweltistgarnichtso.net wrote: The proper solution is to let people vote with their wallet for devices that are perceived as making input easier – not to hand over power to site users making it easier to sniff data. This contains what I think are multiple false assumptions: (1) It's reasonable to discriminate against devices that don't make input as easy as my desktop computer with its full-size keyboard. Given the rise of mobile web usage, it seems clear that users will increasingly access the web with devices that physically can never be as accommodating as my desktop computer can. I don't think that allows us to simply say oh well and ignore the problem. (2) The proposals make it easier to sniff data. The entire point of my email was that IMO this is simply false. It's already the case that Chrome can autofill my credit card number into a form that asks for it, so I'm not totally sure why the proposed capabilities here are viewed as new and scary. It seems like we're just trying to expose a slightly nicer event system for letting authors interact with the existing UA feature set. Looks like an is-ought-problem to me. The descriptive (“It's already the case …”) can not tell us much about what should be done by virtue of its existence alone. Did you use „new and scary” to imply opponents appeal to tradition? No, I used it to make clear that, at least for some UAs, there is no new user data being exposed in these proposals, nor is existing data being exposed to whole new types of sites. A consideration of whether new APIs represent an additional security or privacy risk must take these factors into account. It is also possible that UAs with existing autofill capabilities (like Chrome) are already insecure today, in which case it'd be very useful to note existing problems so that these UAs can fix them and other vendors can avoid the problems. What Chrome can do is started by users; even then a warning is given: http://support.google.com/chrome/bin/answer.py?hl=enanswer=142893 It's important that you use Autofill only on websites you trust, as certain websites might try to capture your information in hidden or hard-to-see fields. And those same properties -- that these APIs require a user gesture, that the UA is in control of the presentation, and that ultimately it is up to users to use them responsibly -- are all true here as well. The systematic difference – for me – is that the proposed functionality may make easier to trick a user into agreeing to „autocomplete everything“ than the current functionality does. Please explain precisely how you see this occurring, because this is the key part of your argument that I don't grasp, but you've provided no explanation for it. An informative reply might be a detailed scenario complete with an explanation of why the malicious site in question could not accomplish a similar effect with existing UA capabilities. This would be very helpful in informing the design here. PK
Re: [whatwg] Should scrollbars move focus?
On Fri, Nov 2, 2012 at 6:21 AM, Etienne Levesque Guitard etienn...@gmail.com wrote: Wouldn't this be considered a browser-specific implementation bug/inconsistency then? If you're referring to IE's reported behavior, I would say that yes, it's not gospel regarding platform conventions, and it may not even intentionally deviate. I verified James' testing and am sufficiently convinced that the Windows convention, like other platforms, seems to be to not change focus due to scrollbar clicks. That makes me lean towards the change Gecko and WebKit to never focus camp. PK
Re: [whatwg] Should scrollbars move focus?
On Wed, Oct 31, 2012 at 4:08 PM, Ojan Vafai o...@chromium.org wrote: On Wed, Oct 31, 2012 at 3:46 PM, Robert O'Callahan rob...@ocallahan.org wrote: I think what's happening here in Gecko is that a click on a focusable element moves focus, and a click on an element's scrollbars counts as a click on the element. So clicking on the scrollbar of a textarea or contenteditable div (or even a button containing content with a scrollbar, if you're mad) moves focus to that element. I think this is quite reasonable actually. Example: http://people.mozilla.org/~roc/scrollbar-focus.html I see. Thanks for the clarification. I don't feel strongly about this. Either direction seems fine. Although, it doesn't violate every native platform's scrollbar convention. The behavior Robert describes seems theoretically reasonable to me as well. Ojan, can you say how you tested the platform conventions? On Windows I'm having a hard time finding an app with multiple scrollable elements that uses native scrollbars. (For example, Visual Studio doesn't use native scrollbars.) PK
Re: [whatwg] communicating plugin state (primarily for click-to-play)
On Mon, Jun 11, 2012 at 5:29 PM, Josh Aas josh...@gmail.com wrote: In order for click-to-play to be a viable feature we'll probably need to allow pages with complex plugin usage (i.e. scripting) to query for click-to-play state. The advice we (Chromium team) give developers is to check navigator.plugins to see whether the plugin is available at all. (Users without the plugin installed, or with it completely disabled, will not have an entry there.) If the plugin is available, go ahead and attempt to construct it and script it. (The best UX is if this instance can, at least initially, get some visible region of the page, so that click-to-play users would see the placeholder content there. This is not always feasible or desirable, but it can be done a large percentage of the time.) If this fails, assume click-to-play is enabled, and show whatever fallback UI is necessary. This avoids the need for extra DOM properties. Separately, the browser should also indicate to users when a page has blocked plugins, and give the user the ability to temporarily or permanently control this restriction. The temporary implementation should probably be along the lines of reload the page, this time allowing all plugins. As noted already in this thread, simply allowing plugins after script has already tried to start them and communicate simply won't work a lot of the time. I don't support Glenn's suggestion to show a larger prompt when a plugin instance isn't visible, for two reasons. One is that determining visibility it, in the limit, impossible. The second is that the purpose of this feature is generally to reduce annoyance; showing prompts atop the window is annoying, especially if it happens frequently. PK
Re: [whatwg] communicating plugin state (primarily for click-to-play)
On Tue, Jun 12, 2012 at 1:07 PM, Glenn Maynard gl...@zewt.org wrote: On Tue, Jun 12, 2012 at 1:22 PM, Peter Kasting pkast...@google.comwrote: The temporary implementation should probably be along the lines of reload the page, this time allowing all plugins. As noted already in this thread, simply allowing plugins after script has already tried to start them and communicate simply won't work a lot of the time. Not according to the model Adam suggested: a plugin that hasn't yet received permission to start acts like a plugin that simply hasn't loaded yet. It's important to distinguish solutions for authors versus solutions for UAs. Authors should try and code according to Adam's model. However, for pages which don't, UAs may still need to direct users to reload the page. I don't support Glenn's suggestion to show a larger prompt when a plugin instance isn't visible, for two reasons. One is that determining visibility it, in the limit, impossible. What matters is if the visibility detection is 1: web-compatible (matches up with what websites are doing with plugins that have in-page UI vs. script-only plugins) and 2: well-defined, not whether you can detect that a plugin is visible in every case. #1 may be impossible, though, especially if it's not known to the browser in advance whether the plugin has UI. It's probably better to just always show a prompt bar. Not only that, but your point 2 again is only accurate when speaking of pages where the authors are trying to work with click-to-play and thus are ware of the visibility rules and take them into account. However, the feature needs to also work well with other sites which don't take these rules into account, meaning that for those pages, you're reduced to the non-computable case. The second is that the purpose of this feature is generally to reduce annoyance; showing prompts atop the window is annoying, especially if it happens frequently. The entire purpose of those non-modal prompts is to be unintrusive and out of the way. That style of prompting is designed exactly for this sort of thing. As a member of Chrome's UI team I can assure you that getting an infobar on every page that has a blocked plugin leads to fury in about ten minutes. This is why our indicators are icons that appear in the page action area of the Chrome omnibox. This is unobtrusive enough to not be annoying. Unfortunately it's also unobtrusive enough to leave less-expert users baffled. Also, pages should not be required to create placeholder areas inside pages to give the browser a place to prompt; it's the browser's job to do that for itself (again with prompt bars, doorhangers, and the like). That's especially true because the page has no way of knowing whether the browser is actually going to prompt (it may not use confirmations for the plugin being used, or the user may have clicked yes, always on a previous session). This belongs out-of-line. It's often easy for a page to give the plugin a temporary visible location and hide it once the plugin actually loads, without the user noticing anything in the common case where permission has been implicitly or explicitly granted. As I said, this isn't always possible. PK
Re: [whatwg] communicating plugin state (primarily for click-to-play)
On Tue, Jun 12, 2012 at 1:26 PM, Ashley Sheridan a...@ashleysheridan.co.ukwrote: ** What about doing what popular plugin blockers do and offer the notification in the area the plugin was intended to be used? I was operating under the assumption the UA was already doing that. Hence why we're talking about non-user-visible plugins in the first place. PK
Re: [whatwg] a download feedback
On Sat, Mar 3, 2012 at 4:27 PM, Bjartur Thorlacius svartma...@gmail.comwrote: In special, a href=http://www.google.com/**url?sa=tamp;rct=jamp;q=l%C3%** B6gbergamp;source=webamp;cd=**2amp;ved=0CCwQFjABamp;url=** http%3A%2F%2Fwww.thingvellir.**is%2Fsaga%2Flogberg%2Famp;ei=** F69ST6T3OM6XOqGOnZEKamp;usg=**AFQjCNEPLku9Nm5bsA12_** oY9mV1gPH3Aegamp;cad=rjahttp://www.google.com/url?sa=trct=jq=l%C3%B6gbergsource=webcd=2ved=0CCwQFjABurl=http%3A%2F%2Fwww.thingvellir.is%2Fsaga%2Flogberg%2Fei=F69ST6T3OM6XOqGOnZEKusg=AFQjCNEPLku9Nm5bsA12_oY9mV1gPH3Aegcad=rja ... does not link to http://www.thingvellir.is/**saga/logberg/http://www.thingvellir.is/saga/logberg/. Google could fix this by linking directly. That, however, would allow for opting out of tracking by simply not running scripts. This is an unrelated issue, which a ping was designed to address. PK
Re: [whatwg] Proposal for autocompletetype Attribute in HTML5 Specification
On Thu, Jan 26, 2012 at 12:15 AM, Ilya Sherman isher...@chromium.orgwrote: Extending the existing input 'type' attribute is an interesting idea, thanks for raising it. Looking through the existing input type values, it seems they are primarily chosen so as to enable user agents to render and format the input data in type-appropriate ways. However, the existing types do not try to nail down the field's exact data type beyond the needs of this use case -- for example, input type='tel' currently covers both phone and fax fields. In contrast, for many autocomplete/autofill agents, the distinction between phone and fax fields is important. I think of the distinction here as follows: Imagine the various values forms might want. For example, first name, last name, home address, work address, home phone, mobile phone, fax. Now classify these by kind. (For an object-oriented programmer like me, this would be enumerate the different classes/types required to hold the above values.) You might come up with name, address, phone number. All phone numbers share some set of properties, such as consisting of digits, as do all names, all addresses, etc. The distinction between what kind of a value something is and what precise instance of that kind it is is a valuable distinction. As you noted already, the former can be used to do structural validation or provide helpful UI for entry without needing to understand the latter. I see type versus autocompletetype in this same way. type allows the UA to understand the structure of a form value while autocompletetype allows it to understand which particular values might commonly go there. Certainly we could eliminate the former and just use the latter, but there is a major downside. Imagine my UA has support for all the above example specific types I gave. Now a web author wants to write a form with a new value, e.g. maiden name or pager number. It would be wrong to use any of the above autocompletetype values, since this field doesn't mean any of those things. But that means I can't get the UA to do validation or UI assistance for me either. We could try to solve this by allowing our unified type attribute to take on the union of all type and autocompletetype values. But this is confusing. When I can have type phone number or home phone number, which do I use? It's not necessarily clear to a web author what the practical ramifications of this choice are. Therefore, I think leaving these fields separate makes sense even if sometimes one could imply the type from the autocompletetype. PK
Re: [whatwg] Proposal for IsSearchProviderInstalled / AddSearchProvider
On Tue, 17 May 2011, Bjartur Thorlacius wrote: Then why add an API when we've already got (IMO superior) declarative markup? In the case of adding the API to the spec, because it's already implemented. As to why it was added to the browsers, no idea. Certainly there's no declarative markup for IsSearchProviderInstalled(). As for AddSearchProvider(), I know one reason it was added to Chrome was explicitly to expose the and make default functionality. Of course one could argue that a UA could give users the option to make any provider default for whatever UI it exposes for the declarative case. But there are a couple fine points worth mentioning: one is that since users rarely want to make an engine default, adding that option to the UI all the time would be even more annoying than adding [ ] And set as my homepage to whatever UI is shown for bookmark this page, and thus UAs may shy away from this idea. Another is that engines may wish to explicitly request to be made default in response to some explicit user action on the page, e.g. clicking a Make this my default search engine button. Creating this UI and making it work smoothly is difficult with the existing mechanisms. Note that I am not the one who proposed, specced, or implemented this in Chrome; I'm just trying to convey a few things that seem apparent to me as another Chrome UI engineer :) PK
Re: [whatwg] Proposal for IsSearchProviderInstalled / AddSearchProvider
On Fri, Dec 16, 2011 at 3:08 PM, Peter Kasting pkast...@google.com wrote: As for AddSearchProvider(), I know one reason it was added to Chrome was explicitly to expose the and make default functionality. I've been informed that the set default part is going away in Chrome 17+ anyway, so since that will leave no UAs implementing that, all discussion related to it is probably moot. PK
Re: [whatwg] Add naturalOrientation property to img
On Fri, Aug 26, 2011 at 2:08 PM, James Salsman jsals...@gmail.com wrote: Maybe someone should ask the browser vendors how many img formats they support and what the code footprint memory overhead would be for adding rotation support for those which are likely to need it at whatever confidence level you feel is appropriate. Auto-rotating images in the browser is controversial for reasons that mostly boil down to web compat, not code footprint. WebKit-on-iOS does it and AFAIK few others do. https://bugs.webkit.org/show_bug.cgi?id=19688 is about doing this in WebKit and you're welcome to read that bug to get a feel for the various viewpoints. PK
Re: [whatwg] a rel=attachment
On Fri, Jul 15, 2011 at 5:38 PM, Tantek Çelik tan...@cs.stanford.eduwrote: * existing rel=enclosure spec - download the link when clicked/activated. I object to rel=enclosure purely on naming grounds. It is completely unintuitive. I don't find the fact that a spec exists for it a compelling reason to use it. (Specs exist for lots of things, many of them bad.) PK
Re: [whatwg] a rel=attachment
On Fri, Jul 15, 2011 at 6:25 PM, Tantek Çelik tan...@cs.stanford.eduwrote: ** Specs *and* publishers/consumers/implementations of rel-enclosure exist (see aforementioned wiki page). The list on the wiki page, which I assume is non-exhaustive, is extraordinarily uncompelling. And the name is based on re-using the existing term with the same semantic from the Atom spec. Don't care. Atom feeds and HTML pages are very different things. Basically I echo all of Tab's annoyances with this. PK
Re: [whatwg] Proposal to extend registerProtocolHandler
On Tue, Jul 5, 2011 at 2:12 PM, Boris Zbarsky bzbar...@mit.edu wrote: Yes, I'm not saying in-page click is a solution. It works for popups, sort of, but I don't think it does for permission request notifications. To be truly honest, requiring a user gesture probably doesn't work for rPH() because it doesn't actually work for window.open, or allowing executable files to download, or any other purpose we've keyed off in UAs so far. That's because a click is not at all a good indicator of some sort of of user understanding and intent. The only thing it buys you is the possibility that a visible UI change happens immediately after a user's click and thus that in theory the user _might_ be able to guess that the click triggered the UI change. In any case I am not suggesting we spec anything regarding user gestures for rPH() for now, it was an example of something we could try that isn't really possible to consider unless we give webpages some sort of way to check registration. Also, I happen to agree with Boris that prompting for permissions is not, in fact, less annoying than opening a new window. Making prompts be non-modal infobars does not mean they're suddenly friction-free and OK to show all the time. It's much harder to close an infobar, for example (no keyboard shortcuts or OS allowances). And the consequences of a user clicking OK randomly to close a grant permission infobar are much greater than the consequences of a user clicking a popup's close box. PK
Re: [whatwg] Proposal to extend registerProtocolHandler
In general, I echo Michael's comment that we follow the notifications model. On Sun, Jul 3, 2011 at 1:01 PM, Nils Dagsson Moskopp n...@dieweltistgarnichtso.net wrote: Right now sites are actually much _more_ annoying without this feature as they just blindly ask you to make them your protocol handler every time. Can UAs not be expected to handle this properly, like they do with repeated alerts? It's not a problem on the UA side, but the web page side. Assume we want to limit action on this call to cases where there's a user gesture (to prevent bad sites from annoying you quite as easily, though I admit it is not a huge roadblock). Now you're Gmail and you want to give the user the ability to register you as a mailto: handler. So you whip up some button that will make the rPH() call and some UI around it that calls attention to it. Without the ability to check if you're already the default handler, you have to show this UI all the time, which is not at all appealing, or else bury it somewhere, which means it will never get seen by most users. PK
Re: [whatwg] Proposal to extend registerProtocolHandler
On Sun, Jul 3, 2011 at 12:11 AM, timeless timel...@gmail.com wrote: It isn't ok to say You can't do X unless you make Y your default Z. I would prefer to solve this if it actually becomes a problem. Right now sites are actually much _more_ annoying without this feature as they just blindly ask you to make them your protocol handler every time. I think we should solve real usage problems today in preference to leaving them unsolved for fear of a hypothetical later problem that we could easily solve down the road. PK
Re: [whatwg] Proposal to extend registerProtocolHandler
On Fri, Jul 1, 2011 at 1:59 PM, Ojan Vafai o...@chromium.org wrote: Do any browser vendors agree with this or have objections? From my work on the Chrome UI side of this, I would very much like to see something like isRegistered(). This would allow sites to conditionalize requests for the protocol handler. This is important to me because I would also like to experiment (after that point) with requiring a user gesture for this request (much like browsers typically require user gestures for window.open()), so sites cannot hammer the user with requests outside of some sort of interaction-based workflow. PK
Re: [whatwg] Can we make checkboxes readonly?
On Wed, Apr 6, 2011 at 1:45 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: Checkboxes being readonly would be useful for the same reasons that text inputs being readonly is. As someone who spends a lot of time writing native UIs, I agree. It's useful to be able to dim out a checkbox that no longer applies when some other, related form control is changed. We could alternately say that a radio button being readonly means that that specific input can't have its checkedness changed - if it's currently unchecked, clicking on it won't check it; if it's currently checked, clicking on a mutable radio button from the same group wouldn't change the checkedness of either input. Enabling individual radio buttons within a group to be disabled would match Windows' capabilities, at least. It's not clear whether the right behavior might not be to allow clicks on an enabled button to unselect the disabled button, though. See for example someone wanting that with a Windows native control here: http://social.msdn.microsoft.com/Forums/en-IE/vcmfcatl/thread/75fef4b4-a7ab-4e96-ac9b-12cb27085ab9 PK PK
Re: [whatwg] Geolocation - Browser usability issues with regards to asking user permission
On Wed, Apr 6, 2011 at 4:37 PM, Andrew de Andrade and...@deandrade.com.brwrote: 2) The HTML5 specification defines how browsers should implement this consistently -- either a bar across the top OR modal dialog box, but not both. This isn't ideal either since there are arguments both for and against both solutions. Besides the con you mention, I think this is also outside the scope of HTML5. The spec has frequently advised browser vendors on characteristics that must or should be true, e.g. w.r.t. allowing users to manage and delete local storage data in a similar fashion to cookies -- but actually dictating precise bits of UI goes too far. 3) Each browser chooses their default interface approach (bar or modal dialog), but the Geolocation API specification allows for the webapp developer to override this default. Those apps for which location is essencial for the user experience can choose to always display a modal dialog box before the user proceeds to use the webapp. Those apps for which it is not important, can opt for the bar across the top. Unfortunately, it is far more common for an author to feel that a particular permission is essential than for the user to feel so. Furthermore, modal dialogs have other usability issues that the browser vendor may wish to avoid, e.g. requiring script on many different tabs to stop. In addressing the privacy aspects of the user experience, we've created a usability issue which needs to be addressed as well. Allowing users to toggle a feature on a per-site basis is not just a privacy issue but in many cases one of general functionality. For example, Chrome includes a click to play feature under a flag that allows users to dynamically control plugin invocation, not for privacy but usability reasons. The browser vendor may have strong UI design goals or interface consistency requirements that dictate how functionality choices are portrayed to the user. As a browser UI developer, I am not willing to cede control over those aspects to the web developer. If users don't notice or understand the geolocation prompts in a particular browser, I think the appropriate response is to provide feedback to the browser vendor that users are not successfully navigating their UI. I would be very interested in the details of your testing, how you determined that users were missing the prompts, and how effective were more generalized methods (than making a floating div as a UI callout) in guiding users (e.g. simply telling users they need to give the site permission to access their location before it will work correctly, showing your UI with a big No permission to access your location; did you tell your browser to allow this?-style banner overlaid, etc.). PK
Re: [whatwg] Can we deprecate alert(), confirm(), prompt() ?
On Tue, Mar 1, 2011 at 1:13 AM, Robert O'Callahan rob...@ocallahan.orgwrote: On Tue, Mar 1, 2011 at 6:38 PM, Ojan Vafai o...@chromium.org wrote: FWIW, chromium is planning on experimenting with disallowing modal dialogs during the beforeunload/unload events. http://code.google.com/p/chromium/issues/detail?id=68780 That sounds fairly unpleasant for users of pages which give are you sure you want to leave this page and lose your data? warnings. Please see my identical question and Tab's answer, which Ojan's reply quoted. PK
Re: [whatwg] Can we deprecate alert(), confirm(), prompt() ?
On Mon, Feb 28, 2011 at 4:42 PM, Ian Hickson i...@hixie.ch wrote: 2. if we are still keeping them, can we disable them in onbeforeunload/onunload[/onhide] etc. Many sites add extra dialogs in those events to confuse users, so that they can trap users for little longer. That's not a bad idea. I recommend approaching the browser vendors to see if they are willing to implement it; if they do, then updating the spec accordingly would be a no-brainer. Isn't this important for the you're trying to navigate away from gmail with an open draft; abandon changes y/n? case? PK
Re: [whatwg] SearchBox API
On Thu, Oct 14, 2010 at 11:09 AM, Aryeh Gregor simetrical+...@gmail.comsimetrical%2b...@gmail.com wrote: If this is meant to be vendor-neutral, there needs to be some way for arbitrary search engines to advertise support for this feature to supporting browsers. That depends on whether the browser supplies info to the DOM APIs at all times, or only when it thinks the target page supports this feature. Clearly, in the former case, the browser doesn't need to know what the page can and cannot do. If the latter, then yes, extending the OSDD is necessary. But as I said, that's still somewhat orthogonal to the question of whether a DOM API like this should exist at all, and what it should look like, assuming that the browser is actually going to populate it accurately. But I might be misunderstanding something here, since the proposal only gave an API This proposal is not by any means the totality of everything involved with instant-style support. It is only a piece. PK
Re: [whatwg] SearchBox API
On Wed, Oct 13, 2010 at 4:12 PM, a...@ashleysheridan.co.uk a...@ashleysheridan.co.uk wrote: Would it not be best to implement this based in the browser search integration thing that allows people to include a search option to a site through the browser, like YouTube, php.net, etc. I can't for the life of me figure out what you're saying. PK
Re: [whatwg] SearchBox API
On Wed, Oct 13, 2010 at 6:53 PM, Aryeh Gregor simetrical+...@gmail.comsimetrical%2b...@gmail.com wrote: On Wed, Oct 13, 2010 at 7:18 PM, Peter Kasting pkast...@google.com wrote: I can't for the life of me figure out what you're saying. I assume he's saying that this should be integrated into OpenSearch, rather than being specific to the default search provider as the proposed API seems to be. The API is completely orthogonal to OpenSearch AFAICT. OSDDs tell a UA about a search engine and how to search with it. The proposed DOM additions provide a search engine with information about what the user is doing in the browser. PK
Re: [whatwg] [URL] Starting work on a URL spec
On Fri, Jul 23, 2010 at 8:59 PM, Silvia Pfeiffer silviapfeiff...@gmail.comwrote: Is that URLs as values of attributes in HTML or is that URLs as pasted into the address bar? I believe their processing differs... I strongly suggest ignoring browser address bars. As the author of most of the Chromium omnibox code, I can testify that there's a ton of fixup, heuristics, and other stuff that's designed to get the user what they want that should never be in a spec. I think limiting the scope to URLs consumed as part of web content makes more sense. PK
Re: [whatwg] Article: Growing pains afflict HTML5 standardization
On Sat, Jul 10, 2010 at 9:14 PM, Garrett Smith dhtmlkitc...@gmail.comwrote: The few headings that you have are improperly capitalized. I think you are mistakenly assuming that the authors of email and article are the same person. PK
Re: [whatwg] Sortable Tables
On Thu, Jul 1, 2010 at 11:38 AM, Christoph Päper christoph.pae...@crissov.de wrote: I have not found much on sortable tables on whatwg.org, especially when excluding ‘datagrid’. Why are you excluding datagrid, when that's the precise element aimed at addressing your issue? PK
Re: [whatwg] Form validation against invisible controls
On Sun, Jun 13, 2010 at 10:16 PM, TAMURA, Kent tk...@chromium.org wrote: There are some objections against omitting invisible controls from form validation. However, it is a real issue with existing sites and users can't submit such forms at all though they can submit it with non-HTML5 browsers. How many existing sites? What sites are asking for form validation but then not actually working with it? If this isn't a large number, I would prefer to stay as-is and let the sites fix themselves. My conclusion is it's better to disable interactive form validation for existing sites as possible. e.g. disabling interactive form validation for documents without !DOCTYPE html. I think this is a mistake. PK
Re: [whatwg] Form validation against invisible controls
On Thu, Jun 3, 2010 at 3:48 PM, Aryeh Gregor simetrical+...@gmail.comsimetrical%2b...@gmail.com wrote: On Thu, Jun 3, 2010 at 12:11 PM, TAMURA, Kent tk...@chromium.org wrote: Oh, I'm sorry. I have found a sentence about visibility in the draft. http://www.whatwg.org/specs/web-apps/current-work/multipage/association-of-controls-and-forms.html#constraint-validation If one of the controls is not being rendered (e.g. it has the hidden attribute set) then user agents may report a script error. The Chrome bug report is here: http://code.google.com/p/chromium/issues/detail?id=45640 I think this isn't a feasible strategy to pursue. You'd have to carefully define what's not being rendered, and it will violate layering massively. CSS should not be able to override constraints set in HTML. The latter are part of the semantics of the form, and the former is supposed to only control presentation. If the user can't actually change the form to match requirements, that's a bug in the page. The browser should not try to guess what the page really meant using some inevitably complicated heuristic. It should respect what the page says, and make it not work. If the browser has a UI for form validation errors, it can use that to tell the user what the problem is in terms that the page author can understand, so the user can report it and the page can be fixed. I posted this on the Chromium bug, but I take the sentence Kent quotes to affect only the UI shown on a validation failure, not the actual results of validation. That is, if a control fails validation and has the hidden attribute, validation still fails, but the UA may display a message indicating the page has an error in addition to/instead of the normal validation failure message. I agree that it would be a mistake to exclude invisible elements from validation, as that would be a rathole (and seems conceptually wrong to me). PK
Re: [whatwg] HTML Cookie API
On Wed, Feb 24, 2010 at 4:30 PM, Garrett Smith dhtmlkitc...@gmail.comwrote: Where is the argument for making the API async? Please see the discussion earlier in this thread. Can you be more specific? I see: | I really think the API should be asynchronous, as to avoid the mess | that .localStorage currently is. But I don't know if that's what you meant by please see earlier. There have been numerous messages (well over a dozen) discussing this. If you don't see them, try checking online archives, waiting for their delivery to your mailbox, or similar. Asynchronous cookies that would mean that cookie setting tests would be harder. No one is suggesting removing the current document.cookie API. Nobody is suggesting you change your tires. Why bring it up? This response makes no sense at all. You expressed concern that an async API would make particular existing patterns harder to write. The response was that these existing patterns will continue to work because they rely on a synchronous API that isn't getting removed; the async API is proposed as an addition. I have no idea what your retort after that is intended to convey. PK
Re: [whatwg] validationMessage
On Thu, Feb 11, 2010 at 6:39 PM, Ian Hickson i...@hixie.ch wrote: The relevant use cases that led to this design are: 1. Getting validation of forms without scripting, with the UA doing all the UI work. 2. Getting validation of forms with the UI designed by the author, but with the actual validation work (including working out what the messages should be) done by the UA. 3. Getting validation of forms with the UI completely done by the author, including deciding what the messages should be. I am explicitly opposed to the UA showing validation messages to the user. I do not think HTML5 should attempt to address use cases where the author wants the UA to show the messages. I think the design should provide the author with return values that indicate what the results of validation were and the author should provide the rest of the UI. In other words, I am opposed to trying to solve use cases #1 and #2 above. Any design that attempts to solve them is a mistake. Please remove validationMessage from the spec. PK
Re: [whatwg] validationMessage
On Thu, Feb 11, 2010 at 11:01 PM, Jonas Sicking jo...@sicking.cc wrote: Would be great if you could provide a reason why you feel this way. Did the previous messages in the thread not say enough reasons? Ian's response was basically then how would we solve use cases 1 and 2? which was why I was clarifying that I did not have an alternative solution, I felt that they are cases we should not be trying to solve. PK
Re: [whatwg] validationMessage
2009/11/19 Scott González scott.gonza...@gmail.com However, following that same logic wouldn't you come to the conclusion that date inputs should not display calendars because they need to be localized? * I am confused, what needs to be localized about the calendar? Are you referring to non-Gregorian calendars, e.g. the Mayan calendar? * I'm making an argument about validationMessage, not a generalized argument. Don't extrapolate to create strawmen. PK
Re: [whatwg] validationMessage
On Tue, Nov 10, 2009 at 12:23 PM, Michelangelo De Simone micde...@gmail.com wrote: What is the rationale about this choice? A simpler behavior with a predetermined list of return values (eg: i.validationMessage == VALUEMISSING) could be much more efficient for authors and implementors to deal with, IMHO. I tend to agree. From https://bugs.webkit.org/show_bug.cgi?id=27959#c29 , where this was implemented for WebKit: This patch sure does seem to be an eloquent argument for not having all these localized strings in the HTML5 form element design! I don't see a lot of value of returning these strings that might not even be in the same language as the website. I wish we could get that changed. -- Darin Adler My oversimplified view of this is: * Providing a way for the webpage to specify validation constraints and understand when they have not been met -- good * Directing the UA to step into this process and show the user messages about the validation failures, which don't take into account context the web page has -- bad This seems like an attempt to make life slightly easier on webpage authors by providing boilerplate UI if they don't want to write anything. But I see that as a small benefit with significant edge cases. Authors are already expected to supply the textual content in the page, the text in alerts, etc., so providing the text in the validation failed UI doesn't seem that bad. The UA can still do things like turn fields red or add warning sign icons or something if it likes. PK
Re: [whatwg] Request to reconsider input minlength=
On Thu, Oct 29, 2009 at 3:03 PM, Ryan Cannon r...@ryancannon.com wrote: In order to correctly report the error to the user, I would have to do a second check of the value to figure out the problem. The only way to determine that the error was caused by too few characters as opposed to invalid characters would be to parse the pattern= attribute in order to determine a minimum length required by the RegExp. I have two problems with this argument: * It assumes you know enough detail of your validation pattern to know that it can fail distinctly for too short versus something else, and you want to report those differently, yet you don't actually know the precise conditions that trigger those errors well enough to code them directly, and instead you have to parse the pattern yourself after-the-fact. This seems like a stretch. * It assumes that too short is semantically distinct from fails validation for other reasons, when other distinctions seem potentially just as important. For example, many password implementations require a minimum number of numeric digits or characters of some other type. Why is too few characters of type X so much less worthy of distinct handling in the spec than too few characters of any type, if the primary use cases here are fields like passwords and usernames? Should an input with minlength smaller than it's value be filled with padding characters? Before or after the value? And what happens to those characters as you type? My answer: the UI should not be altered due to the presence of minlength until validating the input value. There's no need to pad the value or prevent deletion of characters. With maxlength, UAs can provide a version of the user's input that obeys the constraints. Without some form of padding, the same is not true of minlength. The distinction in handling these makes me uncomfortable. I agree with you that if your sole goal is to tell the user that something is too short, minlength saves you a bit of code. I'm not convinced it's compelling enough that it must go in. PK
Re: [whatwg] Web Storage: apparent contradiction in spec
On Thu, Sep 3, 2009 at 6:49 AM, Tab Atkins Jr. jackalm...@gmail.com wrote: You could just *not* specify that LocalStorage is worthless for anything but a cache. This seems like a severe overstatement given the current spec. It's not worthless. It won't be guaranteed to be thrown away all the time automatically like cookies are (due to browsers having what turn out to be low global and per-site limits). Users will have the ability to delete it, but it won't be silently lumped in with cookies. All the spec really says is that UAs should note to their users that sites can keep data about them in Local Storage. This isn't grounds for a tantrum. PK
Re: [whatwg] Web Storage: apparent contradiction in spec
On Thu, Sep 3, 2009 at 3:44 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: And more-than-a-cache-Storage can be explicitly turned off or have its quota dropped to zero. If that's important, the browsers will make it easy. And more importantly, they'll make it *consistent* (within the browser), rather than the user having to figure out how to do it within Flash, then possibly within the next technology that hacks around this lack in browser technology, and the next one... As a UA author I see nothing in the spec that prevents this *now*. If this is important, browsers will expose the ability to blow away all of a site's storages at once. There's nothing to resurrect then. On the other hand, if someone wants a site to keep its permanent Storage, then cookie resurrection isn't a big deal. You're seem to be assuming that either permanent Storage is *really* permanent, or that browsers will never expose a way to delete that data to the user (which amounts to the same). That's silly. The whole *point* of specifying a permanent Storage in HTML is so browsers can produce something that *they* control the UI for, rather than leaving the user's privacy to unknown plugins and other hacky means. Again, this is precisely what we as UA authors can do now, with the current spec. I'm not sure what you're arguing. Our job is to make sure users whose philosophy is like Ian's are as well-served as users whose philosophy is like yours, and our hands are not tied. PK
Re: [whatwg] Web Storage: apparent contradiction in spec
On Thu, Sep 3, 2009 at 3:55 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: Again, this is precisely what we as UA authors can do now, with the current spec. I'm not sure what you're arguing. Our job is to make sure users whose philosophy is like Ian's are as well-served as users whose philosophy is like yours, and our hands are not tied. You may have missed the part where Ian said that, to protect their user's privacy, browsers *must* clear cookies and LocalStorage at the same time. Wrong. This is precisely what I argued that the spec didn't say, and (in agreement) Ian changed the spec so people wouldn't misinterpret it by thinking it said this. This is the precise reason why I don't understand what you're arguing about. PK
Re: [whatwg] Web Storage: apparent contradiction in spec
On Thu, Sep 3, 2009 at 4:08 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: 10 hours ago, Hixie said: The fact that local storage can be used for cookie resurrection means we have to make sure that clearing one clears the other. Anything else would be a huge privacy issue (just as Flash has been). There are a few other remarks in line with this from that email and a subsequent one. Statements in an email are not equivalent to statements in the spec. Ian is rightly concerned about user privacy, and the spec reflects that concern by advising that user agents should try to make this clear to users. But what it does not say is that UAs must clear them at the same time, and the fact that the spec language was changed SPECIFICALLY to try and make this more clear is pretty solid evidence. As I have said before, in the end it's irrelevant what you and Ian want to argue about by email: what ultimately matters is what UA vendors decide to do, which the spec will then reflect. And I find it extraordinarily unlikely that any UA vendor would not implement granular control over local storage. If this doesn't imply that LocalStorage in practice will thus become an ephemeral storage mechanism that is easy for users to accidentally blow away, and thus will be too unreliable for anything beyond a supercookie, then I'd like clear statements to that effect. As it is, theoretical assurances that it's all going to be okay aren't adequate - if any browser *actually* made cookie-clearing *automatically* also clear LocalStorage, we authors can't rely on it. Clear statements aren't going to make you any safer than unclear ones will make you unsafe. A UA vendor can easily decide to violate a clear statement (and this has been done countless times with numerous specs in the past). That said, I have heard nothing from *any* UA vendor that suggests anyone will do what you fear. PK
Re: [whatwg] Web Storage: apparent contradiction in spec
On Thu, Sep 3, 2009 at 4:26 PM, Ian Hickson i...@hixie.ch wrote: There's more wording in a later section on cookie resurrection which gives more background. Does that satisfy your request? I think that later section actually muddies the waters. Something like this would be more clear: If users attempt to protect their privacy by clearing cookies without also clearing persistent storage data, sites can defeat those attempts by using the two features as redundant backup for each other. User agents should present the interfaces for clearing these in a way that helps users to understand this possibility and enables them to delete data in both simultaneously. IMO this achieves what you're trying for while leaving the actual UI design as open as possible. PK
Re: [whatwg] Web Storage: apparent contradiction in spec
On Thu, Sep 3, 2009 at 5:17 PM, Ian Hickson i...@hixie.ch wrote: On Thu, 3 Sep 2009, Peter Kasting wrote: On Thu, Sep 3, 2009 at 4:26 PM, Ian Hickson i...@hixie.ch wrote: There's more wording in a later section on cookie resurrection which gives more background. Does that satisfy your request? I think that later section actually muddies the waters. Something like this would be more clear: If users attempt to protect their privacy by clearing cookies without also clearing persistent storage data, sites can defeat those attempts by using the two features as redundant backup for each other. User agents should present the interfaces for clearing these in a way that helps users to understand this possibility and enables them to delete data in both simultaneously. IMO this achieves what you're trying for while leaving the actual UI design as open as possible. Do you mean this as a repalcement or in addition to what's in the spec now? Replacement. For the Cookie Resurrection section or the User Tracking section? Cookie resurrection section. Although because the comments in both sections are so similar, I'm not sure I see value in having two sections. Just having one, which has this text, seems fine. I don't understand the difference between what you suggest and what the spec says. What is wrong with what the spec says, that is fixed by the above? The key objectionable phrase in the cookie resurrection section is presents data in the persistent storage features ... separately from data in HTTP session cookies. This can be construed to mean that the UA should not _ever_ separate presentation of the stored data in the two features (lest it risk user hazard), when in practice a UA may want UI with some amount of presentation separation (e.g. side-by-side buttons that call up separate dialogs for the data stored in each feature) while still trying to make it clear and easy for users to manage their privacy. I don't believe the spec intends to imply this level of detail about UAs' UI, so I am trying to remove any potential for ambiguity. IMO my suggested text cannot be construed as mandating fine details of the presentation of the data. FWIW, the text in the User Tracking section that says associates them strongly is perhaps also still going too far, for similar reasons. It's not clear precisely what this means, and for some use cases (e.g. gmail storing document drafts for offline editing) the use of persistent storage is not equivalent to an HTTP session cookie; if a UA has some sort of detailed knowledge of the distinctions here, it should be allowed to present data in whatever way is most clear and helpful to the user. The text currently in the spec, while much better than before, still goes beyond noting a risk to users that UAs should highlight, and ventures into the realm of prescribing specific solutions for that risk, which may not always be appropriate. PK
Re: [whatwg] Web Storage: apparent contradiction in spec
On Wed, Sep 2, 2009 at 11:08 AM, Jens Alfke s...@google.com wrote: On Aug 31, 2009, at 12:04 PM, Peter Kasting wrote: If you combine that statement with section 6.1's User agents should present the persistent storage feature to the user in a way that does not distinguish them from HTTP session cookies, then the result is that, when the user requests to delete cookies from a site, the UA will also delete that site's local storage. That is *exactly* the behavior I am concerned about. That's not true. You're misinterpreting a statement about the granularity of control users should have as one about what terminology a UA should use. The [lack of] granularity of control actually is a serious concern, whatever the terminology. It still seems like you are interpreting this statement as saying that the UA must not allow users to keep/clear cookies separately from Local Storage data. While on the face of it that seems like a possible interpretation, I think it's clear that this would be a lousy user experience and detrimental to developers as well. Therefore I am convinced that the intent of the statement is to say that UAs must give users the same _abilities_ to see and clear Local Storage data as they already have with cookies, not that the two things should always be lumped together and made indistinguishable. Of course, Hixie could step in here and clarify what he means. But if he really means what you think he means (that users must not be able to tell a difference or control the two separately) then that seems like obvious grounds for a revolt. The spec already recommends a bunch of things about what users should be shown w.r.t. Local Storage, such as how much space a site is using, so it's clear that a UA that wants to comply with this should is going to need to construct UI that doesn't just use the word cookies everywhere but actually presents the data as here's your locally stored data for this site with local storage content enumerated. Users won't be given a prompt that says clear cookies that, confusingly, clears more than cookies; they'll be given a prompt like clear all locally stored data. The command will have to say something about cookies or it'll confuse anyone but an HTML5 expert. It'd have to be more like Clear cookies and other locally stored data. In general UAs should have separate checkboxes for these on their clear private data UIs. The fundamental problem here is that *some uses of local storage are nothing at all like cookies*, for the same reason that ~/Documents is not the same as ~/Library/Caches. Yes, this is precisely why UAs should present them separately. In the example I gave, the user needs to delete cookies for a site, but absolutely should not delete local storage. For the spec to tell browser developers to present the two as being the same thing makes no sense here. See comment above. PK
Re: [whatwg] Web Storage: apparent contradiction in spec
On Mon, Aug 31, 2009 at 11:12 AM, Jeremy Orlow jor...@chromium.org wrote: Yes, this is pretty disconcerting since there's been OVERWHELMING support for LocalStorage being treated as user-critical on this thread. The spec says basically what you want except that it uses should. It seems like UAs and authors would both be satisfied with this; I don't expect any UA vendor to wantonly discard local storage data. PK
Re: [whatwg] Web Storage: apparent contradiction in spec
On Mon, Aug 31, 2009 at 11:50 AM, Jens Alfke s...@google.com wrote: On Aug 31, 2009, at 11:35 AM, Peter Kasting wrote: Again, the spec now says in 4.3: User agents should expire data from the local storage areas only for security reasons or when requested to do so by the user. The only stronger statement you could get would be by changing this to a must. It's not clear to me that that is going to result in any practical difference on the part of implementations or author perception. If you combine that statement with section 6.1's User agents should present the persistent storage feature to the user in a way that does not distinguish them from HTTP session cookies, then the result is that, when the user requests to delete cookies from a site, the UA will also delete that site's local storage. That is *exactly* the behavior I am concerned about. That's not true. You're misinterpreting a statement about the granularity of control users should have as one about what terminology a UA should use. The spec already recommends a bunch of things about what users should be shown w.r.t. Local Storage, such as how much space a site is using, so it's clear that a UA that wants to comply with this should is going to need to construct UI that doesn't just use the word cookies everywhere but actually presents the data as here's your locally stored data for this site with local storage content enumerated. Users won't be given a prompt that says clear cookies that, confusingly, clears more than cookies; they'll be given a prompt like clear all locally stored data. It seems like you're convinced that UAs won't create UI users can understand, and so you're trying to make the spec mandate what you think will be comprehensible for users. IMO this is not only out-of-scope but pointless, as UAs are going to do what they want anyway. The spec is already pretty clear in telling UAs not to be casual about things, I don't think you're going to change what actually gets implemented by demanding more. This sounds like you are either completely ignoring, or disagreeing with, my claim that UAs aren't going to be flippant about this data. If UA's shouldn't treat the data lightly, then I would prefer to see a statement to that effect in the spec, such as the one that was just deleted. The sentence I quoted in 4.3 says _exactly_ that UAs should not treat data lightly. I think that (no offense) browser developers are not used to taking care of user-critical data for longer than the duration of a DOM tree or POST request. This kind of generalization is just silly. See e.g. saved passwords, extensions, stored browsing history, persistent settings, etc. PK
Re: [whatwg] Web Storage: apparent contradiction in spec
On Wed, Aug 26, 2009 at 4:01 PM, Linus Upson li...@google.com wrote: The analogy was made comparing a user agent that purges local storage to an OS throwing out files without explicit user action. This is misleading since most files arrive on your computer's disk via explicit user action. You copy files to your disk by downloading them from the internet, copying from a network drive, from a floppy, your camera, etc. You put them on your disk and you are responsible for removing them to reclaim space. There are apps that create files in hidden places such as: C:\Documents and Settings\linus\Local Settings\Application Data\Google\Chrome\User Data If those apps do not manage their space carefully, users get annoyed. If such an app filled the user's disk they would have no idea what consumed the space or how to reclaim it. They didn't put the files there. How are they supposed to know to remove them? Most users have no idea that Local Settings exists (it is hidden), much less how to correctly manage any files they find. This seems like an argument for ensuring web apps have as much ability to take reasonable steps to control their space usage as local apps do, not an argument that the UA should be able to discard those files. After all, you are not arguing that Windows should be able to throw away those non-user-visible files in Local Storage. Without automatic space management the local storage consumed will grow without bound. I'm concerned that even without an intentional DOS attack users are going to be unhappy about their shrinking disks and not know what to do about it. The problem is worse on phones. I don't think anyone is suggesting UAs should not have the ability to control the total space usage, e.g. by presetting per-app and global quotas. That's not the same as saying that the UA can throw away data after the fact. Things get worse still if a griefer wants to make a point about the importance of keeping web browsers logically stateless. Here's how such an attack could be carried out: 2a. Acquire a bunch of unrelated domains from a bunch of registrars using stolen credit cards. Skip this step if UAs don't group subdomains under the same storage quota. For extra credit pick names that are similar to legitimate sites that use local storage. 2b. Start up some web hosting accounts. Host your attack code here. If they aren't free, use stolen credit cards. 2c. Buy ads from a network that subsyndicates from a network that subsyndicates from a major ad network that allows 3rd party ad serving. There are lots to choose from. No money? Stolen credit cards. Serve the ads from your previously acquired hosting accounts. 2d. Giggle. The user will be faced with the choice of writing off the space, deleting everything including their precious data, or carefully picking though tens of thousands of entries to find the few domains that hold precious content. User gets really unhappy if the attack managed to fill the disk. I'm not sure why this is more compelling for a griefer than the existing attack (along similar lines) they can already make against the cookie store to blow away 100% of the user's cookies, and keep doing it, such that the user can never log in anywhere. In fact, to some degree that's a testimony that treating things like cookies doesn't mean users will be free from griefing. In practice I don't foresee either of these happening unless doing so allows attackers monetary gain. Chrome's Incognito mode creates a temporary, in-memory profile. Local storage operations will work, but nothing will be saved after the Incognito window is closed. Safari takes a different approach and causes local storage operations to fail when in Private Browsing mode. Some sites won't work in Private Browsing. I don't recall what Firefox or IE do. Pick your poison. This is a problem that has to be solved regardless, and it doesn't seem like a bad one. If the purpose of section 6.1 is to state that UAs must give users the ability to see and clean up their Local Storage data (which seems to me like a good idea but outside the scope of what HTML5 should be specifying), then users have the ability to manually delete this data anyway, and live with the consequences. Chrome's behavior is akin to a user manually clearing his Local Storage data, and Safari's is akin to an app hitting its quota. Apps have to be able to deal with both anyway, perhaps with a (possibly large) reduction in functionality. While that may sound like an argument for your position (since I am saying that apps need to deal with disappearing Local Storage data), the critical difference is that the user is in control of this, either by cleaning up the data manually or by electing to use a private browsing mode. Thus I don't think it justifies some UA behavior when the user is _not_ in explicit control. If the spec requires UAs to maintain local storage as 'precious' it will be the first such
Re: [whatwg] Web Storage: apparent contradiction in spec
On Wed, Aug 26, 2009 at 4:31 PM, Michael Nordman micha...@google.comwrote: A mandate from on high that says 'shall store forever and ever' will be promptly ignored because its impossible to make that guarantee. That's not the proposed mandate. The proposed mandate is thou shalt not discard successfully-written data without explicit user action, which seems implementable to me. Note that this doesn't make claims like the hard drive will not fail, and it doesn't claim that the UA is required to allow the app to write whatever data it wants in the first place. PK
Re: [whatwg] Web Storage: apparent contradiction in spec
On Wed, Aug 26, 2009 at 5:08 PM, Remco remc...@gmail.com wrote: As far as I know, cookies work the same way as the proposed local storage policy: once a cookie is created, the browser won't delete it when space becomes a problem. The site controls the expiration date of the cookie, and it can fill up the entire drive with cookies if it wants to do so. This is all without user interaction. I don't think this has ever been a problem. This is not at all how cookies work. All UAs have various limits (e.g. a per-host and global limit) and purge cookies silently when those limits are reached. It is exactly this model which Linus is proposing for Local Storage. Cookies disappearing causes problems like users not being logged in when they return to a site, sites forgetting user preferences, and (importantly to publishers) ad tracking not working well. All of these are reasons why various sites now use Flash to store cookies instead/in addition. PK
Re: [whatwg] Web Storage: apparent contradiction in spec
On Wed, Aug 26, 2009 at 4:55 PM, Michael Nordman micha...@google.comwrote: What seems inevitable are vista-like prompts to allow something (or prods to delete something) seemingly unrelated to a user's interaction with a site... please, oh please, lets avoid making that part of the web platform. I hate prompts as much as you. Flash uses a model where a site can silently store small amounts of data with no prompts. Because devices have wildly different storage amounts, one could imagine a UA on a desktop machine allowing a site to store, say, 2 MB without prompting, while on a phone the site might only get 20 KB, or maybe none at all. This would mean users would be prompted sooner or more often on a phone, which seems like a reasonable outcome to me given that a phone may have so little storage that serious use of Local Storage may be difficult to impossible anyway. In this world, the hard quotas I suggested become soft quotas which result in some kind of user elevation. A UA could elect not to elevate and just deny the additional space if its authors felt that prompts were evil :) I'm assuming that UA will have out-of-band mechanisms to 'bless' certain sites which should not be subject to automated eviction. If push comes to shove, the system could suggest cleaning up one of these 'blessed' sites if inactivity for an extended period was noticed. But for the overwhelming number of sites in a users browsing history, its a different matter. If the storage APIs are just available for use, no questions asked making the storage just go away, no questions asked, is symmetrical. Blessing involves asking questions... making it go away does too. If we suggest that the user be prompted before anything be written persistently, there are a couple bad outcomes (note that these are problems with Gears today): * The user is asked to make a choice _before_ using the app's functionality, at which point he is ill-prepared to decide how much he likes the app or what it should be able to do * The app author is less-likely to bother to use Local Storage since prompts drive users away, and just uses Flash I think the overall UX from requiring blessing on all persistent data (as opposed to on large data sets) is poorer. PK
Re: [whatwg] Web Storage: apparent contradiction in spec
On Wed, Aug 26, 2009 at 5:42 PM, Michael Nordman micha...@google.comwrote: In addition to the key/value pair storage apis, i think we'd need to make this distinction for databases and appcaches too. This distinction may be better handled in a way not tied to a particular flavor on storage. Or a similar distinction could be expressible within the database and appcache interfaces. window.openPermanentDatabase() / openPurgeableDatabase() manifest file syntax games: PURGEABLE or PERMANENT keyword in there somewhere. I think having authors choose between permanent and purgeable storage types adds complexity to the implementation and usage that is not desirable from either an authoring or a UX perspective. I continue to support Brady et al.'s vision of Local Storage. PK
Re: [whatwg] Text areas with pattern attributes?
On Tue, Aug 25, 2009 at 12:05 AM, Anne van Kesteren ann...@opera.comwrote: Also, maxlength cannot be enforced as client-side validation requirement due to compatibility issues. I don't grasp what you're saying here. Are you saying that maxlength or ValidityState.tooLong() cannot be implemented as specced? PK
Re: [whatwg] HTML 5 clarifications on ValidityState?
On Tue, Aug 25, 2009 at 12:50 AM, Alex Vincent ajvinc...@gmail.com wrote: The validationMessage attribute must return the empty string if the element is not a candidate for constraint validation or if it is one but it satisfies its constraints; otherwise, it must return a suitably localized message that the user agent would show the user if this were the only form with a validity constraint problem. If the element is suffering from a custom error, then the custom validity error message should be present in the return value. Specifically, the last sentence contradicts the rest of the paragraph. If there is a custom error, but the element is not a candidate for constraint validation, should the validationMessage attribute be empty, or should the custom validity error message be present in the return value? You can't have both. I believe the intent is that an element which is not a candidate for constraint validation cannot be suffering from a custom error (just as it cannot be suffering from any other validation error). However, I'm not sure why elements which are barred from constraint validation (fieldset, output) have a setCustomValidity() method; perhaps so that authors could blindly iterate over all form-associated elements and call this method? PK
Re: [whatwg] formNoValidate/novalidate/willValidate
On Tue, Aug 25, 2009 at 7:56 PM, Dean Edwards dean.edwa...@gmail.comwrote: Looking through the spec I see the following DOM properties: * formNoValidate * novalidate * willValidate novalidate sticks out like a sore thumb. Can we change it to noValidate. It's only mentioned in the IDL so maybe it's a typo. IIRC when we (my GSoC student and I; he's been working on form validation in WebKit) encountered this recently, we assumed it was a typo, and I used the snazzy little file a bug from directly on this page UI on the spec to note it. PK
Re: [whatwg] Text areas with pattern attributes?
On Mon, Aug 24, 2009 at 9:08 AM, Chris Taylor chris.tay...@figureout.comwrote: It's been mentioned before about limiting the length of text permissible in a textarea element, specifically for forums. textarea is defined to support maxlength already ( http://www.whatwg.org/specs/web-apps/current-work/#the-textarea-element ). I think pattern is significantly less valuable than maxlength, but it wouldn't be too difficult to add support for it. I vote weakly against. PK
Re: [whatwg] type=email validation is too loose for practical applications
On Mon, Aug 24, 2009 at 5:19 PM, TAMURA, Kent tk...@chromium.org wrote: http://www.whatwg.org/specs/web-apps/current-work/#e-mail-state A valid e-mail address is a string that matches the production dot-atom-text @ dot-atom-text where dot-atom-text is defined in RFC 5322 section 3.2.3. [RFC5322]http://www.whatwg.org/specs/web-apps/current-work/#refsRFC5322 I'd like stricter rule for it. e.g. dot-atom-text @ 1*(ALPHA / DIGIT) 1*(. 1*(ALPHA / DIGIT)) I understand the current production, dot-atom-text @ dot-atom-text, is a subset of addr-spec of RFC 5322. However dot-atom-text for the domain-part is not practical. The production accepts apparently unusable email address like tk...@ It would have been nice to send this email as a reply to the current discussion about type=email validation (several messages sent earlier today), especially since the argument there is for _less_-strict validation. PK
Re: [whatwg] Removing versioning from HTML
On Fri, Aug 14, 2009 at 12:35 PM, João Eiras jo...@opera.com wrote: From an implementor's point of view it is much harder to implement and keep up with a mutating specification. During implementation a stable spec is preferred. As a browser implementer, I have certainly not found the dynamic nature of the spec to be a problem. In fact the opposite is true: problems in the spec can be fixed quickly when they're raised. Currently, because specs are being edited and might take a while to get to CR, we have different implementors implement different parts of the specifications, and then meanwhile the specification mutates and implementors have to waste time updating their implementation which could have been right from the start. I understand that implementation feedback is necessary, but this is not very optimal. As opposed to if we froze versions, which would mean implementers would implement part of the old specification, and meanwhile the new spec has changed it. In other words, I don't see how versioning reduces this problem at all in practice. Furthermore, you seem to be proposing versioning well in advance of CR status, since you say it will take time to reach CR. What is the metric by which we'd decide to freeze a spec, then? PK
Re: [whatwg] Installed Apps
On Tue, Jul 28, 2009 at 9:24 PM, Michael Davidson m...@google.com wrote: These are true, but leave out the part that rewriting large apps to the worker API is nontrivial. A major advantage of a hidden page (as you mention below) is that the programming model is well known, and easy for web developers to adapt to. I don't know enough about this specific case to comment, but in general I am scared of arguments like Model A would be better, but right now people are using something closer to model B because it can enshrine for all eternity something that browsers have to support, based on what people happen to be good at at the moment. - As for persistence beyond browser lifetime, I understand the reticence. However, similar problems have been solved in the past. Flash asks the user for access to hardware like cameras. Surely being able to take pictures of users is as scary as running code after the browser has closed. Not at all. Malware can't set up a darknet using cameras. Your CPU, disk and RAM are much more valuable to a malicious coder than your camera. The rest of your argument may still be true, I'm just not convinced by this analogy. PK
Re: [whatwg] Installed Apps
On Tue, Jul 28, 2009 at 9:39 PM, Michael Davidson m...@google.com wrote: Personally, I'd rather have my CPU and RAM used to send spam than to have pictures of me in my underwear publicly placed on Facebook. The rest of the world would rather not receive that spam, and would probably rather we didn't write systems enabling it on massive scales. PK
Re: [whatwg] Installed Apps
On Tue, Jul 28, 2009 at 9:47 PM, Michael Davidson m...@google.com wrote: I agree 100%. I'm only trying to argue that from a user perspective, access that we currently have acceptable UI for, e.g. camera hardware, is about as scary as agreeing to let a web app run in the background. The whole point is precisely that most users will have _utterly no idea_ what letting an app run in the background means or if it's scary, which is dangerous when combined with the fact that to an actual malware author it's far more valuable than getting access to the camera. I find it highly unlikely this distinction can be explained, or that users should even have to care. I'm not proposing a UI design -- I'm just suggesting that copying existing permissions UIs such as the one Flash uses for camera access may be a poor choice. (My instinct is that, like with Fx extensions or Android apps, users should probably just make an all-or-nothing decision one time, up front, and we should do our best to give them relevant info like ratings.) PK
Re: [whatwg] A New Way Forward for HTML5 (revised)
On Mon, Jul 27, 2009 at 12:06 PM, John Foliot jfol...@stanford.edu wrote: That said, the barrier to equal entry remains high: http://burningbird.net/node/28 I don't understand. That page says We're told that to propose changes to the document for consideration, we need to ... and then a long list of things. But that seems untrue. To propose changes, all you need to do is write them, anywhere you want (in an email, on a webpage, whatever) and notify people. If we had to do everything that page lists in order to propose changes, I'd be upset too. But we don't. A simple email works. I'm beginning to suspect that this whole line of conversation is specific to RDFa, which is a discussion I never took part in. PK
Re: [whatwg] A New Way Forward for HTML5 (revised)
On Sun, Jul 26, 2009 at 7:16 PM, Manu Sporny mspo...@digitalbazaar.comwrote: I'm not proposing that we allow people to directly stomp all over Ian's specification - that wouldn't help anything. I am also not suggesting that Ian should change how he authors his HTML5 specification. What I'm proposing is that others should be able to easily create lasting alternate language, modified sections, remove sections or add sections IN THEIR OWN SANDBOX and generate alternate specifications based on Ian's HTML5 specification. We should provide the tools to enable that. OK, this clarifies some of my confusion in my last response. I do not understand what advantages this would provide over the current system. Here are some use cases: * If one simply wants an easy way to comment, one can now use the new comment-in-the-spec-itself tool Ian has added. * If one wants to share a more detailed proposal for discussion, one can post it on this email list. * If one wants to broaden discussion beyond this list or post long, detailed proposals, one can put up the proposal on the web and link to it (here and elsewhere). * If one wants the proposal to mirror the language of the spec, one can copy and paste language from the spec to edit. What use case outside these are you seeking to aid? What would the tool do that copy-and-paste will not do? How is (whatever it is that tool does) critical to the use case, such that it cannot be well-solved now? So far you have not given a use case (that I've seen) so much as a vague assertion that because the number of spec contributors is in the hundreds rather than tens of thousands, there is some not-well-defined barrier to entry in the above list. PK
Re: [whatwg] A New Way Forward for HTML5
On Thu, Jul 23, 2009 at 2:48 PM, Manu Sporny mspo...@digitalbazaar.comwrote: contribute ideas: great! scrutinize them: wonderful! form consensus: fail (but that's what the W3C is for, right?) produce: fail (unless we don't want to scale the community) Ian is really the only one that is actively allowed to produce anything of significance in WHAT WG. In general, if he doesn't agree with you, it doesn't go in. It's already been stated explicitly multiple times in the past that the HTML5 process is not ultimately consensus-driven, so this shouldn't be news to anyone. I for one consider that a feature, not a bug. I think it's fair to say that one needs to have a pretty significant chunk of time on their hands as well as technical chops to make a contribution to the HTML5 specification. Incorrect. All sorts of people have made contributions of small corrections, opinions on issues, spec proposals, etc. Ian has publicly committed to reply to every email and so far I see him doing precisely that; frequently this results in spec changes. When people's opinions are ultimately rejected, it is not without due consideration first. To approach the issue from another angle, we have roughly 1,000 members on this mailing list and could have close to 1 billion people[1] that could be using some form of HTML by 2012, a number of those are web developers (read: a huge developer base). The Linux kernel mailing lists have close to 30,000 members[2], and I don't think it's a stretch to say that there are fewer kernel developers in the world (read: small developer base) than there are web developers and designers. So, I've been wondering about the 30:1 discrepancy. You're comparing non-analogous situations. LKML is inherently of interest to all kernel developers, pretty much by definition. The HTML spec creation process is not inherently interesting to all web developers. A closer analogy would be to the engineers working on HTML support in UAs. I suspect that this mailing list _is_ inherently of interest to that group. We don't give anybody the impression here that they could directly impact the specification if they so desired. If people sending emails containing proposals, and having the editor directly respond to all of those emails, frequently by changing the spec, does not give you the impression you can impact the specification, I'm not sure what would. I can git clone the Linux kernel, mess around with it and submit a patch to any number of kernel maintainers. If that patch is rejected, I can still share the changes with others in the community. Similarly, nothing prevents UA authors from coding any feature they wish and hoping it will gain traction. Similarly, nothing in the HTML5 process prevents anyone from proposing a feature that has been rejected by HTML5, and attempting to convince UA authors to support it directly. To the degree that these don't happen, it is because practical considerations make success unlikely: it is much more difficult for a random web developer to convince a vendor to support his idea in a particular UA than for a random coder to post a patch online alongside a modified kernel build. (However, it is not impossible: at least Firefox and Google Chrome can be built, as non-branded versions, from source by any interested party; and in fact that capability has been used for precisely the above purposes: see e.g. Iceweasel.) Similarly, people that are creating user agents tend to not care about examples (in general) Speaking as one of those people, you are completely mistaken. Examples are highly useful to UA authors. And implementation details are occasionally useful to web developers, insofar as they document expected behaviors very precisely and thus are useful when trying to test how real-world UA behaviors differ. I think the only valid point here is that web developers trying to read the spec directly probably want the implementation details as a reference rather than inline. They should be able to edit /something/ lasting, publish it for review, and rise or fall on the merits and accuracy of their specification language. They are not being given the opportunity to do so. Anyone can post a proposal anywhere on the web, which they themselves edit. If they want the imprimatur of the WHATWG, then it seems reasonably to expect that that proposal would have to be accepted by the editor(s) of that group. I'm not sure why there is a perceived lack of clarity here. Rejected proposals are always given concrete rationale for rejection (IMO). it was meant as a feeler document to see how this community would react to the proposed changes. For my part, I would be very unhappy to see the HTML5 process made more consensus-driven; I much prefer systems that approximate benevolent dictatorships, and I don't perceive the current leadership of the group to be insufficiently responsive to communication. PK
[whatwg] input type=tel validation, and a small set of typos
Two unrelated comments. First, it seems a bit odd to me that input type=email and input type=url are validated (for typeMismatch problems) but input type=tel isn't. I know it's prohibitively difficult to perfectly validate telephone number formats given the variety around the world, but it's also prohibitively difficult to validate email addresses per the relevant RFC, which is why HTML5 specs a much simpler algorithm that at least rejects obviously bad input. It seems like perhaps input type=tel could set typeMismatch if the input contained no numeric digits at all, or maybe if it contained characters outside 0-9, +, -, (, ), ' ', ...? Maybe the level of validation provided by these proposals is so low that it's not worth doing, though. Second comment: There are 4 instances of a small typo in attribute lists, where ..., required, size, ... is rendered as ..., required size, See the bookkeeping details portions of sections 4.10.4.1.19, 4.10.4.1.20, 4.10.4.1.21, and 4.10.4.1.22. PK
Re: [whatwg] input type=tel validation, and a small set of typos
On Mon, Jul 20, 2009 at 12:56 PM, Nils Dagsson Moskopp nils-dagsson-mosk...@dieweltistgarnichtso.net wrote: What's with alphanumeric notation ? I think of 555-WHATWG as a possibly valid telephone number. It might be good to have an RFC on that. Or maybe ITU has publicly available documents on numbering plans ? Yeah, I thought of that kind of thing (but didn't mention it). If we don't want to disallow users from doing things like this, there probably isn't a simple enough validation algorithm we can use. It might be nice to mention in the spec why type=tel is not validated the way email and url are, at that point. PK
Re: [whatwg] Should target '_search' be taken as part of HTML 5 spec?
On Tue, Jul 14, 2009 at 3:39 AM, Honza Bambas hon...@allpeers.com wrote: Target '_search' makes a link open in a sidebar (Opera) or sidebar-like window (IE). For some offline web apps would be cool to open sidebar by just one click. In other browsers (Firefox) web content could be open in a sidebar only by creating a bookmark, marking it as to open in a sidebar, use (click) that bookmark. So, there are tendencies and voices to open web content in a sidebar in all browsers but it is not taken as a standard. I would really like this feature to be available in all browsers. Not all browsers support sidebars. Notably, Google Chrome has no such concept. I'm also not sure why search semantically means open in a sidebar. Those two aren't really related in my head. PK
Re: [whatwg] Codecs for video and audio
On Tue, Jul 14, 2009 at 11:14 AM, Mike Shaver mike.sha...@gmail.com wrote: which led me to believe that YouTube's opinion was part of the relevant-vendor positions which led to the choice to not specify a codec. If it's not relevant, then its inclusion was certainly quite confusing I am referring to emails sent after that point (sorry, don't have direct quotes handy) which, IIRC, said that the reason Theora was not named a baseline codec was Apple's decision not to support it, and that if people convinced Apple to support it, that decision would be changed. It makes sense if you think about it -- whether YouTube sends videos encoded as H.264 is irrelevant to what the _baseline_ codec for video needs to be, it is only relevant as additional info for vendors deciding whether to support H.264. PK
Re: [whatwg] Serving up Theora video in the real world
On Mon, Jul 13, 2009 at 1:43 AM, Philip Jägenstedt phil...@opera.comwrote: Also, I've reported bugs on Safari and Chrome (I think, neither give confirmation that the report has been sent successfully!) That's odd. Both bugs.webkit.org and crbug.com tell me when I've filed a bug, and give me the bug number for reference. How did you file your issues? (Feel free to respond privately if you want, in order to avoid spamming the list) PK
Re: [whatwg] Codecs for audio and video
On Wed, Jul 1, 2009 at 2:41 AM, Anne van Kesteren ann...@opera.com wrote: On Tue, 30 Jun 2009 21:39:05 +0200, Peter Kasting pkast...@google.com wrote: There is no other reason to put a codec in the spec -- the primary reason to spec a behavior (to document vendor consensus) does not apply. Some vendors agreed, and some objected violently is not consensus. The vendor consensus line of argument seems like a very dangerous slippery slope. It would mean that whenever a vendor refuses to implement something it has to be taken out of the specification. I.e. giving a single vendor veto power over the documentation of the Web Platform. Not good at all in my opinion. I am merely echoing Hixie; from his original email in this thread: At the end of the day, the browser vendors have a very effective absolute veto on anything in the browser specs, You mean they have the power to derail a spec? They have the power to not implement the spec, turning the spec from a useful description of implementations into a work of fiction. That's something I would have considered before the advent of Mozilla Firefox. Mozilla also has the power of veto here. For example, if we required that the browsers implement H.264, and Mozilla did not, then the spec would be just as equally fictional as it would be if today we required Theora. My sole goal was to try and point out that the situation with codecs is not equivalent to past cases where vendors merely _hadn't implemented_ part of the spec; in this case vendors have _actively refused_ to implement support for various codecs (Apple with Theora and Mozilla(/Opera?) with H.264). PK
Re: [whatwg] Codecs for audio and video
I don't believe Chris was speaking in any official capacity for YT or Google any more than I am. I think it is inappropriate to conflate his opinion of the matter with Google's. I have not seen _any_ official statement from Google regarding codec quality. As an aside, I think taking the available recent public comparisons as definitive proof that Theora is (or is not!) comparable to H.264 is inappropriate (and goes further than the Theora developers have). Codec comparison is tricky and broad, and a definitive comparison (which I have not performed) would require a large variety of types/quality of input, compressed with many different option choices, and compared on both subjective and objective criteria. It also would include coverage of issues like how much buffer is needed to ensure continuous play, whether the quality can be dynamically degraded, storage space and CPU usage required on th encoding side, device support (current and projected), etc. Or, to simplify, you're oversimplifying in your declarations that one codec is as good as another. PK On Jul 1, 2009 9:55 AM, David Gerard dger...@gmail.com wrote: 2009/7/1 Ian Fette (イアンフェッティ) ife...@google.com: all of Google to suddenly release all of its information that has legitimate business reasons f... I think it is reasonable to expect Google to address their statements of reasons being demonstrated false, however. They have notably failed to do so. Is Chris DiBona still reading? Oh sorry, I was completely wrong or you're wrong and here's why would go a long way to restore any trust in Google on this matter. - d.
Re: [whatwg] Codecs for audio and video
* I didn't say 5 years from Rec status * Acid3 was meant to be an illustrative example of a case where the test itself was not intentionally introducing new behavior or attempting to force consensus on unwilling vendors, not a perfect analogy to something PK On Jun 30, 2009 12:36 PM, Sam Kuper sam.ku...@uclmail.net wrote: 2009/6/30 Peter Kasting pkast...@google.com On Jun 30, 2009 2:17 AM, Sam Kuper sam.ku...@uclmail.net wrote: 2009/6/30 Silvia Pfeiffe... As a contributor to multiple browsers, I think it's important to note the distinctions between cases like Acid3 (where IIRC all tests were supposed to test specs that had been published with no dispute for 5 years), much of HTML5 (where items not yet implemented generally have agreement-on-principle from various vendors) and this issue, where vendors have publicly refused to implement particular cases. [...] I'd question, based on the following statements, whether your memory of Acid3 is correct: Controversially, [Acid3] includes several elements from the CSS2 recommendation that were later removed in CSS2.1 but reintroduced in W3C CSS3 working drafts that have not made it to candidate recommendations yet.[1] The following standards are tested by Acid3: [...] * SMIL 2.1 (subtests 75-76) [...][1] SMIL 2.1 became a W3C Recommendation in December 2005.[2] [1] http://en.wikipedia.org/wiki/Acid3 [2] http://en.wikipedia.org/wiki/Synchronized_Multimedia_Integration_Language#SMIL_2.1 So, there is some precedent for the W3C to publish specs/tests, expecting browser vendors to catch up with them further down the line. Sam
Re: [whatwg] Codec mess with video and audio tags
On Fri, Jun 5, 2009 at 5:24 PM, King InuYasha ngomp...@gmail.com wrote: The HTML 5 specification should definitely support a codec that fulfills the following legal criteria: At the end of the day, the spec does not mandate vendor behavior; rather vendor consensus informs the spec. For various reasons that (as roc mentioned) it is usually unhelpful to speculate on, there has been no vendor consensus on codecs. Perhaps that will change in the future as Google ships a browser with Theora and H.264 enabled, or as Xiph improves the quality of Theora, or as websites begin using some codec(s) broadly. Or perhaps it will not. I doubt anyone has a crystal ball. I do note that in a vacuum, there isn't a problem with not specifying any codec, as IIRC no codecs are specified for the img tag and yet practically most browsers implement a common subset and the web basically works. PK
Re: [whatwg] Google's use of FFmpeg in Chromium and Chrome
On Sun, Jun 7, 2009 at 6:41 PM, Robert Sayre say...@gmail.com wrote: I wrote about the practice of shipping encumbered software and calling it open. Where is the language where Google is calling H.264 open? The closest I know of is Google Chrome is made possible by the Chromium open source project and other open source software (from Tools-About Google Chrome), which links to a page containing links to the FFMPEG homepage and license. I don't see that as saying what it sounds like you claim something somewhere is saying? In the end I personally view hostility towards patent-encumbered video formats the same way I view hostility toward non-GPL free software licenses: a stance I understand, but not one I agree with. More importantly for this thread in particular, I'm not sure what the purpose of stating that opposition here is. I thought the purpose of this thread was to resolve questions people had about the use of FFMPEG vis-a-vis its license. This is probably going to be an ineffective forum if your hope is to dissuade Google from shipping H.264 support. PK
Re: [whatwg] Google's use of FFmpeg in Chromium and Chrome
On Sun, Jun 7, 2009 at 7:43 PM, Gregory Maxwell gmaxw...@gmail.com wrote: I don't think the particular parallel you've drawn there is the appropriate one. And I think you failed to answer the line in my email that asked what the point of this tangent is. PK
Re: [whatwg] Codec mess with video and audio tags
On Sun, Jun 7, 2009 at 8:13 PM, King InuYasha ngomp...@gmail.com wrote: Google, Apple, and the other naysayers for Ogg video I think you are officially Wasting Our Time when you say something like Google... and the other naysayers about a company that is _shipping Ogg audio and video support in a product today_. PK P.S. I don't know what your point about BMP was. In the spirit of sharing information utterly irrelevant to the thread, I wrote Chromium's BMP decoder. How does that help you? I don't know, just like I don't know how this whole email series helps anyone. Sigh.
Re: [whatwg] Suitable video codec
On Thu, May 7, 2009 at 5:51 PM, David Gerard dger...@gmail.com wrote: The Thusnelda coder is outdoing H.,264 in current tests: Be careful how glowing you make this sound -- this is on a particular objective test (not subjective, and thus perversely less accurate in reflecting how good do people think this looks), and only based on one video clip. That's not to diminish the Theora work at all -- the results are also subjectively better IMO, and Theora getting better is a win no matter what. PK
Re: [whatwg] cross-domain scrollIntoView on frames and iframes
On Sat, Apr 4, 2009 at 12:56 PM, timeless timel...@gmail.com wrote: sounds like a security nightmare. Can you be less vague? We've had a number of security people vet this already, so specific complaints would be very helpful. PK
Re: [whatwg] Input type for phone numbers
On Tue, Mar 31, 2009 at 10:22 AM, Boris Zbarsky bzbar...@mit.edu wrote: I agree that entering a week is pretty rare, though. ;) As someone working on supporting new input types in WebKit: Supporting any one form of date is nontrivial, but supporting the rest after you support the first _is_ trivial. So while I'm on the week is not that useful bandwagon, it'll be simple to support once date is supported. PK
Re: [whatwg] Input type for phone numbers
On Tue, Mar 31, 2009 at 12:58 PM, Maciej Stachowiak m...@apple.com wrote: It depends on the quality of implementation you want to deliver. With a nice visual date picker, the UI for picking a month or a week is probably quite different from the UI for picking a day, which in turn would be different from the UI for picking a time, or a date and time together. For instance, a day picker would probably only show you month or possibly a 2 or 3 months at a time, whereas that would not make sense for a month picker. Just having a type-in box with no visual picker would result in a control that would likely not be usable for the kinds of sites where you enter dates. Have you looked at Opera's implementation? it supports all these various types, and is not too bad. Regardless, from the browser's perspective, these are all pretty equally easy, since the expectation is that each platform just invokes a system date picking object when the user clicks on the control to request one... But we're getting off track. PK
Re: [whatwg] Spellchecking mark III
On Wed, Jan 28, 2009 at 2:35 AM, Křištof Želechovski k...@mimuw.edu.plwrote: *No, the _original_ use was to turn it on on fields where it would otherwise have been on. * I do not understand. If spell checking would be on, why turn it on explicitly? I mistyped. The last word should have been off. If the control is not expected to contain a private language, it should be subject to spell checking. This thread has already had multiple examples of cases where this is untrue. Spelling quizzes, address fields, etc. And even if it were true, it's not the way browsers behave today (e.g. Firefox does not spellcheck single-line fields, precisely to avoid a lot of cases like this), and changing those defaults to be something non-annoying, using complex heuristics, is significantly harder (in terms of your time/money cost below) compared to supporting the attribute. Avoiding an additional attribute is a gain, Why? Because adding an additional attribute costs time and money. To whom? What tradeoff are you making? Keying spellchecking off language support costs engineering time too, for the UA. And for a web author. All changes have costs. The point here seems like a vague principle rather than a specific application. Which no one will ever use, because users aren't going to take the trouble to declare such a thing when human recipients can just _read the text_. After all, WE have built-in language detectors in our heads. We disagree here but further discussion is void unless you have the resources necessary to perform an investigation of the subject. If you need data to prove that people will not make the effort to explicitly tell recipients what languages their messages are in, I offer you the entire history of written communication, where people don't say By the way this is in English! at the top of each letter. Users entering text in a foreign language cause trouble to the forum moderators who have to discipline them. Thus, the software could accommodate to the needs of the moderator, so that the poster gets warned before posting, not admonished afterwards. This is more convenient and less work for everyone. Providing an indication what language is recommended by forum users is good, because most users would take that into account (for fear of getting plonked, if not for good manners). How is this relevant to a discussion about spellchecking? If you want UA-based language detection facilities that are, say, accessible from JS, that may be a reasonable request, but like much of this discussion, it seems tangential. PK
Re: [whatwg] Spellchecking mark III
On Wed, Jan 28, 2009 at 10:27 AM, Křištof Želechovski k...@mimuw.edu.plwrote: Spelling quizzes are an artificial example; they are not interesting once spell checking is commonly available because the user can cheat by temporarily using another control that is being checked. They can cheat today by pasting something into Microsoft Word. Or looking it up in a dictionary. That doesn't mean there's no value in this. There are many internet quizzes where you can cheat by looking answers up with a search engine, but they're still fun and wildly popular. Your argument that because people could cheat no author would, or should, want to write such a thing does not seem supported by evidence. Address fields contain data in a technical language, not in a natural language. Of course, the browser can support technical languages by checking the syntax and validity of data as well (e.g. matching the zip code against the place using an external database). This seems rather far afield from spellchecking. There's a whole section of the spec (forms) that deals with validation of various kinds of form input. It's separate from spellchecking for a reason: the algorithms are completely different (and a potential rabbit-hole). From my perspective as a UA author that actually writes the code to do this stuff, you're conflating too many kinds of input validation here. People do not say this is English but machines do (Content-Language MIME header). And that header content is not generally set by explicit user action. In fact, it's often not set at all, or set incorrectly. Hoping that this will change seems naive. I want incorrect input, including input in an unexpected language, to be marked as such by the spell checker. I already said that having a general-purpose, JS-accessible language detector might be a good thing. It would certainly be a necessary thing for this request. Once one had it, the request would be better addressable without touching the behavior of the browser's spellchecker at all, because the author could use the output of the language detector to display any message or take any action he desired, rather than simply having the UA draw a line under every word and thus look completely broken. What you want is better accomplished by means other than what you propose, and what you propose does not address the use cases for the spellcheck attribute. I'm not sure we can reach further agreement, so I leave this subthread in Hixie's hands. PK
Re: [whatwg] Spellchecking mark III
2009/1/27 Křištof Želechovski k...@mimuw.edu.pl The original use of the spellcheck attribute was to switch spell checking off No, the _original_ use was to turn it on on fields where it would otherwise have been on. (I think we both believe it should generally be on). Using a private language for the control would do the trick equally well, without introducing a new attribute. It wouldn't do it equally well, since semantically, it would mean this is of language private, which will be strictly inaccurate. Avoiding an additional attribute is a gain, Why? If the language detection libraries are as good as you claim, why is Firefox unable to use them in a way that is not annoying? Because no one has had the time or energy to devote to this? I have worked full-time on browsers for a number of years now and have never seen any team with the time to fix all the things that could or should be fixed. As I have already mentioned, GMail should provide an option for the sender to inform the recipient about the language used in the message, not for the client-side spell checker, but for the recipient. Which no one will ever use, because users aren't going to take the trouble to declare such a thing when human recipients can just _read the text_. After all, WE have built-in language detectors in our heads. We can drop the suggestion language=auto if you wish, but it would be an explicit way of informing the user that he is allowed to enter text in any language he pleases. As if users aren't going to just enter whatever language they please into any field they wish? We design software that has to accommodate people, not the other way around :) I have no idea whether there are better things web apps and UAs can do w.r.t. communicating what languages are used where. All I know is that both in the abtstract and practically, whether I want a field spellchecked by default is a distinct concern from which language(s) would be used to spellcheck it. Therefore I continue to see the spellcheck attribute as distinct from (though possibly complimentary to) language. PK
Re: [whatwg] Spellchecking mark III
2009/1/26 Křištof Želechovski k...@mimuw.edu.pl Q: Should the localization influence the spell checking mechanism? A: Definitely, since the user is likely to write most messages in his preferred UI language. Which is why this is a perfectly valid input for the heuristic the UA uses to determine the checking language. Q: Is GMail a use case for having spell check without specifying a language to check against? A: No, it is not. You don't provide any reason why not. The user is likely to write most messages in his preferred UI language (which is not true of all users, but leaving that aside) does not imply the user will write all messages exclusively in his preferred UI language. Therefore gmail cannot (correctly) specify the spellchecking language of editable fields. Therefore the UA must decide. Unless the probable input language of a particular field differs from that of the rest of the page, there's no reason for gmail to specify the probable input language of that field. There is no benefit to conflating this concept with should this field be spellchecked. Q: In case when the user decides to use another language, is the user agent free to detect it? A: Yes, it is, unless the language specified is private, which means the field was not intended for checking. Again, this is needless conflation. You gain nothing, and lose both clarity and flexibility, by mapping don't spellcheck to specify the language as private in this way. In terms of the semantics of the page, this is extremely confusing, sicne whether a field should be spellchecked and what language it's in are nearly orthogonal concepts. Q: When the language recognition technology advances to an acceptable state, will it be possible to extend the language attribute to explicitly request automatic identification of the language? A: Yes, it is. Just specify lang=auto or whatever is agreed upon. There is no benefit to forcing authors to say lang=auto. What have you gained? What if they _don't_ say this? (The HTML5 spec must still say what the UA behavior is.) Language detection libraries today are already extremely good, far more reliable than anything explicitly set ahead of time by authors _or_ users. Unless I am completely misunderstanding you, I think your suggestions fail to solve the original use cases for the spellcheck attribute, add needless burden on web authors, and would be completely ignored by UAs who wished to provide a good user experience. PK
Re: [whatwg] Spellchecking mark III
On Sun, Jan 25, 2009 at 10:52 AM, Křištof Želechovski kri...@wp.pl wrote: Gmail can use 1. the localisation preferences chosen by the user in GMail configuration, 2. the localisation preferences chosen by the user in the browser configuration to determine the what language the user is likely to use in the subject field. (Generally, it should be the same language as the Subject label is in.) If the user incidentally sends a message in another language, the Web browser can recognize the language after the subject is typed, as described before. But your original claim was that the web author, not the UA, should have the ability to force a particular language for spellchecking -- and that the spellcheck attribute was worthless outside this, as what authors needed was a way to force the spellcheck _language_, not simply its presence. Now you seem to be reversing your comments and indicating that perhaps the UA may end up knowing better what language to use (e.g. because the user types in another language), which is what I was saying all along. And none of this gives any support for the idea that spellcheck as an attribute is not useful for gmail! Why should gmail have to try and guess what lanugage the user will be typing emails in? Isn't it instead desirable to tell the UA if you can figure out the right language here, then go ahead and spellcheck this field and leave everything else in the hands of the UA? PK
Re: [whatwg] Spellchecking mark III
On Wed, Jan 21, 2009 at 1:15 AM, Mikko Rantalainen mikko.rantalai...@peda.net wrote: If the browser does not know the language of the content, how on earth is it supposed to *correctly* spellcheck it? As others have noted, the user's preferences are generally a better indicator of how something should be spellchecked, for a number of reasons. (Bill Corry's email was on-point here.) I'm daily hitting a situation where browser is trying to spellcheck content with incorrect language. I've toggled such automatic spellchecker off and those will stay off until correct language is detected. As I said, this seems a separate problem to me. Dynamic language switching or multi-language spellchecking based on various heuristics seems like the solution here. This applies to any spellchecked field anywhere and is separate from the issue of whether an author wants to tell the UA that a field is even appropriate for spellchecking or not. My second sentence was trying to argument that page author has no business forcing the spellchecking on if the page author cannot force the spellchecking language! I disagree completely. Consider one of the original use cases for this: Gmail instructing UAs to spellcheck the optional Subject field of a mail. There's no way Gmail can know what language(s) the user may type in this field, but it's still appropriate to tell the UA that the field is appropriate for spellchecking. At this point it's up to the AU to determine what language to use. I also take issue with the word force, which is imprecise. The spellcheck attribute spec was carefully written to ensure that the user and UA have ultimate control over whether spellchecking actually occurs, regardless of what the author specifies; the attribute is a hint to the UA, not force. Forcing a spellchecking on with incorrect language would harm the user! A good reason why the UA's spellchecking language should not be determined by the author (and thus why your proposal leaves me cold). On the other hand, if the content language is explicitly defined, then the user agent has the required knowledge to decide if the spellchecking should be enabled or disabled. There's no need for the spellcheck attribute. The UA does not know which fields actually contain language and which simply contain strings of characters. Enumerating input types (e.g. this field contains email addresses) can address this, but suffers from two problems: * There are an unbounded number of input types, potentially * Types should perhaps not always be treated equally. For example, if an author wrote a spelling quiz, then input boxes for a user to type in would contain words and thus be of a spellcheckable type, but the author would clearly prefer the UA not spellcheck them :) If we can persuade content authors to specify the correct content language, Proposals that sound like if we could just get authors to write valid, semantic content with no errors... have always seemed naive to me. PK
Re: [whatwg] Spellchecking mark III
On Wed, Jan 21, 2009 at 7:38 PM, Calogero Alex Baldacchino alex.baldacch...@email.it wrote: Why not to let the user choose the language, as it happens in word processors? A UA can't choose accurately whether, for instance, color is a correct American English, a wrong British English, or even a correct (truncated) Italian word, while a human can do it better, thus a UA could provide an interface to change the language for a selection spellchecking, or even for each mispelled word, starting from a hint language, which could be the value of an element lang attribute (beside a default value and a user-preference forced one - the latter bypassing any authored value). Also, using the lang attribute value as the start language to check (if not in contrast with a user preference) would allow an interactive interface with a script changing that value according to a user's choice (UAs could also expose a list of supported languages). I'm not sure I fully grasped everything here, but what I did grasp sounds very much like a cross between what Chromium is doing today and what we want to do in the future (I imagine similar things are true for other browser vendors). User specification and page hints are both useful tools for a UA. But I still claim that all of those aspects are outside the scope of the spellcheck attribute, and fall into the realm of things that should not be in the HTML5 spec as they're very much UA-specific behavior. PK
Re: [whatwg] Spellchecking mark III
2009/1/20 Mikko Rantalainen mikko.rantalai...@peda.net I agree. I think that specifying the spellcheck attribute would be a mistake. It allows only forcing the automatic spell checking on or off but it doesn't help a bit to allow mixing different languages on a single page. I don't see how the second sentence is an argument for the first. Just specify that spell checking must follow the content language. How many pages specify the content language? AFAIK the farthest most authors get is to specify the encoding, and even that is frequently done wrong, and browsers have all kinds of crazy heuristics to try and second-guess authors. This seems like it would make spellchecking function very poorly on the web at large, whereas adding the spellcheck attribute at worst would not harm anyone. As the lang attribute can be used in inner elements, too, it allows mixing different languages on a single page and it allows UA to apply different spell checkers to different parts. Again, this seems somewhat orthogonal to the spellcheck attribute discussion. Pages which mix languages are of interest to the Chromium development team, too, and we have ideas on how to make life better for those users -- but none of those ideas intersect the spellcheck attribute in any way. I think your post is tangential. PK
Re: [whatwg] Spellchecking mark III
On Tue, Dec 30, 2008 at 3:38 AM, Ian Hickson i...@hixie.ch wrote: The same engineers have since implemented this feature in Chrome also, Incorrect. One engineer implemented a crude hack in a small portion of the Chromium glue code that implements a fraction of the spec -- enough to make Gmail work a little more nicely, and that's about it. On Wed, Dec 31, 2008 at 7:15 AM, Maciej Stachowiak m...@apple.com wrote: 2) The proposal Hixie linked seems way overengineered for this purpose. First, it allows spellchecking to be explicitly turned on, potentially overriding normal defaults, but that seems wrong; an input type=email should never spellcheck regardless of the page author says. I can't see any valid use case for the author turning spellchecking on regardless of UA defaults or user preferences. Email subject line boxes. In Firefox (where I implemented support for this attribute matching Hixie's spec), the default is to spellcheck multiline boxes and not single-line boxes, which meant that webmail subject line fields would not be spellchecked by default. Second, it allows spellchecking to be controlled at a finer granularity than editability, for which again I think there is no valid use case. Besides the above example in the positive direction, the negative direction is, again, editable fields which you don't want spellchecked, e.g. email recipient list fields (which may be multiline and contain whitespace). I agree with Roc that it is not practical for UAs to detect (via heuristics) which fields should and should not be checked in all cases, and spellchecking desirability seems finer grained than editability to me (not completely orthogonal, as I don't think non-editable fields should ever be spellchecked). I also agree with Roc that this is not complicated, in practice, to implement. It was a tricky patch for me in Firefox since I was not familiar with any of the associated code, but the actual logic of the spec was not hard at all. I support adding Hixie's spec, as-is, to HTML5. It's implemented in Firefox, it's desired in Opera, and there's a bug on file to add support for it to WebKit (which I would like to do someday). PK
Re: [whatwg] Spellchecking mark III
On Mon, Jan 19, 2009 at 4:53 PM, Robert O'Callahan rob...@ocallahan.orgwrote: Actually I was just poking around and noticed that we don't actually support variation of spellcheck values within different parts of an editable element. So I won't make any claims about how hard that is to support. Doesn't the spec only define things on a per-element level of granularity? I wasn't really paying attention to this side-conversation of yours so I didn't think to confirm/refute it. But I don't think the spec in fact covers doing such a thing. PK
