[Bug 14684] New: fghfghf fgh fgh fgh fdghdffh fgh

[bugzilla]

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

   Summary: fghfghf fgh fgh fgh fdghdffh fgh
   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: WebSocket API (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://dev.w3.org/html5/websockets/
Multipage: http://www.whatwg.org/C#top
Complete: http://www.whatwg.org/c#top

Comment:
fghfghf fgh fgh fgh fdghdffh fgh

Posted from: 213.25.114.38
User agent: Mozilla/5.0 (X11; Linux i686; rv:7.0.1) Gecko/20100101
Firefox/7.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 14684] fghfghf fgh fgh fgh fdghdffh fgh

[bugzilla]

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

Simon Pieters  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||INVALID

-- 
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: CfC: publish a Candidate Recommendation of WebSockets API; deadline Nov 9

[Jonas Sicking]

Yay! Thumbs up from me!

/ Jonas

On Wed, Nov 2, 2011 at 9:22 PM, Arthur Barstow  wrote:
> During the October 31 meeting [1], there was agreement to publish a
> Candidate Recommendation of the WebSockets API and this is a Call for
> Consensus to do so:
>
>  http://dev.w3.org/html5/websockets/
>
> The remaining open editorial bug [13700] will be fixed before publication.
>
> I propose the CR exit criteria is the same as our last CR (Progress Events):
>
> [[
> To exit the Candidate Recommendation (CR) stage the following criteria must
> have been met:
>
> 1. There will be at least two interoperable implementations passing all test
> cases in the test suite for this specification. An implementation is to be
> available (i.e. for download), shipping (i.e. not private), and not
> experimental (i.e. intended for a wide audience). The working group will
> decide when the test suite is of sufficient quality to test interoperability
> and will produce an implementation report (hosted together with the test
> suite).
>
> 2. A minimum of three months of the CR stage will have elapsed (i.e. not
> until after DD MMM 2012). This is to ensure that enough time is given for
> any remaining major errors to be caught. The CR period will be extended if
> implementations are slow to appear.
> ]]
>
> This CfC satisfies: a) the group's requirement to "record the group's
> decision to request advancement" to CR; and b) "General Requirements for
> Advancement on the Recommendation Track" as defined in the Process Document:
>
>  http://www.w3.org/2005/10/Process-20051014/tr.html#transition-reqs
>
> As with all of our CfCs, positive response is preferred and encouraged and
> silence will be considered as agreeing with the proposal. The deadline for
> comments is November 9 and all comments should be sent to public-webapps at
> w3.org.
>
> -AB
>
> [1] http://www.w3.org/2011/10/31-webapps-minutes.html#item14
> [13700] http://www.w3.org/Bugs/Public/show_bug.cgi?id=13700
>
>
>

Re: Copy/cut and event.preventDefault()

[Hallvord R. M. Steen]

On Thu, 03 Nov 2011 00:13:04 +0100, Daniel Cheng  wrote:


What's the expected behavior if a script calls event.preventDefault()
when processing a copy/cut event but does not modify the data store?
Should the system clipboard be cleared or should the contents remain
unchanged?


IMO the content should remain unchanged.

If anyone disagrees with that (or want to suggest clarifications for the  
processing model to make this more obvious) I'm all ears :-)


--
Hallvord R. M. Steen, Core Tester, Opera Software
http://www.opera.com http://my.opera.com/hallvors/

Re: Copy/cut and event.preventDefault()

[Ryosuke Niwa]

On Nov 3, 2011 2:34 AM, "Hallvord R. M. Steen"  wrote:
>
> On Thu, 03 Nov 2011 00:13:04 +0100, Daniel Cheng 
wrote:
>
>> What's the expected behavior if a script calls event.preventDefault()
>> when processing a copy/cut event but does not modify the data store?
>> Should the system clipboard be cleared or should the contents remain
>> unchanged?
>
>
> IMO the content should remain unchanged.
>
> If anyone disagrees with that (or want to suggest clarifications for the
processing model to make this more obvious) I'm all ears :-)

