Re: [whatwg] Proposal to extend registerProtocolHandler
I definitely have privacy concerns regarding a isRegistered function. Such a function might be ok in some contexts, but I'd like to avoid it as far as possible. For example I don't think we need to think in terms of the, arguably crappy, UI that browsers currently use. One simple improvement that browsers could do is to simply have UI that shows yes, not now and never. If the user chooses never then no UI would be displayed the next time that the site calls registerProtocolHandler. Similarly, having a unregisterProtocolHandler without a isRegistered function makes a lot of sense to me. I agree it might not let you create the perfect UI, but you can get pretty far. / Jonas On Wed, Jul 6, 2011 at 10:30 PM, Ojan Vafai o...@chromium.org wrote: All the arguments for registering handlers aside, it ought to be possible for a website to provide some UI for deregistering. For example, many users will expect to go into gmail's settings to stop having gmail handle email links. Gmail's help section needing to give users instructions on each browser's UI for deregistering is not a good user experience. If they're going to have a UI for deregistering, it makes sense for them to be able to show it only when actually registered. On Wed, Jul 6, 2011 at 10:06 PM, Peter Kasting pkast...@google.com wrote: On Wed, Jul 6, 2011 at 6:38 PM, Rich Tibbett ri...@opera.com wrote: For registration, we could allow _auto-registration_ of protocol handlers only if a.) this is the first time the protocol is being registered and b.) when the registration request is coming directly from the top-most window context only (i.e. from a web page that users are actually visiting). We can't allow auto-registration in any case (nor was Robert suggesting that), or the protocol is registered to whoever happens to ask first, land-grab style. This is doubly bad if (like Chrome) the UA registers the protocol handler OS-wide. When the user wants to override the default protocol handler then the UA could allow e.g. ctrl-shift-click to force show the protocol handler dialog to the user. These sorts of click modifiers are all taken already. (Ctrl-shift-click means open link in new foreground tab.) Users should be able to easily detach protocol handlers from this list with either [delete] or [delete all handlers for this domain] on this interface. Honestly I think we're getting a bit afield here. It's not really the WHATWG's purview to say precisely what kind of interface UAs should provide. Even my comments about possibly wanting to check for a user gesture were intended as motivation for discussing various APIs, not as proposed specs. PK
Re: [whatwg] Timing API proposal for measuring intervals
On 08/07/2011 11:54, James Robinson wrote: True. On OS X, however, the CoreVideo and CoreAudio APIs are specified to use a unified time base (see http://developer.apple.com/library/ios/#documentation/QuartzCore/Reference/CVTimeRef/Reference/reference.html) so if we do end up with APIs saying play this sound at time X, like Chris Roger's proposed Web Audio API provides, it'll be really handy if we have a unified timescale for everyone to refer to. If you are to have any hope of synchronizing a set of media streams you need a common timebase. In TV studios it is called house sync. In the first computers capable of properly synchronizing media streams and in the OpenML specification it was called UST (Unadjusted System Time). This is the monotonic uniformly increasing hardware timestamp referred to in the Web Audio API proposal. Plus ça change. Plus ça même. For synchronization purposes, animation is just another media stream and it must use the same timebase as audio and video. Regards -Mark
Re: [whatwg] The blockquote element spec vs common quoting practices
Oli wrote: I’ve outlined the problem and some potential solutions (with their pros and cons) in: http://oli.jp/2011/blockquote/ Excellent work, IMHO. I've added my own little +1 here: http://adactio.com/journal/4675/ Oli continues: I think the blockquote spec should be changed to allow the inclusion of notes and attribution (quote metadata), perhaps by the addition of a sentence like: “Block quotes may also contain annotations or attribution, inline or in an optional footer element” This would change blockquote from being purely source content, to being source content with possible metadata inline or in a footer. However I don’t think that’s a problem, as these things increase the value of the quoted content. I think a spec change is necessary to accommodate common quoting practices. This sounds good to me. 1) Oli has shown the real-world use cases for attribution *within* blockquotes. I know that the Pave the cowpaths principle gets trotted out a lot, but Oli's research here is a great example of highlighting existing cowpaths (albeit in printed rather than online material): http://www.w3.org/TR/html-design-principles/#pave-the-cowpaths When a practice is already widespread among authors, consider adopting it rather than forbidding it or inventing something new. 2) This is something that authors want, both on the semantic and styling level (i.e. a way to avoid having to wrap every blockquote in a div just to associate attribution information with said blockquote). I believe that the problem statement that Oli has outlined fits with the HTML design principle Solve real problems. http://www.w3.org/TR/html-design-principles/#solve-real-problems Abstract architectures that don't address an existing need are less favored than pragmatic solutions to problems that web content faces today. 3) The solution that Oli has proposed (allowing footer within blockquote to include non-quoted information) is an elegant one, in my opinion. I can think of some solutions that would involve putting the attribution data outside the blockquote and then explicitly associating it using something like the @for attribute and an ID, but that feels messier and less intuitive to me. Simply allowing a footer within a blockquote to contain non-quoted material satisfies the design principle Avoid needless complexity. http://www.w3.org/TR/html-design-principles/#avoid-needless-complexity Simple solutions are preferred to complex ones, when possible. Simpler features are easier for user agents to implement, more likely to be interoperable, and easier for authors to understand. 4) Because the footer element is new to HTML5, I don't foresee any backward-compatibility issues. The web isn't filled with blockquotes containing footers that are part of the quoted material. Oli's solution would match up nicely with the design principle Support existing content. http://www.w3.org/TR/html-design-principles/#support-existing-content The benefit of the proposed change should be weighed against the likely cost of breaking content Jeremy -- Jeremy Keith a d a c t i o http://adactio.com/
Re: [whatwg] Microdata feedback
On Fri, 08 Jul 2011 00:33:14 +0200, Ian Hickson i...@hixie.ch wrote: On Wed, 8 Jun 2011, Tomasz Jamroszczak wrote: I've been looking into Microdata specification and it struck me, that crawling algorithm is so complex, when it comes to expressing simple ideas. I think that foremost the algorithm should be described in the specification with explanation what it's supposed to do, before steps of what exactly is to be done are written. Yeah. Turns out the algorithms involved here are quite badly broken. It was intended to expose the microdata graph as completely as possible while dropping anything that would introduce a loop, at the point where the first repetition would start (so A-B-C=A would break at the =), in the API, in the JSON, and in the conformance rules. I didn't do a good job speccing that, though! I've fixed the algorithms to make sense (I hope). http://www.whatwg.org/specs/web-apps/current-work/multipage/microdata.html#the-properties-of-an-item I had a look at this to verify that it is black-box-equivalent to what Opera has implemented, and only discovered one issue: div itemprop= should not be added to the .properties collection, because it has no properties. My bad for suggesting that the criteria should be the presence of an itemprop attribute, it should be an itemprop attribute containing at least one token. Can you update the spec to match? (I implemented the spec'd algorithm pedantically in https://gitorious.org/microdatajs/microdatajs/commit/217cc34e7e679e2e4ea3e670a0dcdd155a7b9800 for verification, it passes the unit tests with said modification.) On Wed, 29 Jun 2011, Philip Jägenstedt wrote: Note also that other algorithms defined in terms of items and their properties need to handle loopiness in some way. That's currently RDF, vCard and iCal conversion. Perhaps something like loopy item could be defined and those algorithms could skip loopy items wherever they occur? Simply failing is also an acceptable solution, IMO. I fixed vCard with a patch that just outputs AGENT;TYPE=VCARD:ERROR in the case of a loop. (Can only happen if the input is non-conforming, so it doesn't matter if the output is non-conforming.) WFM The vEvent stuff was already loop-safe. The JSON algorithm now ends the crawl when it hits a loop, and replaces the offending duplicate item with the string ERROR. WFM The RDF algorithm preserves the loops, since doing so is possible with RDF. Turns out the algorithm almost did this already, looks like it was an oversight. WFM, but note step 3: Add a mapping from the item item to the subject subject in memory, if there isn't one already. Step 1 guarantees that there is no entry for item, so step 3 can be unconditional. On Wed, 29 Jun 2011, Philip Jägenstedt wrote: Indeed, multiple types doesn't work at all if you want to mix different types. I was assuming that the use case was to extend types, kind of like http://schema.org/Person/Governor. However, it doesn't work all that well even in that case, since there's no way to know which type is the extension of the other and which properties exist only on the extended type. I don't really understand this use case. Can you elaborate on the problem that needs solving here? It's whatever problem http://schema.org/docs/extension.html is trying to solve, which is something like allow people to geek out with more specific vocabularies without interfering with search results. I whined a bit in http://groups.google.com/group/schemaorg-discussion/browse_thread/thread/6de3a1761b115271, the short story being: * extensibility encoded with a microsyntax in the URL, making it not-so-opaque * such URLs make the DOM API less useful Perhaps bending Microdata to accommodate for this is not the best idea. If I were schema.org, I would just encourage people to do this: div itemscope itemtype=http://schema.org/Person; div id=wrapper div itemprop=nameArnold/div div itemscope itemtype=http://example.com/Governor; itemref=wrapper div itemprop=stateCalifornia/div /div /div /div Making extensions unsightly is probably a good thing, to discourage people from going too crazy with it. This way it's also clear which properties only apply to the extended type. -- Philip Jägenstedt Core Developer Opera Software
Re: [whatwg] The blockquote element spec vs common quoting practices
Þann fös 8.júl 2011 11:20, skrifaði Jeremy Keith: 3) The solution that Oli has proposed (allowing footer within blockquote to include non-quoted information) is an elegant one, in my opinion. I can think of some solutions that would involve putting the attribution data outside the blockquote and then explicitly associating it using something like the @for attribute and an ID, but that feels messier and less intuitive to me. Simply allowing a footer within a blockquote to contain non-quoted material satisfies the design principle Avoid needless complexity. http://www.w3.org/TR/html-design-principles/#avoid-needless-complexity Simple solutions are preferred to complex ones, when possible. Simpler features are easier for user agents to implement, more likely to be interoperable, and easier for authors to understand. Citation will most likely contain the cited resource (@cite), the title of the cited resource (@title) and the date and optionally time of the quote (@datetime?). Further information could be put into other attributes as necessary. This seems simpler than cluttering the quote and citation together in the blockquote, but just throwing everything inside of the blockquote may very well be easier to implement. But is it really possible to mark such citations up without presentational elements? !-- 2112952019 = my national ID -- blockquote cite=kennitala:2112952019 title=Bjartur Thorlacius pLook ma, no lt;footer!/p pI think we should keep citations outside of lt;blockquote's contents as citations aren't part of the quote per se, but metadata on the quote and the quoted resource/p /blockquote
Re: [whatwg] Timing API proposal for measuring intervals
On 2011-07-08 12:32, Mark Callow wrote: On 08/07/2011 11:54, James Robinson wrote: True. On OS X, however, the CoreVideo and CoreAudio APIs are specified to use a unified time base (see http://developer.apple.com/library/ios/#documentation/QuartzCore/Reference/CVTimeRef/Reference/reference.html) so if we do end up with APIs saying play this sound at time X, like Chris Roger's proposed Web Audio API provides, it'll be really handy if we have a unified timescale for everyone to refer to. If you are to have any hope of synchronizing a set of media streams you need a common timebase. In TV studios it is called house sync. In the first computers capable of properly synchronizing media streams and in the OpenML specification it was called UST (Unadjusted System Time). This is the monotonic uniformly increasing hardware timestamp referred to in the Web Audio API proposal. Plus ça change. Plus ça même. For synchronization purposes, animation is just another media stream and it must use the same timebase as audio and video. Regards -Mark Agreed, and the burden of providing monotonic time lies on the OS (and indirectly the MB, HPET etc. or audio card or GPU clock or whatever the clock source is.) So Browsers should only need to convert to/from (if needed) Double and OS highres time format (which should be there via a OS API in a modern OS). -- Roger Rescator Hågensen. Freelancer - http://www.EmSai.net/
Re: [whatwg] The blockquote element spec vs common quoting practices
Bjartur wrote: Citation will most likely contain the cited resource (@cite), the title of the cited resource (@title) and the date and optionally time of the quote (@datetime?). All three of which are invisible and so do not match the use cases that Oli has outlined. At least @title has a tooltip but the @cite attribute has proven to be a complete disaster, unsupported by user agents and ignored by authors, precisely because it is *hidden* metadata. http://www.well.com/~doctorow/metacrap.htm So I think that we can learn from the history of the @cite attribute in that it shows us how *not* to do it. But is it really possible to mark such citations up without presentational elements? I'm not sure I understand the question. Do you mean presentational as in not conveying semantics or presentational as in visible? Jeremy -- Jeremy Keith a d a c t i o http://adactio.com/
Re: [whatwg] Proposal to extend registerProtocolHandler
If offering a potentially registerable api is done via link rel=protocol-handler type=foopy: href=... Then it'd be reasonable for a handling page to return some well known HTTP response (410?) to indicate that the API is no longer supported. The site wouldn't need to call a method, and the user agent would be able to do something reasonable *when* the user cared about the problem. For the case where the site wants the user to change from an old (dying) api to a new api, the site could use some other well known HTTP response (301?). And yes, it seems perfectly reasonable for UAs to collect possible handlers and let the user choose one when the user needs to use one. -- This is, for example, more or less how Windows handles removable media or other forms of content. And it matches more or less how UAs handle RSS feeds and search engines...
Re: [whatwg] Proposal to extend registerProtocolHandler
On Fri, Jul 8, 2011 at 12:05 AM, Jonas Sicking jo...@sicking.cc wrote: I definitely have privacy concerns regarding a isRegistered function. Such a function might be ok in some contexts, but I'd like to avoid it as far as possible. Just to be clear, you have privacy concerns for an isRegistered function that is same-domain restricted? For example I don't think we need to think in terms of the, arguably crappy, UI that browsers currently use. One simple improvement that browsers could do is to simply have UI that shows yes, not now and never. If the user chooses never then no UI would be displayed the next time that the site calls registerProtocolHandler. Similarly, having a unregisterProtocolHandler without a isRegistered function makes a lot of sense to me. I agree it might not let you create the perfect UI, but you can get pretty far. / Jonas On Wed, Jul 6, 2011 at 10:30 PM, Ojan Vafai o...@chromium.org wrote: All the arguments for registering handlers aside, it ought to be possible for a website to provide some UI for deregistering. For example, many users will expect to go into gmail's settings to stop having gmail handle email links. Gmail's help section needing to give users instructions on each browser's UI for deregistering is not a good user experience. If they're going to have a UI for deregistering, it makes sense for them to be able to show it only when actually registered. On Wed, Jul 6, 2011 at 10:06 PM, Peter Kasting pkast...@google.com wrote: On Wed, Jul 6, 2011 at 6:38 PM, Rich Tibbett ri...@opera.com wrote: For registration, we could allow _auto-registration_ of protocol handlers only if a.) this is the first time the protocol is being registered and b.) when the registration request is coming directly from the top-most window context only (i.e. from a web page that users are actually visiting). We can't allow auto-registration in any case (nor was Robert suggesting that), or the protocol is registered to whoever happens to ask first, land-grab style. This is doubly bad if (like Chrome) the UA registers the protocol handler OS-wide. When the user wants to override the default protocol handler then the UA could allow e.g. ctrl-shift-click to force show the protocol handler dialog to the user. These sorts of click modifiers are all taken already. (Ctrl-shift-click means open link in new foreground tab.) Users should be able to easily detach protocol handlers from this list with either [delete] or [delete all handlers for this domain] on this interface. Honestly I think we're getting a bit afield here. It's not really the WHATWG's purview to say precisely what kind of interface UAs should provide. Even my comments about possibly wanting to check for a user gesture were intended as motivation for discussing various APIs, not as proposed specs. PK
Re: [whatwg] Proposal to extend registerProtocolHandler
On Fri, Jul 8, 2011 at 9:44 AM, Ojan Vafai o...@chromium.org wrote: On Fri, Jul 8, 2011 at 12:05 AM, Jonas Sicking jo...@sicking.cc wrote: I definitely have privacy concerns regarding a isRegistered function. Such a function might be ok in some contexts, but I'd like to avoid it as far as possible. Just to be clear, you have privacy concerns for an isRegistered function that is same-domain restricted? Yes. / Jonas
Re: [whatwg] Video feedback
On Thu, 7 Jul 2011, Eric Winkelman wrote: On Thursday, June 02 Ian Hickson wrote: On Fri, 18 Mar 2011, Eric Winkelman wrote: For in-band metadata tracks, there is neither a standard way to represent the type of metadata in the HTMLTrackElement interface nor is there a standard way to represent multiple different types of metadata tracks. There can be a standard way. The idea is that all the types of metadata tracks that browsers will support should be specified so that all browsers can map them the same way. I'm happy to work with anyone interested in writing such a mapping spec, just let me know. I would be very interested in working on this spec. It would be several specs, probably, each focusing on a particular set of metadata in a particular format (e.g. advertising timings in an MPEG wrapper, or whatever). What's the next step? First, research: what formats and metadata streams are you interested in? Who uses them? How are they implemented in producers and (more importantly) consumers today? What are the use cases? Second, describe the problem: make a clear statement of purpose that scopes the effort to provide guidelines to prevent feature creep. Third, listen to implementors: find those that are interested in implementing this particular mapping of metadata to the DOM API, get their input, see what they want. Fourth, implement: make or have someone else make an experimental implementation of a mapping that addresses the problem described in the earlier steps. Fifth, specify: write a specification that describes the mapping described in step two, based on what you've researched in step one and based on the feedback from steps three and four. Sixth, test: update the experimental implement to fit the spec, get other implementations to implement the spec. Have real users play with it. Seventh, simplify: remove what you don't need. Finally, iterate: repeat all these steps for as long as there's any interest in this mapping, fixing problems, adding new features if they're needed, removing old features that didn't get used or implemented, etc. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Microdata feedback
On Fri, 08 Jul 2011 21:31:49 +0200, Ian Hickson i...@hixie.ch wrote: On Fri, 8 Jul 2011, Philip Jägenstedt wrote: On Fri, 08 Jul 2011 00:33:14 +0200, Ian Hickson i...@hixie.ch wrote: On Wed, 8 Jun 2011, Tomasz Jamroszczak wrote: I've been looking into Microdata specification and it struck me, that crawling algorithm is so complex, when it comes to expressing simple ideas. I think that foremost the algorithm should be described in the specification with explanation what it's supposed to do, before steps of what exactly is to be done are written. Yeah. Turns out the algorithms involved here are quite badly broken. It was intended to expose the microdata graph as completely as possible while dropping anything that would introduce a loop, at the point where the first repetition would start (so A-B-C=A would break at the =), in the API, in the JSON, and in the conformance rules. I didn't do a good job speccing that, though! I've fixed the algorithms to make sense (I hope). http://www.whatwg.org/specs/web-apps/current-work/multipage/microdata.html#the-properties-of-an-item I had a look at this to verify that it is black-box-equivalent to what Opera has implemented, and only discovered one issue: div itemprop= should not be added to the .properties collection, because it has no properties. My bad for suggesting that the criteria should be the presence of an itemprop attribute, it should be an itemprop attribute containing at least one token. Can you update the spec to match? What needs updating? As far as I can tell, what you describe is what the spec requires. Step 11 is If current has an itemprop attribute specified, add it to results. but should be If current has one or more property names, add it to results. Property names are defined in http://www.whatwg.org/specs/web-apps/current-work/multipage/microdata.html#property-names Why? If you start with div itemprop=foo, then div.itemProp.remove(foo) would give you div itemprop=. It'd be weird if the element still showed up in the properties collection after removing the only property name. On Wed, 29 Jun 2011, Philip Jägenstedt wrote: Indeed, multiple types doesn't work at all if you want to mix different types. I was assuming that the use case was to extend types, kind of like http://schema.org/Person/Governor. However, it doesn't work all that well even in that case, since there's no way to know which type is the extension of the other and which properties exist only on the extended type. I don't really understand this use case. Can you elaborate on the problem that needs solving here? It's whatever problem http://schema.org/docs/extension.html is trying to solve, which is something like allow people to geek out with more specific vocabularies without interfering with search results. That doesn't seem to be a problem. I don't really understand what problem this is solving. Neither do I. If the problem is just I want to annotate data that isn't defined in this vocabulary, that's already possible using URL property names. If I were schema.org, I would just encourage people to do this: div itemscope itemtype=http://schema.org/Person; div id=wrapper div itemprop=nameArnold/div div itemscope itemtype=http://example.com/Governor; itemref=wrapper div itemprop=stateCalifornia/div /div /div /div That's a bit weird. Why not just:? div itemscope itemtype=http://schema.org/Person; div itemprop=nameArnold/div div itemprop=http://example.com/Governor/state;California/div /div Yeah, that's better, at least when the number of additional attributes is small. It's hard to know without knowing what concrete user problem we're trying to solve here. I'll leave this discussion to the schema.org sponsors and just hope that the method in http://schema.org/docs/extension.html doesn't catch on. -- Philip Jägenstedt Core Developer Opera Software
Re: [whatwg] Timing API proposal for measuring intervals
, On Fri, Jul 8, 2011 at 2:54 PM, James Robinson jam...@google.com wrote: On Thu, Jul 7, 2011 at 7:36 PM, Robert O'Callahan rob...@ocallahan.orgwrote: Using this value as a clock for media synchronization sounds appealing but is complicated by audio clock drift. When you play N seconds of audio, it might take slightly more or less time to actually play, so it's hard to keep media times perfectly in sync with another timing source. Just something to keep in mind. True. On OS X, however, the CoreVideo and CoreAudio APIs are specified to use a unified time base (see http://developer.apple.com/library/ios/#documentation/QuartzCore/Reference/CVTimeRef/Reference/reference.html) so if we do end up with APIs saying play this sound at time X, like Chris Roger's proposed Web Audio API provides, it'll be really handy if we have a unified timescale for everyone to refer to. Is that unified time base in sync with the system clock, and how accurate is it? I'm concerned about the possibility that it's not feasible to keep the audio hardware clock in sync with the system clock, at least on some platforms. In that case, we probably need to keep media playback and animations in sync with the audio hardware clock, and we could even expose that via some DOM API, but you might not want to use the same clock for other purposes, such general performance timing for example ... I've heard the audio clock drift is often significant. I'm not sure if this is a real problem or not, I just want to make sure. Rob -- If we claim to be without sin, we deceive ourselves and the truth is not in us. If we confess our sins, he is faithful and just and will forgive us our sins and purify us from all unrighteousness. If we claim we have not sinned, we make him out to be a liar and his word is not in us. [1 John 1:8-10]
[whatwg] Call for Clarification of the Menu Element Et Al.
Hey All, I was in the process of coding a prototype for a site I'm working on when I decided that certain nav's should actually be menu's. While the basic concept is apparent, unfortunately, with zero browser implementation at this time, it is impossible to actually know what my markup is doing (or rather, would do). So I looked to the spec for guidance, but ultimately it leaves me very confused. These are some points I feel could be addressed, in no particular order: 1. How does one know whether to wrap a nested menu in li or leave it as a direct child element? Are these semantically-equivalent coding styles or is there a difference? 1.1. When marking up a menu specifically with *multiple* menu items, is menu/li the only way to do it or would menu/menu also be appropriate? 2. What is the difference between a menu containing command elements and a menu containing form controls? Do they merely favor future and legacy UAs respectively? 3. The spec should provide examples demonstrating when it is better to use context vs. toolbar vs. list, as these are very similar in concept. I could easily see them being misappropriated. 4. In the first example, what renders the button UI? Is it menu[@type=toolbar]/li, or li/menu? Or is it implied CSS? 4.1. Furthermore, should this example even depict a button UI, given that most graphical interfaces display top-level toolbars as text/icons against a [mostly] solid background Were a UA to render the example as demonstrated, would designers not have to style away the button appearance in order to achieve a look feel that matches user expectation? Obviously, this would not be the case in secondary (or n-ary) toolbars, for instance as in word processors, where everything below the initial row are usually buttons. Could there be a way, then, whether in markup or CSS, to denote whether a toolbar is displayed as a primary/top-level toolbar or not? 5. Provide more/graphical/clearer examples, to aid both browser vendors in deciding how to implement the elements, and authors in having an idea of what result they can expect from using them. The NPC form, for instance, does not say exactly what it is or does, nor does it represent a common UI convention. The only thing I can think of that comes close is Spotlight in OS X (if I'm interpreting it correctly), which I don't think I've ever seen in a [presumed] game before. 6. How is the command element rendered within a menu context when JavaScript is disabled? Is it meant only for non-essential actions? If it isn't, shouldn't it be able to be non-empty, so it can fallback to links or buttons? Or is the only possible fallback replicating every command with form controls that aren't direct children of the parent menu? 6.1 On that note, why is the spec enabling the use of unstyled spans to achieve alternative rendering? Doesn't this give meaning (however contextual) to an element that is supposed to be semantically neutral? 7. Is the menu element always to be rendered in-page or could it be displayed within the OS itself? Kroc Camen (suggests)[http://camendesign.com/blog/stop_this_madness] the latter but at present there is nothing in the spec about such an implementation. If this is left up to the UA how will developers know how/if to style it without using browser detection? Guidance, insight, reactions? Thank you, Hugh
