[Bug 13691] New: method setItem(key, value) Why don't you fix a third optional parameter to set the "duration" of the key/value pair. If it is not set the key/value pair will not expire otherwise i

[bugzilla]

http://www.w3.org/Bugs/Public/show_bug.cgi?id=13691

   Summary: method setItem(key, value) Why don't you fix a third
optional parameter to set the "duration" of the
key/value pair.  If it is not set the key/value pair
will not expire otherwise it will expire as it is set
in the 'duration' parameter.
   Product: WebAppsWG
   Version: unspecified
  Platform: Other
   URL: http://www.whatwg.org/specs/web-apps/current-work/#top
OS/Version: other
Status: NEW
  Severity: normal
  Priority: P3
 Component: Web Storage (editor: Ian Hickson)
AssignedTo: i...@hixie.ch
ReportedBy: contribu...@whatwg.org
 QAContact: member-webapi-...@w3.org
CC: i...@hixie.ch, m...@w3.org, public-webapps@w3.org


Specification: http://dev.w3.org/html5/webstorage/
Multipage: http://www.whatwg.org/C#top
Complete: http://www.whatwg.org/c#top

Comment:
method setItem(key, value)

Why don't you fix a third optional parameter to set the "duration" of the
key/value pair. 
If it is not set the key/value pair will not expire otherwise it will expire
as it is set in the 'duration' parameter. 


Posted from: 79.50.20.32
User agent: Mozilla/5.0 (X11; Linux i686; rv:2.0.1) Gecko/20100101
Firefox/4.0.1

-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

[Bug 13690] New: method setItem(key, value) Why don't you fix a third optional parameter to set the "duration" of the key/value pair. If it is not set the key/value pair will not expire otherwise i

[bugzilla]

http://www.w3.org/Bugs/Public/show_bug.cgi?id=13690

   Summary: method setItem(key, value) Why don't you fix a third
optional parameter to set the "duration" of the
key/value pair.  If it is not set the key/value pair
will not expire otherwise it will expire as it is set
in the 'duration' parameter.
   Product: WebAppsWG
   Version: unspecified
  Platform: Other
   URL: http://www.whatwg.org/specs/web-apps/current-work/#top
OS/Version: other
Status: NEW
  Severity: normal
  Priority: P3
 Component: Web Storage (editor: Ian Hickson)
AssignedTo: i...@hixie.ch
ReportedBy: contribu...@whatwg.org
 QAContact: member-webapi-...@w3.org
CC: i...@hixie.ch, m...@w3.org, public-webapps@w3.org


Specification: http://dev.w3.org/html5/webstorage/
Multipage: http://www.whatwg.org/C#top
Complete: http://www.whatwg.org/c#top

Comment:
method setItem(key, value)

Why don't you fix a third optional parameter to set the "duration" of the
key/value pair. 
If it is not set the key/value pair will not expire otherwise it will expire
as it is set in the 'duration' parameter. 


Posted from: 79.50.20.32
User agent: Mozilla/5.0 (X11; Linux i686; rv:2.0.1) Gecko/20100101
Firefox/4.0.1

-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

[Bug 13686] Either remove the special case from onmessage (to call start()) or add it also to addEventListener listeners

[bugzilla]

http://www.w3.org/Bugs/Public/show_bug.cgi?id=13686

Ian 'Hixie' Hickson  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||i...@hixie.ch
 Resolution||WONTFIX

--- Comment #3 from Ian 'Hixie' Hickson  2011-08-06 06:08:37 UTC 
---
I don't think changing addEventListener() makes sense. It's one thing to have
an attribute with magic, it's quite another to have an API that is magical only
in certain circumstances.

Anyway, it doesn't make sense to make addEventListener() magical here. If
you're using it, you almost certainly are doing something more complicated than
just hooking a listener and using the port — you're probably hooking a series
of listeners, possibly not all in the same task, each to look for one
particular type of message. IIRC there's an example of this in the spec. For
that use case, it doesn't make sense to start the port quickly.

-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

[Bug 10930] CanvasPixelArray out of range behavior needs clarification

[bugzilla]

http://www.w3.org/Bugs/Public/show_bug.cgi?id=10930

Ian 'Hixie' Hickson  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

--- Comment #16 from Ian 'Hixie' Hickson  2011-08-06 03:52:02 
UTC ---
EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are
satisfied with this response, please change the state of this bug to CLOSED. If
you have additional information and would like the editor to reconsider, please
reopen this bug. If you would like to escalate the issue to the full HTML
Working Group, please add the TrackerRequest keyword to this bug, and suggest
title and text for the tracker issue; or you may create a tracker issue
yourself, if you are able to do so. For more details, see this document:
   http://dev.w3.org/html5/decision-policy/decision-policy.html

Status: Accepted
Change Description: see diff given below
Rationale: Concurred with reporter's comments.

-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

[Bug 13295] The "make disappear a WebSocket object" case should not fail the WebSocket connection

[bugzilla]

http://www.w3.org/Bugs/Public/show_bug.cgi?id=13295

Brian Raymor [MSFT]  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|NEEDSINFO   |

