[whatwg] Web author docs for postMessage, updated postMessage tests
== Documentation == I've written up some documentation on how to use postMessage; suggestions, comments, etc. appreciated. http://developer.mozilla.org/en/docs/DOM:window.postMessage == Tests == I updated and expanded the tests I posted earlier to accommodate uri/domain-origin and the optional targetOrigin argument to postMessage: http://web/jwalden/www/whatwg/postMessage-v2.zip Same rules for use apply as before -- unzip somewhere, start up a local web server on port serving the postMessage/ directory as its root directory, turn on proxy autoconfig with the URL http://localhost:/proxy.js, and load and run http://localhost:/tests/dom/tests/mochitest/whatwg/index.html to see what passes and fails. The tests basically follow the spec or guard Mozilla-specific tests assuming you follow the spec. There are some cases where Mozilla doesn't follow the spec, however, and won't be able to do so before Mozilla 2, so unless you fail those tests exactly like Mozilla does they'll show up as failures when you run the tests. First, most of the problems you'll likely encounter relate to the value of .origin for IDN origins. HTML5 is silent on whether the value should be IDN, punycode, or even a chimeric mixture. I think .origin should never be punycode (authors shouldn't be forced to know about punycode, allowing either would require multiple origin comparisons, and also, Unicode ASCII), and the tests expect that (or, for the places where we fail that, they expect the opposite and mark that situation as a todo). If you do anything other than exactly match Mozilla behavior, you'll see tests listed as failures. Second, test_postMessage_closed.html fails if a popup blocker is enabled. Make sure to run this with the blocker disabled to actually make it do its tests right. Third, the tests require a very strict parsing of the optional targetOrigin argument to postMessage which rejects various malformed URIs. Unless you match Mozilla's behavior exactly, you'll see some errors here -- some quite likely erroneous. Note also that some of these tests check handling when this argument is punycode and when it's IDN; make sure you pass both. I apologize in advance if you find test_postMessage_origin.xhtml a little confusing to read; I don't especially like it either. However, it was the easiest way I could think of to run a whole lot of similar tests without lots of code-copying. I'm guessing existing URL parsers are lax because existing content is lax; for postMessage there's no existing content, so I'd like to see this done right from the start (or at least described that way in the spec, since Mozilla isn't in a position to switch to stricter parsing until Mozilla 2). Fourth, .origin for posts from data: URIs in Mozilla is the origin of the window that opened the data: URL, which is not what HTML5 wants (data: URLs each have origins distinct from all other origins in existence). Mozilla really isn't in a position to make a change to such fundamental security-conscious code right now, so this is expected to fail and marked as todo. If you do the right thing or don't do what we do, you'll get a failure on test_postMessage_special.xhtml. (I've documented Mozilla's behavior at the aforementioned link and noted that it's all but certainly going to change, and I've discouraged authors from using postMessage on pages at data: URIs for now. This isn't optimal, but I don't really think it's that huge a burden.) Fifth, I interpreted present and not null to mean that an explicit |undefined| second argument is converted to the string undefined and thus causes a syntax error to be thrown, based on a literal interpretation of the words in the phrase. Comments, questions, suggestions for more tests, etc. are all appreciated. Jeff
Re: [whatwg] Web author docs for postMessage, updated postMessage tests
http://web/jwalden/www/whatwg/postMessage-v2.zip Sigh: http://web.mit.edu/jwalden/www/whatwg/postMessage-v2.zip Jeff
Re: [whatwg] Geolocation API Proposal
Dnia 05-03-2008, Śr o godzinie 23:36 -0800, Aaron Boodman pisze: Hi all, We're adding an API to Google Gears that will allow an application to obtain (with permission) the user's current location. Here's our current design: http://code.google.com/p/google-gears/wiki/LocationAPI We think there's a lot of potential for interesting applications with an API like this. Some examples would be recommendations for nearby restaurants, turn by turn directions, or city walking tours. What do people think of adding something like this to a future version of HTML? The intersection of this interface with HTML is empty and it will always be because it does not hook on anything to declare. It qualifies as a browser extension. IMHO, Chris
Re: [whatwg] Geolocation API Proposal
On Thu, Mar 6, 2008 at 8:14 AM, Krzysztof Żelechowski [EMAIL PROTECTED] wrote: The intersection of this interface with HTML is empty and it will always be because it does not hook on anything to declare. It qualifies as a browser extension. How is it different than the HTML5 database API? In any case, I wanted to post this here because this seems to be where the right people are. But if you think there's a more appropriate group to approach, let me know. - a
Re: [whatwg] Geolocation API Proposal
Dnia 06-03-2008, Cz o godzinie 08:30 -0800, Aaron Boodman pisze: On Thu, Mar 6, 2008 at 8:14 AM, Krzysztof Żelechowski [EMAIL PROTECTED] wrote: The intersection of this interface with HTML is empty and it will always be because it does not hook on anything to declare. It qualifies as a browser extension. How is it different than the HTML5 database API? A database is general-purpose and this is an oracle for answering one question. In any case, I wanted to post this here because this seems to be where the right people are. But if you think there's a more appropriate group to approach, let me know. How about defining a URI scheme to be used with XMLHttpRequest? Where the URI will be 'about:geolocation' (or 'about:whereami') and the result is text/xml (or text/gps+xml)? I think browser extensions can easily hook into the about scheme and intercept it. Chris
Re: [whatwg] Geolocation API Proposal
Aaron Boodman wrote: On Thu, Mar 6, 2008 at 8:14 AM, Krzysztof Żelechowski [EMAIL PROTECTED] wrote: The intersection of this interface with HTML is empty and it will always be because it does not hook on anything to declare. It qualifies as a browser extension. How is it different than the HTML5 database API? It isn't. See http://blog.mozilla.com/rob-sayre/2008/02/19/bloaty-parts-of-the-whatwg- html5-specification-that-should-be-removed/ In particular, see Ian Hickson's comment. He already acknoledged that this stuff doesn't belong in the HTML specification, and the only reason that the current HTML 5 spec has so much junk in it is because nobody else is writing seperate specs for these features. Regards, Brian
Re: [whatwg] Geolocation API Proposal
2008/3/6 Aaron Boodman [EMAIL PROTECTED]: On Thu, Mar 6, 2008 at 8:14 AM, Krzysztof Żelechowski [EMAIL PROTECTED] wrote: The intersection of this interface with HTML is empty and it will always be because it does not hook on anything to declare. It qualifies as a browser extension. How is it different than the HTML5 database API? In any case, I wanted to post this here because this seems to be where the right people are. But if you think there's a more appropriate group to approach, let me know. After I wrote this, I realized the difference you might be thinking about. We were imagining that when standardized, this API might live at window.geolocation, clearly not google.gears The proposal actually mentions this in the top paragraph, but it might not be clear enough. Gears specifically avoids using the standard entry points (window, document, etc) to avoid conflicting with browser native implementations of the same standards. But from there down, we aim to implement the same interfaces. So the gears geolocation object would implement the same interface as the standard geolocation object, if there was one. Hope this helps, - a
Re: [whatwg] Geolocation API Proposal
2008/3/6 Brian Smith [EMAIL PROTECTED]: It isn't. See http://blog.mozilla.com/rob-sayre/2008/02/19/bloaty-parts-of-the-whatwg- html5-specification-that-should-be-removed/ In particular, see Ian Hickson's comment. He already acknoledged that this stuff doesn't belong in the HTML specification, and the only reason that the current HTML 5 spec has so much junk in it is because nobody else is writing seperate specs for these features. I agree with Ian. This stuff doesn't belong in HTML, but this seems to be a list where a lot of productive discussion is happening about things that don't belong in HTML. So I thought I'd propose it here first for feedback. I'll move the proposal to the W3C WebAPI mailing list. - a
Re: [whatwg] Geolocation API Proposal
Aaron Boodman wrote: 2008/3/6 Brian Smith [EMAIL PROTECTED]: It isn't. See http://blog.mozilla.com/rob-sayre/2008/02/19/bloaty-parts-of-the-whatwg- html5-specification-that-should-be-removed/ In particular, see Ian Hickson's comment. He already acknoledged that this stuff doesn't belong in the HTML specification, and the only reason that the current HTML 5 spec has so much junk in it is because nobody else is writing seperate specs for these features. I agree with Ian. This stuff doesn't belong in HTML, but this seems to be a list where a lot of productive discussion is happening about things that don't belong in HTML. So I thought I'd propose it here first for feedback. This specification at http://www.whatwg.org/specs/web-apps/current-work/ wasn't originally about HTML directly, but about web application APIs, for which these proposed features would be suitable. However, somewhere along the way, that spec became about HTML5 instead and much of the content contained in it was no longer directly applicable. The content just hasn't been moved elsewhere. I'm pretty sure that web APIs are still on topic for this list though.
Re: [whatwg] ARIA
James Graham wrote: Dave Hodder wrote: The current HTML 5 draft doesn't mention ARIA anywhere. Perhaps it should clarify the relationship (or non-relationship as it is at present), even if it's only a brief mention in section 1.1. Unfortunately a brief mention is insufficient as aria functionality overlaps substantially with HTML functionality and so processing requirements for aria-in-html need to be carefully considered (so we can answer questions like how does div aria-role='heading' affect the outline algorithm). This has not yet happened. Okay, so I can speak to this. I developed first browser implementation of ARIA -- the one in Firefox. ARIA doesn't really overlap with HTML, because ARIA only reports what a JS developer is using elements for. So ARIA semantics should not affect behavior. Any code for dealing with ARIA markup should be strictly in the accessibility API support code (MSAA/IAccessible2/ATK/AT-SPI/UI Automation/Universal Access). A div need not affect the outline algorithm, etc. any more than a div does. Thus it should not be complicated to mention ARIA in the spec. - Aaron
Re: [whatwg] Web author docs for postMessage, updated postMessage tests
Jeff Walden wrote: == Tests == http://web.mit.edu/jwalden/www/whatwg/postMessage-v2.zip Fourth, .origin for posts from data: URIs in Mozilla is the origin of the window that opened the data: URL, which is not what HTML5 wants I seem to have misread or misremembered how data: URIs are handled by HTML5, so this part was wrong; I updated the tests in the file at the above location to revert the change. Now there's an explicit, un-Mozilla-guarded check that http://localhost:; == the .origin of an event posted from a data: window to its opener which is located on http://localhost:. Jeff
Re: [whatwg] @Irrelevant [was: Re: Thoughts on HTML 5]
On Mar 1, 2008, at 4:05 AM, Jonas Sicking wrote: This sounds like a good idea to me. First off 'irrelevant' is pretty hard to spell for non-native english speakers (go sweden!). Second, the elements are in fact relevant to the page since in all likelihood they will be used later. 'ignore' feels like a better description since it's weaker. We want to acknowledges the existance of the element, but tells you to not pay attention to it. Though I might be making making the last part up given that I fall into the first category :) I like ignore and omit as options. irrelevant is indeed awkward to spell. - Maciej / Jonas Nicholas C. Zakas wrote: From this thread, it seems like the true purpose of irrelevant is to add to HTML the logical equivalent of display:none in CSS. If that is true, then I'd agree with Jeff that renaming the attribute ignore or omit is a good idea. Can anyone either confirm or deny the purpose of this attribute as the following description: This attribute is used to indicate part of a document whose content is not considered primary to the page. In visual UAs, elements with this attribute are not rendered; in non-visual UAs, elements with this attribute are not read as part of the normal content flow. Thoughts? -Nicholas - Original Message From: Jeff Walden [EMAIL PROTECTED] To: Nicholas C. Zakas [EMAIL PROTECTED] Cc: James Graham [EMAIL PROTECTED]; whatwg@lists.whatwg.org Sent: Friday, February 29, 2008 11:41:41 AM Subject: Re: [whatwg] @Irrelevant [was: Re: Thoughts on HTML 5] Nicholas C. Zakas wrote: If the true purpose of the irrelevant attribute is to aid in accessibility, then I think the name is completely wrong. The term irrelevant is confusing because, as I stated before, why would anyone include content in a page that is irrelevant? What you really need is a way to say this is relevant only for non-visual UA's. Perhaps a better attribute name would be nonvisual? Unnecessarily suggests a particular medium of display; I suggest the shorter alternatives ignore(d) or omit(ted) if you really want the functionality. The biggest problem with the attribute is the spec doesn't sufficiently clearly describe the motivation for it; I suggest mentioning the preloading of iframes as such an example (they don't load/render if they're display:none, so it's either visibility:hidden (?) or launching the element into outer space offscreen with position/top/left), perhaps in an informative paragraph. Jeff Looking for last minute shopping deals? Find them fast with Yahoo! Search. http://us.rd.yahoo.com/evt=51734/*http://tools.search.yahoo.com/newsearch/category.php?category=shopping
Re: [whatwg] Geolocation API Proposal
2008/3/6 Aaron Boodman [EMAIL PROTECTED]: How is it different than the HTML5 database API? It's not. Neither belongs in an HTML specification, but a charismatic leader should be able to overcome this obstacle. -- Robert Sayre
