Re: [whatwg] WebWorkers and images
On Thu, 13 Jan 2011 22:15:09 +0100, Boris Zbarsky bzbar...@mit.edu wrote: Do current browsers implement the structured clones already ? Firefox 4 does, for postMessage to workers (but not yet to other windows; known bug). I'm not sure about others. Opera since 10.60 supports structured clone for workers and cross-document messaging (but not for storage). I think so too for objects composed only of data properties, but what about methods ? getters ? setters ? and prototypes ? Maybe. It'd certainly take more work, and might start depending on exactly how your VM is structured. Restricting to objects with null prototype and no non-data properties has the slight problem that imagedata doesn't have a null prototype. Structured clone currently doesn't support Functions. -- Simon Pieters Opera Software
Re: [whatwg] Web DOM Core feedback
On Thu, 13 Jan 2011 22:05:54 +0100, Aryeh Gregor simetrical+...@gmail.com wrote: There are a bunch of places where it says When invoked with the same argument the same NodeList object may be returned as returned by an earlier call. Shouldn't this be either required or prohibited in any given case, not left undefined? Implementors wanted to have a choice on whether to cache or not to maximize performance while not leaking memory. See thread starting at http://lists.w3.org/Archives/Public/public-webapps/2010JanMar/0250.html -- Simon Pieters Opera Software
[whatwg] Google Feedback on the HTML5 media a11y specifications
Hi everyone, Over the last months I have worked with several people at Google who are amongst else from areas of accessibility, YouTube, Google Video, Google Chrome and WebM. We have analysed the track specification and the WebVTT (former WebSRT) specification mostly from a captioning point of view. Here is the summary of all the feedback we have put together. There are some questions of clarification and some proposals for improvements. We hope this will spawn some discussion and help improve the specifications. Best Regards, Silvia (with a Google contractor hat on). Feedback on the HTML5 media a11y specifications At Google we have reviewed the track and caption text file format proposal to introduce caption support into HTML5 video. We have in particular compared it to our needs for YouTube and to needs that originate from making sure that caption files sourced from legacy TV content can be represented as intended. We focused on the European EBU STL and the US CEA-608 and 708 caption standards. We particularly care that it is possible for people to watch their TV shows online with the exact same experience as they receive it on TV, since this is a contractual obligation with many content owners. We also care that a transform from broadcast to WebVTT and back to broadcast can be done without loss of information. Overall, the WebVTT format and the track element and related TimedTrack JavaScript API seem to satisfy most of the requirements. A few major and a couple of minor gaps remain to be filled. This document summarizes where we have seen gaps and proposes changes. There are two sections - the first one concerns the WebVTT format and the second one the track specification. A. Feedback on the WebVTT format In our opinion, WebVTT (with a few more improvements as proposed below) *when used in Web browsers* in combination with track and CSS can provide the same level of features as current TV caption formats. Therefore we are happy for WebVTT to become the baseline caption format for HTML5. We expect that browsers will implement support for other formats, too, and are satisfied that this has been made possible through the track element. We are concerned, however, about the introduction of WebVTT as a universal captioning format *when used outside browsers*. Since a subset of CSS features is required to bring HTML5 video captions on par with TV captions, non-browser applications will need to support these CSS features, too. However, we do not believe that external CSS files are an acceptable solution for non-browser captioning and therefore think that those CSS features (see [1]) should eventually be made part of the WebVTT specification. [1] http://www.whatwg.org/specs/web-apps/current-work/multipage/rendering.html#the-'::cue'-pseudo-element Aside from this general observation, we have the following feedback for WebVTT: 1. Introduce file-wide metadata WebVTT requires a structure to add header-style metadata. We are here talking about lists of name-value pairs as typically in use for header information. The metadata can be optional, but we need a defined means of adding them. Required attributes in WebVTT files should be the main language in use and the kind of data found in the WebVTT file - information that is currently provided in the track element by the @srclang and @kind attributes. These are necessary to allow the files to be interpreted correctly by non-browser applications, for transcoding or to determine if a file was created as a caption file or something else, in particular the @kind=metadata. @srclang also sets the base directionality for BiDi calculations. Further metadata fields that are typically used by authors to keep specific authoring information or usage hints are necessary, too. As examples of current use see the format of MPlayer mpsub’s header metadata [2], EBU STL’s General Subtitle Information block [3], and even CEA-608’s Extended Data Service with its StartDate, Station, Program, Category and TVRating information [4]. Rather than specifying a specific subset of potential fields we recommend to just have the means to provide name-value pairs and leave it to the negotiation between the author and the publisher which fields they expect of each other. [2] http://www.mplayerhq.hu/DOCS/tech/mpsub.sub [3] https://docs.google.com/viewer?a=vq=cache:UKnzJubrIh8J:tech.ebu.ch/docs/tech/tech3264.pdf [4] http://edocket.access.gpo.gov/cfr_2007/octqtr/pdf/47cfr15.119.pdf An example document with header metadata could look as follows: == WEBVTT Language=en-US Kind=Caption Title=Weird Al Yankovic - The Saga Begin Author=Gabucino CreationDate=2008-10-03 00:00:15.000 -- 00:00:18.000 A long, long time ago... == 2. Introduce file-wide cue settings At the moment if authors want to change the default display of cues, they can only set them per cue (with the D:, S:, L:, A: and T:. cue settings) or have to use an external CSS file through a HTML page with the ::cue
Re: [whatwg] Control over selection direction
Another relevant precedent is window.getSelection().modify (Webkit and Gecko-2 specific), which uses the strings forward and backward to specify the direction in which to alter the selection. English is not my native language, and I'm not sure what the semantic difference between forward and forwards is, but I do expect people to misremember which one we end up using, and use the other one. Would it make sense to accept both the with-s and the without-s versions, or is that kind of do-what-mean stuff not HTML5-style? (This .modify method can, by the way, already be used, on the browsers that support it, to create reversed selections by setting a collapsed selection at the end of the desired selection, and then calling getSelection().modify(extend, backward, character) X times to adjust the start to the desired point. This is, unfortunately, horribly slow, and quite clunky.)
Re: [whatwg] Web DOM Core feedback
On 01/13/2011 10:05 PM, Aryeh Gregor wrote: In defining the interface for Node, some of the attributes are defined like The parentElement attribute must return the parent node of the context node if there is a parent and it is an Element node, or null otherwise. while others are defined like The parentNode attribute must run these steps: 1. If the context node does not have a parent node, return null and terminate these steps. 2. Return the parent node of the context node. They seem to be equivalent, but the first way is shorter. IMHO the second is clearer (I also note that they do not seem to be equivalent in this specific case). There are a bunch of places where it says When invoked with the same argument the same NodeList object may be returned as returned by an earlier call. Shouldn't this be either required or prohibited in any given case, not left undefined? It seems like making this a requirement would interact badly with GC e.g. if I have some call that produces a huge NodeList that is then not referenced, I don't want to keep it around just in case some future script returns the same NodeList. On the other hand, there are scripts that put calls returning identical NodeLists in inner loops. In these cases not recreating the object every time is a big performance win.
Re: [whatwg] WebWorkers and images
On 13/01/2011, at 22:15, Boris Zbarsky wrote: On 1/13/11 3:19 PM, Jorge wrote: I think so too for objects composed only of data properties, but what about methods ? getters ? setters ? and prototypes ? Maybe. It'd certainly take more work, and might start depending on exactly how your VM is structured. Restricting to objects with null prototype and no non-data properties has the slight problem that imagedata doesn't have a null prototype. Are you sure there's really a maybe for methods ? Methods' functions have access to (at least) the sender's global context and contexts can't be shared, how to deal with that if not by prohibiting methods ? WRT to prototypes, to keep it simple, I think .__proto__ should be null, because we can't pass (and make unreachable) things like Object.prototype :-) -- Jorge.
Re: [whatwg] Web DOM Core feedback
On Fri, Jan 14, 2011 at 11:41 PM, James Graham jgra...@opera.com wrote: On 01/13/2011 10:05 PM, Aryeh Gregor wrote: There are a bunch of places where it says When invoked with the same argument the same NodeList object may be returned as returned by an earlier call. Shouldn't this be either required or prohibited in any given case, not left undefined? It seems like making this a requirement would interact badly with GC e.g. if I have some call that produces a huge NodeList that is then not referenced, I don't want to keep it around just in case some future script returns the same NodeList. On the other hand, there are scripts that put calls returning identical NodeLists in inner loops. In these cases not recreating the object every time is a big performance win. The usual trick here is to weakly reference the cached NodeList. So if the script holds onto a reference, then future calls will return that NodeList, but if the script does not hold onto a reference, it can be GCed and future calls will return a different NodeList. Then the spec can say that the same NodeList will be returned, and that implementation satisfies the spec since a script can't tell that the NodeList has changed without holding onto a reference to the old NodeList. ... except I guess it can, because it could set expando properties on the old NodeList and check for their presence later. Sigh. Rob -- Now the Bereans were of more noble character than the Thessalonians, for they received the message with great eagerness and examined the Scriptures every day to see if what Paul said was true. [Acts 17:11]
Re: [whatwg] WebWorkers and images
On 14/01/2011, at 09:32, Simon Pieters wrote: On Thu, 13 Jan 2011 22:15:09 +0100, Boris Zbarsky bzbar...@mit.edu wrote: Do current browsers implement the structured clones already ? Firefox 4 does, for postMessage to workers (but not yet to other windows; known bug). I'm not sure about others. Opera since 10.60 supports structured clone for workers and cross-document messaging (but not for storage). I think so too for objects composed only of data properties, but what about methods ? getters ? setters ? and prototypes ? Maybe. It'd certainly take more work, and might start depending on exactly how your VM is structured. Restricting to objects with null prototype and no non-data properties has the slight problem that imagedata doesn't have a null prototype. Structured clone currently doesn't support Functions. Good. And if I understand it correctly (*), it does make a shallow copy, ignoring the prototype chain, doesn't it ? (*)http://dev.w3.org/html5/spec/common-dom-interfaces.html#internal-structured-cloning-algorithm Simon, what are your feelings about this proposed mechanism to pass-by-reference and make-unreachable ? Do you think it's feasible, too ? -- Jorge.
Re: [whatwg] Control over selection direction
On 14 January 2011 10:16, Marijn Haverbeke mari...@gmail.com wrote:
Another relevant precedent is window.getSelection().modify (Webkit and
Gecko-2 specific), which uses the strings forward and backward to
specify the direction in which to alter the selection. English is not
my native language, and I'm not sure what the semantic difference
between forward and forwards is, but I do expect people to
misremember which one we end up using, and use the other one. Would it
make sense to accept both the with-s and the without-s versions, or is
that kind of do-what-mean stuff not HTML5-style?
(This .modify method can, by the way, already be used, on the browsers
that support it, to create reversed selections by setting a collapsed
selection at the end of the desired selection, and then calling
getSelection().modify(extend, backward, character) X times to
adjust the start to the desired point. This is, unfortunately,
horribly slow, and quite clunky.)
If you don't need the TextRange-like character-based modification, you
can instead use the selection's extend() method (supported in Mozilla,
WebKit and Opera for years) to create a backwards selection:
function selectRangeBackwards(range) {
var sel = window.getSelection();
var endRange = range.cloneRange();
endRange.collapse(false);
sel.addRange(endRange);
sel.extend(range.startContainer, range.startOffset);
}
Tim
Re: [whatwg] WebWorkers and images
On 13/01/2011, at 22:15, Boris Zbarsky wrote: On 1/13/11 3:19 PM, Jorge wrote: On 13/01/2011, at 15:41, Boris Zbarsky wrote: On 1/13/11 7:24 AM, Jorge wrote: Not too long ago, the browsers did allow timeouts of less than 10ms. Uh, no. Not too long ago browsers did not allow timeouts of less than 10ms, ever. Last time I checked that in 2008, most Mac browsers had a +new Date() and a SetTimeout resolution of ~1ms down to ~ 0 ms 1) 2008 is not long ago. ;) 2) Don't mix up new Date and setTimeout. But in order to measure such short setTimeout()s I needed to know whether +new Date() had enough resolution (*), in Oct 2008 it was in: All Macs, all browsers: 1ms. Win XP: Chrome, FF3, Safari: 1ms. IE, Opera, FF2 : 10ms. (*) http://jorgechamorro.com/cljs/024/ 3) For setTimeout in particular, if the timeout is nested, browsers clamp it from below and always have. For non-nesting timeouts I'm not sure when Safari stopped clamping, if it ever did; Gecko always did until mid-2009. 4) All of the above applies to browsers that had enough market share that web compat was an issue. I haven't done testing of the behavior in iCab, or links, or w3m or Amaya, because it's not really relevant at this point. Current Mac browsers behave ~ as you say, except Opera, that converts 0ms timeouts to 10ms, but for anything= 1ms honors the ms parameter. Ah, indeed. I believe that Opera does this cross-platform. Thank you for the correction. It looks like other browsers will be following suit on the 4ms thing eventually for two reasons: the HTML5 spec specs it and there are lots of bogus performance benchmarks that measure JavaScript execution speed across timeouts. Now I suspect browsers won't actually _deliver_ decent 4ms timers on Windows unless they jump through the hoops that Chrome does with a polling thread; Windows just doesn't give you a sane way to deal with times less than a tick (10ms on single-processor systems, 15ms on multiprocessor ones). But they might be able to deliver something that fires every 4ms on average (firing immediately sometimes and after 10-15ms other times). If the goal is to protect the users from (badly written) programs that may drain the mobile's or laptop's battery, it's a bit sad to have to go down this route. Well, the problem is there are multiple somwhat-conflicting goals here: 1) Provide web pages with high-quality and high-resolution timers that they can use to do various useful things. 2) Provide some protection against miscoded pages, especially accidentally miscoded ones that are accidentally relying on the old timeout clamps. 3) Don't break web compat too much. (and maybe some others). Chrome started with a 1ms clamp for reason #1, then moved to 4ms due to reasons 2 and 3 Ok. Thanks for sharing. It should have, even with the copying that probably happens now. Worth retesting. Do current browsers implement the structured clones already ? Firefox 4 does, for postMessage to workers (but not yet to other windows; known bug). I'm not sure about others. This is actually not all that bad for imagedata: just deallocate its storage on the caller and make any access to the buffer throw. The key is that you don't care that you have to copy things like the width/height; you just don't want to copy the giant byte array. So you move the byte array, and deny all access to its elements after that. Since the elements are never pointed to by reference from JS, this works. For arbitrary objects this is harder, but could be done, actually. Gecko already does something similar for Window objects when their origin changes: you might still have a reference to the original object, but you can no longer actually touch any of it. Under the hood, this is implemented in a way that could be used for sending objects to a worker too, I think. Good. So you think it might be feasible ? Yes. Cool. What's the right place to start lobbying for it :-) ? I think so too for objects composed only of data properties, but what about methods ? getters ? setters ? and prototypes ? Maybe. It'd certainly take more work, and might start depending on exactly how your VM is structured. Restricting to objects with null prototype and no non-data properties has the slight problem that imagedata doesn't have a null prototype. Hmm. I don't think there's hope for functions. -- Jorge.
Re: [whatwg] Control over selection direction
If you don't need the TextRange-like character-based modification, you can instead use the selection's extend() method (supported in Mozilla, WebKit and Opera for years) to create a backwards selection: Maybe that is what you meant by this not working for TextRange-like things, but, unfortunately, the regular selection primitives do not appear to treat the content of text input and textarea elements as separate elements. I can use this trick to create a reversed selection that starts at the start of the textarea, but not one starting at an arbitrary character.
Re: [whatwg] Control over selection direction
On 14 January 2011 11:33, Marijn Haverbeke mari...@gmail.com wrote: If you don't need the TextRange-like character-based modification, you can instead use the selection's extend() method (supported in Mozilla, WebKit and Opera for years) to create a backwards selection: Maybe that is what you meant by this not working for TextRange-like things, but, unfortunately, the regular selection primitives do not appear to treat the content of text input and textarea elements as separate elements. I can use this trick to create a reversed selection that starts at the start of the textarea, but not one starting at an arbitrary character. I'm sorry, I thought you were referring to regular selections as opposed to inputs or textareas, since you mentioned window.getSelection(). It hadn't occurred to me to use modify() to try and affect the selection in a textarea. Tim
Re: [whatwg] WebWorkers and images
Boris Zbarsky wrote: It would be interesting to have an API that allows passing an imagedata object (not a copy) to a worker. Such an API would have to make the data disappear on the caller's side. That could be implemented reasonably efficiently using shared memory (either directly with threads or using shared memory segments with processes). FWIW, there's some interesting discussion on handing over data in message passing in this Google TechTalk: http://www.youtube.com/watch?v=37NaHRE0Sqw although this is about a Java framework. (some data structure pictures at 27:57 and forward) Best regards Mike Wilson
Re: [whatwg] link onLoad event
Diogo Resende wrote: I see already information on the latest draft about a load and error event, I think this is it. I was hoping some browser vendors would implement it sooner :) Yes, ironically link.onload works in IE6, but not in current stable versions of Firefox, Safari or Chrome :-P Best regards Mike Wilson
Re: [whatwg] Revisiting innerWidth quirks
On 1/14/11 2:05 AM, Charles Pritchard wrote: I've noticed, recently, that FF4b8 on Windows has a minimum window.innerWidth of 392px. For what it's worth, that's more or less a bug. It happens due to the details of the UI structure (e.g. the url bar width can't shrink below a certain amount) and the way XUL layout works. In FF, at least, using zoom in allows the the innerWidth to be reduced. This is a helpful trick for testing out more narrow window widths, such as a 200px width. Or you could just create an iframe of whatever size you want and do the testing there I don't know that FF supports matchMedia http://dev.w3.org/csswg/cssom-view/#dom-window-matchmedia Not yet. I don't believe we've even reviewed that proposal for sanity yet. -Boris
Re: [whatwg] Revisiting innerWidth quirks
On Fri, 14 Jan 2011 15:04:11 +0100, Boris Zbarsky bzbar...@mit.edu wrote: On 1/14/11 2:05 AM, Charles Pritchard wrote: I don't know that FF supports matchMedia http://dev.w3.org/csswg/cssom-view/#dom-window-matchmedia Not yet. I don't believe we've even reviewed that proposal for sanity yet. David Baron came up with the current design. -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] WebWorkers and images
On 1/14/11 5:42 AM, Jorge wrote: Are you sure there's really a maybe for methods ? Methods' functions have access to (at least) the sender's global context and contexts can't be shared, how to deal with that if not by prohibiting methods ? We might need some ES spec changes/additions to produce methods that would be safe to pass. I agree that it's not that feasible for now. (Though with enough hackery it could all be done: the method could sync proxy the property access on things that are not on the worker thread to the main thread, etc. It's probably not worth it.) WRT to prototypes, to keep it simple, I think .__proto__ should be null, because we can't pass (and make unreachable) things like Object.prototype :-) So proto is null on the result of the clone; not required to be null on the thing being cloned. Right? -Boris
Re: [whatwg] Web DOM Core feedback
On 1/14/11 5:53 AM, Robert O'Callahan wrote: ... except I guess it can, because it could set expando properties on the old NodeList and check for their presence later. Sigh. We could make expandos on nodelists pin them so they can't be collected as long as they can be reached via DOM APIs; that already happens for nodes I'm not sure we want to go there, though. -Boris
Re: [whatwg] WebWorkers and images
On 1/14/11 6:15 AM, Jorge wrote: But in order to measure such short setTimeout()s I needed to know whether +new Date() had enough resolution (*) OK, yes. Cool. What's the right place to start lobbying for it :-) ? File a bug? ;) (Either on the spec or on browsers, depending on whom you want to lobby.) -Boris
Re: [whatwg] link onLoad event
On Fri, Jan 14, 2011 at 2:08 PM, Mike Wilson mike...@hotmail.com wrote: Diogo Resende wrote: I see already information on the latest draft about a load and error event, I think this is it. I was hoping some browser vendors would implement it sooner :) Yes, ironically link.onload works in IE6, but not in current stable versions of Firefox, Safari or Chrome :-P More ironically that browser emulator could never understand/parse the contents of those files correctly anyway :) A decade after, current stable version of IE browser (IE8) still doesn't understand half of the CSS 2.1 specifications and barf at Query Selectors API. Detecting the style loading happened and incorrectly parsing the contents doesn't seem to be a better solution. Nor something planned ! -- Diego Best regards Mike Wilson
Re: [whatwg] Control over selection direction
On Fri, Jan 14, 2011 at 3:09 AM, Tim Down timd...@gmail.com wrote:
If you don't need the TextRange-like character-based modification, you
can instead use the selection's extend() method (supported in Mozilla,
WebKit and Opera for years) to create a backwards selection:
function selectRangeBackwards(range) {
var sel = window.getSelection();
var endRange = range.cloneRange();
endRange.collapse(false);
sel.addRange(endRange);
sel.extend(range.startContainer, range.startOffset);
}
WebKit-based browsers also support setBaseAndExtent, which takes
startContainer, startOffset, endContainer, endOffset. IMHO, this function
is better than extend because it can set the whole selection at once.
On Fri, Jan 14, 2011 at 3:53 AM, Tim Down timd...@gmail.com wrote:
I'm sorry, I thought you were referring to regular selections as
opposed to inputs or textareas, since you mentioned
window.getSelection(). It hadn't occurred to me to use modify() to try
and affect the selection in a textarea.
Maybe we can spec this so that regular selection primitives work properly
for textarea/input. e.g. you can expect that when
startContainer/endContainer is textarea/input, selection is set inside
textarea/input.
- Ryosuke
Re: [whatwg] Control over selection direction
Maybe we can spec this so that regular selection primitives work properly for textarea/input. e.g. you can expect that when startContainer/endContainer is textarea/input, selection is set inside textarea/input. That would work for me, however, it'd be backwards-incompatible -- not in a critical way, but probably enough to break a few pieces of code. Also, I assume there is a reason that textarea/textinput content is not 'officially' part of the DOM, and that separate selection-management functionality has been implemented for it. This might be a *much* bigger can of worms than the simple change I proposed. I, personally, am more interested in getting *some* solution agreed on and specified, than in doing this in the most elegant way possible.
Re: [whatwg] Control over selection direction
On Fri, Jan 14, 2011 at 11:42 AM, Marijn Haverbeke mari...@gmail.comwrote: That would work for me, however, it'd be backwards-incompatible -- not in a critical way, but probably enough to break a few pieces of code. Also, I assume there is a reason that textarea/textinput content is not 'officially' part of the DOM, and that separate selection-management functionality has been implemented for it. This might be a *much* bigger can of worms than the simple change I proposed. If you accept that other selection APIs can't be used in textarea / input, then why would you expect your property/method to specify direction can be? Specifically that this direction property/method works for textarea / input and other properties/method doesn't is very inconsistent, and very unlikely to be adopted by browser vendors. (I for one will not support such an interface if proposed in the WebKit community). - Ryosuke
Re: [whatwg] Control over selection direction
If you accept that other selection APIs can't be used in textarea / input, then why would you expect your property/method to specify direction can be? Because I proposed it as *only* working for input fields. Specifically that this direction property/method works for textarea / input and other properties/method doesn't is very inconsistent, This is exactly the situation we have now with the selectionStart and selectionEnd properties. I'm merely working in the spirit of the existing situation.
[whatwg] Small consistency issue with HTML5 nav element examples
In section 4.4.5 (the aside element), an example is given that shows nav being used within footer. Section 4.4.3 (the nav element), explains that this would be an inappropriate use of nav (http://dev.w3.org/html5/spec/Overview.html#the-nav-element): Not all groups of links on a page need to be in a nav element - only sections that consist of major navigation blocks are appropriate for the nav element. In particular, it is common for footers to have a short list of links to various pages of a site, such as the terms of service, the home page, and a copyright page. The footer element alone is sufficient for such cases, without a nav element. Minor inconsistency, but felt it was worth pointing out to avoid confusion. -Nicholas __ Commander Lock: Dammit Morpheus, not everyone believes what you believe! Morpheus: My beliefs do not require them to.
Re: [whatwg] Small consistency issue with HTML5 nav element examples
On Fri, 14 Jan 2011, Nicholas Zakas wrote: In section 4.4.5 (the aside element), an example is given that shows nav being used within footer. Section 4.4.3 (the nav element), explains that this would be an inappropriate use of nav (http://dev.w3.org/html5/spec/Overview.html#the-nav-element): Not all groups of links on a page need to be in a nav element - only sections that consist of major navigation blocks are appropriate for the nav element. In particular, it is common for footers to have a short list of links to various pages of a site, such as the terms of service, the home page, and a copyright page. The footer element alone is sufficient for such cases, without a nav element. It doesn't say it's inappropriate, such that it's not necessary. It's still fine to use it there. I'll try to clarify that. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Small consistency issue with HTML5 nav element examples
Ah, I misinterpreted. With this in mind, I'm a bit unclear as to when nav should be used. If it's intended for primary navigation but secondary navigation can also be marked up with it, does that mean it's best to use nav whenever you have more than one link grouped together? Thanks. -Nicholas __ Commander Lock: Dammit Morpheus, not everyone believes what you believe! Morpheus: My beliefs do not require them to. -Original Message- From: Ian Hickson [mailto:i...@hixie.ch] Sent: Friday, January 14, 2011 3:58 PM To: Nicholas Zakas Cc: wha...@whatwg.org Subject: Re: [whatwg] Small consistency issue with HTML5 nav element examples On Fri, 14 Jan 2011, Nicholas Zakas wrote: In section 4.4.5 (the aside element), an example is given that shows nav being used within footer. Section 4.4.3 (the nav element), explains that this would be an inappropriate use of nav (http://dev.w3.org/html5/spec/Overview.html#the-nav-element): Not all groups of links on a page need to be in a nav element - only sections that consist of major navigation blocks are appropriate for the nav element. In particular, it is common for footers to have a short list of links to various pages of a site, such as the terms of service, the home page, and a copyright page. The footer element alone is sufficient for such cases, without a nav element. It doesn't say it's inappropriate, such that it's not necessary. It's still fine to use it there. I'll try to clarify that. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