--- Comment #2 from Brian Raymor [MSFT]  2011-08-06 
00:13:38 UTC ---
If the connection is not established, then the preference is to treat this as a
"user cancel" rather than an error and simply "close the websocket connection"
and fire onClose.

The other option is to be specific about the "fail the websocket connection"
behavior for this case and indicate onError is not fired.

Based on the definition of "fail the websocket connection" in the protocol
draft, "report the problem to the user" is a MAY:

http://tools.ietf.org/html/draft-ietf-hybi-thewebsocketprotocol-10#section-7.1.7

 Certain algorithms and specifications require an endpoint to _Fail
   the WebSocket Connection_.  To do so, the client MUST _Close the
   WebSocket Connection_, and MAY report the problem to the user (which
   would be especially useful for developers) in an appropriate manner.

-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

[Bug 12574] AbstractWorker and WorkerGlobalScope should inherit EventTarget

[bugzilla]

http://www.w3.org/Bugs/Public/show_bug.cgi?id=12574

Ian 'Hixie' Hickson  changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution||FIXED

--- Comment #16 from Ian 'Hixie' Hickson  2011-08-05 23:43:34 
UTC ---
Fair enough.

-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

[Bug 13322] Add UDP! Quake uses UDP, I can't continue development of WebQuake because it uses UDP.

[bugzilla]

http://www.w3.org/Bugs/Public/show_bug.cgi?id=13322

Ian 'Hixie' Hickson  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||i...@hixie.ch
 Resolution||FIXED

--- Comment #1 from Ian 'Hixie' Hickson  2011-08-05 23:34:33 UTC 
---
Done. See PeerConnection in http://whatwg.org/html

-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

[Bug 13294] The send() method should fail the WebSocket connection when data cannot be sent

[bugzilla]

http://www.w3.org/Bugs/Public/show_bug.cgi?id=13294

Ian 'Hixie' Hickson  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||i...@hixie.ch
 Resolution||FIXED

--- Comment #2 from Ian 'Hixie' Hickson  2011-08-05 23:34:02 UTC 
---
Failing the WebSocket connection involves sending more data. We can't send more
data in this situation, by definition (that's why we're giving up, after all).

But we can still fire an 'error' event, sure. Done.

Note that both 'error' and 'close' are fired asynchronously (well, they're
fired synchronously, but on a task that is queued after the connection is
closed).

-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

[Bug 13295] The "make disappear a WebSocket object" case should not fail the WebSocket connection

[bugzilla]

http://www.w3.org/Bugs/Public/show_bug.cgi?id=13295

Ian 'Hixie' Hickson  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||i...@hixie.ch
 Resolution||NEEDSINFO

--- Comment #1 from Ian 'Hixie' Hickson  2011-08-05 23:05:42 UTC 
---
I don't understand the question. What would you do instead? Let the handshake
complete then close it?

How would it be captured as an error condition? It's not like any events are
going to be fired, the event queue is about to be torn down...

-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

[Bug 13633] Add high-level overviews to more of the abstract algorithms, like for "set the selection's value"

[bugzilla]

http://www.w3.org/Bugs/Public/show_bug.cgi?id=13633

Aryeh Gregor  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

--- Comment #2 from Aryeh Gregor  2011-08-05 21:48:28 UTC ---
I added explanations to a lot more places:

http://aryeh.name/gitweb.cgi?p=editing;a=commitdiff;h=008821cc
http://aryeh.name/gitweb.cgi?p=editing;a=commitdiff;h=96e65cdc
http://aryeh.name/gitweb.cgi?p=editing;a=commitdiff;h=a1d44fea
http://aryeh.name/gitweb.cgi?p=editing;a=commitdiff;h=a76a3c12

Tell me if you want anything specific explained more.

-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

Re: Reference to the HTML specification

[Julian Reschke]

On 2011-08-05 17:22, Ian Hickson wrote:

They're errors. Some of the text in the HTML WG specs is actually
self-contradictory, other parts of it are gramatically incorrect, there


a) File bugs.

b) Fix the grammar errors, if you think they are harmful. You are the 
editor.



are decisions that contradict 10-15 years of accessibility advocacy, and


Oh my. Whose advocacy exactly?


there's text that misuses terms as defined in the spec itself.


Fix the text, you are the editor. Or file bugs. Maybe let somebody else 
fix them.



In an earlier e-mail you wrote:


This undermines and is disrespectful the work of the HTML Working Group.


Respect is earned.


Indeed.

Best regards, Julian

WebGL/Khronos liaison (Was: Reference to the HTML specification)

[Philippe Le Hegaret]

On Fri, 2011-08-05 at 14:52 -0400, Arun Ranganathan wrote:
> I'm aware of public-script-coord, and think WG-to-WG coordination is 
> definitely more efficient for technical matters.  I assumed (perhaps 
> incorrectly) existing relations between working groups across 
> organizations (e.g. W3C/IETF) was by virtue of cross-organization 
> coordination by W3C Team, but if you're happy with the status quo and 
> think nothing needs to be done, I'm certainly happy :)

Unless you believe something is broken, I'm inclined to keep the status
quo,

