Re: [whatwg] HTML form controls inside of editable area
On Thu, 23 Jul 2009, Alexander Surkov wrote: HTML 5 contentEditable section doesn't define behaviour of HTML form controls inside of editable area explicitly (http://dev.w3.org/html5/spec/Overview.html#user-editing-actions). The question is the following: is behaviour on keyboard or mouse interaction with form controls inside of editable the same like it is for form controls outside of editable area? So that for example if I click on HTML button inside of editable area then will button be clicked and onclick event handler be invoked? Or, for example, if HTML select is focused and I press down arrow key then will selected option be changed? It's obviously some keyboard shortcuts can have one meaning on focused HTML element and another meaning in editable area. It's necessary to define who wins. HTML 5 specification has words confirming implicitly the idea HTML form controls inside of editable area should preserve behaviour. These words are When an editable form control is edited, the changes must be reflected in both its current value and its default value. for select elements it means updating the option elements' defaultSelected DOM attribute as well as the selected DOM attribute which means user should be able to change selected option and therefore it's reasonable to expect form control behaves as usually. Can I get some clarification please? The only thing the spec says that might make the behaviour of form controls different when editing than when not editing is the text you quote. Therefore, by definition, the form controls are unaffected (other than in that small way) by contenteditable. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
[whatwg] Spec comments, sections 3.1-4.7
First, a general remark: what's the difference supposed to be between PASS and BUG? Firefox and WebKit are listed as PASS and BUG in these two cases respectively, for instance: http://www.whatwg.org/specs/web-apps/current-work/multipage/dom.html#interactions-with-xpath-and-xslt http://www.whatwg.org/specs/web-apps/current-work/multipage/dom.html#controlling-the-input-stream The descriptions just say passes all the available test cases for this feature, and has nearly complete support for this feature, but does not yet pass all the relevant test cases. But in both cases, it says Tests: 0. I guess this is an error in the XPath/XSLT section, since all the other parts with no tests list browsers as BUG rather than PASS? In 3.2.3: This specification does not define what makes an HTTP-only cookie, and at the time of publication the editor is not aware of any reference for HTTP-only cookies. They are a feature supported by some Web browsers wherein an httponly parameter added to the cookie string causes the cookie to be hidden from script. Why doesn't the spec define them? In 3.4.1.7: When a pointing device is clicked, the user agent must run these steps: 1. Let e be the nearest activatable element of the element designated by the user, if any. 2. If there is an element e, run pre-click activation steps on it. 3. Dispatching the required click event. . . . The third item's grammar doesn't match the first two. Probably it should be Dispatch instead of Dispatching. In 3.5: I'm not certain what the point of 3.5 is. What agents are supposed to keep track of paragraph boundaries, and what are they supposed to do with them? They don't affect the DOM or rendering as far as I can tell; what do they affect? Should browsers care about them? Conformance checkers? What should authors be aware of, other than not straddling elements across paragraph boundaries? (And why should they care about that? That's not clearly explained either.) In 4.2.3: If there are multiple base elements with href attributes, all but the first are ignored. If there are multiple base elements with target attributes, all but the first are ignored. Why are these notes, and not normative? Do they duplicate normative requirements elsewhere? In 4.2.4: If the attribute is present, then the user agent must assume that the resource is of the given type. If the attribute is omitted, but the external resource link type has a default type defined, then the user agent must assume that the resource is of that type. Why must and not should? Perhaps the user agent has some good reason to think the attribute is wrong. In 4.6.1: suports - supports 4.6.11 and 4.6.12: Most new elements in HTML 5 either add clear functionality (e.g., video) or provide convenient styling hooks (e.g., article). progress and meter seem to do neither. What's the point of these elements, from an author's perspective? Or even from anyone's perspective? What use cases do they fulfill? In particular, it seems like authors would be reluctant to use progress and meter if they couldn't style them. I don't think there's any obvious way to really control the styling of these controls with CSS, so authors would be stuck with whatever color scheme and general feel the UA happens to support. That seems like it would look ugly compared to manually-constructed elements that serve the same purpose. In 4.6.16: pTo make George eat an apple, select kbdkbdsampFile/samp/kbd|kbdsampEat Apple.../samp/kbd/kbd /p That seems excessively baroque. While it's a matter of taste, I guess, I think it would be better if the spec didn't go out of its way to encourage markup that's so excessively nested and unreadable for no apparent purpose. In 4.6.17: When the sub element is used inside a var element, it represents the subscript that identifies the variable in a family of variables. While this is often what subscripts are used for in variable names, it doesn't have to be. For instance, F_\sigma and G_\delta are used in real analysis to refer to a countable union of closed sets and a countable intersection of open sets, respectively. \sigma and \delta here denote somme and Durchschnitt respectively, and don't serve as identifiers in a family of variables in any meaningful sense: they represent the operation of taking countable unions/intersections. This statement should either be removed, or weakened (usually or such) and made informative. In 4.6.26: I don't think it's a good idea to recommend the use of the title attribute for annotations or footnotes. User agents do not normally provide any visual cue if a title attribute is present, to the best of my knowledge, except on abbr elements. Even if some cue is provided, it's unlikely that many users will actually recognize the cue as a suggestion to hover over the element. The large majority of users probably won't realize there's a tooltip. IMO, tooltips should never be used to provide information that's not
[whatwg] question about Web Storage setItem()'s behavior
Hi, I'm implementing the HTML5 Web Storage using Gears (http://code.google.com/p/gear5/), so I have several questions with the spec. -Storage.setItem(key, val) --is key allowed non-string type object? --and when pass non-string object to key/value, is it automatically converted to string?(I'm considering to convert to use String constructor - String(key) ) --when value is null, should `setItem(key, null)` behave as like as `removeItem(key)`? (localStorage.setItem(key, null); alert(localStorage.length); -- what is value displayed?) Shumpei
Re: [whatwg] question about Web Storage setItem()'s behavior
On Sun, Aug 2, 2009 at 7:17 PM, 白石俊平 shumpei.shirai...@gmail.com wrote: Hi, I'm implementing the HTML5 Web Storage using Gears (http://code.google.com/p/gear5/), so I have several questions with the spec. -Storage.setItem(key, val) --is key allowed non-string type object? Yes, but... --and when pass non-string object to key/value, is it automatically converted to string?(I'm considering to convert to use String constructor - String(key) ) Yes. --when value is null, should `setItem(key, null)` behave as like as `removeItem(key)`? (localStorage.setItem(key, null); alert(localStorage.length); -- what is value displayed?) No, it's not the same as removeItem. It'll be set to 'null'. Check out Safari 4's implementation if you'd like to see the correct behavior for all of these cases. I've been spending a lot of time with it, and it matches the spec in every case I've tried. (And I've tried a lot...I'm working on it for Chromium.) :-) J
Re: [whatwg] Make quoted attributes a conformance criteria
On Thu, 23 Jul 2009, Keryx Web wrote: I'd say it is safe to say that using quotation marks for attribute values, always, except perhaps for collapsed, boolean attributes, has been regarded as best practice for a long time now. Speaking as an instructor for newbies, enforcing quotation marks has proven its value countless of times for me and my students. I'd say that all of my colleagues in WaSP EduTF would agree on that. [...] For the WHATWG, it doesn't matter how many people agree on something, as we base the spec's text on reasoned debate and research. :-) With this in mind I suggest that the spec would be improved in the (below) following ways, and that we open a discussion about requiring quotation marks for all non-boolean attributes as a conformance criterion. Suggested spec edits (some written in a diff-ish way, not all a true diff, though): Section 1.9 Keep: Attributes are placed inside the start tag, and consist of a name and a value, separated by an = character. The attribute value can be left unquoted if it doesn't contain any special characters. Otherwise, it has to be quoted using either single or double quotes. The value, along with the = character, can be omitted altogether if the value is the empty string. Add: In order to avoid errors and increase readability, using quotes is highly recommended for all non-omitted attribute values. [edit a lot of examples to include quotes] 9.1.2.3 No suggested text, but a rewrite will be necessary if quotation marks becomes a conformance criterion. Instead of preventing anyone from not using quote marks, I would instead recommend asking your validator vendor to offer you an option to require quote marks and warn you when you have forgotten them. This would address your use case, as far as I can tell, without preventing anyone who _likes_ omitting quote marks from doing so. In practice, parsing omitted quote marks is pretty reliably implemented, and it's been valid before and _widely_ used, so it's not an area we can really use to extend the language. Therefore the usual reasons we have to ban things don't really apply here, and I'd rather continue to allow quotes to be omitted. Omitting quotes would also make a large number of pages invalid for more or less stylistic reasons, which would make it harder for people to transition to HTML5, and may annoy them (Why do I have to add these quotes, they don't really add anything -- bah! I hate html5). On Thu, 23 Jul 2009, Kornel wrote: I wouldn't mind much if specification used more quotes in examples, however I'm afraid that taking this to the extreme could give false impression that unquoted attributes are an error, and spec would fail to illustrate when quotes are necessary and when they're perfectly safe to omit. The spec intentionally uses a variety of markup styles (including many I find quote ugly) in order to show that they are all valid, and to not mislead the reader into thinking there are unstated rules. On Thu, 23 Jul 2009, Keryx Web wrote: As for conformance criteria only being about unambiguous parsing: If that is the case we do not need them at all any more, since HTML 5 defines how to handle badly written markup. We also want to make things non-conforming if their parsing behaviour is highly non-intuitive, or if it might be a future extension point, or if there is some harm that might come from using the feature, etc. And speaking directly to Ian H, a few years ago you said on this list that you'd love for the spec to help teachers as much as possible (within the limits of being a spec). My suggested example markup changes is definitely such a help. Unfortunately such benefits have to be balanced against the costs on more experience authors, many of whom like the flexibility of omitting quotes. However, I do think that a conformance checker could support a stricter or teaching mode in which it requires that attributes be quoted and optional tags not be omitted. On Thu, 23 Jul 2009, Eduard Pascual wrote: [p class=foo bar] Furthermore, with the previous example, what'd happen if HTML6 defines a new empty bar attribute that alters the rendering and/or semantics of elements? If HTML6 is written like HTML5, then we wouldn't use bar if it was commonly subject to this mistake. The part on readability is indeed a matter of style; but the part of avoiding errors is quite valid. Maybe a more to-the-point wording would work better; how about something like this?: Quoting attribute values is always allowed, but only sometimes required. In case of doubt, the safest choice is to quote the value. In the introduction section, it now says: # The attribute value can be left unquoted if it doesn't contain any # special characters. Otherwise, it has to be quoted using either single # or double quotes. --
Re: [whatwg] question about Web Storage setItem()'s behavior
Hi, OK, I'll check the Safari4's implementation. Very thanks, Jeremy. On Mon, Aug 3, 2009 at 11:41 AM, Jeremy Orlowjor...@chromium.org wrote: On Sun, Aug 2, 2009 at 7:17 PM, 白石俊平 shumpei.shirai...@gmail.com wrote: Hi, I'm implementing the HTML5 Web Storage using Gears (http://code.google.com/p/gear5/), so I have several questions with the spec. -Storage.setItem(key, val) --is key allowed non-string type object? Yes, but... --and when pass non-string object to key/value, is it automatically converted to string?(I'm considering to convert to use String constructor - String(key) ) Yes. --when value is null, should `setItem(key, null)` behave as like as `removeItem(key)`? (localStorage.setItem(key, null); alert(localStorage.length); -- what is value displayed?) No, it's not the same as removeItem. It'll be set to 'null'. Check out Safari 4's implementation if you'd like to see the correct behavior for all of these cases. I've been spending a lot of time with it, and it matches the spec in every case I've tried. (And I've tried a lot...I'm working on it for Chromium.) :-) J
Re: [whatwg] 4.10.4.3 - stepUp and stepDown
On Thu, 23 Jul 2009, Kartikaya Gupta wrote: The algorithm for stepUp() and stepDown() doesn't seem to take into account the n parameter to those methods. The delta value used is the allowed step value; shouldn't delta actually be the allowed step value multiplied by n? Or am I missing something here? It was an error. Fixed. Thanks! -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
[whatwg] HTMLOptionElement::value compatibility
The `value' DOM attribute of HTMLOptionElement is incompatible with the current major browsers. The spec says: http://www.whatwg.org/specs/web-apps/current-work/multipage/forms.html#dom-option-value http://www.whatwg.org/specs/web-apps/current-work/multipage/forms.html#dom-option-value The disabled, label, and value DOM attributes must reflecthttp://www.whatwg.org/specs/web-apps/current-work/multipage/infrastructure.html#reflect the respective content attributes of the same name. However .value in IE8, Firefox3.5, Chrome2, Safari4, and Opera10b2 doesn't work so. It returns the value of `value' HTML attribute, or the value of .text DOM attribute if the element doesn't have the `value' HTML attribute or the value of `value' HTML attribute is empty. If we substitute a string to .value DOM attribute, the `value' HTML attribute is updated. The spec should follow this behavior. -- TAMURA Kent Software Engineer, Google