I support this behavior.

- Ryosuke

Re: CfC: publish a Candidate Recommendation of WebSockets API; deadline Nov 9

[Julian Reschke]

On 2011-11-03 05:22, Arthur Barstow wrote:

During the October 31 meeting [1], there was agreement to publish a
Candidate Recommendation of the WebSockets API and this is a Call for
Consensus to do so:

http://dev.w3.org/html5/websockets/
...


That specification has a new section "Parsing Websocket URLs" which is 
broken in that it references algorithms in other specs without saying so 
(see Anne's explanation from yesterday).


As such, I can't see how you can progress it.

Please fix this problem, and then give people sufficient time to review 
what that section actually says.


Best regards, Julian

Re: Spec changes for LCs and later maturity levels

[Julian Reschke]

On 2011-11-02 20:02, Anne van Kesteren wrote:

On Wed, 02 Nov 2011 11:59:14 -0700, Julian Reschke
 wrote:

On 2011-11-02 19:46, Anne van Kesteren wrote:

If you are confused about the terms, they are defined in HTML.


But they aren't linked, as far as I can tell. It would be good if they
were, and then we can review that text again.


They are in

http://www.whatwg.org/specs/web-apps/current-work/multipage/network.html#parsing-websocket-urls


so you can use that for review.
...


OK, I have tried to understand what's going on here, but I largely failed.

0) The algorithm "Resolve the url string" doesn't exist in the spec, nor 
does it reference anything. If nobody has complained about this yet then 
my conclusion is that nobody has read that section. Not surprisingly, as 
it was added past last-call.


1) Anne explains that it's supposed to reference 
, 
so that change should be made.


2) Assuming that change *will* be made...: the difference to what the 
protocol spec says seems to be...


2a) it deals with IRIs (converting them to URIs),

2b) it specifies certain fixup operations for broken input, such as 
converting \ to /, which, last time I checked, were controversial even 
among browser implementers.


Reminder: this was a past-LC change. I think I'm not asking too much 
when I'm asking for a precise explanation of what the rational for this 
change was.


Best regards, Julian

Re: CfC: publish a Candidate Recommendation of WebSockets API; deadline Nov 9

[Anne van Kesteren]

On Thu, 03 Nov 2011 07:50:08 -0700, Julian Reschke   
wrote:

On 2011-11-03 05:22, Arthur Barstow wrote:

During the October 31 meeting [1], there was agreement to publish a
Candidate Recommendation of the WebSockets API and this is a Call for
Consensus to do so:

http://dev.w3.org/html5/websockets/
...