Philippe

Re: Reference to the HTML specification

[Arun Ranganathan]

On 8/5/11 2:19 PM, Philippe Le Hegaret wrote:

On Fri, 2011-08-05 at 13:41 -0400, Arun Ranganathan wrote:

On 8/5/11 11:52 AM, Philippe Le Hegaret wrote:

On Fri, 2011-08-05 at 17:18 +0200, Marcos Caceres wrote:

Again, what are the reasons to link to the WHATWG HTML version?

If there is something you need that is not in the W3C spec, then it seems like 
a valid reason (e.g., PeerConnection API or some helpful concept).

Agreed, but no one has come up with such need so far.

I refer to the HTML WG's work as normative, but in the File API's
Editor's Draft [0], I'd also like to link to the WHATWG document as an
informative reference for the Stream API [1]  and LocalMediaStream [2].
This is a pragmatic, and not a political, cross-referencing.

I have no issue with that. I would simply note that work is now ongoing
in the WebRTC group so you might want to monitor what they're doing.


Duly noted!



Stream API reuses blob: URIs; LocalMediaStream defines globally unique
identifiers in a way that I find useful for the opaqueString
production.  I'm tidying up normative and informative links, and in
general, I think the time is ripe for a good discussion of affiliated
specifications.  Another area for coordination that I'd encourage is
between W3C and Khronos, if it isn't happening already.  For instance,
File API makes use of ArrayBuffer [3] *normatively* which is defined at
Khronos [3] and which is implemented in some user agents.  Is there a
formal liaison?  This will benefit WebGL as well.

We don't have a formal liaison with Khronos at the moment. In fact, we
don't do formal liaison in general, we prefer to have technical liaisons
instead (ie directly from Working Group to Working Group). Why would we
need to have a formal liaison in order to reference a specification? Are
you aware of public-script-co...@w3.org [1] ?

Philippe

[1] http://lists.w3.org/Archives/Public/public-script-coord/


I'm aware of public-script-coord, and think WG-to-WG coordination is 
definitely more efficient for technical matters.  I assumed (perhaps 
incorrectly) existing relations between working groups across 
organizations (e.g. W3C/IETF) was by virtue of cross-organization 
coordination by W3C Team, but if you're happy with the status quo and 
think nothing needs to be done, I'm certainly happy :)


-- A*

Re: Reference to the HTML specification

[Philippe Le Hegaret]

On Fri, 2011-08-05 at 13:41 -0400, Arun Ranganathan wrote:
> On 8/5/11 11:52 AM, Philippe Le Hegaret wrote:
> > On Fri, 2011-08-05 at 17:18 +0200, Marcos Caceres wrote:
> >>> Again, what are the reasons to link to the WHATWG HTML version?
> >> If there is something you need that is not in the W3C spec, then it seems 
> >> like a valid reason (e.g., PeerConnection API or some helpful concept).
> > Agreed, but no one has come up with such need so far.
> 
> I refer to the HTML WG's work as normative, but in the File API's 
> Editor's Draft [0], I'd also like to link to the WHATWG document as an 
> informative reference for the Stream API [1]  and LocalMediaStream [2].  
> This is a pragmatic, and not a political, cross-referencing.

I have no issue with that. I would simply note that work is now ongoing
in the WebRTC group so you might want to monitor what they're doing.

> Stream API reuses blob: URIs; LocalMediaStream defines globally unique 
> identifiers in a way that I find useful for the opaqueString 
> production.  I'm tidying up normative and informative links, and in 
> general, I think the time is ripe for a good discussion of affiliated 
> specifications.  Another area for coordination that I'd encourage is 
> between W3C and Khronos, if it isn't happening already.  For instance, 
> File API makes use of ArrayBuffer [3] *normatively* which is defined at 
> Khronos [3] and which is implemented in some user agents.  Is there a 
> formal liaison?  This will benefit WebGL as well.

We don't have a formal liaison with Khronos at the moment. In fact, we
don't do formal liaison in general, we prefer to have technical liaisons
instead (ie directly from Working Group to Working Group). Why would we
need to have a formal liaison in order to reference a specification? Are
you aware of public-script-co...@w3.org [1] ?

Philippe

[1] http://lists.w3.org/Archives/Public/public-script-coord/

Re: Reference to the HTML specification

[Charles Pritchard]

On 8/5/2011 9:23 AM, Marcos Caceres wrote:

>>  It should be left to the editor's (or working group) discretion as to which 
spec they cite regardless of the reason.

>
>  And one of the role of the W3C staff is to ensure proper coordination
>  between the various Working Groups at the W3C. I'm pointing out we are
>  being inconsistent,

I'm still not sure what the problem is. It seems like the problem is
that some people feel the citing a WHATWG spec is "disrespectful" of
the HTML WG. I think we should get on with making the best possible
technology for our fellow humans and not get so caught up with who is


There have been chair decisions which the WHATWG does not follow, many
of them having to do with accessibility requirements. By continuing to link
to the WHATWG spec as a primary source, during such fractures in consensus,
it undermines the decision processes of the w3c.

