[whatwg] Spec review results I
Since currently reviewing and proof-reading the HTML 5 spec draft (again) I'm feeling free to send (rather non-technical) /suggestions/ and eventual typos to this list. This tiny first part refers to CVS revision 1.904 [1]. * Please drop or the idea that the working group should even spend time discussing the concept of that section as this is unnecessarily judgmental. * Change order of change history locations [2] (inverting the order seems to make sense to put more emphasis on CVS/SVN access than on Twitter). * Remove emphasis from This in This specification aims to extend HTML so that it is also suitable in these contexts [3] (and probably use The HTML 5 specification instead of This) as this unnecessarily seems to judge XHTML 2. * Better write HTML documents do not exist in a vacuum. This section … instead of HTML documents do not exist in a vacuum — this section … [4]. * In the same section [4] it might be fine to drop the first half of the Language Syntax description, All of these features would be for naught if they couldn't be represented in a serialized form and sent to other people, and so …. * Add a period behind etc (many occurrences), as I Merriam-Webster [5] and Wikipedia [6] seem to confirm (Typically, the abbreviated versions should always be followed by a full stop). * In the conformance section [7], if errors have been so preserved might be rephrased to if errror have been preserved this way or the like (not too sure about it, but the current phrase sounded strange to my non-native ears). * Please simplify the Unless otherwise specified … exception notes [8] as there is a lot of redundancy. [1] http://dev.w3.org/cvsweb/~checkout~/html5/spec/Overview.html?rev=1.904 [2] http://dev.w3.org/cvsweb/~checkout~/html5/spec/Overview.html?rev=1.904#status [3] http://dev.w3.org/cvsweb/~checkout~/html5/spec/Overview.html?rev=1.904#relationship0 [4] http://dev.w3.org/cvsweb/~checkout~/html5/spec/Overview.html?rev=1.904#structure [5] http://www.merriam-webster.com/dictionary/etc [6] http://en.wikipedia.org/wiki/Et_cetera [7] http://dev.w3.org/cvsweb/~checkout~/html5/spec/Overview.html?rev=1.904#conformance [8] http://dev.w3.org/cvsweb/~checkout~/html5/spec/Overview.html?rev=1.904#common -- Jens Meiert http://meiert.com/en/
Re: [whatwg] Focus management
On Fri, 4 May 2007, Simon Fraser wrote: Some web applications may need more control over focus than is offered by the existing focus management proposal: http://www.whatwg.org/specs/web-apps/current-work/#focus Specifically, it's hard to write JavaScript that has more explicit control over focus changes. Functionality that is missing (but often included in native UI toolkits) includes: * Focus chain queries need the ability to ask the document what the next/previous focusable element is from a given element, or from null (first/last focusable element). * Is element focusable need to be able to ask an element if it can take focus. Focusability is currently some function of element type, tabindex, visibility, contentEditability, UA preferenes etc, and it's hard to write JS that computes this. * Explicit advance/rewind focus need to be able to move focus to the next/previous focusable element without having explicit knowledge of what the next element is (this mirrors what happens when the user hits the Tab or Shift-Tab keys). (If nextFocus()/previousFocus() are available, this could be achieved with document.nextFocus(document.activeElement).focus(), but that seems a little long-winded.) Could you elaborate on the use cases for these? I'd rather not add these features just because other environments have them, but if there are good reasons to have them, I'd naturally be happy to add them. In addition, I'd like to see a few clarifications in the Focus management section of the Web Applications draft: * What does focus() do on an unfocusable element? Does the previously focused element remain focused? This is now clarified, hopefully. * document.activeElement has some ambiguities: - Is it valid when the window does not have focus? Does this sentence in an earlier sentence answer this unambigiously?: # Which element(s) within a top-level browsing context currently has focus # must be independent of whether or not the top-level browsing context # itself has the system focus. - IE has a setActive() method that changes the activeElement, but does not change the focus. So the activeElement is not always the focused element. Should we specify setActive()? Does it just set which element would be focused if the document were to get focus? As defined, activeElement just returns the element _within the document_ that is focued, that might not be the element with system focus if another document has the system focus. * how does display: none or visibility: hidden interact with focus? - can non-rendered elements be focused? No (this is explicit now, though it could probably be clearer). - if a focused element becomes unrendered, does focus move to the next focusable element? No (this is implicit in that it becomes an unfocusable element and thus can't be focused, but the focus doesn't go anywhere in particular, there's just not focused element). Finally I'd like to see some discussion around focus() and window activation. window.focus() obviously (and annoyingly) activates the window, but should focussing an element inside a window raise the window? What happens if that window is a hidden tab in a tabbed browser? window.focus() isn't in HTML5 as there doesn't appear to be a valid use case for it and it is too abusable, and thus shouldn't be supported. If pages depend on it being supported we could make it a no-op, I guess. Focusing an element inside a window should raise the window or hidden tab at the UA's discretion. I don't know that there's anything we need to explicitly say about that. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] HTML5 Feedback: Section 3.5.2 Focus
On Mon, 8 Oct 2007, Brad Fults wrote: A few things in Section 3.5.2: There is always an element focused; in the absence of other elements being focused, the document's root element is it. [1] This sentence is awkwardly worded and as far as I can tell, document's root element is referenced but not defined anywhere. It might be better as something like: There is always a single element with focus. If no other element in the document has focus, focus is given to the document's root element -- in this case the body element. That is assuming, of course, that the body element is indeed the element that is to receive focus when no other element is focused. I'm not thrilled with this wording either, but it is an incremental improvement in comprehensibility. This section got rewritten recently and the above text is no longer there in that form. Let me know if it's still broken in your opinion. If no element specifically has focus, this must return the body element. [2] This sentence references the body element (with proper linking to its definition). Is the intention here to distinguish the body element from the document's root element mentioned in the previous quote? If so, it's not clear what the distinction is or why it is present. If not, these two sentences should use the same terminology. Fixed as part of the earlier changes. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] HTML5 Feedback: Section 3.5.3 Scrolling elements into view
On Mon, 8 Oct 2007, Brad Fults wrote: There are a couple of problems I have found in this section. If it isn't possible to show the entire element in that way, or if the argument is omitted or is true, then the user agent must instead simply align the top of the element with the top of the viewport. [1] I have two issues with this text: 1. The word simply is rhetoric and doesn't seem reasonable or useful in the context of this part of the specification. Removed. 2. It may not be possible to align the top of the element with the top of the viewport without scrolling past the bottom of the document, so the must is unreasonable. This contingency should be mentioned (scrolling past the bottom of the document is not, as far as I know, desired). I don't understand what you mean. How can something in the document be further down than the bottom of the document? Secondly, with respect to this section as a whole, I see no description of necessary behavior for horizontal scrolling. Surely this is an issue that must be addressed, as it would be decidedly deficient if scrollIntoView() only took vertical scrolling into account, leaving horizontally overflown content still outside of the viewport after the method's invocation. Do UAs do any horizontal scrolling today? I've mentioned it, but I'm not sure what to say really. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] HTMLDocument hasFocus - should it be a function?
On Tue, 4 Mar 2008, Adele Peterson wrote: I started implementing the hasFocus attribute in WebKit, but then I realized that IE and Firefox 3 both implement it as a function. Should the spec change to match the existing implementations? Fixed. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
[whatwg] Interpretation of video poster attribute
Hi! I'm a bit puzzled about how to interpret the poster attribute on HTMLVideoElement: The poster attribute gives the address of an image file that the user agent can show while no video data is available. The attribute, if present, must contain a URI (or IRI). Is the intention that this image should be stretched to the size of the video element, or that it should be centered in the frame? If the width and height attributes are not given, should the video element initially be given the size of the poster image, or should the user agent wait until it has the dimensions of the video (thereby making the poster useless)? In short, what is the intended use of poster? -- Philip Jägenstedt
Re: [whatwg] [canvas] imageRenderingQuality property
If you don't mind someone weighing in who's been working with the Nintendo Wii for the past year and a half, I have found that the quality setting in Flash is tremendously useful. While the march of Moore's law has ensured that Flash on the desktop is zippy, it has also created a gap whereby smaller devices are powerful enough to compete with last generation desktops. For these devices, the quality setting is more than a nice to have. It's absolutely critical to obtaining decent performance. The algorithm's I've used over on WiiCade automatically adjust for high quality when on the desktop, and low to medium quality when on the Wii. This provides a more consistent experience to users of both systems. In addition, many game provide a quality setting in their options screen. (Similar to the rendering features options in most 3D games.) This allows the user to adjust the rendering speed manually if he finds his system is too slow or the game in question is more than fast enough on the Wii. I can see a quality setting in Javascript used in much the same way. The site would set the quality of the rendering based on knowledge of particular platforms. Modern desktops would default to highest quality. Furthermore, video games (and we all know that's going to be a huge use of Canvas at some point ;-)) that push the limit of Canvas may allow the user to shift down as it were to compensate for their slower machine or the slow Canvas rendering of their browser. I definitely think this setting should be a hint rather than a hard and fast set of rules. If a UA (especially desktop UAs) wants to ignore the setting, that's fine. It will cause no appreciable damage. But it will allow for slower UAs to be tuned for usage. e.g. If I'm looking at charts on my Wii, I'd rather they be high quality. If I'm playing a video game, the quality simply does not matter as much. I hope you will all keep we poor device users in mind when you come to your decision. Thanks! Jerason Banes On Mon, Jun 2, 2008 at 5:52 PM, Oliver Hunt [EMAIL PROTECTED] wrote: Neither of these apply if the property were just a hint, but now you have to think about what happens to content that uses this property in 18 months time. You've told the UA to use a low quality rendering when it may no longer be necessary, so now the UA has a choice it either always obeys the property meaning lower quality than is necessary so that new content performs well, or it ignores the property in which case new content performs badly. If the quality knob is no longer necessary, why would new content perform badly? The issue is not that certain operations are slower than others, the issue is that anything that requires the developer to choose between performance/quality is going to become obsolete as the performance trade offs are constantly moving and are not the same from UA to UA, from platform to platform. I think the issue of performance is a complex one that will not benefit in the long term from a simple on off switch. Conceivably we could introduce new rendering primitives, such as CanvasSprite, CanvasLayer, or some such which would, i suspect, provide a similar benefit, but be more resilient in the face of changing performance characteristics.
[whatwg] Fwd: Interpretation of video poster attribute
On Tue, Jun 3, 2008 at 7:36 AM, Philip Jägenstedt [EMAIL PROTECTED] wrote: Hi! I'm a bit puzzled about how to interpret the poster attribute on HTMLVideoElement: The poster attribute gives the address of an image file that the user agent can show while no video data is available. The attribute, if present, must contain a URI (or IRI). Is the intention that this image should be stretched to the size of the video element, or that it should be centered in the frame? If the width and height attributes are not given, should the video element initially be given the size of the poster image, or should the user agent wait until it has the dimensions of the video (thereby making the poster useless)? In short, what is the intended use of poster? -- Philip Jägenstedt Just for similar-implementation-ideas, flvplayer simply aligns the poster image to the upper-left of the object element, with no scaling at all. If width and height are not given, it simply doesn't display at all. Unless there's already some alternate intent, I suggest video scale to the poster's size if no explicit size is given. ~TJ
Re: [whatwg] HTML5 Feedback: Section 3.5.3 Scrolling elements into view
Nothing in the document can be further down than the bottom. If the document scrolls past the bottom, it shows nothing under the bottom but the bottom is in the middle of the window. This is inevitable if the document is short so that it can be displayed without scrolling (and without scroll bars); it should be avoided if the document is longer than the window's height. Best regards, Chris -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ian Hickson Sent: Tuesday, June 03, 2008 1:33 PM To: Brad Fults Cc: WHAT-WG Subject: Re: [whatwg] HTML5 Feedback: Section 3.5.3 Scrolling elements into view On Mon, 8 Oct 2007, Brad Fults wrote: There are a couple of problems I have found in this section. If it isn't possible to show the entire element in that way, or if the argument is omitted or is true, then the user agent must instead simply align the top of the element with the top of the viewport. [1] 2. It may not be possible to align the top of the element with the top of the viewport without scrolling past the bottom of the document, so the must is unreasonable. This contingency should be mentioned (scrolling past the bottom of the document is not, as far as I know, desired). I don't understand what you mean. How can something in the document be further down than the bottom of the document?
Re: [whatwg] Context help in Web Forms
On Mon, 02 Jun 2008 09:40:55 -0300, Matthew Paul Thomas [EMAIL PROTECTED] wrote: Ian Hickson wrote on 27/05/08 07:47: On Mon, 12 Nov 2007, Matthew Paul Thomas wrote: On Oct 30, 2007, at 6:01 PM, Ian Hickson wrote: On Mon, 13 Jun 2005, Matthew Thomas wrote: ... Many applications provide inline help which is not a label, and the same attributes would be appropriate here: div rel=help for=phone-numberpThe full number, including country code./p pExample: samp+61 3 1234 5678/samp/p/div How would UAs use this? UAs likely wouldn't, but scripts could. For example, a form might include sparing help by default, with a style sheet hiding more exhaustive help (as indicated by rel=help). Then a script could add a small help button after each control that has associated help (i.e. each control with name=x where there exists an element on the page with rel=help for=x). When a control's help button was clicked, the control's help would be shown. ... The data-* attributes are intended for scripts like this. ... The disadvantage of using a data-* attribute is that more kinds of mistakes would be undetectable by a validator. It would have no idea that (a) the value of the attribute must be the ID of an element elsewhere in the document, and (b) each value must be unique within the document. Indeed. There is an attribute for this called contexthelp or something that JAWS implemented years ago, collaborating with the US Treasury or seomthing. I proposed it to the whatwg a couple of years ago but my recollection is that this was rejected as not useful or important or something. Certainly it seems mor sensible to go with existing implementation than to make up something incompatible, and it seems that using data-* means we will actually get several dozen different versions of this - using ARIA would be an approximately infinitely better alternative. I wonder if the data-* attribute naming scheme could be classified somehow to allow basic type checking like this. I expect there will be other cases where authors want an attribute value to match the ID of an element in the page. Sounds like a semantic web project to me, infobot. (Personally I think that would be useful, but at that point I'd switch to basing my work on XML anyway, where there are infrastructures for this kind of thing). cheers Chaals -- Charles McCathieNevile Opera Software, Standards Group je parle français -- hablo español -- jeg lærer norsk http://my.opera.com/chaals Try Opera 9.5: http://snapshot.opera.com
Re: [whatwg] Context help in Web Forms
On Jun 2, 2008, at 15:40, Matthew Paul Thomas wrote: The disadvantage of using a data-* attribute is that more kinds of mistakes would be undetectable by a validator. It would have no idea that (a) the value of the attribute must be the ID of an element elsewhere in the document, and (b) each value must be unique within the document. I wonder if the data-* attribute naming scheme could be classified somehow to allow basic type checking like this. I expect there will be other cases where authors want an attribute value to match the ID of an element in the page. I don't like the idea of trying to encode the datatypes of data-* attributes in a validator-sensitive way. What datatypes would a validator support for data-* attributes? The HTML5 datatype library used by Validator.nu already contains 41 datatypes, but people will likely want to have others. The whole point of data-* is to provide a place where a validator doesn't go without authors having to abuse e.g. title which is a freeform but exposed to humans. The foreseeable problem with data-* is, of course, that microformat- like activity will happen there instead of going through the trouble of getting unprefixed validator-sensitive attributes minted with community review in the WHATWG and the HTML WG. -- Henri Sivonen [EMAIL PROTECTED] http://hsivonen.iki.fi/
Re: [whatwg] Context help in Web Forms
On Tue, 03 Jun 2008 20:51:39 +0200, Henri Sivonen [EMAIL PROTECTED] wrote: I don't like the idea of trying to encode the datatypes of data-* attributes in a validator-sensitive way. What datatypes would a validator support for data-* attributes? The HTML5 datatype library used by Validator.nu already contains 41 datatypes, but people will likely want to have others. The whole point of data-* is to provide a place where a validator doesn't go without authors having to abuse e.g. title which is a freeform but exposed to humans. I agree. The foreseeable problem with data-* is, of course, that microformat-like activity will happen there instead of going through the trouble of getting unprefixed validator-sensitive attributes minted with community review in the WHATWG and the HTML WG. That'd be wrong as data-* does not allow implementation by UAs... Having said that, if we don't make it clear what the idea is that might end up happening in practice here and there. -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