That specification has a new section "Parsing Websocket URLs" which is  
broken in that it references algorithms in other specs without saying so  
(see Anne's explanation from yesterday).


It does say so, right in the dependency section.



As such, I can't see how you can progress it.

Please fix this problem, and then give people sufficient time to review  
what that section actually says.



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

Re: Spec changes for LCs and later maturity levels

[Anne van Kesteren]

On Thu, 03 Nov 2011 08:07:20 -0700, Julian Reschke   
wrote:
Reminder: this was a past-LC change. I think I'm not asking too much  
when I'm asking for a precise explanation of what the rational for this  
change was.


As I explained already, we moved processing requirements from the protocol  
to the API.



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

Re: CfC: publish a Candidate Recommendation of WebSockets API; deadline Nov 9

[Julian Reschke]

On 2011-11-03 16:29, Anne van Kesteren wrote:

On Thu, 03 Nov 2011 07:50:08 -0700, Julian Reschke
 wrote:

On 2011-11-03 05:22, Arthur Barstow wrote:

During the October 31 meeting [1], there was agreement to publish a
Candidate Recommendation of the WebSockets API and this is a Call for
Consensus to do so:

http://dev.w3.org/html5/websockets/
...


That specification has a new section "Parsing Websocket URLs" which is
broken in that it references algorithms in other specs without saying
so (see Anne's explanation from yesterday).


It does say so, right in the dependency section.
...


That section says:

"2.1 Dependencies

This specification relies on several other underlying specifications.

HTML

Many fundamental concepts from HTML are used by this specification. 
[HTML]

WebIDL

The IDL blocks in this specification use the semantics of the 
WebIDL specification. [WEBIDL]"


How is a reader supposed to know that "resolve a URL", printed in bold, 
refers to a very specific algorithm in the HTML spec?


Best regards, Julian

[Bug 14364] appcache: Add an API to make appcache support caching specific URLs dynamically

[bugzilla]

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

Ian 'Hixie' Hickson  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||LATER

--- Comment #7 from Ian 'Hixie' Hickson  2011-11-03 16:03:26 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: Partially Accepted
Change Description: none yet
Rationale: The use case described in comment 6 seems reasonable. I have marked
this LATER so that we can look add this once browsers have caught up with what
we've specified so far.

-- 
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: CfC: publish a Candidate Recommendation of WebSockets API; deadline Nov 9

[Anne van Kesteren]

On Thu, 03 Nov 2011 08:40:56 -0700, Julian Reschke   
wrote:

That section says:

"2.1 Dependencies

This specification relies on several other underlying specifications.

HTML

 Many fundamental concepts from HTML are used by this specification.  
[HTML]

WebIDL

 The IDL blocks in this specification use the semantics of the  
WebIDL specification. [WEBIDL]"


How is a reader supposed to know that "resolve a URL", printed in bold,  
refers to a very specific algorithm in the HTML spec?


It is indeed not ideal, and as I mentioned earlier we are looking for  
someone to make it better, but it is not too hard to find out either. You  
open the two dependencies, do a full text search, and you are done.



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

Re: "We just ran out of time ..." [Was: Re: Component Model f2f: Actionable things]

[Dimitri Glazkov]

Meeting more frequently is something that appeals to me greatly. Email
discussions (or worse IRC banter) are not as productive.

:DG<

On Wed, Nov 2, 2011 at 9:38 PM, Arthur Barstow  wrote:
> On 11/2/11 6:41 PM, ext Dimitri Glazkov wrote:
>>
>> You can see the minutes here:
>> http://www.w3.org/2011/11/02-webapps-minutes.html
>
> Thanks Dimitri.
>
>> First of all, thank you all for coming and participating.
>
> That goes for me and Chaals too re Monday and Tuesday!
>
>> It was exhausting, and we just ran out of time. Stupid time!
>
> Well, we may get together more frequently than just the annual TPAC meeting
> week. If folks think that would be useful (e.g. in 6 months), please speak
> up and we can take it from there. Otherwise, WebApps' next f2f meeting is
> during the 2012 TPAC meeting in Lyon, FR Oct 29 - Nov 2.
>
> -AB
>
>
>

innerHTML in DocumentFragment

[Yehuda Katz]

It would be useful if there was a way to take a String of HTML and parse it
into a document fragment. This should work even if the HTML string contains
elements that are invalid in the "in body" insertion mode.

Something like this code should work:

  var frag = document.createDocumentFragment();
  frag.innerHTML = "hello"
  someTable.appendChild(frag)

At present, this can sometimes be achieved if the context of the HTML
string is known in advance. However, this is not always the case. For
instance, jQuery supplies an API that looks like this:

  $("html string").appendTo("#table")

At the time that jQuery is creating the document fragment for the HTML
string, it does not yet know what its context will be. This approach is
used in order to enable convenient setup code. Here is a very contrived
example to illustrate the point:

  var frag = $("html string")

  // replace the HTML content of a descendent  with the contents of
its data-title attribute
  frag.find("span[data-title]").html(function() { return
this.attr("data-title"); })

  html.appendTo("#table")

In general, this makes it easier to build abstractions that work with
Strings of HTML, without always needing to make sure consumers of the
abstraction know and pass in the existing context.

This would probably require a new, laxer insertion mode, which would behave
similarly to the body insertion mode, but with different semantics in the "*A
start tag whose tag name is one of: "caption", "col", "colgroup", "frame",
"head", "tbody", "td", "tfoot", "th", "thead", "tr""* case. One way to
handle those cases would be to immediately enter an appropriate insertion
mode if an unexpected tag was found. For instance, if a start tr tag was
encountered "at the root", the parser could go into "in table" or "in table
body" insertion mode instead of treating it like a parse error and ignoring
the token.

-- Yehuda


-- 
Yehuda Katz
(ph) 718.877.1325

Re: innerHTML in DocumentFragment

[Tim Down]

Have you looked at the createContextualFragment() method of Range?

http://html5.org/specs/dom-parsing.html#dom-range-createcontextualfragment

Tim

On 3 November 2011 23:03, Yehuda Katz  wrote:
> It would be useful if there was a way to take a String of HTML and parse it
> into a document fragment. This should work even if the HTML string contains
> elements that are invalid in the "in body" insertion mode.
> Something like this code should work:
>   var frag = document.createDocumentFragment();
>   frag.innerHTML = "hello"
>   someTable.appendChild(frag)
> At present, this can sometimes be achieved if the context of the HTML string
> is known in advance. However, this is not always the case. For instance,
> jQuery supplies an API that looks like this:
>   $("html string").appendTo("#table")
> At the time that jQuery is creating the document fragment for the HTML
> string, it does not yet know what its context will be. This approach is used
> in order to enable convenient setup code. Here is a very contrived example
> to illustrate the point:
>   var frag = $("html string")
>   // replace the HTML content of a descendent  with the contents of
> its data-title attribute
>   frag.find("span[data-title]").html(function() { return
> this.attr("data-title"); })
>   html.appendTo("#table")
> In general, this makes it easier to build abstractions that work with
> Strings of HTML, without always needing to make sure consumers of the
> abstraction know and pass in the existing context.
> This would probably require a new, laxer insertion mode, which would behave
> similarly to the body insertion mode, but with different semantics in the "A
> start tag whose tag name is one of: "caption", "col", "colgroup", "frame",
> "head", "tbody", "td", "tfoot", "th", "thead", "tr"" case. One way to handle
> those cases would be to immediately enter an appropriate insertion mode if
> an unexpected tag was found. For instance, if a start tr tag was encountered
> "at the root", the parser could go into "in table" or "in table body"
> insertion mode instead of treating it like a parse error and ignoring the
> token.
> -- Yehuda
>
> --
> Yehuda Katz
> (ph) 718.877.1325
>

Re: innerHTML in DocumentFragment

[Anne van Kesteren]

On Thu, 03 Nov 2011 16:44:49 -0700, Tim Down  wrote:

Have you looked at the createContextualFragment() method of Range?

http://html5.org/specs/dom-parsing.html#dom-range-createcontextualfragment


That requires a context. Yehuda wants a way of parsing where you do not  
know the context in advance.



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

Re: innerHTML in DocumentFragment

[James Graham]

On Thu, 3 Nov 2011, Tim Down wrote:


Have you looked at the createContextualFragment() method of Range?

http://html5.org/specs/dom-parsing.html#dom-range-createcontextualfragment


That doesn't meet the use case where you don't know the contextual 
element upfront. As I understand it that is important for some of the use 
cases.


I think this is possible to solve, but needs an extra mode in the parser. 
Also, createcontextualFragment could be modified to take null as the 
context to work in this mode.

Re: innerHTML in DocumentFragment

[Tim Down]

Yes, now I re-read it, that's clear. Sorry.

Tim

On 3 November 2011 23:51, James Graham  wrote:
> On Thu, 3 Nov 2011, Tim Down wrote:
>
>> Have you looked at the createContextualFragment() method of Range?
>>
>> http://html5.org/specs/dom-parsing.html#dom-range-createcontextualfragment
>
> That doesn't meet the use case where you don't know the contextual element
> upfront. As I understand it that is important for some of the use cases.
>
> I think this is possible to solve, but needs an extra mode in the parser.
> Also, createcontextualFragment could be modified to take null as the context
> to work in this mode.
>

Re: innerHTML in DocumentFragment

[Ojan Vafai]

If we can get away with it WRT web compat, we should make
createContextualFragment work context-less and we should make
DocumentFragment.innerHTML work as Yehuda describes. There are clear
use-cases for this that web devs want to do all the time.

I don't see any downside except if the web already depends on the current
behavior of these two cases throwing an error.

On Thu, Nov 3, 2011 at 4:53 PM, Tim Down  wrote:

> Yes, now I re-read it, that's clear. Sorry.
>
> Tim
>
> On 3 November 2011 23:51, James Graham  wrote:
> > On Thu, 3 Nov 2011, Tim Down wrote:
> >
> >> Have you looked at the createContextualFragment() method of Range?
> >>
> >>
> http://html5.org/specs/dom-parsing.html#dom-range-createcontextualfragment
> >
> > That doesn't meet the use case where you don't know the contextual
> element
> > upfront. As I understand it that is important for some of the use cases.
> >
> > I think this is possible to solve, but needs an extra mode in the parser.
> > Also, createcontextualFragment could be modified to take null as the
> context
> > to work in this mode.
> >
>
>

Re: innerHTML in DocumentFragment

[Erik Arvidsson]

http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2011-September/033360.html

I'm in favor of making DocumentFragment.prototype.set innerHTML do the above.

erik

Re: innerHTML in DocumentFragment

[Jonas Sicking]

On Thu, Nov 3, 2011 at 4:03 PM, Yehuda Katz  wrote:
> It would be useful if there was a way to take a String of HTML and parse it
> into a document fragment. This should work even if the HTML string contains
> elements that are invalid in the "in body" insertion mode.
> Something like this code should work:
>   var frag = document.createDocumentFragment();
>   frag.innerHTML = "hello"
>   someTable.appendChild(frag)
> At present, this can sometimes be achieved if the context of the HTML string
> is known in advance. However, this is not always the case. For instance,
> jQuery supplies an API that looks like this:
>   $("html string").appendTo("#table")
> At the time that jQuery is creating the document fragment for the HTML
> string, it does not yet know what its context will be. This approach is used
> in order to enable convenient setup code. Here is a very contrived example
> to illustrate the point:
>   var frag = $("html string")
>   // replace the HTML content of a descendent  with the contents of
> its data-title attribute
>   frag.find("span[data-title]").html(function() { return
> this.attr("data-title"); })
>   html.appendTo("#table")
> In general, this makes it easier to build abstractions that work with
> Strings of HTML, without always needing to make sure consumers of the
> abstraction know and pass in the existing context.
> This would probably require a new, laxer insertion mode, which would behave
> similarly to the body insertion mode, but with different semantics in the "A
> start tag whose tag name is one of: "caption", "col", "colgroup", "frame",
> "head", "tbody", "td", "tfoot", "th", "thead", "tr"" case. One way to handle
> those cases would be to immediately enter an appropriate insertion mode if
> an unexpected tag was found. For instance, if a start tr tag was encountered
> "at the root", the parser could go into "in table" or "in table body"
> insertion mode instead of treating it like a parse error and ignoring the
> token.

This sounds good to me. I actually thought that we already had
something like this.

No matter what, we'll need a definition for how to do context-less
parsing sometime in the future in order to support html quasi-literals
per ES6 [1].

But we also need this short-term in order to support better developer
ergonomics as well as to support existing library APIs.

[1] http://wiki.ecmascript.org/doku.php?id=harmony:quasis

/ Jonas

Re: Spec changes for LCs and later maturity levels

[Peter Saint-Andre]

On 11/3/11 8:28 AM, Anne van Kesteren wrote:
> On Thu, 03 Nov 2011 08:07:20 -0700, Julian Reschke
>  wrote:
>> Reminder: this was a past-LC change. I think I'm not asking too much
>> when I'm asking for a precise explanation of what the rational for
>> this change was.
> 
> As I explained already, we moved processing requirements from the
> protocol to the API.

Round and round we go, where it stops nobody knows. :)

It seems there are two topics here:

1. The procedural issue of moving the text from the protocol spec to the
API document. I have no opinion about this.

2. The substantive issue of whether the text is correct. Julian asked
some questions about that, and I'd be curious to see replies (especially
because they are related to similar topics in HTML5).