Linking to in the mailing list can be helpful, but making it a primary 
source
in w3c standards documents has some difficulties. We all do our best to 
regain

consensus, to come to an agreeable solution. Using the W3C specs to link-out
of the process isn't the right way to approach things.

Re: Reference to the HTML specification

[Arun Ranganathan]

On 8/5/11 11:52 AM, Philippe Le Hegaret wrote:

On Fri, 2011-08-05 at 17:18 +0200, Marcos Caceres wrote:

Again, what are the reasons to link to the WHATWG HTML version?

If there is something you need that is not in the W3C spec, then it seems like 
a valid reason (e.g., PeerConnection API or some helpful concept).

Agreed, but no one has come up with such need so far.


I refer to the HTML WG's work as normative, but in the File API's 
Editor's Draft [0], I'd also like to link to the WHATWG document as an 
informative reference for the Stream API [1]  and LocalMediaStream [2].  
This is a pragmatic, and not a political, cross-referencing.


Stream API reuses blob: URIs; LocalMediaStream defines globally unique 
identifiers in a way that I find useful for the opaqueString 
production.  I'm tidying up normative and informative links, and in 
general, I think the time is ripe for a good discussion of affiliated 
specifications.  Another area for coordination that I'd encourage is 
between W3C and Khronos, if it isn't happening already.  For instance, 
File API makes use of ArrayBuffer [3] *normatively* which is defined at 
Khronos [3] and which is implemented in some user agents.  Is there a 
formal liaison?  This will benefit WebGL as well.


Some of these affiliated technologies are not under strictly under the 
aegis of W3C, and I think that is perfectly fine.



What
does it mean for the work of the HTML Working Group?

Egos aside, it should not mean anything… one has green headings, the other has 
blue ones.

In the ideal world, it should not, but the fact that we're having this
exact discussion indicates there is meaning behind. For example, Ian
pointed out earlier that "The W3C one has a growing list of intentional
errors.".



I'd like an ideal world as well, but I am optimistic that 
implementations will clarify discrepancies.  The ability to refer across 
specifications keeps them current with implementations.


-- A*

[0] http://dev.w3.org/2006/webapi/FileAPI/
[1] 
http://www.whatwg.org/specs/web-apps/current-work/multipage/video-conferencing-and-peer-to-peer-communication.html#stream-api

[2] http://www.whatwg.org/specs/web-apps/current-work/#localmediastream
[3] http://www.khronos.org/registry/typedarray/specs/latest/

Re: Reference to the HTML specification

[Marcos Caceres]

On Fri, Aug 5, 2011 at 5:52 PM, Philippe Le Hegaret  wrote:
> On Fri, 2011-08-05 at 17:18 +0200, Marcos Caceres wrote:
>> > Again, what are the reasons to link to the WHATWG HTML version?
>>
>> If there is something you need that is not in the W3C spec, then it seems 
>> like a valid reason (e.g., PeerConnection API or some helpful concept).
>
> Agreed, but no one has come up with such need so far.
>
>> > What
>> > does it mean for the work of the HTML Working Group?
>>
>> Egos aside, it should not mean anything… one has green headings, the other 
>> has blue ones.
>
> In the ideal world, it should not, but the fact that we're having this
> exact discussion indicates there is meaning behind. For example, Ian
> pointed out earlier that "The W3C one has a growing list of intentional
> errors.".

This is unfortunate, but I have experienced the same thing with
Widgets (stuff I knew was wrong but some WG members wanted, even
though it was pointed out to them it would not get implemented or made
no sense). That's what's valuable about the WHATWG spec: it more
closely resembles reality at times... other times, it might not - but
I think the WHATWG (and Ian) is trying to do the right thing here.
It's important to capture and reject such "intentional errors", so I
support what the WHATWG is doing in this case.

>> > There are features
>> > in the WHATWG version that got rejected in the HTML Working Group. See
>> >
>> > http://www.whatwg.org/specs/web-apps/current-work/multipage/introduction.html#how-do-the-whatwg-and-w3c-specifications-differ?
>> >
>> > This list keeps growing.
>> >
>> > I don't think it's appropriate for one Working Group to ditch the work
>> > of an other.
>>
>> Both the W3C and WHATWG have an equal and legitimate authoritative claim 
>> over the content of the HTML specification (with real authoritative 
>> legitimacy being determined by which version actually gets implemented and 
>> by who).
>>
>> It should be left to the editor's (or working group) discretion as to which 
>> spec they cite regardless of the reason.
>
> And one of the role of the W3C staff is to ensure proper coordination
> between the various Working Groups at the W3C. I'm pointing out we are
> being inconsistent,

I'm still not sure what the problem is. It seems like the problem is
that some people feel the citing a WHATWG spec is "disrespectful" of
the HTML WG. I think we should get on with making the best possible
technology for our fellow humans and not get so caught up with who is
citing who. At the end of the day, what matters is the Web and more
importantly the people that use it though I'm sure the history of
the HTML5 spec is going to make for a great book or movie!

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

Re: Reference to the HTML specification

[Philippe Le Hegaret]

