Re: CfC: to publish a new WD of the DOM3 Events spec; deadline Sep 4

[mozer]

On Fri, Aug 28, 2009 at 5:28 PM, 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.
>

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

Re: CfC: to publish a new WD of the DOM3 Events spec; deadline Sep 4

[Philippe Le Hegaret]

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

[Robin Berjon]

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

[Arthur Barstow]

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

CfC: to publish a new WD of the DOM3 Events spec; deadline Sep 4

[Arthur Barstow]

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 
Date: August 28, 2009 11:08:01 AM EDT
To: "member-weba...@w3.org" 
Subject: New WD of DOM3 Events?
Archived-At: 

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: [widgets] P&C the following should be a note

[Marcos Caceres]

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."

Re: [widgets] P&C UA does not deal with SVG icons

[Arthur Barstow]

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 Berjon
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 P&C 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] P&C the following should be a note

[Arthur Barstow]

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] More misplaced assertions

[Arthur Barstow]

On Aug 28, 2009, at 5:50 AM, ext Marcos Caceres wrote:

On Fri, Aug 28, 2009 at 11:22 AM, Robin Berjon  
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 P&C 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] P&C, assertion in wrong spec

[Arthur Barstow]

On Aug 28, 2009, at 5:54 AM, ext Marcos Caceres wrote:

On Fri, Aug 28, 2009 at 11:23 AM, Robin Berjon  
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 (P&C):

[[
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 P&C 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: [webdatabase] changeVersion should allow all callbacks to be optional

[Lachlan Hunt]

Lachlan Hunt wrote:
  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.


On second thought, this might not be such a good idea.  If the purpose 
of the first callback in this case is to allow the author to actually 
make changes to the database, rather than simply change the version 
number and do nothing else.  I just didn't realise that's what it's 
purpose was at first.


FWIW, this API is insanely complicated and has way too many callbacks to 
keep track of.  It's caused me a lot of confusion and makes using it 
incredibly complex.


--
Lachlan Hunt - Opera Software
http://lachy.id.au/
http://www.opera.com/

Re: [widgets] P&C UA does not deal with SVG icons

[Robin Berjon]

On Aug 28, 2009, at 11:52 , Marcos Caceres wrote:
On Fri, Aug 28, 2009 at 11:25 AM, Robin Berjon  
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 P&C 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] P&C, assertion in wrong spec

[Robin Berjon]

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/

[webdatabase] changeVersion should allow all callbacks to be optional

[Lachlan Hunt]

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] P&C the following should be a note

[Robin Berjon]

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

--
Robin Berjon - http://berjon.com/

Re: [widgets] P&C, assertion in wrong spec

[Robin Berjon]

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 (P&C):


[[
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 P&C into the API spec or some  
other spec.


Why?

--
Robin Berjon - http://berjon.com/

Re: [widgets] P&C, assertion in wrong spec

[Marcos Caceres]

On Fri, Aug 28, 2009 at 11:23 AM, Robin Berjon 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 (P&C):
>>
>> [[
>> 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 P&C 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.


-- 
Marcos Caceres
http://datadriven.com.au

Re: [widgets] P&C UA does not deal with SVG icons

[Marcos Caceres]

On Fri, Aug 28, 2009 at 11:25 AM, Robin Berjon wrote:
> On Aug 27, 2009, at 17:33 , Marcos Caceres wrote:
>>
>> I also don't believe that the following text belongs in the P&C 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 P&C spec. What spec
would house the UI product?


-- 
Marcos Caceres
http://datadriven.com.au

Re: ISSUE-99 (listen): Add shorter method names for addEventListener, et al? [DOM3 Events]

[Robin Berjon]

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] More misplaced assertions

[Marcos Caceres]

On Fri, Aug 28, 2009 at 11:22 AM, Robin Berjon 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 P&C 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]

[Robin Berjon]

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: ISSUE-99 (listen): Add shorter method names for addEventListener, et al? [DOM3 Events]

[Sergey Ilinsky]

> > 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: [widgets] More misplaced assertions

[Robin Berjon]

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 P&C 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?


--
Robin Berjon - http://berjon.com/

Re: ISSUE-99 (listen): Add shorter method names for addEventListener, et al? [DOM3 Events]

[Anne van Kesteren]

On Fri, 28 Aug 2009 11:19:54 +0200, Robin Berjon  wrote:

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.


I don't really agree.  It would dramatically increase the number of tests  
required, you would get pages that do not work in older browsers for no  
reason other than using a "better" name, the complexity of the platform  
increases.


Authors would all have to learn the new methods, how they differ (if we  
decide to make minor cosmetic changes). Future authors would be left  
wondering why the old method exist, etc. And maybe further in the future  
they decide to do the big renaming thing again because well, our names  
were not so consistent after all.


If you want a much cleaner platform than what browsers provide you can  
write it on top of what browsers provide. Hopefully we get XBL soon as  
that will make such things much easier and neater.



--
Anne van Kesteren
http://annevankesteren.nl/

Re: [widgets] P&C UA does not deal with SVG icons

[Robin Berjon]

On Aug 27, 2009, at 17:33 , Marcos Caceres wrote:
I also don't believe that the following text belongs in the P&C 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.


--
Robin Berjon - http://berjon.com/