Thanks!

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

Re: innerHTML in DocumentFragment

[Sean Hogan]

On 4/11/11 10:03 AM, Yehuda Katz wrote:
It would be useful if there was a way to take a String of HTML and 
parse it into a document fragment. This should work even if the HTML 
string contains elements that are invalid in the "in body" insertion 
mode.


Something like this code should work:

  var frag = document.createDocumentFragment();
  frag.innerHTML = "hello"
  someTable.appendChild(frag)

At present, this can sometimes be achieved if the context of the HTML 
string is known in advance. However, this is not always the case. For 
instance, jQuery supplies an API that looks like this:


  $("html string").appendTo("#table")

At the time that jQuery is creating the document fragment for the HTML 
string, it does not yet know what its context will be. This approach 
is used in order to enable convenient setup code. Here is a very 
contrived example to illustrate the point:


  var frag = $("html string")

  // replace the HTML content of a descendent  with the contents 
of its data-title attribute
  frag.find("span[data-title]").html(function() { return 
this.attr("data-title"); })


  html.appendTo("#table")

In general, this makes it easier to build abstractions that work with 
Strings of HTML, without always needing to make sure consumers of the 
abstraction know and pass in the existing context.


This would probably require a new, laxer insertion mode, which would 
behave similarly to the body insertion mode, but with different 
semantics in the "/A start tag whose tag name is one of: "caption", 
"col", "colgroup", "frame", "head", "tbody", "td", "tfoot", "th", 
"thead", "tr""/ case. One way to handle those cases would be to 
immediately enter an appropriate insertion mode if an unexpected tag 
was found. For instance, if a start tr tag was encountered "at the 
root", the parser could go into "in table" or "in table body" 
insertion mode instead of treating it like a parse error and ignoring 
the token.