On Fri, 2011-08-05 at 17:18 +0200, Marcos Caceres wrote:
> > Again, what are the reasons to link to the WHATWG HTML version?
> 
> If there is something you need that is not in the W3C spec, then it seems 
> like a valid reason (e.g., PeerConnection API or some helpful concept).  

Agreed, but no one has come up with such need so far.

> > What
> > does it mean for the work of the HTML Working Group?
> 
> Egos aside, it should not mean anything… one has green headings, the other 
> has blue ones.

In the ideal world, it should not, but the fact that we're having this
exact discussion indicates there is meaning behind. For example, Ian
pointed out earlier that "The W3C one has a growing list of intentional
errors.".

> > There are features
> > in the WHATWG version that got rejected in the HTML Working Group. See
> > 
> > http://www.whatwg.org/specs/web-apps/current-work/multipage/introduction.html#how-do-the-whatwg-and-w3c-specifications-differ?
> > 
> > This list keeps growing.
> > 
> > I don't think it's appropriate for one Working Group to ditch the work
> > of an other.
> 
> Both the W3C and WHATWG have an equal and legitimate authoritative claim over 
> the content of the HTML specification (with real authoritative legitimacy 
> being determined by which version actually gets implemented and by who).  
>
> It should be left to the editor's (or working group) discretion as to which 
> spec they cite regardless of the reason.  

And one of the role of the W3C staff is to ensure proper coordination
between the various Working Groups at the W3C. I'm pointing out we are
being inconsistent,

Philippe

[Bug 13686] New: Either remove the special case from onmessage (to call start()) or add it also to addEventListener listeners

[bugzilla]

http://www.w3.org/Bugs/Public/show_bug.cgi?id=13686

   Summary: Either remove the special case from onmessage (to call
start()) or add it also to addEventListener listeners
   Product: WebAppsWG
   Version: unspecified
  Platform: Other
   URL: http://www.whatwg.org/specs/web-apps/current-work/#han
dler-messageport-onmessage
OS/Version: other
Status: NEW
  Severity: normal
  Priority: P3
 Component: Web Messaging (editor: Ian Hickson)
AssignedTo: i...@hixie.ch
ReportedBy: contribu...@whatwg.org
 QAContact: member-webapi-...@w3.org
CC: m...@w3.org, public-webapps@w3.org


Specification:
http://www.whatwg.org/specs/web-apps/current-work/multipage/comms.html
Multipage: http://www.whatwg.org/C#handler-messageport-onmessage
Complete: http://www.whatwg.org/c#handler-messageport-onmessage

Comment:
Either remove the special case from onmessage (to call start()) or add it also
to addEventListener listeners

Posted from: 91.154.41.96
User agent: Mozilla/5.0 (X11; Linux x86_64; rv:8.0a1) Gecko/20110804
Firefox/8.0a1

-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

[Bug 13180] [Editorial] Causes that lead to failing the WebSocket connection, which results in an error event, should be more clearly specified

[bugzilla]

http://www.w3.org/Bugs/Public/show_bug.cgi?id=13180

Ian 'Hixie' Hickson  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||i...@hixie.ch
 Resolution||WONTFIX

--- Comment #2 from Ian 'Hixie' Hickson  2011-08-05 15:44:33 UTC 
---
Assuming you mean the references to "fail the WebSocket connection", all those
references are of things that happen on the protocol side, I believe. I don't
really know how we could do anything in the API spec here. I recommend bringing
this up with the hybi group.

-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

[Bug 13264] please more pics to visually understand. too much reading.

[bugzilla]

http://www.w3.org/Bugs/Public/show_bug.cgi?id=13264

Ian 'Hixie' Hickson  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||NEEDSINFO

--- Comment #1 from Ian 'Hixie' Hickson  2011-08-05 15:42:33 UTC 
---
Anyone got any ideas of what could be put in pictures for this spec?

-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

[Bug 13675] MessageEvent::ports should be a nullable platform array object for interop

[bugzilla]

http://www.w3.org/Bugs/Public/show_bug.cgi?id=13675

Ian 'Hixie' Hickson  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||i...@hixie.ch
 Resolution||WONTFIX

--- Comment #1 from Ian 'Hixie' Hickson  2011-08-05 15:24:16 UTC 
---
It would be much better to return an empty array. Returning null or an array is
a great way to have programming errors.

-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

Re: Reference to the HTML specification

[Ian Hickson]

On Fri, 5 Aug 2011, Philippe Le Hegaret wrote:
> On Fri, 2011-08-05 at 14:32 +, Ian Hickson wrote:
> > On Fri, 5 Aug 2011, Philippe Le Hegaret wrote:
> > >
> > > Again, what are the reasons to link to the WHATWG HTML version? What 
> > > does it mean for the work of the HTML Working Group? There are features 
> > > in the WHATWG version that got rejected in the HTML Working Group. See
> > > 
> > > http://www.whatwg.org/specs/web-apps/current-work/multipage/introduction.html#how-do-the-whatwg-and-w3c-specifications-differ?
> > > 
> > > This list keeps growing.
> > 
> > This is exactly _why_ we should reference the WHATWG copy rather than 
> > the W3C one. The W3C one has a growing list of intentional errors.
> 
> They're not errors, they're decision by the Working Group.

