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
> si
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.
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 b
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
encourage
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
comment
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
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
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]
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
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 c
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 s
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
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
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 - Op
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://ber
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 docu
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., vi
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 displa
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 complic
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 th
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 oka
> > 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-
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 attribu
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.
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, ... ]]
25 matches
Mail list logo
