Re: [whatwg] [canvas] Path object
On Oct 2, 2012, at 4:58 PM, Elliott Sprehn espr...@gmail.com wrote: What of the fact that this breaks existing pages with input id=Path that access it as just Path? Historically this has been a non-starter for new APIs. On Wed, 03 Oct 2012 05:12:46 +0200, Maciej Stachowiak m...@apple.com wrote: Can we get data on prevalence of such pages? Data set: http://www.paciellogroup.com/blog/2012/04/html5-accessibility-chops-data-for-the-masses/ $ grep -aPc \s(?i:(id|name))\s*=\s*(\|')?Path((\|')|(\s||/)) stevef-all 0 $ grep -aPc \s(?i:(id|name))\s*=\s*(\|')?Audio((\|')|(\s||/)) stevef-all 2 $ grep -aPc \s(?i:(id|name))\s*=\s*(\|')?URL((\|')|(\s||/)) stevef-all 18 Data set: http://dotnetdotcom.org/ $ grep -aPc \s(?i:(id|name))\s*=\s*(\|')?Path((\|')|(\s||/)) web200904 85 $ grep -aPc \s(?i:(id|name))\s*=\s*(\|')?Audio((\|')|(\s||/)) web200904 27 $ grep -aPc \s(?i:(id|name))\s*=\s*(\|')?URL((\|')|(\s||/)) web200904 1357 (I don't have data on how many of these also do something like form onsubmit=return validate(URL) etc.) -- Simon Pieters Opera Software
[whatwg] Firing WebStorage storage event
Hi all, I would like to ask for your help. I'm having hard time understanding the rules for firing WebStorage's storage event. In section 11.2.3 (http://www.whatwg.org/specs/web-apps/current-work/multipage/webstorage.html#the-localstorage-attribute) we have this sentence [1]: When the setItem(), removeItem(), and clear() methods are called on a Storage object x that is associated with a local storage area, if the methods did something, then in every Document object whose Window object's localStorage attribute's Storage object is associated with the same storage area, other than x, a storage event must be fired, as described below. as described below points to section 11.2.4, which reads [2]: The storage event is fired when a storage area changes, as described in the previous two sections (for session storage, for local storage). When this happens, the user agent must queue a task to fire an event with the name storage, which does not bubble and is not cancelable, and which uses the StorageEvent interface, at each Window object whose Document object has a Storage object that is affected. What I understood: Sentence [1] says that storage events should be fired on affected Document objects, except the one that originated the change. Sentences in [2] say that when a storage event is fired as described in [1], a task must be queued to fire storage events on all affected Window objects. It also says that Document objects have Storage objects, which I don't think is true. Is my understanding correct? What am I missing? Thanks in advance for your help. Best regards, Janusz Majnert
Re: [whatwg] [canvas] Path object
On 10/3/12 1:31 AM, Charles Pritchard wrote: Mozilla has an extensive system for bug reporting. You mean like a bug database? I suspect their switch between various versions is related to their data as captured by those systems. I suspect that's bollocks, with all due respect. They have publicized how they track bug reports from the browser, and in doing so, how they analyze what breaks the web. I am unaware of such a system. Link please? I'd really like to make use of it, if it exists. ;) -Boris
[whatwg] FW: [[IANA #598704] Registration for application/microdata+json media type]
Hixie, See below the reply from IANA about registration for application/microdata+json. I'll make the simple n/a changes when I re-submit it. But see in particular the suggestion about security. --Mike - Forwarded message from Amanda Baber via RT iana-m...@iana.org - Subject: [IANA #598704] Registration for application/microdata+json media type From: Amanda Baber via RT iana-m...@iana.org To: m...@w3.org Date: Tue, 18 Sep 2012 18:29:33 + Hi Michael, The IESG-designated expert has reviewed your application and returned the inline comments below. Please reply to this email within 30 days (i.e. by October 17) with a revised application. If you have any questions, please don't hesitate to contact us. Best regards, Amanda Baber ICANN/IANA === Type name: application Subtype name: microdata+json Required parameters: Same as for application/json [JSON] Optional parameters: Same as for application/json [JSON] Application/json does not define any parameters. As such, this is an unnecessary reference that forces readers to check something and find nothing. Moreover, in the highly unlikely event that parameters were to be added to application/json in the future, it would be extremely unwise for existing registrations to inherit them willy-nilly. Both of these need to be changed to: n/a. Encoding considerations: 8bit (always UTF-8) Security considerations: Same as for application/json [JSON] If my understanding is correct, like JSON in general, microdata content is essentially arbitrary. The point of having a microdata specification is to have a consistent means of embedding stuff in HTML5, not to define what that stuff is. Given this, and had the security considerations for application/json been done properly, this might, and I emphasize might, have been sufficient to just reference the application/json security considerations. But the security considerations for application/json fail to address the issues associated with being able to represent arbitrary content. As such, they need to be addressed here. At a minimum the possibility of active or executable content as well as privacy and integrity need to be addressed. I suggest something like: The security considerations associated with the JSON format [JSON] apply to this media type. The content of this media type can include active or executable content. The content may also be sensitive, so privacy and integrity services may need to be used to protect the content in some instances. Interoperability considerations: Same as for application/json [JSON] This is again a reference to nothing. It needs to change to: n/a Published specification: Labeling a resource with the application/microdata+json type asserts that the resource is a JSON text that consists of an object with a single entry called items consisting of an array of entries, each of which consists of an object with an entry called id whose value is a string, an entry called type whose value is another string, and an entry called properties whose value is an object whose entries each have a value consisting of an array of either objects or strings, the objects being of the same form as the objects in the aforementioned items entry. Thus, the relevant specifications are the JSON specification and the HTML Microdata specification. http://www.w3.org/TR/microdata/#application-microdata-json This is a hard one to get right. Referencing the media type declaration is circular and therefore somewhat pointless, but referencing the entire microdata specification seems wrong somehow. My suggestion would be to reference section 5.1: http://www.w3.org/TR/microdata/#json But if you want to reference the entire specification that's also OK: http://www.w3.org/TR/microdata Applications that use this media type: Same as for application/json [JSON] It's fine not to list specific applications and therefore leave this blank, but this is effectively asserting that every application that uses JSON also uses microdata, which is rather obviously incorrect. Additional information: Magic number(s): Same as for application/json [JSON] Change to: n/a File extension(s): Same as for application/json [JSON] Change to: .json Macintosh file type code(s): Same as for application/json [JSON] Change to: n/a Person email address to contact for further information: Michael[tm] Smith m...@w3.org Intended usage: Common Restrictions on usage: No restrictions apply. Author: Ian Hickson i...@hixie.ch Change controller: W3C Fragment identifiers used with application/microdata+json resources have the same semantics as when used with application/json (namely, at the time of writing, no semantics at all). [JSON] I have to wonder if this is a good idea, but it's acceptable from a registration standpoint. - End forwarded message - -- Michael[tm] Smith http://people.w3.org/mike
Re: [whatwg] [canvas] Path object
This subthread has crossed the line of what is acceptable on this mailing list. I'd like to remind everyone that discussion on this list should focus on technical issues and not on process discussions, and that all communication should be respectful, and avoid presenting wild speculation as facts. Thanks. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] [canvas] Path object
On Wed, Oct 3, 2012 at 2:01 PM, Glenn Maynard gl...@zewt.org wrote: On Tue, Oct 2, 2012 at 7:16 PM, Charles Pritchard ch...@jumis.com wrote: I think moz already made the move to require document.getElementById for these cases. It looks like they did in FF13 (in standards mode, not quirks mode), but no longer in FF15. I'm surprised this was even considered, never mind deployed--it must break tons of pages. Gecko *always* required getElementById in standards mode, until FF15. That's why most pages worked (and still do) without element IDs in the global scope. But no-one else was willing to follow suit, so we dropped it. Rob -- “You have heard that it was said, ‘Love your neighbor and hate your enemy.’ But I tell you, love your enemies and pray for those who persecute you, that you may be children of your Father in heaven. ... If you love those who love you, what reward will you get? Are not even the tax collectors doing that? And if you greet only your own people, what are you doing more than others? [Matthew 5:43-47]
Re: [whatwg] [canvas] Path object
On Wed, Oct 3, 2012 at 8:44 PM, Robert O'Callahan rob...@ocallahan.orgwrote: Gecko *always* required getElementById in standards mode, until FF15. That's why most pages worked (and still do) without element IDs in the global scope. But no-one else was willing to follow suit, so we dropped it. That's unfortunate. It's one of the most pathologically broken behaviors on the platform; now there will be nothing discouraging people from using it. I think this was a net win despite the cost to interoperability. -- Glenn Maynard
Re: [whatwg] [canvas] Path object
On 10/3/12 10:19 PM, Glenn Maynard wrote: That's unfortunate. It's one of the most pathologically broken behaviors on the platform; now there will be nothing discouraging people from using it. I think this was a net win despite the cost to interoperability. That is as may be, but: 1) Every single other UA implemented the global scope polluter in standards mode. 2) The spec called for it to be implemented in standards mode. Repeated requests that the spec be changed got denied with see point 1. 3) Repeated requests for other UAs to drop support for the global scope polluter in standards mode were met with either silence or great surprise that Gecko had the behavior it did, followed by silence. 4) The growing number of web developers who only bother testing in WebKit meant that there were more and more sites that were breaking in Gecko due to relying on the global scope polluter. 5) Other browser vendors were putting out conformance and performance tests that relied on the global scope polluter to function. I decided it wasn't worth punishing our users further if no one else in the world cared about this. -Boris
Re: [whatwg] [canvas] Path object
On 10/3/12 11:04 PM, Boris Zbarsky wrote: I decided it wasn't worth punishing our users further if no one else in the world cared about this. Oh, and for the record we added gsp support in standards mode in Firefox 14. We kept the warning when it was used until Firefox 15, somewhat by accident; at that point we removed it, since warning on something every UA implements and the spec requires is a bit pointless. -Boris