It would also be great to have some notification of the parser error - a 
console warning might be most appropriate. This would be a great aid 
when debugging functions that generate html. This feature is probably up 
to the browser vendors though.


Sean

RE: CfC: publish a Candidate Recommendation of WebSockets API; deadline Nov 9

[Brian Raymor]

Microsoft also supports this call.

> On Thu, Nov 3, 2011 at 12:08 AM, Jonas Sicking  wrote:
> 
> Yay! Thumbs up from me!
> 
> / Jonas
> 
> On Wed, Nov 2, 2011 at 9:22 PM, Arthur Barstow 
> wrote:
> > During the October 31 meeting [1], there was agreement to publish a
> > Candidate Recommendation of the WebSockets API and this is a Call for
> > Consensus to do so:
> >
> >  http://dev.w3.org/html5/websockets/
> >
> > The remaining open editorial bug [13700] will be fixed before publication.
> >
> > I propose the CR exit criteria is the same as our last CR (Progress Events):
> >
> > [[
> > To exit the Candidate Recommendation (CR) stage the following criteria
> > must have been met:
> >
> > 1. There will be at least two interoperable implementations passing
> > all test cases in the test suite for this specification. An
> > implementation is to be available (i.e. for download), shipping (i.e.
> > not private), and not experimental (i.e. intended for a wide
> > audience). The working group will decide when the test suite is of
> > sufficient quality to test interoperability and will produce an
> > implementation report (hosted together with the test suite).
> >
> > 2. A minimum of three months of the CR stage will have elapsed (i.e.
> > not until after DD MMM 2012). This is to ensure that enough time is
> > given for any remaining major errors to be caught. The CR period will
> > be extended if implementations are slow to appear.
> > ]]
> >
> > This CfC satisfies: a) the group's requirement to "record the group's
> > decision to request advancement" to CR; and b) "General Requirements
> > for Advancement on the Recommendation Track" as defined in the Process
> Document:
> >
> >  http://www.w3.org/2005/10/Process-20051014/tr.html#transition-reqs
> >
> > As with all of our CfCs, positive response is preferred and encouraged
> > and silence will be considered as agreeing with the proposal. The
> > deadline for comments is November 9 and all comments should be sent to
> > public-webapps at w3.org.
> >
> > -AB
> >
> > [1] http://www.w3.org/2011/10/31-webapps-minutes.html#item14
> > [13700] http://www.w3.org/Bugs/Public/show_bug.cgi?id=13700
> >
> >
> >
> 