They're errors. Some of the text in the HTML WG specs is actually 
self-contradictory, other parts of it are gramatically incorrect, there 
are decisions that contradict 10-15 years of accessibility advocacy, and 
there's text that misuses terms as defined in the spec itself.

In an earlier e-mail you wrote:

> This undermines and is disrespectful the work of the HTML Working Group.

Respect is earned.

-- 
Ian Hickson   U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Re: Reference to the HTML specification

[Marcos Caceres]

On 5 Aug 2011, at 14:50, Philippe Le Hegaret wrote:

> On Fri, 2011-08-05 at 08:22 -0400, Arthur Barstow wrote:
>> On 8/4/11 11:47 AM, ext Philippe Le Hegaret wrote:
>>> Several documents in the WebApps Working Group are linking to HTML, more
>>> specifically to the WHATWG HTML specification. An example of those is
>>> Progress Events. This is done for no reason than political as far as I
>>> can tell. This undermines and is disrespectful the work of the HTML
>>> Working Group. Unless the WebApps comes up with a set of good reasons of
>>> why this is done and convince the HTML Working Group, those references
>>> must be changed in order to publish the documents properly and respect
>>> the work of the HTML Working Group,
>> 
>> Philippe,
>> 
>> Re the specific case of the Progress Events spec - when it was last 
>> published it included non-normative references to both version of HTML:
>> 
>>   http://www.w3.org/TR/progress-events/#references
>> 
>> May we do that again? (I interpret that to mean the W3C has a fixed 
>> version of HTML and the WHATWG has a tip-of-the-tree version of HTML and 
>> as such, I don't think it  'disses the HTMLWG nor the W3C.)
> 
> Again, what are the reasons to link to the WHATWG HTML version?

If there is something you need that is not in the W3C spec, then it seems like 
a valid reason (e.g., PeerConnection API or some helpful concept).  

> What
> does it mean for the work of the HTML Working Group?

Egos aside, it should not mean anything… one has green headings, the other has 
blue ones. There are just two equally valid authoritative sources for the 
document. If both organisations can guarantee that the specification will be 
there tomorrow, then I don't see any issue. As an Editor, I just want my 
hyperlinks to work so people can implement my spec and get to the normative 
dependencies (personally, I chose the W3C version because it had everything I 
needed). If either the WHATWG or W3C vanish tomorrow, it's good that we have a 
fallback for this important work. 

> There are features
> in the WHATWG version that got rejected in the HTML Working Group. See
> 
> http://www.whatwg.org/specs/web-apps/current-work/multipage/introduction.html#how-do-the-whatwg-and-w3c-specifications-differ?
> 
> This list keeps growing.
> 
> I don't think it's appropriate for one Working Group to ditch the work
> of an other.

Both the W3C and WHATWG have an equal and legitimate authoritative claim over 
the content of the HTML specification (with real authoritative legitimacy being 
determined by which version actually gets implemented and by who).  

It should be left to the editor's (or working group) discretion as to which 
spec they cite regardless of the reason.  

Kind regards,
Marcos 

Re: Reference to the HTML specification

[Glenn Adams]

On Fri, Aug 5, 2011 at 7:36 AM, Arthur Barstow wrote:

> On 8/5/11 8:50 AM, ext Philippe Le Hegaret wrote:
>
>> On Fri, 2011-08-05 at 08:22 -0400, Arthur Barstow wrote:
>>
>>> On 8/4/11 11:47 AM, ext Philippe Le Hegaret wrote:
>>>
 Several documents in the WebApps Working Group are linking to HTML, more
 specifically to the WHATWG HTML specification. An example of those is
 Progress Events. This is done for no reason than political as far as I
 can tell. This undermines and is disrespectful the work of the HTML
 Working Group. Unless the WebApps comes up with a set of good reasons of
 why this is done and convince the HTML Working Group, those references
 must be changed in order to publish the documents properly and respect
 the work of the HTML Working Group,

>>> Philippe,
>>>
>>> Re the specific case of the Progress Events spec - when it was last
>>> published it included non-normative references to both version of HTML:
>>>
>>>
>>> http://www.w3.org/TR/progress-**events/#references
>>>
>>> May we do that again? (I interpret that to mean the W3C has a fixed
>>> version of HTML and the WHATWG has a tip-of-the-tree version of HTML and
>>> as such, I don't think it  'disses the HTMLWG nor the W3C.)
>>>
>> Again, what are the reasons to link to the WHATWG HTML version? What
>> does it mean for the work of the HTML Working Group? There are features
>> in the WHATWG version that got rejected in the HTML Working Group.
>>
>
> I agree with the requirement for a single normative reference for HTML and
> that it should be the HTMLWG's version.
>

I agree. The W3C HTMLWG is the only reference that is viable as far as the
larger standards community is concerned, and as far as Samsung is concerned.
Perhaps it is acceptable to reference WHATWG versions as an expedient in the
near term, however, that should be avoided unless there is no alternative.

