Re: ISSUE-99 (listen): Add shorter method names for addEventListener, et al? [DOM3 Events]
Starting shortening member names can open the Pandora box. What about getElementsByTagName, querySelector etc.? I think at this point of time it is better to avoid such an initiative. Because? And why at this point in time? To my knowledge the group is trying to advance the DOM-Events specification to the next level of acceptance. Will it become okay next week? I am not right person to be asked this question. We collectively made some pretty bad naming decisions in the past, fixing them is both harmless and useful. Yes, an example of the recent bad naming decision: querySelectorAll? Robin, I think proper naming as well as good API design indeed are highly important to the developer productivity. The length of the name to be typed in - hardly. Regards, Sergey/
Re: ISSUE-99 (listen): Add shorter method names for addEventListener, et al? [DOM3 Events]
On Aug 27, 2009, at 11:46 , Sergey Ilinsky wrote: Starting shortening member names can open the Pandora box. What about getElementsByTagName, querySelector etc.? I think at this point of time it is better to avoid such an initiative. Because? And why at this point in time? Will it become okay next week? We collectively made some pretty bad naming decisions in the past, fixing them is both harmless and useful. -- Robin Berjon - http://berjon.com/
Re: [widgets] More misplaced assertions
On Fri, Aug 28, 2009 at 11:22 AM, Robin Berjonro...@berjon.com wrote: On Aug 27, 2009, at 17:11 , Marcos Caceres wrote: I don't think the following two assertions are worth testing (and should not apply to the PC UA). [[ A user agent should expose custom icons in a way that it is visible to the end user. ]] And... [[ When the license element's href attribute is used, the user agent should provide end users the ability to view or otherwise link to the referenced license. ]] I don't know if we should delete them, or move them to another spec. Both of those are UI-level conformance criteria. Maybe there should just be a UI product? Yeah, that's what I'm thinking too. -- Marcos Caceres http://datadriven.com.au
Re: ISSUE-99 (listen): Add shorter method names for addEventListener, et al? [DOM3 Events]
On Aug 27, 2009, at 12:00 , Oliver Hunt wrote: I agree, also it is trivial for a developer or library to provide aliases to provide the shortened form (including supporting listenOnce) One shouldn't need to add a library just to make core interfaces user friendly. Libraries are for complicated, interesting, specific things that you don't expect a browser to support. -- Robin Berjon - http://berjon.com/
Re: [widgets] PC UA does not deal with SVG icons
On Fri, Aug 28, 2009 at 11:25 AM, Robin Berjonro...@berjon.com wrote: On Aug 27, 2009, at 17:33 , Marcos Caceres wrote: I also don't believe that the following text belongs in the PC spec (though it certainly needs to go somewhere): [[ A user agent that supports [SVG] as an icon format may display declarative animation. However, for security reasons, ... ]] WDYT? Same thing, should be a UI product — there's nothing wrong with having a bit of that, so long as it's not too constraining. I agree. I don't have a issue with the assertions. I just don't think this UI product should be defined as part of the PC spec. What spec would house the UI product? -- Marcos Caceres http://datadriven.com.au
[webdatabase] changeVersion should allow all callbacks to be optional
Hi, The spec currently requires the first 2 callbacks for the changeVersion method, while the 3rd is optional. The spec should make all of the callbacks optional so authors don't resort to specifying empty functions when they don't actually need to do anything with it. -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
Re: [widgets] PC UA does not deal with SVG icons
On Aug 28, 2009, at 11:52 , Marcos Caceres wrote: On Fri, Aug 28, 2009 at 11:25 AM, Robin Berjonro...@berjon.com wrote: Same thing, should be a UI product — there's nothing wrong with having a bit of that, so long as it's not too constraining. I agree. I don't have a issue with the assertions. I just don't think this UI product should be defined as part of the PC spec. What spec would house the UI product? Why not? Of the P+C consumer UAs, some will expose a UI. When they do, there are a few rules to follow. P+C is the spec that tells you what an icon is and where to find it — it seems perfectly fine to me that the attached UI requirements would be co-located. If I may paraphrase: there is no problem that cannot be solved by splitting bits into a different specification, apart from the problem of having too many specifications. -- Robin Berjon - http://berjon.com/
Re: [widgets] PC, assertion in wrong spec
On Aug 28, 2009, at 11:54 , Marcos Caceres wrote: Oh yeah, explaining why would help:) Like with the UI product from the prev email, this UA does not execute or deal with scripts. It only deals with processing config.xml and zip files. It should not behave as a policy enforcement point. So this could go into the WURI spec, that would make URIs pointing to DigSig documents point to nothing? -- Robin Berjon - http://berjon.com/
Re: [widgets] PC, assertion in wrong spec
On Aug 28, 2009, at 5:54 AM, ext Marcos Caceres wrote: On Fri, Aug 28, 2009 at 11:23 AM, Robin Berjonro...@berjon.com wrote: On Aug 27, 2009, at 14:33 , Marcos Caceres wrote: For the purpose of testing, I think the following assertion is in the wrong spec (PC): [[ A user agent must prevent a browsing context of a widget from accessing (e.g., via scripts, CSS, HTML, etc.) the contents of a digital signature document unless an access control mechanism explicitly enables such access, e.g. via an access control policy. The definition of such a policy mechanism is beyond the scope this specification, but can be defined by implementers to allow access to all or parts of the signature documents, or deny any such access. An exception is if a user agent that implements this specification also implements the optional [Widgets-DigSig] specification, in which case the user agent must make digital signature documents available only to the implementation of the [Widgets-DigSig] specification; a user agent must not make the digital signatures accessible to scripting or other content loading mechanisms, unless explicitly enabled by an access control mechanism. ]] It think we should move it out of PC into the API spec or some other spec. Why? Oh yeah, explaining why would help:) Like with the UI product from the prev email, this UA does not execute or deal with scripts. It only deals with processing config.xml and zip files. It should not behave as a policy enforcement point. I think this requirement isn't appropriate for what we should consider a strict P+C UA. As such, this bug could be addressed in a number of ways including making the text non-normative, removing the text from the spec, etc. The text could also be included in a document that describes or defines a Widget [runtime] User Agent. -Regards, Art Barstow
Re: [widgets] More misplaced assertions
On Aug 28, 2009, at 5:50 AM, ext Marcos Caceres wrote: On Fri, Aug 28, 2009 at 11:22 AM, Robin Berjonro...@berjon.com wrote: On Aug 27, 2009, at 17:11 , Marcos Caceres wrote: I don't think the following two assertions are worth testing (and should not apply to the PC UA). [[ A user agent should expose custom icons in a way that it is visible to the end user. ]] And... [[ When the license element's href attribute is used, the user agent should provide end users the ability to view or otherwise link to the referenced license. ]] I don't know if we should delete them, or move them to another spec. Both of those are UI-level conformance criteria. Maybe there should just be a UI product? Yeah, that's what I'm thinking too. I agree those two assertions should not apply to a strict P+C UA. Creating a new conformance criteria for these requirements on a Widget runtime UA is one way to address these bugs. -Regards, Art Barstow
Re: [widgets] PC the following should be a note
On Aug 28, 2009, at 5:24 AM, ext Robin Berjon wrote: On Aug 27, 2009, at 17:22 , Marcos Caceres wrote: [[ Note: A user agent that supports the [Widgets-APIs] specification will expose any declared preference to the author at runtime via scripting in the manner described in the [Widgets-APIs] specification. ]] +1 I agree the assertion Marcos cited should not be a requirement for a P +C UA. The proposed text above above would address this bug but I think will is too strong for this non-normative text and may would probably be more appropriate. Additionally, the use of *author* in the above is confusing; why is this particular Actor relevant in this context and how would a Widget runtime UA know about this Actor. -Regards, Art Barstow
Re: [widgets] PC UA does not deal with SVG icons
On Aug 28, 2009, at 8:55 AM, ext Robin Berjon wrote: On Aug 28, 2009, at 11:52 , Marcos Caceres wrote: On Fri, Aug 28, 2009 at 11:25 AM, Robin Berjonro...@berjon.com wrote: Same thing, should be a UI product — there's nothing wrong with having a bit of that, so long as it's not too constraining. I agree. I don't have a issue with the assertions. I just don't think this UI product should be defined as part of the PC spec. What spec would house the UI product? Why not? Of the P+C consumer UAs, some will expose a UI. When they do, there are a few rules to follow. P+C is the spec that tells you what an icon is and where to find it — it seems perfectly fine to me that the attached UI requirements would be co-located. I agree the text Marcos originally cited [1] should not be a normative requirement for a P+C UA. One way to address this bug is to make the cited text non-normative. As implied by these related threads, it would probably make sense to consolidate these Widget runtime UA requirements in a document. Any volunteers? -Regards, Art Barstow [1] http://www.w3.org/mid/4a96a741.8040...@opera.com
Re: [widgets] PC the following should be a note
Arthur Barstow wrote: On Aug 28, 2009, at 5:24 AM, ext Robin Berjon wrote: On Aug 27, 2009, at 17:22 , Marcos Caceres wrote: [[ Note: A user agent that supports the [Widgets-APIs] specification will expose any declared preference to the author at runtime via scripting in the manner described in the [Widgets-APIs] specification. ]] +1 I agree the assertion Marcos cited should not be a requirement for a P+C UA. The proposed text above above would address this bug but I think will is too strong for this non-normative text and may would probably be more appropriate. Additionally, the use of *author* in the above is confusing; why is this particular Actor relevant in this context and how would a Widget runtime UA know about this Actor. Agreed. The note should just read: A user agent that supports the [Widgets-APIs] specification will expose any declared preference at runtime in the manner described in the [Widgets-APIs] specification.
CfC: to publish a new WD of the DOM3 Events spec; deadline Sep 4
This is a Call for Consensus (CfC) to publish a new WD of the DOM 3 Events spec: http://dev.w3.org/2006/webapi/DOM-Level-3-Events/html/DOM3-Events.html As with all of our CfCs, positive response is preferred and encouraged and silence will be assumed to be assent. The deadline for comments is Sep 4. Although rev 1.50 is currently the latest version [1] and it says the date is July 20, the CVS history indicates Doug modified the document today. Doug - please update the date. DOM folks - please see [2] for a brief overview of WebApps' CfC process. -Regards, Art Barstow [1] http://dev.w3.org/cvsweb/2006/webapi/DOM-Level-3-Events/html/DOM3- Events.html [2] http://www.w3.org/2008/webapps/wiki/ WorkMode#Consensus_and_Call_for_Consensus Begin forwarded message: From: ext Doug Schepers schep...@w3.org Date: August 28, 2009 11:08:01 AM EDT To: member-weba...@w3.org member-weba...@w3.org Subject: New WD of DOM3 Events? Archived-At: http://www.w3.org/mid/4a97f2d1.6010...@w3.org Hi, WebApps WG- We have been working on the DOM3 Events spec for a while, and I have made quite a few edits recently. While it's certainly not complete, I believe it is at a stage where it would benefit from greater public review. I would like to ask the chairs to put the question to the WG on publishing a new Working Draft of the spec: http://dev.w3.org/2006/webapi/DOM-Level-3-Events/html/DOM3- Events.html Regards- -Doug Schepers W3C Team Contact, SVG and WebApps WGs
Re: CfC: to publish a new WD of the DOM3 Events spec; deadline Sep 4
On Aug 28, 2009, at 11:28 AM, Barstow Art (Nokia-CIC/Boston) wrote: This is a Call for Consensus (CfC) to publish a new WD of the DOM 3 Events spec: http://dev.w3.org/2006/webapi/DOM-Level-3-Events/html/DOM3- Events.html As with all of our CfCs, positive response is preferred and encouraged and silence will be assumed to be assent. The deadline for comments is Sep 4. We support this publication. -Regards, Art Barstow
Re: CfC: to publish a new WD of the DOM3 Events spec; deadline Sep 4
On Aug 28, 2009, at 17:28 , Arthur Barstow wrote: This is a Call for Consensus (CfC) to publish a new WD of the DOM 3 Events spec: http://dev.w3.org/2006/webapi/DOM-Level-3-Events/html/DOM3-Events.html As with all of our CfCs, positive response is preferred and encouraged and silence will be assumed to be assent. The deadline for comments is Sep 4. We very much support pushing a new WD out, and thank Doug for taking over this difficult yet essential specification — the editors' list reads like a war monument... let's hope he can take it all the way to Rec! -- Robin Berjon - http://berjon.com/
Re: CfC: to publish a new WD of the DOM3 Events spec; deadline Sep 4
On Fri, 2009-08-28 at 17:46 +0200, Robin Berjon wrote: the editors' list reads like a war monument... Actually, names have been added between the December 2007 and this version and I don't know why (more people to blame? :). Arnaud and Bob didn't edit the events specification [1] in the past. Philippe [1] http://www.w3.org/TR/2007/WD-DOM-Level-3-Events-20071221/
Re: CfC: to publish a new WD of the DOM3 Events spec; deadline Sep 4
On Fri, Aug 28, 2009 at 5:28 PM, Arthur Barstowart.bars...@nokia.com wrote: This is a Call for Consensus (CfC) to publish a new WD of the DOM 3 Events spec: http://dev.w3.org/2006/webapi/DOM-Level-3-Events/html/DOM3-Events.html As with all of our CfCs, positive response is preferred and encouraged and silence will be assumed to be assent. The deadline for comments is Sep 4. Please publish it and thanks for your contribution Doug to this spec It will always be time to make detail comment after that (it's always easier than following a moving target) Xmlizer
