http://www.w3.org/Bugs/Public/show_bug.cgi?id=14364
Simon Pieters changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|LATER
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 wr
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
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 o
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:
v
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,
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 sho
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
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
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 do
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 imp
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 advan
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
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();
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/201
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 sp
http://www.w3.org/Bugs/Public/show_bug.cgi?id=14364
Ian 'Hixie' Hickson changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
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
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
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
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, an
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 Websock
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 cl
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 sh
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/
>
> T
http://www.w3.org/Bugs/Public/show_bug.cgi?id=14684
Simon Pieters changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
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
27 matches
Mail list logo