Glenn (speaking as Samsung rep. to WebApps WG)

[Bug 13063] MessagePort normatively referenced by not defined

[bugzilla]

http://www.w3.org/Bugs/Public/show_bug.cgi?id=13063

Ian 'Hixie' Hickson  changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution||FIXED

-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

[Bug 13064] WindowBase64 normatively referenced by not defined

[bugzilla]

http://www.w3.org/Bugs/Public/show_bug.cgi?id=13064

Ian 'Hixie' Hickson  changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution||FIXED

--- Comment #4 from Ian 'Hixie' Hickson  2011-08-05 14:44:09 UTC 
---
thanks. fixed.

-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

[Bug 13065] WindowTimers normatively referenced by not defined

[bugzilla]

http://www.w3.org/Bugs/Public/show_bug.cgi?id=13065

Ian 'Hixie' Hickson  changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution||FIXED

--- Comment #3 from Ian 'Hixie' Hickson  2011-08-05 14:43:43 UTC 
---
ah, i see. fixed.

-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

Re: Reference to the HTML specification

[Philippe Le Hegaret]

On Fri, 2011-08-05 at 14:32 +, Ian Hickson wrote:
> On Fri, 5 Aug 2011, Philippe Le Hegaret wrote:
> >
> > Again, what are the reasons to link to the WHATWG HTML version? What 
> > does it mean for the work of the HTML Working Group? There are features 
> > in the WHATWG version that got rejected in the HTML Working Group. See
> > 
> > http://www.whatwg.org/specs/web-apps/current-work/multipage/introduction.html#how-do-the-whatwg-and-w3c-specifications-differ?
> > 
> > This list keeps growing.
> 
> This is exactly _why_ we should reference the WHATWG copy rather than the 
> W3C one. The W3C one has a growing list of intentional errors.

They're not errors, they're decision by the Working Group. The fact that
the editor of the W3C HTML5 specification considers the differences as
errors is highly disturbing as well.

Philippe

Re: Reference to the HTML specification

[Ian Hickson]

On Fri, 5 Aug 2011, Philippe Le Hegaret wrote:
>
> Again, what are the reasons to link to the WHATWG HTML version? What 
> does it mean for the work of the HTML Working Group? There are features 
> in the WHATWG version that got rejected in the HTML Working Group. See
> 
> http://www.whatwg.org/specs/web-apps/current-work/multipage/introduction.html#how-do-the-whatwg-and-w3c-specifications-differ?
> 
> This list keeps growing.

This is exactly _why_ we should reference the WHATWG copy rather than the 
W3C one. The W3C one has a growing list of intentional errors.


On Fri, 5 Aug 2011, Philippe Le Hegaret wrote:
>
> I don't see that in any of the HTML last call documents,  like
>http://www.w3.org/TR/2dcontext/#references

The only reason that refers to the W3C copy of HTML and not the WHATWG 
copy is that the WHATWG copy includes canvas in its entirety already, so 
the reference would just be confusing. The only reason there's a reference 
there in the first place is because the W3C copy is randomly split into 
two unlike the WHATWG version.

-- 
Ian Hickson   U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Re: Reference to the HTML specification

[Philippe Le Hegaret]

On Fri, 2011-08-05 at 15:51 +0200, Anne van Kesteren wrote:
> On Fri, 05 Aug 2011 14:50:35 +0200, Philippe Le Hegaret  wrote:
> > What does it mean for the work of the HTML Working Group?
> 
> It means we are consistent with their work:
> 
>http://www.w3.org/TR/2011/WD-html5-diff-20110525/#references

I don't see that in any of the HTML last call documents,  like
   http://www.w3.org/TR/2dcontext/#references
or 

So, I would say that the HTML5 diff is also inconsistent,

Philippe

Re: Reference to the HTML specification

[Anne van Kesteren]

On Fri, 05 Aug 2011 14:50:35 +0200, Philippe Le Hegaret  wrote:

What does it mean for the work of the HTML Working Group?


It means we are consistent with their work:

  http://www.w3.org/TR/2011/WD-html5-diff-20110525/#references


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

Re: Reference to the HTML specification

[Arthur Barstow]

On 8/5/11 8:50 AM, ext Philippe Le Hegaret wrote:

On Fri, 2011-08-05 at 08:22 -0400, Arthur Barstow wrote:

On 8/4/11 11:47 AM, ext Philippe Le Hegaret wrote:

Several documents in the WebApps Working Group are linking to HTML, more
specifically to the WHATWG HTML specification. An example of those is
Progress Events. This is done for no reason than political as far as I
can tell. This undermines and is disrespectful the work of the HTML
Working Group. Unless the WebApps comes up with a set of good reasons of
why this is done and convince the HTML Working Group, those references
must be changed in order to publish the documents properly and respect
the work of the HTML Working Group,

Philippe,

Re the specific case of the Progress Events spec - when it was last
published it included non-normative references to both version of HTML:

http://www.w3.org/TR/progress-events/#references

May we do that again? (I interpret that to mean the W3C has a fixed
version of HTML and the WHATWG has a tip-of-the-tree version of HTML and
as such, I don't think it  'disses the HTMLWG nor the W3C.)