Re: Spec changes for LCs and later maturity levels

[Anne van Kesteren]

On Thu, 03 Nov 2011 17:16:35 -0700, Peter Saint-Andre   
wrote:

2. The substantive issue of whether the text is correct. Julian asked
some questions about that, and I'd be curious to see replies (especially
because they are related to similar topics in HTML5).


So I think irrespective of whether the details of "parse a URL" are  
correct, it is pretty clear we want everything that takes a URL to be  
handled in the same way on the platform. I think this is at the same level  
as whether or not the definition of Web IDL has issues. It might, but the  
details do not affect this specification materially.



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

Re: innerHTML in DocumentFragment

[Ryosuke Niwa]

This sounds like an excellent idea. Chromium / WebKit had an issue with
this in regards to copy & paste because some applications where inserting
table-element-less tables into clipboard, and HTML5 parsing algorithm was
stripping them out.

- Ryosuke

On Thu, Nov 3, 2011 at 4:03 PM, Yehuda Katz  wrote:

> It would be useful if there was a way to take a String of HTML and parse
> it into a document fragment. This should work even if the HTML string
> contains elements that are invalid in the "in body" insertion mode.
>
> Something like this code should work:
>
>   var frag = document.createDocumentFragment();
>   frag.innerHTML = "hello"
>someTable.appendChild(frag)
>
> At present, this can sometimes be achieved if the context of the HTML
> string is known in advance. However, this is not always the case. For
> instance, jQuery supplies an API that looks like this:
>
>   $("html string").appendTo("#table")
>
> At the time that jQuery is creating the document fragment for the HTML
> string, it does not yet know what its context will be. This approach is
> used in order to enable convenient setup code. Here is a very contrived
> example to illustrate the point:
>
>   var frag = $("html string")
>
>   // replace the HTML content of a descendent  with the contents of
> its data-title attribute
>   frag.find("span[data-title]").html(function() { return
> this.attr("data-title"); })
>
>   html.appendTo("#table")
>
> In general, this makes it easier to build abstractions that work with
> Strings of HTML, without always needing to make sure consumers of the
> abstraction know and pass in the existing context.
>
> This would probably require a new, laxer insertion mode, which would
> behave similarly to the body insertion mode, but with different semantics
> in the "*A start tag whose tag name is one of: "caption", "col",
> "colgroup", "frame", "head", "tbody", "td", "tfoot", "th", "thead", "tr""* 
> case.
> One way to handle those cases would be to immediately enter an appropriate
> insertion mode if an unexpected tag was found. For instance, if a start tr
> tag was encountered "at the root", the parser could go into "in table" or
> "in table body" insertion mode instead of treating it like a parse error
> and ignoring the token.
>
> -- Yehuda
>
>
> --
> Yehuda Katz
> (ph) 718.877.1325
>

[Bug 14364] appcache: Add an API to make appcache support caching specific URLs dynamically

[bugzilla]

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

Simon Pieters  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|LATER   |

--- Comment #8 from Simon Pieters  2011-11-04 06:16:57 UTC ---
(In reply to comment #7)
> I have marked
> this LATER so that we can look add this once browsers have caught up with what
> we've specified so far.

I believe this has already happened.

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