Again, what are the reasons to link to the WHATWG HTML version? What
does it mean for the work of the HTML Working Group? There are features
in the WHATWG version that got rejected in the HTML Working Group.


I agree with the requirement for a single normative reference for HTML 
and that it should be the HTMLWG's version.


However, I don't see any particular harm with including *non-normative* 
references to both given the reality is there are two versions of HTML 
serving two different organizations.


It seems somewhat myopic for the "HTMLWG" to pretend there is no other  
version of HTML (at least within the context of the informational 
reference in the PE spec) so I respectfully disagree including both 
references is "ditching" the W3C's version.


-AB


See

http://www.whatwg.org/specs/web-apps/current-work/multipage/introduction.html#how-do-the-whatwg-and-w3c-specifications-differ?

This list keeps growing.

I don't think it's appropriate for one Working Group to ditch the work
of an other.

Philippe

Re: Reference to the HTML specification

[Philippe Le Hegaret]

On Fri, 2011-08-05 at 08:22 -0400, Arthur Barstow wrote:
> On 8/4/11 11:47 AM, ext Philippe Le Hegaret wrote:
> > Several documents in the WebApps Working Group are linking to HTML, more
> > specifically to the WHATWG HTML specification. An example of those is
> > Progress Events. This is done for no reason than political as far as I
> > can tell. This undermines and is disrespectful the work of the HTML
> > Working Group. Unless the WebApps comes up with a set of good reasons of
> > why this is done and convince the HTML Working Group, those references
> > must be changed in order to publish the documents properly and respect
> > the work of the HTML Working Group,
> 
> Philippe,
> 
> Re the specific case of the Progress Events spec - when it was last 
> published it included non-normative references to both version of HTML:
> 
>http://www.w3.org/TR/progress-events/#references
> 
> May we do that again? (I interpret that to mean the W3C has a fixed 
> version of HTML and the WHATWG has a tip-of-the-tree version of HTML and 
> as such, I don't think it  'disses the HTMLWG nor the W3C.)

Again, what are the reasons to link to the WHATWG HTML version? What
does it mean for the work of the HTML Working Group? There are features
in the WHATWG version that got rejected in the HTML Working Group. See

http://www.whatwg.org/specs/web-apps/current-work/multipage/introduction.html#how-do-the-whatwg-and-w3c-specifications-differ?

This list keeps growing.

I don't think it's appropriate for one Working Group to ditch the work
of an other.

Philippe

Re: Reference to the HTML specification

[Arthur Barstow]

On 8/4/11 11:47 AM, ext Philippe Le Hegaret wrote:

Several documents in the WebApps Working Group are linking to HTML, more
specifically to the WHATWG HTML specification. An example of those is
Progress Events. This is done for no reason than political as far as I
can tell. This undermines and is disrespectful the work of the HTML
Working Group. Unless the WebApps comes up with a set of good reasons of
why this is done and convince the HTML Working Group, those references
must be changed in order to publish the documents properly and respect
the work of the HTML Working Group,


Philippe,

Re the specific case of the Progress Events spec - when it was last 
published it included non-normative references to both version of HTML:


  http://www.w3.org/TR/progress-events/#references

May we do that again? (I interpret that to mean the W3C has a fixed 
version of HTML and the WHATWG has a tip-of-the-tree version of HTML and 
as such, I don't think it  'disses the HTMLWG nor the W3C.)


-AB

Re: publish new WD of DOM Core; deadline August 10

[Anne van Kesteren]

On Fri, 05 Aug 2011 00:17:30 +0200, David Flanagan   
wrote:

On 8/4/11 12:21 PM, Anne van Kesteren wrote:

Alright, how about "DOM4"?


I suspect it is the inclusion of the word "core" that causes the  
confusion, not the lack of a version number.  If you google "dom core"  
you get lots of hits for various old Level 2 and Level 3 specs.  Given  
how much this spec removes from level 2 and level 3, it seem strange to  
give it a version number in the same series...


How about "WebDOM" instead?


I am not really a fan of the "Web" prefix anymore. It is pretty clear  
these are specifications for the web platform. No need to say so in the  
title. We prefixed it initially because we thought there would be a group  
of people against a somewhat drastic revision of the DOM. This turned out  
much better than expected so we could drop the prefix. I think we are now  
at the point where we could drop the suffix.


The reason for giving it a version number is that the W3C works with  
snapshots at the moment.



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

Possible errata for http://www.w3.org/TR/IndexedDB/

[陈天舟]

Hi there,
 I have read the spec and I spot one minor issue in the spec:

- 3.1.8 Requests. 2nd paragraph.

Finally, requests have a request transaction. When a request is created, it
is always placed against atransaction using either the steps to a
asynchronously execute a request or the steps to a synchronously execute a
request. This sets the request transaction to be that request.

Should be

Finally, requests have a request transaction. When a request is created, it
is always placed against atransaction using either the steps to a
asynchronously execute a request or the steps to a synchronously execute a
request. This sets the request transaction to be that transaction.

Thanks
Tianzhou