element re. content being contained in a , has
>> now been loosened up.
>
> It is implied by content model for the element, I am not sure if more
> explict
> explanation is needed.
Maybe no explicit explanation is required, but people pay almost
exegesis-like attention to code samples in specs, so I agree with Phil
that it would be good to have one "bare" text example in the spec
--
Hang loose and stay groovy,
Bruce Lawson
Web Evangelist
www.opera.com (work)
www.brucelawson.co.uk (personal)
www.twitter.com/brucel
From douglips at gmail.com Mon Mar 1 13:05:25 2010
From: douglips at gmail.com (Doug Simpkinson)
Date: Mon, 1 Mar 2010 13:05:25 -0800
Subject: [whatwg] Content encoding (e.g. compression) in Web Sockets
Message-ID: <188fcbce1003011305s2b8bf91cp475b3246342bccf4@mail.gmail.com>
The current Web Socket wire protocol does not make allowances for
compression. ?In cases where only small messages are passed this is
not a concern, but if larger messages are to be passed then
compression is highly desireable. ?Applications that are latency
sensitive and/or send more than a few KB of data at a time would find
this beneficial - examples would include interactive games or web
search results being served over web sockets.
Since most of the Web Socket user agents are web browsers that already
support compression/content encoding for HTTP responses, I propose
adding support for?optional?content encoding to the Web Socket
protocol. ?User agents could opt to accept compression, and servers
could opt to support it when the user agents accept it, just as is
done in HTTP.
This would mean the following:
- In requesting a web socket connection, if the client can handle
compressed messages the client would add an optional header line
Accept-Encoding just as is done for an HTTP request, for example
?? ? ? ?GET /demo HTTP/1.1
?? ? ? ?Upgrade: WebSocket
?? ? ? ?Connection: Upgrade
?? ? ? ?Host:?example.com
?? ? ? ?Origin:?http://example.com
?? ? ? ?WebSocket-Protocol: sample
?? ? ? ?Accept-Encoding: gzip
- In response, the server could choose whether messages will be
encoded or not, and if so, can add a Content-Encoding header, for
example:
HTTP/1.1 101 Web Socket Protocol Handshake
Upgrade: WebSocket
Connection: Upgrade
WebSocket-Origin: http://example.com
WebSocket-Location: ws://example.com/demo
WebSocket-Protocol: sample
?? ? ? ?Content-Encoding: gzip
- If the server has specified a content encoding, then all messages
sent by the server MUST have that content encoding applied.
Once the data transfer part starts, any message the server sends will
be exactly as currently specified, but with the content-encoding
applied. ?The user agent must apply the necessary content encoding
transformation to the message, at which point the resulting data will
be as currently specified (i.e. framed by ?0x00 and 0xFF or with the
appropriate framing for data that may include high bits.)
If the received message does not transform to a message that satisfies
the web socket protocol, either by not really being encoded in that
form or by the resulting decoded message not being properly framed
data, then the standard "fail the connection" step would happen.
I think a wide variety of possible web sockets applications would
benefit from compression. What are people's thoughts on this?
-Doug Simpkinson
Software Engineer, Google
From bent at mozilla.com Mon Mar 1 14:50:30 2010
From: bent at mozilla.com (ben turner)
Date: Mon, 1 Mar 2010 14:50:30 -0800
Subject: [whatwg] Structured clone algorithm a little too friendly?
Message-ID: <21b1517c1003011450q4fb1c521g8ee38d608196d4e5@mail.gmail.com>
Hi folks,
I'm implementing the structured clone algorithm and this part bothers
me a little bit:
- If input is a host object (e.g. a DOM node)
Return the null value.
Seems like this has the potential to confuse web programmers somewhat.
If I were to write code like this:
worker.postMessage(window);
I would expect something meaningful to happen as long as no exception
was generated. According to the spec, though, we would send null to
the worker and not generate any exception. Is that really desirable?
I like the idea of making the structured clone as friendly as possible
but maybe we should add some teeth to this case just like we do for
recursive objects?
-Ben Turner
From ian at hixie.ch Mon Mar 1 14:52:39 2010
From: ian at hixie.ch (Ian Hickson)
Date: Mon, 1 Mar 2010 22:52:39 +0000 (UTC)
Subject: [whatwg] Content encoding (e.g. compression) in Web Sockets
In-Reply-To: <188fcbce1003011305s2b8bf91cp475b3246342bccf4@mail.gmail.com>
References: <188fcbce1003011305s2b8bf91cp475b3246342bccf4@mail.gmail.com>
Message-ID:
On Mon, 1 Mar 2010, Doug Simpkinson wrote:
>
> The current Web Socket wire protocol does not make allowances for
> compression.
Yeah, this is a known issue. We're still trying to nail down the exact
handshake and basics of the framing, but compression will almost certainly
be one of the first features we add in version 2. I expect we'll add a new
header that the client sends to indicate it supports compression, and if
the server responds with the same header, the frames will be compressed
instead of being raw data.
--
Ian Hickson U+1047E )\._.,--....,'``. fL
http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
From dbaron at dbaron.org Mon Mar 1 21:20:04 2010
From: dbaron at dbaron.org (L. David Baron)
Date: Mon, 1 Mar 2010 21:20:04 -0800
Subject: [whatwg] borders on images inside links
Message-ID: <20100302052004.GA31564@pickering.dbaron.org>
I believe the rendering section should describe a default style
rule, present in Gecko and in Internet Explorer (and also in
Netscape 4.x and earlier, Mosaic, etc.), that gives borders to
images inside links. In Gecko, this is represented as:
:link img, :visited img, img[usemap], object[usemap] { border: 2px solid; }
People have expressed concern that this rule is a bad default
because it's a rule that authors frequently override. I agree that
it's a bad default for HTML that is used as an application, but I
think it's a good default for HTML as a document. And I think there
is content written on the assumption that borders would visually
indicate links -- I know I've written some.
I think we're better off not breaking compatibility here, as it's a
very-long-standing (for the Web) precedent. I'd rather see
15-year-old Web pages continue to work as intended rather than
gradually turn them into something that requires 15-year-old
software to read.
For more information (and the reason that prompted me to post here),
see https://bugzilla.mozilla.org/show_bug.cgi?id=452915 .
-David
--
L. David Baron http://dbaron.org/
Mozilla Corporation http://www.mozilla.com/
From mjs at apple.com Tue Mar 2 01:41:35 2010
From: mjs at apple.com (Maciej Stachowiak)
Date: Tue, 02 Mar 2010 01:41:35 -0800
Subject: [whatwg] borders on images inside links
In-Reply-To: <20100302052004.GA31564@pickering.dbaron.org>
References: <20100302052004.GA31564@pickering.dbaron.org>
Message-ID:
On Mar 1, 2010, at 9:20 PM, L. David Baron wrote:
> I believe the rendering section should describe a default style
> rule, present in Gecko and in Internet Explorer (and also in
> Netscape 4.x and earlier, Mosaic, etc.), that gives borders to
> images inside links. In Gecko, this is represented as:
>
> :link img, :visited img, img[usemap], object[usemap] { border: 2px
> solid; }
>
>
> People have expressed concern that this rule is a bad default
> because it's a rule that authors frequently override. I agree that
> it's a bad default for HTML that is used as an application, but I
> think it's a good default for HTML as a document. And I think there
> is content written on the assumption that borders would visually
> indicate links -- I know I've written some.
>
> I think we're better off not breaking compatibility here, as it's a
> very-long-standing (for the Web) precedent. I'd rather see
> 15-year-old Web pages continue to work as intended rather than
> gradually turn them into something that requires 15-year-old
> software to read.
>
> For more information (and the reason that prompted me to post here),
> see https://bugzilla.mozilla.org/show_bug.cgi?id=452915 .
A few comments:
1) WebKit has never had this rule. We have not had any significant
problem reports based on it. Therefore I doubt there is truly a
compatibility issue.
2) I do not believe the proposed rule is a good default for either
documents or applications. It looks ugly. I randomly checked 10 of the
sites I browse most often and I could not find a single one that
explicitly added this rule for the browsers that don't have it. What's
more, I could not find a single one that retained it for images. This
rule is just a vestigial artifact that Web developers have to work
around.
3) I expect the WebKit community would be against adding such a style
rule, even if a spec said we should.
4) Even the 13-year-old HTML 3.2 spec has border="0" on images used as
links: . That's before CSS!
5) I'd like to see some examples of actual 15-year-old Web pages that
render better with this style rule than without, to the point that a
modern reader would consider them broken.
Regards,
Maciej
From mjs at apple.com Tue Mar 2 01:56:26 2010
From: mjs at apple.com (Maciej Stachowiak)
Date: Tue, 02 Mar 2010 01:56:26 -0800
Subject: [whatwg] borders on images inside links
In-Reply-To:
References: <20100302052004.GA31564@pickering.dbaron.org>
Message-ID: <39941621-F7FE-461B-8763-20D8BF5079DC@apple.com>
On Mar 2, 2010, at 1:41 AM, Maciej Stachowiak wrote:
> 2) I do not believe the proposed rule is a good default for either
> documents or applications. It looks ugly. I randomly checked 10 of
> the sites I browse most often and I could not find a single one that
> explicitly added this rule for the browsers that don't have it.
> What's more, I could not find a single one that retained it for
> images. This rule is just a vestigial artifact that Web developers
> have to work around.
I partially take it back, news.google.com and images.google.com
deliberately add blue borders to image links. However they do not use
a default border (it's 1px instead of 2px for one thing).
- Maciej
From ash at ashleysheridan.co.uk Tue Mar 2 02:14:35 2010
From: ash at ashleysheridan.co.uk (Ashley Sheridan)
Date: Tue, 02 Mar 2010 10:14:35 +0000
Subject: [whatwg] borders on images inside links
In-Reply-To: <39941621-F7FE-461B-8763-20D8BF5079DC@apple.com>
References: <20100302052004.GA31564@pickering.dbaron.org>
<39941621-F7FE-461B-8763-20D8BF5079DC@apple.com>
Message-ID: <1267524875.2235.6.camel@localhost>
On Tue, 2010-03-02 at 01:56 -0800, Maciej Stachowiak wrote:
> On Mar 2, 2010, at 1:41 AM, Maciej Stachowiak wrote:
>
> > 2) I do not believe the proposed rule is a good default for either
> > documents or applications. It looks ugly. I randomly checked 10 of
> > the sites I browse most often and I could not find a single one that
> > explicitly added this rule for the browsers that don't have it.
> > What's more, I could not find a single one that retained it for
> > images. This rule is just a vestigial artifact that Web developers
> > have to work around.
>
> I partially take it back, news.google.com and images.google.com
> deliberately add blue borders to image links. However they do not use
> a default border (it's 1px instead of 2px for one thing).
>
> - Maciej
>
I agree with David Baron on this. The majority of browsers render images
within links as having a border (which is the image highlight equivalent
of a text underline when you think about it in context). Having some
default expected behavior would be nice to see in a spec, even if the
majority of websites actually override it. Having it in a spec will
remain consistent with the older browser implementations, and may serve
as a guideline as to exactly what should be expected.
Besides, like you say Maciej, most website devs override this rule
anyway, so it won't actually break anything, it would just clarify what
is already happening.
Thanks,
Ash
http://www.ashleysheridan.co.uk
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From derernst at gmx.ch Tue Mar 2 02:41:10 2010
From: derernst at gmx.ch (Markus Ernst)
Date: Tue, 02 Mar 2010 11:41:10 +0100
Subject: [whatwg] borders on images inside links
In-Reply-To: <1267524875.2235.6.camel@localhost>
References: <20100302052004.GA31564@pickering.dbaron.org> <39941621-F7FE-461B-8763-20D8BF5079DC@apple.com>
<1267524875.2235.6.camel@localhost>
Message-ID: <4B8CEB46.9030403@gmx.ch>
Ashley Sheridan schrieb:
> On Tue, 2010-03-02 at 01:56 -0800, Maciej Stachowiak wrote:
>> On Mar 2, 2010, at 1:41 AM, Maciej Stachowiak wrote:
>>
>> > 2) I do not believe the proposed rule is a good default for either
>> > documents or applications. It looks ugly. I randomly checked 10 of
>> > the sites I browse most often and I could not find a single one that
>> > explicitly added this rule for the browsers that don't have it.
>> > What's more, I could not find a single one that retained it for
>> > images. This rule is just a vestigial artifact that Web developers
>> > have to work around.
>>
>> I partially take it back, news.google.com and images.google.com
>> deliberately add blue borders to image links. However they do not use
>> a default border (it's 1px instead of 2px for one thing).
>>
>> - Maciej
>>
>
> I agree with David Baron on this. The majority of browsers render images
> within links as having a border (which is the image highlight equivalent
> of a text underline when you think about it in context). Having some
> default expected behavior would be nice to see in a spec, even if the
> majority of websites actually override it. Having it in a spec will
> remain consistent with the older browser implementations, and may serve
> as a guideline as to exactly what should be expected.
>
> Besides, like you say Maciej, most website devs override this rule
> anyway, so it won't actually break anything, it would just clarify what
> is already happening.
I assume that it would be desirable for a specified default to reflect
the most common case, unless there are serious BC issues. The most
common case seems to be images without borders.
I apologize for the case this is a stupid suggestion: Could the spec say
that the default for HTML5 is no border, but UAs are encouraged to
render linked images in documents with pre-HTML5 or no doctypes with a
border?
From elharo at ibiblio.org Tue Mar 2 02:44:55 2010
From: elharo at ibiblio.org (Elliotte Rusty Harold)
Date: Tue, 2 Mar 2010 05:44:55 -0500
Subject: [whatwg] Parsing processing instructions in HTML syntax: 10.2.4.44
Bogus comment state
Message-ID: <654a2bb31003020244w4934d194k5b56ad85f2561947@mail.gmail.com>
The handling of processing instructions in the XHTML syntax seems
reasonably well-defined; but it feels a little off in the HTML syntax.
Briefly it seems that . Because processing
instructions can contain > and terminate only at the two character
sequence ?> this could cause PI processing to terminate early and
leave a lot more error handling and a confused parser state in the
text yet to come.
It might be wise to add a separate processing instruction state that
would consume all characters up to the first occurrence of ?> instead
of reusing Bogus comment state. The parser could still emit a comment
token containing the processing instruction text. The goal here is not
to enable processing instructions in the HTML syntax. It's simply an
effort to ensure that if one does slip in by mistake we more
accurately detect what the author or generator likely intended as the
end of the processing instruction.
--
Elliotte Rusty Harold
elharo at ibiblio.org
From hsivonen at iki.fi Tue Mar 2 02:45:35 2010
From: hsivonen at iki.fi (Henri Sivonen)
Date: Tue, 2 Mar 2010 12:45:35 +0200
Subject: [whatwg] borders on images inside links
In-Reply-To: <1267524875.2235.6.camel@localhost>
References: <20100302052004.GA31564@pickering.dbaron.org>
<39941621-F7FE-461B-8763-20D8BF5079DC@apple.com>
<1267524875.2235.6.camel@localhost>
Message-ID:
On Mar 2, 2010, at 12:14, Ashley Sheridan wrote:
> The majority of browsers render images within links as having a border
Do you mean the majority of browser installed base (IE's installed base plus Firefox's)? Of the 5 top browsers 3 don't have a border and 2 have. Of the 4 top engines, 2 have a border and 2 don't.
> (which is the image highlight equivalent of a text underline when you think about it in context).
It's not really equivalent in practice, though. The underline convention is widely retained, so users actually can use the convention as a signal. The border is virtually universally removed by authors, so it's not a convention users can look for as a signal.
--
Henri Sivonen
hsivonen at iki.fi
http://hsivonen.iki.fi/
From ian at hixie.ch Tue Mar 2 02:54:56 2010
From: ian at hixie.ch (Ian Hickson)
Date: Tue, 2 Mar 2010 10:54:56 +0000 (UTC)
Subject: [whatwg] Parsing processing instructions in HTML syntax:
10.2.4.44 Bogus comment state
In-Reply-To: <654a2bb31003020244w4934d194k5b56ad85f2561947@mail.gmail.com>
References: <654a2bb31003020244w4934d194k5b56ad85f2561947@mail.gmail.com>
Message-ID:
On Tue, 2 Mar 2010, Elliotte Rusty Harold wrote:
>
> The handling of processing instructions in the XHTML syntax seems
> reasonably well-defined; but it feels a little off in the HTML syntax.
There's no such thing as processing instructions in text/html.
There was such a thing in HTML4, because of its SGML heritage, though it
was explicitly deprecated.
> Briefly it seems that state, which is fair enough. (I wouldn't really recommend that anyone
> use processing instructions in HTML syntax anyway.) However the parser
> comes out of that state at the first >. Because processing instructions
> can contain > and terminate only at the two character sequence ?> this
> could cause PI processing to terminate early and leave a lot more error
> handling and a confused parser state in the text yet to come.
In HTML4, PIs ended at the first >, not at ?>. "" is the
syntax of PIs when the SGML options used by HTML4 are applied.
In any case, the parser in HTML5 is based on what browsers do, which is
also to terminate at the first >. It's unlikely that we can change that,
given backwards-compatibility needs.
There's a simple workaround: don't use PIs in text/html, since they don't
exist in HTML5 at all, and don't send XML as text/html, since XML and HTML
have different syntaxes and aren't compatible.
HTH,
--
Ian Hickson U+1047E )\._.,--....,'``. fL
http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
From ash at ashleysheridan.co.uk Tue Mar 2 03:00:32 2010
From: ash at ashleysheridan.co.uk (Ashley Sheridan)
Date: Tue, 02 Mar 2010 11:00:32 +0000
Subject: [whatwg] borders on images inside links
In-Reply-To:
References: <20100302052004.GA31564@pickering.dbaron.org>
<39941621-F7FE-461B-8763-20D8BF5079DC@apple.com>
<1267524875.2235.6.camel@localhost>
Message-ID: <1267527632.2235.25.camel@localhost>
On Tue, 2010-03-02 at 12:45 +0200, Henri Sivonen wrote:
> On Mar 2, 2010, at 12:14, Ashley Sheridan wrote:
>
> > The majority of browsers render images within links as having a border
>
> Do you mean the majority of browser installed base (IE's installed base plus Firefox's)? Of the 5 top browsers 3 don't have a border and 2 have. Of the 4 top engines, 2 have a border and 2 don't.
>
> > (which is the image highlight equivalent of a text underline when you think about it in context).
>
> It's not really equivalent in practice, though. The underline convention is widely retained, so users actually can use the convention as a signal. The border is virtually universally removed by authors, so it's not a convention users can look for as a signal.
>
I did mean the majority of the browsers installed (as an install base)
Of my tests on a few browsers, here is what I see:
Browser
Linked Image Border
IE
Yes
Firefox
Yes
Opera
No
Chromium
No
Konqueror
No
Seamonkey
Yes
Chrome
No
Safari
No
Epiphany
Yes
So yes, on the majority of actual distinct browsers (and I count Chrome
different from Chromium here) then the border is suppressed.
Thanks,
Ash
http://www.ashleysheridan.co.uk
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From mjs at apple.com Tue Mar 2 03:45:26 2010
From: mjs at apple.com (Maciej Stachowiak)
Date: Tue, 02 Mar 2010 03:45:26 -0800
Subject: [whatwg] borders on images inside links
In-Reply-To: <4B8CEB46.9030403@gmx.ch>
References: <20100302052004.GA31564@pickering.dbaron.org>
<39941621-F7FE-461B-8763-20D8BF5079DC@apple.com>
<1267524875.2235.6.camel@localhost> <4B8CEB46.9030403@gmx.ch>
Message-ID: <33F05698-61FE-45B5-B2BE-89C3D0260B9D@apple.com>
On Mar 2, 2010, at 2:41 AM, Markus Ernst wrote:
> Ashley Sheridan schrieb:
>> On Tue, 2010-03-02 at 01:56 -0800, Maciej Stachowiak wrote:
>>> On Mar 2, 2010, at 1:41 AM, Maciej Stachowiak wrote:
>>>
>>> > 2) I do not believe the proposed rule is a good default for
>>> either > documents or applications. It looks ugly. I randomly
>>> checked 10 of > the sites I browse most often and I could not
>>> find a single one that > explicitly added this rule for the
>>> browsers that don't have it. > What's more, I could not find a
>>> single one that retained it for > images. This rule is just a
>>> vestigial artifact that Web developers > have to work around.
>>>
>>> I partially take it back, news.google.com and images.google.com
>>> deliberately add blue borders to image links. However they do not
>>> use a default border (it's 1px instead of 2px for one thing).
>>>
>>> - Maciej
>>>
>> I agree with David Baron on this. The majority of browsers render
>> images within links as having a border (which is the image
>> highlight equivalent of a text underline when you think about it in
>> context). Having some default expected behavior would be nice to
>> see in a spec, even if the majority of websites actually override
>> it. Having it in a spec will remain consistent with the older
>> browser implementations, and may serve as a guideline as to exactly
>> what should be expected.
>> Besides, like you say Maciej, most website devs override this rule
>> anyway, so it won't actually break anything, it would just clarify
>> what is already happening.
>
> I assume that it would be desirable for a specified default to
> reflect the most common case, unless there are serious BC issues.
> The most common case seems to be images without borders.
I don't think there are serious compatibility issues. We've been
shipping this behavior in Safari since 2003. I searched all our bugs
mentioning images or borders (including closed bugs) and could not
find one mentioning this issue. Probably no one noticed because the
vast majority of Websites had already been overriding this behavior
for years.
> I apologize for the case this is a stupid suggestion: Could the spec
> say that the default for HTML5 is no border, but UAs are encouraged
> to render linked images in documents with pre-HTML5 or no doctypes
> with a border?
I don't think there is any evidence that this behavior is necessary or
desirable for pre-HTML5 documents.
Regards,
Maciej
From hsivonen at iki.fi Tue Mar 2 03:51:20 2010
From: hsivonen at iki.fi (Henri Sivonen)
Date: Tue, 2 Mar 2010 13:51:20 +0200
Subject: [whatwg] borders on images inside links
In-Reply-To: <4B8CEB46.9030403@gmx.ch>
References: <20100302052004.GA31564@pickering.dbaron.org> <39941621-F7FE-461B-8763-20D8BF5079DC@apple.com>
<1267524875.2235.6.camel@localhost> <4B8CEB46.9030403@gmx.ch>
Message-ID: <57F75915-3BB3-4531-976C-5C6869C6EF16@iki.fi>
On Mar 2, 2010, at 12:41, Markus Ernst wrote:
> I apologize for the case this is a stupid suggestion: Could the spec say that the default for HTML5 is no border, but UAs are encouraged to render linked images in documents with pre-HTML5 or no doctypes with a border?
Taking your suggestion literally would mean introducing a fourth layout mode in addition to quirks, limited quirks (aka. almost standards) and standards. The modes are enough implementation trouble as they are, so I wouldn't support adding a new one.
What about making the standards mode borderless by default but making the quirks mode have the border by default? This would be historically consistent. The purpose of the quirks mode is to cater for late 1990s authoring practices and the reason to have the default border is to avoid changing the appearance of pages from the 1990s. (In the past decade, authors haven't been able to rely on the default border either way, because the default browser on Mac for at least the past decade--first Mac IE 5 and then Safari--hasn't had the default border.)
Still, I wouldn't support a mode-based divergence here. I think it's safe to assume that the same people who have control over the doctype also have control over page-wide style rules. The already is a page-wide precise toggle for the border behavior: img { border: 0; }. I think that, in retrospect, especially considering the difference between the almost standards mode and the standards mode, making style/layout characteristics depend on the doctype is a worse solution that having a targeted CSS-based toggle (see http://hsivonen.iki.fi/almost-precedent/).
More to the point, having a toggle of any kind for this behavior wouldn't solve the problem that I'm interested in solving by not having a default border. My primary concern isn't that authors who control the entire page have to include an additional incantation (img { border: 0; }). My concern is that the default border makes copy-pasteable HTML fragments unnecessarily crufty, because the providers of these fragments feel compelled to zap the border regardless of the toggles in the target document.
Currently, the toggle is available, but providers of fragments still include border="0" or style="border: 0;". If there were also a doctype toggle, fragment providers would still probably resort to crufty markup.
(Yes, I realize that to get rid of the cruft, both Firefox *and IE* would need to change and old version of both of them would need to fade.)
--
Henri Sivonen
hsivonen at iki.fi
http://hsivonen.iki.fi/
From douglips at gmail.com Tue Mar 2 17:22:15 2010
From: douglips at gmail.com (Doug Simpkinson)
Date: Tue, 2 Mar 2010 17:22:15 -0800
Subject: [whatwg] Content encoding (e.g. compression) in Web Sockets
In-Reply-To:
References: <188fcbce1003011305s2b8bf91cp475b3246342bccf4@mail.gmail.com>
Message-ID: <188fcbce1003021722m498c1a7fkf15722b2984993b4@mail.gmail.com>
If the headers are optional, is there a reason they can't be added to
the spec in version 1? It's OK if the first implementations ignore
it, but it seems that some implementations have a faster release cycle
than IETF protocol spec updates, so the upside to having it in the
spec sooner is huge.
If I can help, for example by providing a patch to the spec, I'd be glad to.
On Mon, Mar 1, 2010 at 2:52 PM, Ian Hickson wrote:
> On Mon, 1 Mar 2010, Doug Simpkinson wrote:
>>
>> The current Web Socket wire protocol does not make allowances for
>> compression.
>
> Yeah, this is a known issue. We're still trying to nail down the exact
> handshake and basics of the framing, but compression will almost certainly
> be one of the first features we add in version 2. I expect we'll add a new
> header that the client sends to indicate it supports compression, and if
> the server responds with the same header, the frames will be compressed
> instead of being raw data.
>
> --
> Ian Hickson ? ? ? ? ? ? ? U+1047E ? ? ? ? ? ? ? ?)\._.,--....,'``. ? ?fL
> http://ln.hixie.ch/ ? ? ? U+263A ? ? ? ? ? ? ? ?/, ? _.. \ ? _\ ?;`._ ,.
> Things that are impossible just take longer. ? `._.-(,_..'--(,_..'`-.;.'
>
From ian at hixie.ch Tue Mar 2 17:50:57 2010
From: ian at hixie.ch (Ian Hickson)
Date: Wed, 3 Mar 2010 01:50:57 +0000 (UTC)
Subject: [whatwg] Content encoding (e.g. compression) in Web Sockets
In-Reply-To: <188fcbce1003021722m498c1a7fkf15722b2984993b4@mail.gmail.com>
References: <188fcbce1003011305s2b8bf91cp475b3246342bccf4@mail.gmail.com>
<188fcbce1003021722m498c1a7fkf15722b2984993b4@mail.gmail.com>
Message-ID:
On Tue, 2 Mar 2010, Doug Simpkinson wrote:
>
> If the headers are optional, is there a reason they can't be added to
> the spec in version 1? It's OK if the first implementations ignore it,
> but it seems that some implementations have a faster release cycle than
> IETF protocol spec updates, so the upside to having it in the spec
> sooner is huge.
There's no reason we can't update the spec quickly.
--
Ian Hickson U+1047E )\._.,--....,'``. fL
http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
From ddailey at zoominternet.net Tue Mar 2 20:05:48 2010
From: ddailey at zoominternet.net (ddailey)
Date: Tue, 2 Mar 2010 23:05:48 -0500
Subject: [whatwg] borders on images inside links
References: <20100302052004.GA31564@pickering.dbaron.org>
Message-ID: <8C85D5F381F8421BBE09FE78C6FAFEB6@disxgdg31szkx7>
I tend to concur not just with the specific (borders around images in )
but with the broader principle of working hard to preserve simple HTML. It
is good to keep in mind that there are novices in the world for whom the
concepts of HTML, CSS, script, DOM, semantics, microformats. libraries, etc.
are becoming a steeper and steeper learning curve than was the case when all
the implementers learned the stuff. I worry that things are becoming
increasingly esoteric and elevated and sometimes question if all the noble
efforts expended here will ultimately help with cross-browser compatability
or not. It is not a foregone conclusion to me that they will. A good many
things that I used to do routinely (albeit naively) as an instructor using
IE and Netscape are now hour-long quests to figure out how to do it "right."
A shortest path now often involves the strangest admixtures of CSS, multiple
versions of DOM, innerHTML, and script. Doctrine sometimes seems to override
comprehensibility.
grumble
David
(I'll be cheerier in the morning)
----- Original Message -----
From: "L. David Baron"
To:
Sent: Tuesday, March 02, 2010 12:20 AM
Subject: [whatwg] borders on images inside links
>I believe the rendering section should describe a default style
> rule, present in Gecko and in Internet Explorer (and also in
> Netscape 4.x and earlier, Mosaic, etc.), that gives borders to
> images inside links. In Gecko, this is represented as:
>
> :link img, :visited img, img[usemap], object[usemap] { border: 2px
> solid; }
>
>
> People have expressed concern that this rule is a bad default
> because it's a rule that authors frequently override. I agree that
> it's a bad default for HTML that is used as an application, but I
> think it's a good default for HTML as a document. And I think there
> is content written on the assumption that borders would visually
> indicate links -- I know I've written some.
>
> I think we're better off not breaking compatibility here, as it's a
> very-long-standing (for the Web) precedent. I'd rather see
> 15-year-old Web pages continue to work as intended rather than
> gradually turn them into something that requires 15-year-old
> software to read.
>
> For more information (and the reason that prompted me to post here),
> see https://bugzilla.mozilla.org/show_bug.cgi?id=452915 .
>
> -David
>
> --
> L. David Baron http://dbaron.org/
> Mozilla Corporation http://www.mozilla.com/
>
>
From brettz9 at yahoo.com Wed Mar 3 02:55:46 2010
From: brettz9 at yahoo.com (Brett Zamir)
Date: Wed, 03 Mar 2010 18:55:46 +0800
Subject: [whatwg] Parsing processing instructions in HTML syntax:
10.2.4.44 Bogus comment state
In-Reply-To:
References: <654a2bb31003020244w4934d194k5b56ad85f2561947@mail.gmail.com>
Message-ID: <4B8E4032.1030409@yahoo.com>
On 3/2/2010 6:54 PM, Ian Hickson wrote:
> On Tue, 2 Mar 2010, Elliotte Rusty Harold wrote:
>
>> Briefly it seems that> state, which is fair enough. (I wouldn't really recommend that anyone
>> use processing instructions in HTML syntax anyway.) However the parser
>> comes out of that state at the first>. Because processing instructions
>> can contain> and terminate only at the two character sequence ?> this
>> could cause PI processing to terminate early and leave a lot more error
>> handling and a confused parser state in the text yet to come.
>>
> In HTML4, PIs ended at the first>, not at ?>. "" is the
> syntax of PIs when the SGML options used by HTML4 are applied.
>
> In any case, the parser in HTML5 is based on what browsers do, which is
> also to terminate at the first>. It's unlikely that we can change that,
> given backwards-compatibility needs.
>
Are there really a lot of folks out there depending on old HTML4-style
processing instructions not being broken? Given that as I understand it
such HTML4 processing instructions were not even used by any standard at
that time, and with XHTML 1.0+ processing instructions bringing into
practice the XML form, and especially with all of the progress made in
X/HTML5 on harmonizing HTML and XHTML, I'd think that it'd really be
ideal if this issue would not get in the way (along with the unfortunate
loss of external DTDs)...
As long as website creators have the freedom to be sloppy, why not go a
little further to make XML compatibility better? It'd be a whole lot
more appealing to work in both environments out of the box than deal
with complex server-side conversion solutions...
Brett
From excors+whatwg at gmail.com Wed Mar 3 03:06:52 2010
From: excors+whatwg at gmail.com (Philip Taylor)
Date: Wed, 3 Mar 2010 11:06:52 +0000
Subject: [whatwg] Parsing processing instructions in HTML syntax:
10.2.4.44 Bogus comment state
In-Reply-To: <4B8E4032.1030409@yahoo.com>
References: <654a2bb31003020244w4934d194k5b56ad85f2561947@mail.gmail.com>
<4B8E4032.1030409@yahoo.com>
Message-ID:
On Wed, Mar 3, 2010 at 10:55 AM, Brett Zamir wrote:
> On 3/2/2010 6:54 PM, Ian Hickson wrote:
>>
>> On Tue, 2 Mar 2010, Elliotte Rusty Harold wrote:
>>
>>>
>>> Briefly it seems that>> state, which is fair enough. (I wouldn't really recommend that anyone
>>> use processing instructions in HTML syntax anyway.) However the parser
>>> comes out of that state at the first>. Because processing instructions
>>> can contain> ?and terminate only at the two character sequence ?> ?this
>>> could cause PI processing to terminate early and leave a lot more error
>>> handling and a confused parser state in the text yet to come.
>>>
>>
>> In HTML4, PIs ended at the first>, not at ?>. "" is the
>> syntax of PIs when the SGML options used by HTML4 are applied.
>>
>> In any case, the parser in HTML5 is based on what browsers do, which is
>> also to terminate at the first>. It's unlikely that we can change that,
>> given backwards-compatibility needs.
>>
>
> Are there really a lot of folks out there depending on old HTML4-style
> processing instructions not being broken?
Yes, e.g. a load of pages like
http://www.forex.com.cn/html/2008-01/821561.htm (to pick one example
at random) say:
and don't have the string "?>" anywhere.
--
Philip Taylor
excors at gmail.com
From frantisek.rezac at calavera.info Wed Mar 3 05:08:39 2010
From: frantisek.rezac at calavera.info (=?UTF-8?B?RnJhbnRpxaFlayDFmGV6w6HEjQ==?=)
Date: Wed, 3 Mar 2010 14:08:39 +0100
Subject: [whatwg] Feature proposal - add method to CanvasRenderingContext2D
Message-ID: <17fcfe911003030508t39f74dfdyb5566b5ba15f7b49@mail.gmail.com>
Hi,
the subject says it all. Details follows.
Description
add overload of (or add similarly called) method "createImageData" to
interface CanvasRenderingContext2D which would take two arguments:
- encodedImageBinaryData
- dataMimeType
which are rather self explanatory.
Reason
The reason is to be able to supply output of the future File API
standard (http://www.w3.org/TR/FileAPI/) into canvas.
Use case
Usually there is a lot of image processing during image upload. This
processing takes place at the server and it can consume a lot of
system resources. The method I propose would enable basic client side
image processing by loading image to canvas tag. Then the modified
image could be sent to server instead of the original one. This would
save a lot of server's resources and sometimes even a lot of
bandwidth.
Another possibilities
There are already solutions for this use case, but they are based on
technologies like Flash or Silverlight. With this proposal, no plugin
would be needed.
--
Franti?ek ?ez??
Prague, Czech Republic
From excors+whatwg at gmail.com Wed Mar 3 06:33:52 2010
From: excors+whatwg at gmail.com (Philip Taylor)
Date: Wed, 3 Mar 2010 14:33:52 +0000
Subject: [whatwg] Feature proposal - add method to
CanvasRenderingContext2D
In-Reply-To: <17fcfe911003030508t39f74dfdyb5566b5ba15f7b49@mail.gmail.com>
References: <17fcfe911003030508t39f74dfdyb5566b5ba15f7b49@mail.gmail.com>
Message-ID:
On Wed, Mar 3, 2010 at 1:08 PM, Franti?ek ?ez??
wrote:
> Description
> add overload of (or add similarly called) method "createImageData" to
> interface CanvasRenderingContext2D which would take two arguments:
> - encodedImageBinaryData
> - dataMimeType
> which are rather self explanatory.
>
> Reason
> The reason is to be able to supply output of the future File API
> standard (http://www.w3.org/TR/FileAPI/) into canvas.
The canvas API already lets you do:
var img = new Image();
img.onload = function() {
ctx.drawImage(img, 0, 0);
// do processing on the canvas
};
img.src = 'data:image/png;base64,...'; // get this string from
readAsDataURL etc
Is that sufficient for your use case?
--
Philip Taylor
excors at gmail.com
From frantisek.rezac at calavera.info Wed Mar 3 07:44:26 2010
From: frantisek.rezac at calavera.info (=?UTF-8?B?RnJhbnRpxaFlayDFmGV6w6HEjQ==?=)
Date: Wed, 3 Mar 2010 16:44:26 +0100
Subject: [whatwg] Feature proposal - add method to
CanvasRenderingContext2D
In-Reply-To:
References: <17fcfe911003030508t39f74dfdyb5566b5ba15f7b49@mail.gmail.com>
Message-ID: <17fcfe911003030744g20f68311u5c506b9f1e84408b@mail.gmail.com>
Yes, it works. I failed to spot that it's possible to put data url to
Image.src, sorry.
On Wed, Mar 3, 2010 at 3:33 PM, Philip Taylor wrote:
> On Wed, Mar 3, 2010 at 1:08 PM, Franti?ek ?ez??
> wrote:
>> Description
>> add overload of (or add similarly called) method "createImageData" to
>> interface CanvasRenderingContext2D which would take two arguments:
>> - encodedImageBinaryData
>> - dataMimeType
>> which are rather self explanatory.
>>
>> Reason
>> The reason is to be able to supply output of the future File API
>> standard (http://www.w3.org/TR/FileAPI/) into canvas.
>
> The canvas API already lets you do:
>
> ?var img = new Image();
> ?img.onload = function() {
> ? ?ctx.drawImage(img, 0, 0);
> ? ?// do processing on the canvas
> ?};
> ?img.src = 'data:image/png;base64,...'; // get this string from
> readAsDataURL etc
>
> Is that sufficient for your use case?
>
> --
> Philip Taylor
> excors at gmail.com
>
--
Franti?ek ?ez??
Prague, Czech Republic
--------------------------------------------------
Mobile - personal: +420776161038
Mobile - work: +420725817361
Email - personal:
frantisek.rezac at calavera.info
Email - work:
frantisek.rezac at profinit.cz
Jabber IM (GTalk):
frantisek.rezac at calavera.info
Skype: calavera.info
www: http://calavera.info
---------------------------------------------------
Ekonomov? jsou politruci kapitalismu.
From stewart.brodie at antplc.com Wed Mar 3 09:11:01 2010
From: stewart.brodie at antplc.com (Stewart Brodie)
Date: Wed, 3 Mar 2010 17:11:01 +0000
Subject: [whatwg] [html5] Attaching option elements to select elements in
different documents
Message-ID: <676b4b3edb061471bce0eddfdafe2ceeaa38e569@localhost>
The algorithm in the HTML5 specification for attaching an option element to
a select element is incomplete, because it doesn't describe how to handle
the case where the option element does not belong to the same document as
the select element.
It seems that HTMLOptionElement objects are immune to WRONG_DOCUMENT_ERR
exceptions on any tree modifications. Thus the HTML5 specification also
needs to note that it is overriding the rules from DOM Core about what may
be attached to what. I've written some proposed changes further below.
As far as I can tell, this affects: HTMLSelectElement.add(),
HTMLOptionsCollection.add(), Node.appendChild(), Node.replaceChild(),
Node.insertBefore().
My tests show that this isn't even confined to the cases where the new
parent node is an HTML select element - any cross-document attachment of
option elements operates as though the same-document check has been
bypassed. In fact, the behaviour I'm seeing looks very much like an
implicit adoptNode() call has occurred. I'm basing that suspicion on a
comparison of the (equally inconsistent) behaviour of adoptNode() in
different browsers[*]
I'm testing this from ECMAScript in my test page which is at:
http://www.metahusky.net/~stewart/css/html-options/
In all browsers, if the insertion of the option succeeds, then the inserted
option element compares strictly equal to the option in the receiving select
element. i.e. the option tree has not been cloned.
In some browsers, the [[Prototype]] of the HTMLOptionElement is reset to be
HTMLOptionElement.prototype of the receiving document's script context; in
others, it does not get changed. However, in all browsers, all the nodes in
the option's subtree are affected similarly (i.e. if the option's
[[Prototype]] changes, so does the text node's)
In some browsers, you can only insert the option element if the option
element is not currently attached to anything else.
In some browsers, the option isn't inserted at the right index into the
receiving select, but I think that must just be a different bug.
I propose the following changes to the specification:
Change 1: Renumber existing step 7 to step 8 and insert a new step 7 in
http://www.whatwg.org/specs/web-apps/current-work/multipage/urls.html#htmloptionscollection
"7. If _element_ does not belong to the same document as _parent_, then act
as if the DOM Core adoptNode() method was invoked on the _parent_ node's
ownerDocument with _element_ as the parameter."
[Aside: whilst in the vicinity, shouldn't step 3 be using node rather than
element i.e. "If _before_ is a *node*, but that *node* ..."? Otherwise, I
could legitimately insert it before any text node anywhere in the document.
Should it require that _before_ has to be an option or optgroup?]
Change 2: Append some text to section 2.2.1 (Conformance Requirements ->
Dependencies) to indicate the change to DOM Core, and include a link to the
text added by change 3:
"Some requirements in this specification are a wilful violation of
constraints imposed by the DOM Core specification [DOMCORE]:
* attaching _option_ elements to different documents is permitted"
Change 3: append explanatory text, linked from change 2's text to:
http://www.whatwg.org/specs/web-apps/current-work/multipage/the-button-element.html#the-option-element
"If any attempt is made to attach an _option_ element to a node in a
Document other than the Document of the _option_ element, then the user
agent must not throw a _WRONG_DOCUMENT_ERR_ exception. If the tree change
would otherwise succeed, then the user agent must behave as if a call to the
DOM Core adoptNode() method has been made so that the Document of the
_option_ element is updated. This affects the DOM Core appendChild(),
insertBefore() and replaceChild() methods."
Actually, all of these changes might have to say "_option_ or _optgroup_".
[*] Opera 10.10, Chrome 5.0.307.11 beta, Firefox 3.5.8, and our own ANT
Galio 3.1.0
--
Stewart Brodie
Team Leader - ANT Galio Browser
ANT Software Limited
From darin at apple.com Wed Mar 3 09:14:38 2010
From: darin at apple.com (Darin Adler)
Date: Wed, 03 Mar 2010 09:14:38 -0800
Subject: [whatwg] [html5] Attaching option elements to select elements
in different documents
In-Reply-To: <676b4b3edb061471bce0eddfdafe2ceeaa38e569@localhost>
References: <676b4b3edb061471bce0eddfdafe2ceeaa38e569@localhost>
Message-ID: <6D03AED4-72A1-4CA0-BEA8-6B99F2EC7E1F@apple.com>
Was your testing done with option elements created with document.createElement("option") or new Option? I ask because I seem to recall the behavior being different for at least some types of elements.
-- Darin
From stewart.brodie at antplc.com Wed Mar 3 09:49:38 2010
From: stewart.brodie at antplc.com (Stewart Brodie)
Date: Wed, 3 Mar 2010 17:49:38 +0000
Subject: [whatwg] [html5] Attaching option elements to select elements
in different documents
In-Reply-To: <6D03AED4-72A1-4CA0-BEA8-6B99F2EC7E1F@apple.com>
References: <676b4b3edb061471bce0eddfdafe2ceeaa38e569@localhost>
<6D03AED4-72A1-4CA0-BEA8-6B99F2EC7E1F@apple.com>
Message-ID: <1029ee07e6943b3ef39f0ed5a507afea74135044@localhost>
Darin Adler wrote:
> Was your testing done with option elements created with
> document.createElement("option") or new Option? I ask because I seem to
> recall the behavior being different for at least some types of elements.
That's a good idea - I forgot to test that. I've updated my test so that it
tries both.
The behaviour seems to be the same, regardless of how the option is created.
--
Stewart Brodie
Team Leader - ANT Galio Browser
ANT Software Limited
From bzbarsky at MIT.EDU Wed Mar 3 11:07:36 2010
From: bzbarsky at MIT.EDU (Boris Zbarsky)
Date: Wed, 03 Mar 2010 14:07:36 -0500
Subject: [whatwg] [html5] Attaching option elements to select elements
in different documents
In-Reply-To: <676b4b3edb061471bce0eddfdafe2ceeaa38e569@localhost>
References: <676b4b3edb061471bce0eddfdafe2ceeaa38e569@localhost>
Message-ID: <4B8EB378.3020000@mit.edu>
On 3/3/10 12:11 PM, Stewart Brodie wrote:
> As far as I can tell, this affects: HTMLSelectElement.add(),
> HTMLOptionsCollection.add(), Node.appendChild(), Node.replaceChild(),
> Node.insertBefore().
Is it option-specific, though? Last I checked, various browsers
implicitly adopted on append/insert/replace, period.
-Boris
From ojan at chromium.org Wed Mar 3 18:11:14 2010
From: ojan at chromium.org (Ojan Vafai)
Date: Wed, 3 Mar 2010 18:11:14 -0800
Subject: [whatwg] oninput for contentEditable
In-Reply-To:
References: <78dc8440906231820o150d4a6byeec73bd83f9215a4@mail.gmail.com>
<78dc8440906231842h2cc1fa5ayaa901992435eaafc@mail.gmail.com>
Message-ID: <78dc8441003031811m25947b08u75d53b259252e493@mail.gmail.com>
WebKit would like to implement this in the (very) near future. Before
proceeding, we'd like to hear from other browser vendors that you're roughly
on board with this direction of adding beforeinput and input events.
Here are the changes I can think of that would result from this:
1) Fire "input" event for contentEditable areas as well as for text-entry
form controls.
2) For every case where we'd fire "input", add a new "beforeinput" event
that fires before the DOM has been modified.
3) Add a new InputEvent interface with an "action" attribute to use for
"input" and "beforeinput" events.
4) For events with an "inserttext" action attribute, also provide a "data"
attribute that specifies the text being inserted. For other actions, "data"
is the empty string.
5) "input" events may be batched as long as they have the same action. In
the case of "inserttext" actions, the data attribute is the accumulation of
text being inserted. One strange side effect here is that there may be
multiple "beforeinput" events per "input" event fire, although it's not
unlike having multiple keydown events before a single keyup.
The list of actions still needs to be enumerated, but some obvious ones are
inserttext, undo, redo, copy, paste, cut and drop.
I also think we should get rid of the textInput event in deference to this
more useful event, but that's a discussion we can have on www-dom once this
is resolved. As far as I know, only WebKit currently implements textInput.
Ojan
On Tue, Jul 14, 2009 at 6:02 PM, Ian Hickson wrote:
> On Tue, 23 Jun 2009, Ojan Vafai wrote:
> >
> > Currently, textareas and text inputs support the "oninput" event that
> > fires on all user-initiated modifications to their content. We should
> > add this event to contentEditable elements as well and add an "action"
> > property the specifies what action the user took that caused the input
> > event.
>
> I haven't yet added this.
>
> I think we should probably address the various problems with
> contenteditable all at once, to make sure the solution is coherent
> overall. I'm watching what happens with the mutation event changes and
> tracking proposals for various other changes to contentEditable.
>
> It may be that we need to defer these changes to after HTML5 reaches last
> call, though, and have them in a future version next year some time.
>
> --
> Ian Hickson U+1047E )\._.,--....,'``. fL
> http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,.
> Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From ukai at chromium.org Wed Mar 3 18:42:01 2010
From: ukai at chromium.org (=?UTF-8?B?RnVtaXRvc2hpIFVrYWkgKOm1nOmjvOaWh+aVjyk=?=)
Date: Thu, 4 Mar 2010 11:42:01 +0900
Subject: [whatwg] WebSocket bufferedAmount includes overhead or not.
Message-ID:
Hi,
I noticed that WebSocket spec updated to not inlcude framing overhead in
bufferedAmount.
http://lists.whatwg.org/pipermail/commit-watchers-whatwg.org/2010/003971.html
I tried to implement it in WebKit, but found it make hard to implement
correctly. https://bugs.webkit.org/show_bug.cgi?id=35571
It's easy after WebSocket is closed (just add length of message), but while
it's open, we'll manage buffer including frame bytes and underlying socket
will write arbitrary length of the buffer (may not be on frame boundary)
To get bufferdAmount correctly without framing overhead, we need to parse
the buffer again. It's not light operation and it's challenge to make it
effective.
I think including frame overhead is much easier.
Could you revert it?
--
Fumitoshi Ukai
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From bzbarsky at MIT.EDU Wed Mar 3 18:44:13 2010
From: bzbarsky at MIT.EDU (Boris Zbarsky)
Date: Wed, 03 Mar 2010 21:44:13 -0500
Subject: [whatwg] oninput for contentEditable
In-Reply-To: <408607e11003031831w5bd0906cv46b51cbe53589dd9@mail.gmail.com>
References: <78dc8440906231820o150d4a6byeec73bd83f9215a4@mail.gmail.com>
<78dc8440906231842h2cc1fa5ayaa901992435eaafc@mail.gmail.com>
<78dc8441003031811m25947b08u75d53b259252e493@mail.gmail.com>
<408607e11003031831w5bd0906cv46b51cbe53589dd9@mail.gmail.com>
Message-ID: <4B8F1E7D.5000608@mit.edu>
On 3/3/10 9:31 PM, Daniel Danilatos wrote:
> Worth noting, the events should convey the user intent - so, e.g. not
> just "delete chars 5 - 8" but "forward word delete, which is chars 5 -
> 8".
So I have to ask... Why are events _before_ the edit needed?
If we add these, then you have to define what happens when those event
handlers modify the state of the DOM in arbitrary ways, including
carrying out operations that spin the event loop, operations that make
the edit that's about to happen nonsensical, and so forth. It's a huge
chunk of spec and implementation complexity. So I'd like to see some
very compelling use cases to even consider it.
-Boris
From Olli.Pettay at helsinki.fi Thu Mar 4 01:52:02 2010
From: Olli.Pettay at helsinki.fi (Olli Pettay)
Date: Thu, 04 Mar 2010 11:52:02 +0200
Subject: [whatwg] WebSocket bufferedAmount includes overhead or not.
In-Reply-To:
References:
Message-ID: <4B8F82C2.4070107@helsinki.fi>
On 3/4/10 4:42 AM, Fumitoshi Ukai (????) wrote:
> Hi,
>
> I noticed that WebSocket spec updated to not inlcude framing overhead in
> bufferedAmount.
I asked that since from API point of view it doesn't make
much sense to have the frame bytes to be magically included in the
bufferedAmount.
What if we change the protocol and require different amount framing
bytes?
Also why to have framing bytes and not the bytes related to http handling?
Also, XHR+progress events don't include http headers etc in the
.loaded or .total.
> http://lists.whatwg.org/pipermail/commit-watchers-whatwg.org/2010/003971.html
> I tried to implement it in WebKit, but found it make hard to implement
> correctly.
Not hard at all in gecko's implementation (the patch is still waiting
for a review and will be possibly updated to include the latest
changes to the protocol before pushing to hg repo).
> https://bugs.webkit.org/show_bug.cgi?id=35571
> It's easy after WebSocket is closed (just add length of message),
right
> but
> while it's open, we'll manage buffer including frame bytes
In the patch for gecko there is a different buffer for each
"message", so it is easy to count how many frame bytes are in the
buffers.
> and
> underlying socket will write arbitrary length of the buffer (may not be
> on frame boundary)
> To get bufferdAmount correctly without framing overhead, we need to
> parse the buffer again. It's not light operation and it's challenge to
> make it effective.
> I think including frame overhead is much easier.
> Could you revert it?
That would make the API worse, especially for web developers, IMO.
They shouldn't need to know about the protocol, they should just be able
to use the API and understand easily what bufferedAmount means.
br,
-Olli
>
> --
> Fumitoshi Ukai
>
From Olli.Pettay at helsinki.fi Thu Mar 4 01:57:18 2010
From: Olli.Pettay at helsinki.fi (Olli Pettay)
Date: Thu, 04 Mar 2010 11:57:18 +0200
Subject: [whatwg] oninput for contentEditable
In-Reply-To: <78dc8441003031811m25947b08u75d53b259252e493@mail.gmail.com>
References: <78dc8440906231820o150d4a6byeec73bd83f9215a4@mail.gmail.com>
<78dc8440906231842h2cc1fa5ayaa901992435eaafc@mail.gmail.com>
<78dc8441003031811m25947b08u75d53b259252e493@mail.gmail.com>
Message-ID: <4B8F83FE.5020600@helsinki.fi>
On 3/4/10 4:11 AM, Ojan Vafai wrote:
> WebKit would like to implement this in the (very) near future. Before
> proceeding, we'd like to hear from other browser vendors that you're
> roughly on board with this direction of adding beforeinput and input events.
>
> Here are the changes I can think of that would result from this:
> 1) Fire "input" event for contentEditable areas as well as for
> text-entry form controls.
> 2) For every case where we'd fire "input", add a new "beforeinput" event
> that fires before the DOM has been modified.
> 3) Add a new InputEvent interface with an "action" attribute to use for
> "input" and "beforeinput" events.
> 4) For events with an "inserttext" action attribute, also provide a
> "data" attribute that specifies the text being inserted. For other
> actions, "data" is the empty string.
> 5) "input" events may be batched as long as they have the same action.
> In the case of "inserttext" actions, the data attribute is the
> accumulation of text being inserted. One strange side effect here is
> that there may be multiple "beforeinput" events per "input" event fire,
> although it's not unlike having multiple keydown events before a single
> keyup.
>
> The list of actions still needs to be enumerated, but some obvious ones
> are inserttext, undo, redo, copy, paste, cut and drop.
>
> I also think we should get rid of the textInput event in deference to
> this more useful event, but that's a discussion we can have on www-dom
> once this is resolved. As far as I know, only WebKit currently
> implements textInput.
textInput should be pretty useful when combined with the new key events
and with the all the properties DOM 3 Events draft defines for it.
Webkit's textInput isn't quite that, IIRC.
-Olli
>
> Ojan
>
> On Tue, Jul 14, 2009 at 6:02 PM, Ian Hickson > wrote:
>
> On Tue, 23 Jun 2009, Ojan Vafai wrote:
> >
> > Currently, textareas and text inputs support the "oninput" event that
> > fires on all user-initiated modifications to their content. We should
> > add this event to contentEditable elements as well and add an
> "action"
> > property the specifies what action the user took that caused the
> input
> > event.
>
> I haven't yet added this.
>
> I think we should probably address the various problems with
> contenteditable all at once, to make sure the solution is coherent
> overall. I'm watching what happens with the mutation event changes and
> tracking proposals for various other changes to contentEditable.
>
> It may be that we need to defer these changes to after HTML5 reaches
> last
> call, though, and have them in a future version next year some time.
>
> --
> Ian Hickson U+1047E )\._.,--....,'``. fL
> http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,.
> Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
>
>
From ukai at chromium.org Thu Mar 4 02:17:32 2010
From: ukai at chromium.org (=?UTF-8?B?RnVtaXRvc2hpIFVrYWkgKOm1nOmjvOaWh+aVjyk=?=)
Date: Thu, 4 Mar 2010 19:17:32 +0900
Subject: [whatwg] WebSocket bufferedAmount includes overhead or not.
In-Reply-To: <4B8F82C2.4070107@helsinki.fi>
References:
<4B8F82C2.4070107@helsinki.fi>
Message-ID:
On Thu, Mar 4, 2010 at 18:52, Olli Pettay wrote:
> On 3/4/10 4:42 AM, Fumitoshi Ukai (????) wrote:
>
>> Hi,
>>
>> I noticed that WebSocket spec updated to not inlcude framing overhead in
>> bufferedAmount.
>>
> I asked that since from API point of view it doesn't make
> much sense to have the frame bytes to be magically included in the
> bufferedAmount.
> What if we change the protocol and require different amount framing
> bytes?
> Also why to have framing bytes and not the bytes related to http handling?
>
I think bufferedAmount is a number of bytes are buffered to be sent on wire,
so including frame byte is reasonable.
>
> Also, XHR+progress events don't include http headers etc in the
> .loaded or .total.
>
>
>
>
>> http://lists.whatwg.org/pipermail/commit-watchers-whatwg.org/2010/003971.html
>> I tried to implement it in WebKit, but found it make hard to implement
>> correctly.
>>
> Not hard at all in gecko's implementation (the patch is still waiting for a
> review and will be possibly updated to include the latest
> changes to the protocol before pushing to hg repo).
I just look over https://bugzilla.mozilla.org/show_bug.cgi?id=472529
It looks just updating bufferedAmount once a whole message has been sent,
isn't it?
But I think user of the API might want to know progress while partial
transfer of large messsage, so this implementation isn't so happy, IMO.
Anyway, if this level of feedback is ok, it would be better to have onsent
event listener to fire after each message has been sent.
Then, we don't need to poll bufferedAmount as do in example in WebSocket API
draft.
What do you think?
--
ukai
>
>
> https://bugs.webkit.org/show_bug.cgi?id=35571
>> It's easy after WebSocket is closed (just add length of message),
>>
> right
>
>
>
> but
>> while it's open, we'll manage buffer including frame bytes
>>
> In the patch for gecko there is a different buffer for each
> "message", so it is easy to count how many frame bytes are in the
> buffers.
>
>
>
> and
>> underlying socket will write arbitrary length of the buffer (may not be
>> on frame boundary)
>> To get bufferdAmount correctly without framing overhead, we need to
>> parse the buffer again. It's not light operation and it's challenge to
>> make it effective.
>> I think including frame overhead is much easier.
>>
>
>
> Could you revert it?
>>
> That would make the API worse, especially for web developers, IMO.
> They shouldn't need to know about the protocol, they should just be able to
> use the API and understand easily what bufferedAmount means.
>
>
>
> br,
>
>
> -Olli
>
>
>
>
>> --
>> Fumitoshi Ukai
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From Olli.Pettay at helsinki.fi Thu Mar 4 02:26:32 2010
From: Olli.Pettay at helsinki.fi (Olli Pettay)
Date: Thu, 04 Mar 2010 12:26:32 +0200
Subject: [whatwg] WebSocket bufferedAmount includes overhead or not.
In-Reply-To:
References:
<4B8F82C2.4070107@helsinki.fi>
Message-ID: <4B8F8AD8.3040403@helsinki.fi>
On 3/4/10 12:17 PM, Fumitoshi Ukai (????) wrote:
> On Thu, Mar 4, 2010 at 18:52, Olli Pettay > wrote:
>
> On 3/4/10 4:42 AM, Fumitoshi Ukai (????) wrote:
>
> Hi,
>
> I noticed that WebSocket spec updated to not inlcude framing
> overhead in
> bufferedAmount.
>
> I asked that since from API point of view it doesn't make
> much sense to have the frame bytes to be magically included in the
> bufferedAmount.
> What if we change the protocol and require different amount framing
> bytes?
> Also why to have framing bytes and not the bytes related to http
> handling?
>
>
> I think bufferedAmount is a number of bytes are buffered to be sent on
> wire, so including frame byte is reasonable.
>
>
> Also, XHR+progress events don't include http headers etc in the
> .loaded or .total.
>
>
>
> http://lists.whatwg.org/pipermail/commit-watchers-whatwg.org/2010/003971.html
> I tried to implement it in WebKit, but found it make hard to
> implement
> correctly.
>
> Not hard at all in gecko's implementation (the patch is still
> waiting for a review and will be possibly updated to include the latest
> changes to the protocol before pushing to hg repo).
>
>
> I just look over https://bugzilla.mozilla.org/show_bug.cgi?id=472529
> It looks just updating bufferedAmount once a whole message has been
> sent, isn't it?
There might be still a bug there, but fortunately easy to fix one.
Thanks for noticing that.
> But I think user of the API might want to know progress while partial
> transfer of large messsage,
Indeed.
> so this implementation isn't so happy, IMO.
>
> Anyway, if this level of feedback is ok, it would be better to have
> onsent event listener to fire after each message has been sent.
That would make the JS code a bit uglier and I think JS needs to know if
there are some pending messages.
-Olli
> Then, we don't need to poll bufferedAmount as do in example in WebSocket
> API draft.
> What do you think?
>
> --
> ukai
>
>
>
>
> https://bugs.webkit.org/show_bug.cgi?id=35571
> It's easy after WebSocket is closed (just add length of message),
>
> right
>
>
>
> but
> while it's open, we'll manage buffer including frame bytes
>
> In the patch for gecko there is a different buffer for each
> "message", so it is easy to count how many frame bytes are in the
> buffers.
>
>
>
> and
> underlying socket will write arbitrary length of the buffer (may
> not be
> on frame boundary)
> To get bufferdAmount correctly without framing overhead, we need to
> parse the buffer again. It's not light operation and it's
> challenge to
> make it effective.
> I think including frame overhead is much easier.
>
>
>
> Could you revert it?
>
> That would make the API worse, especially for web developers, IMO.
> They shouldn't need to know about the protocol, they should just be
> able to use the API and understand easily what bufferedAmount means.
>
>
>
> br,
>
>
> -Olli
>
>
>
>
> --
> Fumitoshi Ukai
>
>
>
From stewart.brodie at antplc.com Thu Mar 4 02:27:23 2010
From: stewart.brodie at antplc.com (Stewart Brodie)
Date: Thu, 4 Mar 2010 10:27:23 +0000
Subject: [whatwg] [html5] Attaching option elements to select elements
in different documents
In-Reply-To: <4B8EB378.3020000@mit.edu>
References: <676b4b3edb061471bce0eddfdafe2ceeaa38e569@localhost>
<4B8EB378.3020000@mit.edu>
Message-ID:
Boris Zbarsky wrote:
> On 3/3/10 12:11 PM, Stewart Brodie wrote:
> > As far as I can tell, this affects: HTMLSelectElement.add(),
> > HTMLOptionsCollection.add(), Node.appendChild(), Node.replaceChild(),
> > Node.insertBefore().
>
> Is it option-specific, though? Last I checked, various browsers
> implicitly adopted on append/insert/replace, period.
Since when? I was sure that they didn't used to do this. DOM Core is
extremely clear on this issue (both in level 2 and level 3). You appear to
be correct: Firefox and Opera both just ignore the standard and get this
wrong. Chrome just seems to get confused.
--
Stewart Brodie
Team Leader - ANT Galio Browser
ANT Software Limited
From mjs at apple.com Thu Mar 4 02:44:32 2010
From: mjs at apple.com (Maciej Stachowiak)
Date: Thu, 04 Mar 2010 02:44:32 -0800
Subject: [whatwg] [html5] Attaching option elements to select
elements in different documents
In-Reply-To:
References: <676b4b3edb061471bce0eddfdafe2ceeaa38e569@localhost>
<4B8EB378.3020000@mit.edu>
Message-ID:
On Mar 4, 2010, at 2:27 AM, Stewart Brodie wrote:
> Boris Zbarsky wrote:
>
>> On 3/3/10 12:11 PM, Stewart Brodie wrote:
>>> As far as I can tell, this affects: HTMLSelectElement.add(),
>>> HTMLOptionsCollection.add(), Node.appendChild(), Node.replaceChild
>>> (),
>>> Node.insertBefore().
>>
>> Is it option-specific, though? Last I checked, various browsers
>> implicitly adopted on append/insert/replace, period.
>
> Since when? I was sure that they didn't used to do this. DOM Core is
> extremely clear on this issue (both in level 2 and level 3). You
> appear to
> be correct: Firefox and Opera both just ignore the standard and get
> this
> wrong. Chrome just seems to get confused.
In WebKit, we originally implemented the rule required by the DOM
spec, but found that was insufficiently compatible with the Web. Below
see our current rule. I think this should be errata'd in the DOM to
give a more reasonable behavior.
// WRONG_DOCUMENT_ERR: Raised if newChild was created from a
different document than the one that
// created this node.
// We assume that if newChild is a DocumentFragment, all children
are created from the same document
// as the fragment itself (otherwise they could not have been
added as children)
if (newChild->document() != document()) {
// but if the child is not in a document yet then loosen the
// restriction, so that e.g. creating an element with the
Option()
// constructor and then adding it to a different document
works,
// as it does in Mozilla and Mac IE.
if (!newChild->inDocument()) {
shouldAdoptChild = true;
} else {
ec = WRONG_DOCUMENT_ERR;
return;
}
}
From annevk at opera.com Thu Mar 4 02:45:58 2010
From: annevk at opera.com (Anne van Kesteren)
Date: Thu, 04 Mar 2010 11:45:58 +0100
Subject: [whatwg] [html5] Attaching option elements to select elements
in different documents
In-Reply-To:
References: <676b4b3edb061471bce0eddfdafe2ceeaa38e569@localhost>
<4B8EB378.3020000@mit.edu>
Message-ID:
On Thu, 04 Mar 2010 11:27:23 +0100, Stewart Brodie
wrote:
> Boris Zbarsky wrote:
>> On 3/3/10 12:11 PM, Stewart Brodie wrote:
>> > As far as I can tell, this affects: HTMLSelectElement.add(),
>> > HTMLOptionsCollection.add(), Node.appendChild(), Node.replaceChild(),
>> > Node.insertBefore().
>>
>> Is it option-specific, though? Last I checked, various browsers
>> implicitly adopted on append/insert/replace, period.
>
> Since when? I was sure that they didn't used to do this. DOM Core is
> extremely clear on this issue (both in level 2 and level 3). You appear
> to be correct: Firefox and Opera both just ignore the standard and get
> this
> wrong. Chrome just seems to get confused.
This changed a while ago due to compatibility problems. Consensus at the
time was to change DOM Core.
--
Anne van Kesteren
http://annevankesteren.nl/
From stewart.brodie at antplc.com Thu Mar 4 04:05:13 2010
From: stewart.brodie at antplc.com (Stewart Brodie)
Date: Thu, 4 Mar 2010 12:05:13 +0000
Subject: [whatwg] [html5] Attaching option elements to select elements
in different documents
In-Reply-To:
References: <676b4b3edb061471bce0eddfdafe2ceeaa38e569@localhost>
<4B8EB378.3020000@mit.edu>
Message-ID: <46f2bbccf39dedcc6259ff268c986427c9afd497@localhost>
Anne van Kesteren wrote:
> On Thu, 04 Mar 2010 11:27:23 +0100, Stewart Brodie
> wrote:
> > Boris Zbarsky wrote:
> >> On 3/3/10 12:11 PM, Stewart Brodie wrote:
> >> > As far as I can tell, this affects: HTMLSelectElement.add(),
> >> > HTMLOptionsCollection.add(), Node.appendChild(), Node.replaceChild(),
> >> > Node.insertBefore().
> >>
> >> Is it option-specific, though? Last I checked, various browsers
> >> implicitly adopted on append/insert/replace, period.
> >
> > Since when? I was sure that they didn't used to do this. DOM Core is
> > extremely clear on this issue (both in level 2 and level 3). You appear
> > to be correct: Firefox and Opera both just ignore the standard and get
> > this wrong. Chrome just seems to get confused.
>
> This changed a while ago due to compatibility problems. Consensus at the
> time was to change DOM Core.
Is this documented anywhere? By "compatibility problems", presumably you
mean bugs in Firefox that were then exploited by content authors who didn't
know better? From Maciej's description of WebKit's behaviour, it looks
like either they didn't know about this consensus or they didn't implement
it compatibly.
This definitely needs to be documented in HTML5.
Are there any more retrospective changes to fundamental behaviour specified
in DOM Core in the pipeline that I need to know about? I already know about
the one in DOM Event about capturing listeners being called in the target
phase.
That leaves the issue of how adoptNode() affects the [[Prototype]] of the
node objects, which is currently inconsistent between desktop browsers.
Opera & Chrome agree with each other (that the [[Prototype]] is unchanged);
Firefox disagrees (it changes the [[Prototype]] to be that it would have
been if the node had been created anew in the destination document).
--
Stewart Brodie
Team Leader - ANT Galio Browser
ANT Software Limited
From annevk at opera.com Thu Mar 4 04:18:21 2010
From: annevk at opera.com (Anne van Kesteren)
Date: Thu, 04 Mar 2010 13:18:21 +0100
Subject: [whatwg] [html5] Attaching option elements to select elements
in different documents
In-Reply-To: <46f2bbccf39dedcc6259ff268c986427c9afd497@localhost>
References: <676b4b3edb061471bce0eddfdafe2ceeaa38e569@localhost>
<4B8EB378.3020000@mit.edu>
<46f2bbccf39dedcc6259ff268c986427c9afd497@localhost>
Message-ID:
On Thu, 04 Mar 2010 13:05:13 +0100, Stewart Brodie
wrote:
> Is this documented anywhere?
On some W3C mailing list archive I think.
> By "compatibility problems", presumably you
> mean bugs in Firefox that were then exploited by content authors who
> didn't know better? From Maciej's description of WebKit's behaviour,
> it looks
> like either they didn't know about this consensus or they didn't
> implement it compatibly.
I forgot the details.
> This definitely needs to be documented in HTML5.
It seems it should be specified in the new version of DOM Core.
> Are there any more retrospective changes to fundamental behaviour
> specified in DOM Core in the pipeline that I need to know about? I
> already know about the one in DOM Event about capturing listeners being
> called in the target
> phase.
Well, features that are not implemented are planned to be dropped. Don't
recall anything else right now.
> That leaves the issue of how adoptNode() affects the [[Prototype]] of the
> node objects, which is currently inconsistent between desktop browsers.
> Opera & Chrome agree with each other (that the [[Prototype]] is
> unchanged);
> Firefox disagrees (it changes the [[Prototype]] to be that it would have
> been if the node had been created anew in the destination document).
--
Anne van Kesteren
http://annevankesteren.nl/
From robert at ocallahan.org Thu Mar 4 13:14:44 2010
From: robert at ocallahan.org (Robert O'Callahan)
Date: Fri, 5 Mar 2010 10:14:44 +1300
Subject: [whatwg] [html5] Attaching option elements to select elements
in different documents
In-Reply-To: <46f2bbccf39dedcc6259ff268c986427c9afd497@localhost>
References: <676b4b3edb061471bce0eddfdafe2ceeaa38e569@localhost>
<4B8EB378.3020000@mit.edu>
<46f2bbccf39dedcc6259ff268c986427c9afd497@localhost>
Message-ID: <11e306601003041314v7cd29e44ncc4a9bbfb73aefb@mail.gmail.com>
Apart from compatibility issues, there's also the fact that requiring
explicit adopt/import is a pointless burden on authors.
Rob
--
"He was pierced for our transgressions, he was crushed for our iniquities;
the punishment that brought us peace was upon him, and by his wounds we are
healed. We all, like sheep, have gone astray, each of us has turned to his
own way; and the LORD has laid on him the iniquity of us all." [Isaiah
53:5-6]
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From brettz9 at yahoo.com Thu Mar 4 18:23:46 2010
From: brettz9 at yahoo.com (Brett Zamir)
Date: Fri, 05 Mar 2010 10:23:46 +0800
Subject: [whatwg] Parsing processing instructions in HTML
syntax: 10.2.4.44 Bogus comment state
In-Reply-To:
References: <654a2bb31003020244w4934d194k5b56ad85f2561947@mail.gmail.com> <4B8E4032.1030409@yahoo.com>
Message-ID: <4B906B32.6090002@yahoo.com>
On 3/3/2010 7:06 PM, Philip Taylor wrote:
> On Wed, Mar 3, 2010 at 10:55 AM, Brett Zamir wrote:
>
>> On 3/2/2010 6:54 PM, Ian Hickson wrote:
>>
>>> On Tue, 2 Mar 2010, Elliotte Rusty Harold wrote:
>>>
>>>
>>>> Briefly it seems that>>> state, which is fair enough. (I wouldn't really recommend that anyone
>>>> use processing instructions in HTML syntax anyway.) However the parser
>>>> comes out of that state at the first>. Because processing instructions
>>>> can contain> and terminate only at the two character sequence ?> this
>>>> could cause PI processing to terminate early and leave a lot more error
>>>> handling and a confused parser state in the text yet to come.
>>>>
>>>>
>>> In HTML4, PIs ended at the first>, not at ?>. "" is the
>>> syntax of PIs when the SGML options used by HTML4 are applied.
>>>
>>> In any case, the parser in HTML5 is based on what browsers do, which is
>>> also to terminate at the first>. It's unlikely that we can change that,
>>> given backwards-compatibility needs.
>>>
>>>
>> Are there really a lot of folks out there depending on old HTML4-style
>> processing instructions not being broken?
>>
> Yes, e.g. a load of pages like
> http://www.forex.com.cn/html/2008-01/821561.htm (to pick one example
> at random) say:
>
>
>
> and don't have the string "?>" anywhere.
>
Ok, fair enough. But while it is great that HTML5 seeks to be
transitional and backwards compatible, HTML5 (thankfully) already breaks
compatibility for the sake of XML compatibility (e.g., localName or
getElementsByTagNameNS). It seems to me that there should still be a
role of eventually transitioning into something more full-featured in a
fundamental, language-neutral way (e.g., supporting a fuller subset of
XML's features such as external entities and yes, XML-style processing
instructions); extensible, including the ability to include XML from
other namespaces which may also encourage or rely on using their own XML
processing instructions, for those who wish to experiment or supplement
the HTML standard behavior; and more harmonious and compatible with a
simpler syntax (i.e., XML's)--even if the more complex syntax is more
prominent and continues to be supported indefinitely.
Brett
From rnairn at gmail.com Thu Mar 4 22:14:13 2010
From: rnairn at gmail.com (Rowan Nairn)
Date: Thu, 4 Mar 2010 22:14:13 -0800
Subject: [whatwg] Making cross-domain overlays more user-friendly
In-Reply-To: <4B6C9FBC.3090807@mit.edu>
References: <989aa6911002051440l1431ffd7taa49b3e1f0e5799f@mail.gmail.com>
<4B6C9FBC.3090807@mit.edu>
Message-ID: <989aa6911003042214l79db300er23a5e27e838e8cd2@mail.gmail.com>
I'd like to see if I can move this forward a bit. Let's drop some of
my original suggestions and break the solution into two separate
simple features that we can discuss independently. Firstly, of the
problems with overlays listed in my original email ([1]), I think the
following are the most important to deal with:
> - Navigation in framed page does not get rid of the overlay (without
> explicit frame breaking)
> - After the user navigates within the frame, information in the
> overlay no longer applies to framed content
I propose a "oneshot" attribute for iframe to alleviate this:
> - Add one new method to iframe:
> e.g. removeOverlay()
> [...]
This is an interesting idea. The most effective way forward for an idea
like this would be to get some experimental implementations, to see if
the security issues that were brought up can be sufficiently addressed.
--
Ian Hickson U+1047E )\._.,--....,'``. fL
http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
From hsivonen at iki.fi Wed Mar 10 06:38:12 2010
From: hsivonen at iki.fi (Henri Sivonen)
Date: Wed, 10 Mar 2010 06:38:12 -0800 (PST)
Subject: [whatwg] XSS safe templating
In-Reply-To: <270790479.35969.1268231464701.JavaMail.root@cm-mail03.mozilla.org>
Message-ID: <213441389.35988.1268231892352.JavaMail.root@cm-mail03.mozilla.org>
"Mike Samuel" wrote:
> I'm working with EcmaScript TC39 trying to allow for experimentation
> with new content generation techniques in JavaScript.
> There's one missing piece which would let template language authors
> experiment with varying degrees of XSS-safety, and I was hoping that
> a
> change like the below might make it into HTML5.
Shouldn't XSS-safe templating use the DOM APIs to generate a tree (fragment) instead of trusting the built-in HTML parser of the browser to behave in a certain way?
> When user-code does
> ? ?document.write(value), myElement.innerHTML = value, etc.
> and the value is an object, currently it is coerced to a string by
> indirectly calling the toString method. ?I would like the toString
> method to be called with 'html ' + the current HTML 5 insertion mode
> to give structured template return values a chance to apply
> appropriate escaping schemes. ?For attribute sets, it would be nice
> to
> call toString with the argument 'attr ' + attribute name. ?This would
> be backwards compatible as toString implementations ignore parameters
> (modulo Number).
What would the object do with this information? Without knowing how you are planning on using this information and filling in the lack of information with my own guesses, my knee jerk reaction is very negative.
FWIW, in Gecko currently, the stringification happens a few abstraction layers away from the parser, so implementing your suggestion would involve punching holes in those abstractions.
--
Henri Sivonen
hsivonen at iki.fi
http://hsivonen.iki.fi/
From usenet at laliluna.de Wed Mar 10 07:26:22 2010
From: usenet at laliluna.de (Sebastian Hennebrueder)
Date: Wed, 10 Mar 2010 16:26:22 +0100
Subject: [whatwg] Window id - a proposal to leverage session usage in
web application
In-Reply-To:
References: <4B6B32CA.7010302@laliluna.de>
Message-ID: <4B97BA1E.2080508@laliluna.de>
Ian Hickson schrieb:
> On Thu, 4 Feb 2010, Sebastian Hennebrueder wrote:
>> About half a year ago I came up with an idea to add a unique window id
>> as request header to each browser request. I published this initially on
>> my website
>> http://www.laliluna.de/blog/2009/05/19/browser_feature_request.html
>
> The best way to get something like this into the specs is to follow the
> steps outlined here:
>
> http://wiki.whatwg.org/wiki/FAQ#Is_there_a_process_for_adding_new_features_to_a_specification.3F
>
> HTH,
Hello Ian,
thank you for the pointer. I had been busy the last weeks and will
continue working on this the next week. In the web app mailing list
people pointed out that this could be part of another spec as well. I
need to carefully read both and will come back.
--
Best Regards / Viele Gr??e
Sebastian Hennebrueder
-----
Software Developer and Trainer for Hibernate / Java Persistence
http://www.laliluna.de
From ifette at google.com Wed Mar 10 07:54:19 2010
From: ifette at google.com (=?UTF-8?B?SWFuIEZldHRlICjjgqTjgqLjg7Pjg5Xjgqfjg4Pjg4bjgqMp?=)
Date: Wed, 10 Mar 2010 07:54:19 -0800
Subject: [whatwg] Storage quota introspection and modification
Message-ID:
As I talk with more application developers (both within Google and at
large), one thing that consistently gets pointed out to me as a problem is
the notion of the opaqueness of storage quotas in all of the new storage
mechanisms (Local Storage, Web SQL Database, Web Indexed Database, the
Filesystem API being worked on in DAP, etc). First, without being able to
know how large your quota currently is and how much headroom you are using,
it is very difficult to plan in an efficient manner. For instance, if you
are trying to sync email, I think it is reasonable to ask "how much space do
I have," as opposed to just getting halfway through an update and finding
out that you hit your quota, rolling back the transaction, trying again with
a smaller subset, realizing you still hit your quota, etc.
I would like to see a method added, for any "storage mechanism", something
like "GetCurrentQuota()" and "GetCurrentQuotaUsed()". (I specifically don't
care what they're called or the details, e.g. whether they need to be
callbacks, I just want to see us address this use case.)
Secondly, I think we need a better answer for obtaining a larger quota.
Let's think for a moment about the use cases -- in most instances, I am
going to make a decision that I want to use an application offline. (I
personally would not expect to browse to a site and then just happen to be
able to use it offline, nor do I expect users to have that expectation or
experience. Rather, I expect going through some sort of flow like clicking
something that says "Yes, I want to use Application X offline". At this
point, I want to get any permissioning issues out of the way. I don't want
to wait until the data sync to the Web XXX Database starts failing 10
minutes later to pop up an infobar that is no longer in the user's current
flow / state of mind, I don't want to then pop up another infobar 30 minutes
later saying their Filesystem quota is full, etc. I want to be able to get
this out of the way all at once, at a point in time where I believe the user
is actually in the mindset / task of deciding that they want to use my web
application. I specifically do not want to have to deal with 4 different
infobars, potentially at 4 different points in time, to use an application I
have decided I want to use.
To that point, I would like to see a method added (presumably that can only
be called in response to a user action) that would allow my page to request
a bundle of permissions. I am going to go out on a limb here and include
geolocation in this bundle. Some sort of a callback type API where I pass in
a list of permissions that I want, the UA is free to display this to the
user in whatever mechanism it determines appropriate (if at all -- e.g. if
the user has already denied geolocation and that's being requested again, as
a UA i might decide not to present that request). That is, I could pass in
something like ["LocalStorageQuota", 20*1024*1024 /* 20M */, "WebSQLQuota",
1*1024*1024*1024 /* 1GB */, "FileSystemQuota", 10*1024*1024*1024 /* 10GB */,
"Geolocation", true], and the callback could then (as a convenience)
indicate the current quota for all of the things that I asked for, so that I
could figure out whether the user accepted, denied, or accepted and modified
the request and how I can then proceed (or not proceed). Again, I don't care
terribly about the details of how the API looks, the above is just meant for
illustration.
-Ian
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From jorlow at chromium.org Wed Mar 10 08:21:40 2010
From: jorlow at chromium.org (Jeremy Orlow)
Date: Wed, 10 Mar 2010 16:21:40 +0000
Subject: [whatwg] Storage quota introspection and modification
In-Reply-To:
References:
Message-ID: <5dd9e5c51003100821r1f83df21udafba0a8f6262e55@mail.gmail.com>
2010/3/10 Ian Fette (????????)
> As I talk with more application developers (both within Google and at
> large), one thing that consistently gets pointed out to me as a problem is
> the notion of the opaqueness of storage quotas in all of the new storage
> mechanisms (Local Storage, Web SQL Database, Web Indexed Database, the
> Filesystem API being worked on in DAP, etc). First, without being able to
> know how large your quota currently is and how much headroom you are using,
> it is very difficult to plan in an efficient manner. For instance, if you
> are trying to sync email, I think it is reasonable to ask "how much space do
> I have," as opposed to just getting halfway through an update and finding
> out that you hit your quota, rolling back the transaction, trying again with
> a smaller subset, realizing you still hit your quota, etc.
>
> I would like to see a method added, for any "storage mechanism", something
> like "GetCurrentQuota()" and "GetCurrentQuotaUsed()". (I specifically don't
> care what they're called or the details, e.g. whether they need to be
> callbacks, I just want to see us address this use case.)
>
I too have heard this plea over and over again. I've also heard that even
knowing the order of magnitude of headway would be useful. This is nearly a
deal breaker for a lot of apps. Having to gracefully handle a quota related
error _every_ single time you do an operation is a big pain.
> Secondly, I think we need a better answer for obtaining a larger quota.
> Let's think for a moment about the use cases -- in most instances, I am
> going to make a decision that I want to use an application offline. (I
> personally would not expect to browse to a site and then just happen to be
> able to use it offline, nor do I expect users to have that expectation or
> experience. Rather, I expect going through some sort of flow like clicking
> something that says "Yes, I want to use Application X offline". At this
> point, I want to get any permissioning issues out of the way. I don't want
> to wait until the data sync to the Web XXX Database starts failing 10
> minutes later to pop up an infobar that is no longer in the user's current
> flow / state of mind, I don't want to then pop up another infobar 30 minutes
> later saying their Filesystem quota is full, etc. I want to be able to get
> this out of the way all at once, at a point in time where I believe the user
> is actually in the mindset / task of deciding that they want to use my web
> application. I specifically do not want to have to deal with 4 different
> infobars, potentially at 4 different points in time, to use an application I
> have decided I want to use.
>
> To that point, I would like to see a method added (presumably that can only
> be called in response to a user action) that would allow my page to request
> a bundle of permissions. I am going to go out on a limb here and include
> geolocation in this bundle. Some sort of a callback type API where I pass in
> a list of permissions that I want, the UA is free to display this to the
> user in whatever mechanism it determines appropriate (if at all -- e.g. if
> the user has already denied geolocation and that's being requested again, as
> a UA i might decide not to present that request). That is, I could pass in
> something like ["LocalStorageQuota", 20*1024*1024 /* 20M */, "WebSQLQuota",
> 1*1024*1024*1024 /* 1GB */, "FileSystemQuota", 10*1024*1024*1024 /* 10GB */,
> "Geolocation", true], and the callback could then (as a convenience)
> indicate the current quota for all of the things that I asked for, so that I
> could figure out whether the user accepted, denied, or accepted and modified
> the request and how I can then proceed (or not proceed). Again, I don't care
> terribly about the details of how the API looks, the above is just meant for
> illustration.
>
I wish you had put this in its own email. These are really two very
different subjects.
That said, I agree with you...as long as we can do it in a manor that's
completely unobtrusive and not in the "Do you want this app to work: yes or
no" style (where yes implies giving them tons of permissions). Ideally with
an
From dresende at thinkdigital.pt Wed Mar 10 08:25:36 2010
From: dresende at thinkdigital.pt (Diogo Resende)
Date: Wed, 10 Mar 2010 16:25:36 +0000
Subject: [whatwg] Storage quota introspection and modification
In-Reply-To:
References:
Message-ID: <1268238336.9543.1.camel@nasgul.local>
Agree 100% (even with geolocation).
On Wed, 2010-03-10 at 07:54 -0800, Ian Fette (????????) wrote:
> As I talk with more application developers (both within Google and at
> large), one thing that consistently gets pointed out to me as a
> problem is the notion of the opaqueness of storage quotas in all of
> the new storage mechanisms (Local Storage, Web SQL Database, Web
> Indexed Database, the Filesystem API being worked on in DAP, etc).
> First, without being able to know how large your quota currently is
> and how much headroom you are using, it is very difficult to plan in
> an efficient manner. For instance, if you are trying to sync email, I
> think it is reasonable to ask "how much space do I have," as opposed
> to just getting halfway through an update and finding out that you hit
> your quota, rolling back the transaction, trying again with a smaller
> subset, realizing you still hit your quota, etc.
>
>
> I would like to see a method added, for any "storage mechanism",
> something like "GetCurrentQuota()" and "GetCurrentQuotaUsed()". (I
> specifically don't care what they're called or the details, e.g.
> whether they need to be callbacks, I just want to see us address this
> use case.)
>
>
> Secondly, I think we need a better answer for obtaining a larger
> quota. Let's think for a moment about the use cases -- in most
> instances, I am going to make a decision that I want to use an
> application offline. (I personally would not expect to browse to a
> site and then just happen to be able to use it offline, nor do I
> expect users to have that expectation or experience. Rather, I expect
> going through some sort of flow like clicking something that says
> "Yes, I want to use Application X offline". At this point, I want to
> get any permissioning issues out of the way. I don't want to wait
> until the data sync to the Web XXX Database starts failing 10 minutes
> later to pop up an infobar that is no longer in the user's current
> flow / state of mind, I don't want to then pop up another infobar 30
> minutes later saying their Filesystem quota is full, etc. I want to be
> able to get this out of the way all at once, at a point in time where
> I believe the user is actually in the mindset / task of deciding that
> they want to use my web application. I specifically do not want to
> have to deal with 4 different infobars, potentially at 4 different
> points in time, to use an application I have decided I want to use.
>
>
> To that point, I would like to see a method added (presumably that can
> only be called in response to a user action) that would allow my page
> to request a bundle of permissions. I am going to go out on a limb
> here and include geolocation in this bundle. Some sort of a callback
> type API where I pass in a list of permissions that I want, the UA is
> free to display this to the user in whatever mechanism it determines
> appropriate (if at all -- e.g. if the user has already denied
> geolocation and that's being requested again, as a UA i might decide
> not to present that request). That is, I could pass in something like
> ["LocalStorageQuota", 20*1024*1024 /* 20M */, "WebSQLQuota",
> 1*1024*1024*1024 /* 1GB */, "FileSystemQuota", 10*1024*1024*1024 /*
> 10GB */, "Geolocation", true], and the callback could then (as a
> convenience) indicate the current quota for all of the things that I
> asked for, so that I could figure out whether the user accepted,
> denied, or accepted and modified the request and how I can then
> proceed (or not proceed). Again, I don't care terribly about the
> details of how the API looks, the above is just meant for
> illustration.
>
>
> -Ian
From mikesamuel at gmail.com Wed Mar 10 09:45:13 2010
From: mikesamuel at gmail.com (Mike Samuel)
Date: Wed, 10 Mar 2010 09:45:13 -0800
Subject: [whatwg] XSS safe templating
In-Reply-To: <213441389.35988.1268231892352.JavaMail.root@cm-mail03.mozilla.org>
References: <270790479.35969.1268231464701.JavaMail.root@cm-mail03.mozilla.org>
<213441389.35988.1268231892352.JavaMail.root@cm-mail03.mozilla.org>
Message-ID: <178b8d441003100945o1f4fb0c0qc61655cc7d1de8e8@mail.gmail.com>
2010/3/10 Henri Sivonen :
> "Mike Samuel" wrote:
>
>> I'm working with EcmaScript TC39 trying to allow for experimentation
>> with new content generation techniques in JavaScript.
>> There's one missing piece which would let template language authors
>> experiment with varying degrees of XSS-safety, and I was hoping that
>> a
>> change like the below might make it into HTML5.
>
> Shouldn't XSS-safe templating use the DOM APIs to generate a tree (fragment) instead of trusting the built-in HTML parser of the browser to behave in a certain way?
That's one way to do it.
But most programmers, by default, write code like this:
html += '' + foo + ' ';
Many JS programmers come from a perl/python/ruby/PHP background, and
it looks like there will be changes to ES harmony to allow a familiar
syntax like
html += s{{$foo }};
where the result ends up being a structured interpolation
(('literal "") ('substitution foo) ('literal " "))
then with the appropriate context provided to toString, this can be
converted to a "safe" chunk of HTML that preserves the property that
literal portions are interpreted the same regardless of substitution
values.
So we want to move from inherently unsafe idioms to ones that are
safer, letting library authors experiment with the right mix of
strictness and strategies for resolving ambiguity, without imposing an
extra syntactic burden.
>> When user-code does
>> ? ?document.write(value), myElement.innerHTML = value, etc.
>> and the value is an object, currently it is coerced to a string by
>> indirectly calling the toString method. ?I would like the toString
>> method to be called with 'html ' + the current HTML 5 insertion mode
>> to give structured template return values a chance to apply
>> appropriate escaping schemes. ?For attribute sets, it would be nice
>> to
>> call toString with the argument 'attr ' + attribute name. ?This would
>> be backwards compatible as toString implementations ignore parameters
>> (modulo Number).
>
> What would the object do with this information? Without knowing how you are planning on using this information and filling in the lack of information with my own guesses, my knee jerk reaction is very negative.
I think having a knee-jerk reaction to vague, poorly specified
proposals is probably a good thing :)
I didn't want to dump a whole lot of detail on the list on my first
post, but I can put together some runnable demos if that would help.
I've already got the JS side of things speced out.
Would that help?
Or I can try and do a bit of draft-spec writing, but I don't
understand all the implications of changing operations that take
DOMStrings to accept objects and so would probably make a hash of it.
> FWIW, in Gecko currently, the stringification happens a few abstraction layers away from the parser, so implementing your suggestion would involve punching holes in those abstractions.
Ah, so there's a layer that sits between the XPCOM object and the JS
Host object that knows a DOMString is expected, and does the JS foo
necessary to convert to a string?
> --
> Henri Sivonen
> hsivonen at iki.fi
> http://hsivonen.iki.fi/
>
From ericu at google.com Wed Mar 10 09:51:27 2010
From: ericu at google.com (Eric Uhrhane)
Date: Wed, 10 Mar 2010 09:51:27 -0800
Subject: [whatwg] Multiple file download
In-Reply-To: <26b395e61003100028pcee4073uacc864c312e5a85f@mail.gmail.com>
References: <6b04dc91002230210n584ec21k1b4471d833b45e9f@mail.gmail.com>
<4B84223F.7010108@mit.edu> <4B845E6F.5040204@doxdesk.com>
<1266984198.23066.3.camel@localhost>
<7c2a12e21002251613m704f6226u50618ca1fe49cda@mail.gmail.com>
<1267143215.2895.40.camel@localhost>
<6b04dc91002251731k51eed0aencf3a76c758760e68@mail.gmail.com>
<26b395e61003100028pcee4073uacc864c312e5a85f@mail.gmail.com>
Message-ID: <44b058fe1003100951n45ffd846x3f617f0fd9f6f262@mail.gmail.com>
On Wed, Mar 10, 2010 at 12:28 AM, timeless wrote:
> On Fri, Feb 26, 2010 at 3:31 AM, Jose Fandos wrote:
>> Er... sure. It is not as convenient for certain web apps when compared to
>> desktop apps. With this supported, the gap get's reduced.
>
> Adding support for tar (and all of its variations) involves adding
> extra code, testing, etc. to browsers. This is sometimes called bloat,
> and can be painful for browsers that work on mobile devices. Things
> aren't "free", especially not duplicative features.
>
> I'm quite happy to demand that web sites include code for generating Zip files.
>
> http://www.pkware.com/documents/casestudies/APPNOTE.TXT V. General
> Format of a .ZIP file
>
> the zip format is fairly streaming friendly, the directory is at the
> end of the file. And if you're actually generating a file which has so
> many records that you can't remember all of them, you're probably
> trying to attack my user agent, so I'm quite happy that you'd fail.
Isn't a format that has its directory at the end about as
streaming-UNfriendly as you can get? You need to pull the whole thing
down before you can take it apart. With a .tar.gz, you can unpack
files as they arrive.
Eric
From bzbarsky at MIT.EDU Wed Mar 10 09:52:03 2010
From: bzbarsky at MIT.EDU (Boris Zbarsky)
Date: Wed, 10 Mar 2010 12:52:03 -0500
Subject: [whatwg] XSS safe templating
In-Reply-To: <178b8d441003100945o1f4fb0c0qc61655cc7d1de8e8@mail.gmail.com>
References: <270790479.35969.1268231464701.JavaMail.root@cm-mail03.mozilla.org> <213441389.35988.1268231892352.JavaMail.root@cm-mail03.mozilla.org>
<178b8d441003100945o1f4fb0c0qc61655cc7d1de8e8@mail.gmail.com>
Message-ID: <4B97DC43.3070203@mit.edu>
On 3/10/10 12:45 PM, Mike Samuel wrote:
>> FWIW, in Gecko currently, the stringification happens a few abstraction layers away from the parser, so implementing your suggestion would involve punching holes in those abstractions.
>
> Ah, so there's a layer that sits between the XPCOM object and the JS
> Host object that knows a DOMString is expected, and does the JS foo
> necessary to convert to a string?
That's correct. The C++ object just implements a method as declared in
the DOM IDL; there is a glue layer responsible for coercing the
arguments actually given to the types declared in the IDL. This isn't
just the case in Gecko; Webkit+JSC has similar behavior. I'd assume
that Webkit+V8 does as well, though I haven't looked at the code.
-Boris
From bzbarsky at MIT.EDU Wed Mar 10 10:01:17 2010
From: bzbarsky at MIT.EDU (Boris Zbarsky)
Date: Wed, 10 Mar 2010 13:01:17 -0500
Subject: [whatwg] Multiple file download
In-Reply-To: <44b058fe1003100951n45ffd846x3f617f0fd9f6f262@mail.gmail.com>
References: <6b04dc91002230210n584ec21k1b4471d833b45e9f@mail.gmail.com>
<4B84223F.7010108@mit.edu> <4B845E6F.5040204@doxdesk.com>
<1266984198.23066.3.camel@localhost>
<7c2a12e21002251613m704f6226u50618ca1fe49cda@mail.gmail.com>
<1267143215.2895.40.camel@localhost>
<6b04dc91002251731k51eed0aencf3a76c758760e68@mail.gmail.com>
<26b395e61003100028pcee4073uacc864c312e5a85f@mail.gmail.com>
<44b058fe1003100951n45ffd846x3f617f0fd9f6f262@mail.gmail.com>
Message-ID: <4B97DE6D.7060600@mit.edu>
On 3/10/10 12:51 PM, Eric Uhrhane wrote:
>> the zip format is fairly streaming friendly, the directory is at the
>> end of the file. And if you're actually generating a file which has so
>> many records that you can't remember all of them, you're probably
>> trying to attack my user agent, so I'm quite happy that you'd fail.
>
> Isn't a format that has its directory at the end about as
> streaming-UNfriendly as you can get? You need to pull the whole thing
> down before you can take it apart. With a .tar.gz, you can unpack
> files as they arrive.
That depends on whether you're the producer or the consumer. Given a
format that has a directory (which is an assumption, of course), it's
easier to consume as a stream if the directory is at the beginning and
easier to produce as a stream if the directory is at the end.
-Boris
From mikesamuel at gmail.com Wed Mar 10 10:15:53 2010
From: mikesamuel at gmail.com (Mike Samuel)
Date: Wed, 10 Mar 2010 10:15:53 -0800
Subject: [whatwg] XSS safe templating
In-Reply-To: <4B97DC43.3070203@mit.edu>
References: <270790479.35969.1268231464701.JavaMail.root@cm-mail03.mozilla.org>
<213441389.35988.1268231892352.JavaMail.root@cm-mail03.mozilla.org>
<178b8d441003100945o1f4fb0c0qc61655cc7d1de8e8@mail.gmail.com>
<4B97DC43.3070203@mit.edu>
Message-ID: <178b8d441003101015y71f67bfem31e837fc1143f064@mail.gmail.com>
Hmm. It occurs to me that many libraries -- at least jQuery and
prototype have their own layers in between their users and the DOM.
When I cooked up this scheme, I didn't know how likely proxies and
ephemeron tables were to make it into ES Harmony, but I think Andreas
Gal just implemented (both? or just ephemerons) in a tracemonkey
nightly. Those are all you need to do a really efficient
interposition layer, so libraries are probably not going to stop doing
that.
So I think the non-document.write portion can be implemented entirely
in the library interposition layer.
document.write can be wrapped. But the wrapper would still need to
know the insertion-mode.
If the insertion mode were exposed, or at least some context were
given -- enough to know whether the next char if not something that
changed the current token, would be interpreted as
* inside a tag
* outside a tag in a comment / application instruction / doctype
* outside a tag in a PCDATA/RCDATA/CDATA context and ideally in what
kind of containing tag
* outside a tag in a CDATA section.
So maybe some kind of
(DOMString|null) document.getInsertionMode().
2010/3/10 Boris Zbarsky :
> On 3/10/10 12:45 PM, Mike Samuel wrote:
>>>
>>> FWIW, in Gecko currently, the stringification happens a few abstraction
>>> layers away from the parser, so implementing your suggestion would involve
>>> punching holes in those abstractions.
>>
>> Ah, so there's a layer that sits between the XPCOM object and the JS
>> Host object that knows a DOMString is expected, and does the JS foo
>> necessary to convert to a string?
>
> That's correct. ?The C++ object just implements a method as declared in the
> DOM IDL; there is a glue layer responsible for coercing the arguments
> actually given to the types declared in the IDL. ?This isn't just the case
> in Gecko; Webkit+JSC has similar behavior. ?I'd assume that Webkit+V8 does
> as well, though I haven't looked at the code.
>
> -Boris
>
From excors+whatwg at gmail.com Wed Mar 10 10:32:23 2010
From: excors+whatwg at gmail.com (Philip Taylor)
Date: Wed, 10 Mar 2010 18:32:23 +0000
Subject: [whatwg] Multiple file download
In-Reply-To: <44b058fe1003100951n45ffd846x3f617f0fd9f6f262@mail.gmail.com>
References: <6b04dc91002230210n584ec21k1b4471d833b45e9f@mail.gmail.com>
<4B845E6F.5040204@doxdesk.com>
<1266984198.23066.3.camel@localhost>
<7c2a12e21002251613m704f6226u50618ca1fe49cda@mail.gmail.com>
<1267143215.2895.40.camel@localhost>
<6b04dc91002251731k51eed0aencf3a76c758760e68@mail.gmail.com>
<26b395e61003100028pcee4073uacc864c312e5a85f@mail.gmail.com>
<44b058fe1003100951n45ffd846x3f617f0fd9f6f262@mail.gmail.com>
Message-ID:
On Wed, Mar 10, 2010 at 5:51 PM, Eric Uhrhane wrote:
> On Wed, Mar 10, 2010 at 12:28 AM, timeless wrote:
>> http://www.pkware.com/documents/casestudies/APPNOTE.TXT V. General
>> Format of a .ZIP file
>>
>> the zip format is fairly streaming friendly, the directory is at the
>> end of the file. And if you're actually generating a file which has so
>> many records that you can't remember all of them, you're probably
>> trying to attack my user agent, so I'm quite happy that you'd fail.
>
> Isn't a format that has its directory at the end about as
> streaming-UNfriendly as you can get? ?You need to pull the whole thing
> down before you can take it apart. ?With a .tar.gz, you can unpack
> files as they arrive.
Each file's compressed data is preceded with a header with enough
information to decompress it (filename etc), and then that information
is duplicated in the central directory at the end, so I believe you
can still do streaming decompression (as well as doing random access
once you've got the directory). And you can still do streaming
compression without even buffering a single file, by setting a flag
and moving a part of the file header (lengths and checksum) to just
after the compressed file data.
(But I never understood why pkunzip asked me to put in the last floppy
disk of a multi-disk zip before it would start decompressing the first
- maybe there's some reason that streaming decompression doesn't quite
work perfectly in practice?)
--
Philip Taylor
excors at gmail.com
From shess at google.com Wed Mar 10 14:39:51 2010
From: shess at google.com (Scott Hess)
Date: Wed, 10 Mar 2010 14:39:51 -0800
Subject: [whatwg] Storage quota introspection and modification
In-Reply-To: <5dd9e5c51003100821r1f83df21udafba0a8f6262e55@mail.gmail.com>
References:
<5dd9e5c51003100821r1f83df21udafba0a8f6262e55@mail.gmail.com>
Message-ID: <696e4b7c1003101439j6ad3a74dg81cd1e14887fbbc@mail.gmail.com>
2010/3/10 Jeremy Orlow :
> 2010/3/10 Ian Fette (????????)
>> As I talk with more application developers (both within Google and at
>> large), one thing that consistently gets pointed out to me as a problem is
>> the notion of the opaqueness of storage quotas in all of the new storage
>> mechanisms (Local Storage, Web SQL Database, Web Indexed Database, the
>> Filesystem API being worked on in DAP, etc). First, without being able to
>> know how large your quota currently is and how much headroom you are using,
>> it is very difficult to plan in an efficient manner. For instance, if you
>> are trying to sync email, I think it is reasonable to ask "how much space do
>> I have," as opposed to just getting halfway through an update and finding
>> out that you hit your quota, rolling back the transaction, trying again with
>> a smaller subset, realizing you still hit your quota, etc.
>> I would like to see a method added, for any "storage mechanism", something
>> like "GetCurrentQuota()" and "GetCurrentQuotaUsed()". (I specifically don't
>> care what they're called or the details, e.g. whether they need to be
>> callbacks, I just want to see us address this use case.)
>
> I too have heard this plea over and over again. I've also heard that even
> knowing the order of magnitude of headway would be useful. This is nearly a
> deal breaker for a lot of apps. Having to gracefully handle a quota related
> error _every_ single time you do an operation is a big pain.
As with any other API, just because the browser says you can do it
doesn't mean that when you try to do it, it will work, so you pretty
much have to handle it.
An alternative to providing a measure of what your remaining quota is
would be to provide an estimate of the minimum amount of additional
data which the system has a high confidence that it can store for you.
That number can probably be generated more reliably, and it sidesteps
some of the issues with what quota really is (after considering
straight storage overhead and the overhead needed to deal with
transactions).
-scott
From mike.shaver at gmail.com Wed Mar 10 16:11:53 2010
From: mike.shaver at gmail.com (Mike Shaver)
Date: Wed, 10 Mar 2010 16:11:53 -0800
Subject: [whatwg] Storage quota introspection and modification
In-Reply-To:
References:
Message-ID:
2010/3/10 Ian Fette (????????) :
> As I talk with more application developers (both within Google and at
> large), one thing that consistently gets pointed out to me as a problem is
> the notion of the opaqueness of storage quotas in all of the new storage
> mechanisms (Local Storage, Web SQL Database, Web Indexed Database, the
> Filesystem API being worked on in DAP, etc). First, without being able to
> know how large your quota currently is and how much headroom you are using,
> it is very difficult to plan in an efficient manner. For instance, if you
> are trying to sync email, I think it is reasonable to ask "how much space do
> I have," as opposed to just getting halfway through an update and finding
> out that you hit your quota, rolling back the transaction, trying again with
> a smaller subset, realizing you still hit your quota, etc.
It generally seems that "desktop" mail clients behave in the
undesirable way you describe, in that I've never seen one warn me
about available disk space, and I've had several choke on a disk being
surprisingly full. And yet, I don't think it causes a lot of problems
for users. One reason for that is likely that most users don't
operate in the red zone of their disk capacity; a reason for THAT
might be that the OS tells them that they're getting close, and that
many of their apps start to fail when they get full, so they are more
conditioned to react appropriately when they're warned. (Also,
today's disks are gigantic, so if you fill one up it's usually a WTF
sort of moment.)
Part of that is also helped by the fact that they're managing a single
quota, effectively, which might point to a useful simplification: when
the disk gets close to full, and there's "a lot" of data in the
storage cache, the UA could prompt the user to do some cleanup. Just
as with cleaning their disk, they would look for stuff they had
forgotten was still on there ("I haven't used Google Reader in ages!")
or didn't know was taking up so much space ("Flickr is caching *how*
much image data locally?"). The browser could provide a unified
interface for setting a limit, forbidding any storage, compressing to
trade space for perf; on the desktop users need to configure those
things per-application, if such are configurable at all. If I really
don't like an app's disk space usage on the desktop, I can uninstall
it, for which the web storage analogue would perhaps be setting a
small/zero quota, or just not going there.
One thing that could help users make better quota decisions is a way
for apps to opt in to sub-quotas: gmail might have quotas for contact
data, search indexing, message bodies, and attachments. I could
decide that on my netbook I want message bodies and contact data, but
will be OK with slow search and missing attachments. An app like
Remember The Milk might just use one quota for simplicity, but with
the ability to expose distinct storage types to the UA, more complex
web applications could get sophisticated storage management "for
free".
So I guess my position is this: I think it's reasonable for apps to
run into their quota, and to that end they should probably synchronize
data in priority order where they can distinguish (and if they were
going to make some decision based on the result of a quota check,
presumably they can). User agents should seek to make quota
management as straightforward as possible for users. One reasonable
approach, IMO, is to assume that if there is space available on the
disk, then an app they've "offlined" can use it. If it hurts, don't
go back to that site, or put it in a quota box when you get the
"achievement unlocked: 1GB of offline data" pop-up.
Mike
From ian at hixie.ch Wed Mar 10 17:19:48 2010
From: ian at hixie.ch (Ian Hickson)
Date: Thu, 11 Mar 2010 01:19:48 +0000 (UTC)
Subject: [whatwg] URN or protocol attribute
In-Reply-To: <4B73AD79.5030701@yahoo.com>
References: <4B6FCA82.3050508@yahoo.com> <4B72668C.9070706@degeneration.co.uk>
<4B73AD79.5030701@yahoo.com>
Message-ID:
On Mon, 8 Feb 2010, Brett Zamir wrote:
>
> Internet Explorer has an attribute on anchor elements for URNs:
> http://msdn.microsoft.com/en-us/library/ms534710%28VS.85%29.aspx
>
> This has not caught on in other browsers, though I believe it could be a very
> powerful feature once the feature was supported with a UI that handled URNs
> (as with adding support for custom protocols).
>
> Imagine, for example, to take a link like:
>
> urn="isbn:9210020251">United Nations charter
>
> The default behavior would simply follow the link, but if a user agent
> supported the @urn attribute, and if the browser (or browser add-ons)
> had registered support for that URN namespace identifier (here "isbn"),
> it could, for example, open a dialog to ask which handler to use (or
> whether to always use it), it could ask or otherwise allow in
> preferences an HTML page (with wildcards) where the attribute's content
> could be passed, or it could give the option whenever the user
> right-clicked to choose which handler they wanted to use for a given
> link.
Does this match IE's behaviour with the urn="" attribute?
Historically, browsers that have wanted to offer dedicated services for
specific features, e.g. the iPhone handling map views using a dedicated
Maps application, have done so by simply overriding parts of the URL
space, e.g. in that case detecting when a page is on the Google Maps site
and parsing the URL locally instead of sending it to the remote site.
Is there really a need for a more dedicated mechanism? It's not clear that
there is much pent-up demand for this.
--
Ian Hickson U+1047E )\._.,--....,'``. fL
http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
From brettz9 at yahoo.com Wed Mar 10 17:58:09 2010
From: brettz9 at yahoo.com (Brett Zamir)
Date: Thu, 11 Mar 2010 09:58:09 +0800
Subject: [whatwg] URN or protocol attribute
In-Reply-To:
References: <4B6FCA82.3050508@yahoo.com>
<4B72668C.9070706@degeneration.co.uk> <4B73AD79.5030701@yahoo.com>
Message-ID: <4B984E31.9020407@yahoo.com>
On 3/11/2010 9:19 AM, Ian Hickson wrote:
> On Mon, 8 Feb 2010, Brett Zamir wrote:
>
>> Internet Explorer has an attribute on anchor elements for URNs:
>> http://msdn.microsoft.com/en-us/library/ms534710%28VS.85%29.aspx
>>
>> This has not caught on in other browsers, though I believe it could be a very
>> powerful feature once the feature was supported with a UI that handled URNs
>> (as with adding support for custom protocols).
>>
>> Imagine, for example, to take a link like:
>>
>> > urn="isbn:9210020251">United Nations charter
>>
>> The default behavior would simply follow the link, but if a user agent
>> supported the @urn attribute, and if the browser (or browser add-ons)
>> had registered support for that URN namespace identifier (here "isbn"),
>> it could, for example, open a dialog to ask which handler to use (or
>> whether to always use it), it could ask or otherwise allow in
>> preferences an HTML page (with wildcards) where the attribute's content
>> could be passed, or it could give the option whenever the user
>> right-clicked to choose which handler they wanted to use for a given
>> link.
>>
> Does this match IE's behaviour with the urn="" attribute?
>
>
No, to my knowledge, there is no special behavior in IE with regard to
how it is used. I was really more listing it as a precedent, since I was
more in favor of a more general purpose "defaultProtocol" attribute
which could not only allow URNs but other protocols to be tried before
defaulting to a regular "href" link.
> Historically, browsers that have wanted to offer dedicated services for
> specific features, e.g. the iPhone handling map views using a dedicated
> Maps application, have done so by simply overriding parts of the URL
> space, e.g. in that case detecting when a page is on the Google Maps site
> and parsing the URL locally instead of sending it to the remote site.
>
>
The problem with this is that it is not an approach which can likely be
taken by browser extensions nor be offered to websites which wish to
register themselves as handlers. And URNs by definition are not specific
to any site.
> Is there really a need for a more dedicated mechanism? It's not clear that
> there is much pent-up demand for this.
>
There wasn't a lot of pent up demand for the web itself either ("why
would people or companies want to link to other people's sites?"); if
people aren't able to use a feature or know of the concept, they might
not think of asking for it. I think that as with my earlier suggestion
on shared databases or storage, I think people are just not accustomed
to thinking that the web can be used in a way which collaborates between
sites (more than mere links), since the first idea that pops into
people's minds is how they can put their own site up. That doesn't mean
they wouldn't like to work with other sites or offer a feature that
would have normal fallback behavior in browsers that didn't support it.
If people can see a need for registering protocol handlers, the
"defaultProtocol" attribute is I think the best way to make it work.
Why would someone want to experiment in using a protocol (including
urn:), say ISBN:, if the interface will only say to their users, "This
browser does not recognize that protocol/namespace ID". The
defaultProtocol attribute would give a chance for the protocol/URN NID
to be checked for support, but if not working could default to visiting
the "href" target. Wouldn't that be a useful feature? Few will
experiment with ... as it is just a dead link
for browsers that don't support the protocol, but I'm sure many sites
would be willing to allow ... as it doesn't hurt to add one extra
attribute, even if say browsers are slow at supporting the attribute.
The web is not only about companies that want to make money and shuffle
people in the direction they want. There are also sites (including
companies without a stake in certain content) who want to offer more
choice to their users (e.g., Wikipedia, governments, individuals, etc.).
And no doubt any company wouldn't mind being able to register themselves
in a way where they could offer themselves to users visiting those more
neutral sites (e.g., Amazon registering itself for links leading to ISBN
links at other sites). It simply offers more choice to users...
Brett
From ian at hixie.ch Wed Mar 10 18:31:13 2010
From: ian at hixie.ch (Ian Hickson)
Date: Thu, 11 Mar 2010 02:31:13 +0000 (UTC)
Subject: [whatwg] URN or protocol attribute
In-Reply-To: <4B984E31.9020407@yahoo.com>
References: <4B6FCA82.3050508@yahoo.com> <4B72668C.9070706@degeneration.co.uk>
<4B73AD79.5030701@yahoo.com>
<4B984E31.9020407@yahoo.com>
Message-ID:
On Thu, 11 Mar 2010, Brett Zamir wrote:
> >
> > Is there really a need for a more dedicated mechanism? It's not clear
> > that there is much pent-up demand for this.
>
> There wasn't a lot of pent up demand for the web itself either ("why
> would people or companies want to link to other people's sites?"); if
> people aren't able to use a feature or know of the concept, they might
> not think of asking for it.
That's true, but we only have so many resources, so we have to prioritise.
Things that have pent-up demand are typically more important. :-)
I would recommend following a pattern somewhat like the Web's initial
development: create a proof of concept, and convince people that it's what
they want. That's the best way to get a feature adopted. This is described
in more detail in the FAQ:
http://wiki.whatwg.org/wiki/FAQ#Is_there_a_process_for_adding_new_features_to_a_specification.3F
--
Ian Hickson U+1047E )\._.,--....,'``. fL
http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
From ian at hixie.ch Wed Mar 10 18:40:01 2010
From: ian at hixie.ch (Ian Hickson)
Date: Thu, 11 Mar 2010 02:40:01 +0000 (UTC)
Subject: [whatwg] <% text %> and in corporate intranet html
content
In-Reply-To:
References: <4a27dd81002091905sb91d56dy96135f64e3a085d2@mail.gmail.com>
<4a27dd81002150045y4f353ac0w9ddbce909accc40a@mail.gmail.com>
Message-ID:
On Thu, 11 Feb 2010, Biju wrote:
> On Wed, Feb 10, 2010 at 10:40 PM, Ian Hickson wrote:
> >> At least in one page I saw, which was Case 1 and page was originally
> >> from a JSP or ASP template later modified and saved as a *.html
> >
> > I recommend fixing the page. :-)
>
> Hey, this is corporate intranet page, there is no way to fix it unless
> you show them broken in IE6
> it would have been remotely possible if Safari and Chrome also followed Firefox
I do not understand what you mean here.
What I mean by "fixing the page" is editing the markup to not have these
invalid constructs.
> >> So will IE and Safari (may be chrome also, i have not tested it)
> >> follow Firefox way?
> >
> > Hard to say. You'd have to ask Microsoft.
>
> What about Apple and Google, as at least Safari/Chrome/Webkit developers
> are active participant on this list.
I have heard WebKit developers indicate an intent to implement the HTML5
parsing rules in due course.
On Mon, 15 Feb 2010, Biju wrote:
>
> Why cant we consider <% some text %> and as
> pre-processor command node in HTML DOM.
We could, there just doesn't seem to be a great benefit to it. It's never
been allowed, so why should we support it? There aren't many pages that
use this kind of markup, and they already don't work in all browsers.
> Also as a user I feel why cant Firefox, Safari, Opera, Chrome agree to
> behave same.
In due course they will. It takes time to fix bugs, especially in areas as
complicated as the HTML parser.
--
Ian Hickson U+1047E )\._.,--....,'``. fL
http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
From brettz9 at yahoo.com Wed Mar 10 18:44:07 2010
From: brettz9 at yahoo.com (Brett Zamir)
Date: Thu, 11 Mar 2010 10:44:07 +0800
Subject: [whatwg] URN or protocol attribute
In-Reply-To:
References: <4B6FCA82.3050508@yahoo.com>
<4B72668C.9070706@degeneration.co.uk> <4B73AD79.5030701@yahoo.com> <4B984E31.9020407@yahoo.com>
Message-ID: <4B9858F7.9070303@yahoo.com>
On 3/11/2010 10:31 AM, Ian Hickson wrote:
> On Thu, 11 Mar 2010, Brett Zamir wrote:
>
>>> Is there really a need for a more dedicated mechanism? It's not clear
>>> that there is much pent-up demand for this.
>>>
>> There wasn't a lot of pent up demand for the web itself either ("why
>> would people or companies want to link to other people's sites?"); if
>> people aren't able to use a feature or know of the concept, they might
>> not think of asking for it.
>>
> That's true, but we only have so many resources, so we have to prioritise.
> Things that have pent-up demand are typically more important. :-)
>
> I would recommend following a pattern somewhat like the Web's initial
> development: create a proof of concept, and convince people that it's what
> they want. That's the best way to get a feature adopted. This is described
> in more detail in the FAQ:
>
> http://wiki.whatwg.org/wiki/FAQ#Is_there_a_process_for_adding_new_features_to_a_specification.3F
>
Ok, fair enough. I think I'll try that as a browser extension, as well
as possibly the other idea of a shared database API which I think has
the potential to become an even more powerful feature (e.g., a local
calendar to which any site could offer to add events and be viewed on
the web or in a browser extension)... But there still may be some things
(like an official auxiliary world language!) which can only show their
real benefits (and potential demand) when implemented across the board...
Brett
From ian at hixie.ch Wed Mar 10 18:44:36 2010
From: ian at hixie.ch (Ian Hickson)
Date: Thu, 11 Mar 2010 02:44:36 +0000 (UTC)
Subject: [whatwg] prompts,
alerts and showModalDialog during beforeunload/unload events
In-Reply-To: <78dc8441002111825t8e0aadi18d5bf7368908f0b@mail.gmail.com>
References: <78dc8441002111825t8e0aadi18d5bf7368908f0b@mail.gmail.com>
Message-ID:
On Thu, 11 Feb 2010, Ojan Vafai wrote:
>
> Currently, modal dialogs that fire during beforeunload/unload events are
> used to confuse users into not being able to leave websites (e.g. to
> tell the user to click on the wrong button for in the browser's
> beforeunload alert dialog). They also add a layer of complexity to
> browser shutdown behavior. I can't think of any legitimate use-case for
> opening a modal dialog when a user is trying to navigate away from a
> page.
>
> Proposal: Opening a modal dialog during beforeunload/unload should
> either throw an error or just silently fail.
I haven't made a change to the spec here. I do believe, however, that it
would be perfectly reasonable for a user agent to offer the user the
choice to stop supporting JavaScript from any modal prompt. Other possible
ways of handling this are to make the alerts tab-modal only, and to still
allow navigation using the UI (location bar) while one of these "modal"
dialogs is up, and simply aborting all running scripts when that is done.
Basically, I think this is a UA UI issue, and out of scope for the spec.
--
Ian Hickson U+1047E )\._.,--....,'``. fL
http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
From mjs at apple.com Thu Mar 11 00:38:16 2010
From: mjs at apple.com (Maciej Stachowiak)
Date: Thu, 11 Mar 2010 00:38:16 -0800
Subject: [whatwg] XSS safe templating
In-Reply-To: <4B97DC43.3070203@mit.edu>
References: <270790479.35969.1268231464701.JavaMail.root@cm-mail03.mozilla.org>
<213441389.35988.1268231892352.JavaMail.root@cm-mail03.mozilla.org>
<178b8d441003100945o1f4fb0c0qc61655cc7d1de8e8@mail.gmail.com>
<4B97DC43.3070203@mit.edu>
Message-ID:
On Mar 10, 2010, at 9:52 AM, Boris Zbarsky wrote:
> On 3/10/10 12:45 PM, Mike Samuel wrote:
>>> FWIW, in Gecko currently, the stringification happens a few
>>> abstraction layers away from the parser, so implementing your
>>> suggestion would involve punching holes in those abstractions.
>>
>> Ah, so there's a layer that sits between the XPCOM object and the JS
>> Host object that knows a DOMString is expected, and does the JS foo
>> necessary to convert to a string?
>
> That's correct. The C++ object just implements a method as declared
> in the DOM IDL; there is a glue layer responsible for coercing the
> arguments actually given to the types declared in the IDL. This
> isn't just the case in Gecko; Webkit+JSC has similar behavior.
Correct, the type coercion is autogenerated code based on IDL.
> I'd assume that Webkit+V8 does as well, though I haven't looked at
> the code.
V8's DOM bindings are autogenerated from the same IDL and in roughly
the same way as the ones for JavaScriptCore, so yes.
Regards,
Maciej
From mjs at apple.com Thu Mar 11 00:50:11 2010
From: mjs at apple.com (Maciej Stachowiak)
Date: Thu, 11 Mar 2010 00:50:11 -0800
Subject: [whatwg] XSS safe templating
In-Reply-To: <178b8d441003101015y71f67bfem31e837fc1143f064@mail.gmail.com>
References: <270790479.35969.1268231464701.JavaMail.root@cm-mail03.mozilla.org>
<213441389.35988.1268231892352.JavaMail.root@cm-mail03.mozilla.org>
<178b8d441003100945o1f4fb0c0qc61655cc7d1de8e8@mail.gmail.com>
<4B97DC43.3070203@mit.edu>
<178b8d441003101015y71f67bfem31e837fc1143f064@mail.gmail.com>
Message-ID: <7B551FE2-8AE9-49F2-916C-7FFFF334BF67@apple.com>
On Mar 10, 2010, at 10:15 AM, Mike Samuel wrote:
> Hmm. It occurs to me that many libraries -- at least jQuery and
> prototype have their own layers in between their users and the DOM.
> When I cooked up this scheme, I didn't know how likely proxies and
> ephemeron tables were to make it into ES Harmony, but I think Andreas
> Gal just implemented (both? or just ephemerons) in a tracemonkey
> nightly. Those are all you need to do a really efficient
> interposition layer, so libraries are probably not going to stop doing
> that.
> So I think the non-document.write portion can be implemented entirely
> in the library interposition layer.
>
> document.write can be wrapped. But the wrapper would still need to
> know the insertion-mode.
> If the insertion mode were exposed, or at least some context were
> given -- enough to know whether the next char if not something that
> changed the current token, would be interpreted as
> * inside a tag
> * outside a tag in a comment / application instruction / doctype
> * outside a tag in a PCDATA/RCDATA/CDATA context and ideally in what
> kind of containing tag
> * outside a tag in a CDATA section.
>
> So maybe some kind of
> (DOMString|null) document.getInsertionMode().
Thoughts:
1) I'm not enthusiastic about exposing internal details of the HTML
parser to script.
2) Given the way document.write works, the information you ask for may
not even be available at the time of the document.write call. There
may be considerable other parsing and/or script execution to do before
the parser reaches the insertion point. Consider the following example:
At the time of the second document.write, the *current* insertion mode
is outside a tag in normal text content, but it's impossible to tell
what it will be by the time untrustedString actually gets parsed. (In
case it's not clear why: untrustedString is inserted into the
character stream after the
>
Ah, thanks for the excellent example.
> At the time of the second document.write, the *current* insertion mode is
> outside a tag in normal text content, but it's impossible to tell what it
> will be by the time untrustedString actually gets parsed. (In case it's not
> clear why: untrustedString is inserted into the character stream after the
>
]]> ?> !> \"> ");
and just abort if that ends up introducing a plaintext element onto
the document.
> --
> Henri Sivonen
> hsivonen at iki.fi
> http://hsivonen.iki.fi/
>
>
>
From levin at google.com Fri Mar 12 11:57:26 2010
From: levin at google.com (David Levin)
Date: Fri, 12 Mar 2010 11:57:26 -0800
Subject: [whatwg] Offscreen canvas (or canvas for web workers).
In-Reply-To:
References:
<5dd9e5c51002230740t16ad9dc2p2677081a7e62e0f5@mail.gmail.com>
<1F24538C-4F1C-456D-B2FB-AD0433F88A7C@apple.com>
<63df84f1002232204h221214cbse78623bc82cfc5c5@mail.gmail.com>
<506F5F67-F236-4995-8583-62FA9AB8861F@apple.com>
<63df84f1002240135g804e08bw5b3f706b1296aab9@mail.gmail.com>
<8E782679-17C2-400B-A781-93447617B2FD@apple.com>
<3128e0551002240745x15ad69eaq243943aefad921ad@mail.gmail.com>
Message-ID:
On Mon, Feb 22, 2010 at 11:57 AM, Drew Wilson wrote:
> Do we feel that text APIs are, in general, difficult to implement in a
> multi-thread safe manner?
>
On Mon, Feb 22, 2010 at 11:51 AM, Michael Nordman
wrote:
> The lack of support for text drawing in the worker context seems like a
> short sighted mistake.
>
On Mon, Feb 22, 2010 at 2:35 PM, Jeremy Orlow wrote:
> It does indeed seem pretty short sighted.
On Mon, Feb 22, 2010 at 2:48 PM, Maciej Stachowiak wrote:
> 1) Like others, I would recommend not omitting the text APIs. I can see why
> they are a bit trickier to implement than the others, but I don't see a
> fundamental barrier.
>
I did want to add the text apis but it does add implementation difficulties
for WebKit (and as I understand Firefox). However, they are part of what
people want and it does simplify the interfaces, so done.
On Mon, Feb 22, 2010 at 2:48 PM, Maciej Stachowiak wrote:
> 2) I would propose adding createPattern and drawImage overloads that take
> an OffscreenCanvas. The other overloads would in practice not be usefully
> callable in the worker case since you couldn't get an image, canvas or video
> element.
>
> 3) This would leave the only difference between the two interfaces as the
> drawFocusRing method. This would not be usefully callable in a worker, since
> there would be no way to get an Element. But it doesn't seem worth it to add
> an interface just for one method's worth of difference.
>
Sounds good.
On Mon, Feb 22, 2010 at 3:10 PM, Jonas Sicking wrote:
> What is the use case for this? It seems like in most cases you'll want
> to display something on screen to the user, and so the difference
> comes down to shipping drawing commands across the pipe, vs. shipping
> the pixel data.
Apologies for not including this at the start. As now mentioned in several
places in the thread, the simplest use case is resize/rotate of images.
However, more complex use cases may involve heavy users of canvas who would
like to either prerender the canvas and/or move the time taken to generate
the canvas off of the main thread. While it is true that simple uses of
canvas would not get a performance win out of this, if you are doing many
canvas operations, (like many complex operations) it is faster to copy a
result than it is to generate it.
Ideally canvas will get some form of toBlob which will allow the image to be
appropriately compressed as well which will also reduce the number of bits
that need to be copied from the worker to the main thread (as well as make
for a smaller upload than the raw bits).
Lastly, in the future, one can see other uses for the OffscreenCanvas
including WebGL for workers which several folks (Maciej and Jonas) have
expressed interest about on this thread.
dave
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From levin at google.com Fri Mar 12 12:00:53 2010
From: levin at google.com (David Levin)
Date: Fri, 12 Mar 2010 12:00:53 -0800
Subject: [whatwg] feedback
In-Reply-To:
References: <17fcfe911003030508t39f74dfdyb5566b5ba15f7b49@mail.gmail.com>
<17fcfe911003030744g20f68311u5c506b9f1e84408b@mail.gmail.com>
Message-ID:
On Thu, Mar 11, 2010 at 9:16 PM, Ian Hickson wrote:
>
>
> On Mon, 22 Feb 2010, David Levin wrote:
> >
> > I've talked with some other folks on WebKit (Maciej and Oliver) about
> > having a canvas that is available to workers. They suggested some nice
> > modifications to make it an offscreen canvas, which may be used in the
> > Document or in a Worker.
>
> What are the use cases?
>
The simplest is resize/rotate for large images.
However there are more advanced uses in which the page heavily uses canvas.
Since there are many canvas operations, they take a noticeable amount of
time, and it would be better than they are done on a different thread than
the main one.
Another use related use case is when a page needs to render multiple
canvases and each one is involved. (One could think of some sort of
animation.) It would also be nice if they could do multiple operations in
parallel (using multiple workers for instance.)
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From jonas at sicking.cc Fri Mar 12 12:16:55 2010
From: jonas at sicking.cc (Jonas Sicking)
Date: Fri, 12 Mar 2010 12:16:55 -0800
Subject: [whatwg] Offscreen canvas (or canvas for web workers).
In-Reply-To:
References:
<1F24538C-4F1C-456D-B2FB-AD0433F88A7C@apple.com>
<63df84f1002232204h221214cbse78623bc82cfc5c5@mail.gmail.com>
<506F5F67-F236-4995-8583-62FA9AB8861F@apple.com>
<63df84f1002240135g804e08bw5b3f706b1296aab9@mail.gmail.com>
<8E782679-17C2-400B-A781-93447617B2FD@apple.com>
<3128e0551002240745x15ad69eaq243943aefad921ad@mail.gmail.com>
Message-ID: <63df84f1003121216n72eb60edqa66dfd2e660d55a2@mail.gmail.com>
On Fri, Mar 12, 2010 at 11:57 AM, David Levin wrote:
> On Mon, Feb 22, 2010 at 3:10 PM, Jonas Sicking??wrote:
>>
>> What is the use case for this? It seems like in most cases you'll want
>> to display something on screen to the user, and so the difference
>> comes down to shipping drawing commands across the pipe, vs. shipping
>> the pixel data.
>
> Apologies?for not including this at the start.?As now mentioned in several
> places in the thread, the simplest use case is resize/rotate of images.
As Hixie pointed out, resize/rotate images do not seem solved by this
API. In order to resize an image with this API you need to:
1. Load the image into an
3. Extract an ImageData from the
4. Send the ImageData to the worker thread
5. Import the ImageData into the worker thread canvas
6. Resize/rotate the image using the worker thread canvas
7. Extract an ImageData from the worker thread canvas
8. Send the ImageData to the main thread
9. Import the ImageData into a main thread
And if you want to send the resized image to the server:
10. Extract the data in a serialized format from the
11. Send using XHR.
Just looking at just the work happening on the main thread it sounds
like just resizing/rotating on the main thread is faster. Not to
mention much less complex.
I'm not saying that the proposed API is bad. It just doesn't seem to
solve the (seemingly most commonly requested) use case of
rotating/scaling images. So if we want to solve those use cases we
need to either come up with a separate API for that, or extend this
proposal to solve that use case somehow.
/ Jonas
From levin at google.com Fri Mar 12 12:41:36 2010
From: levin at google.com (David Levin)
Date: Fri, 12 Mar 2010 12:41:36 -0800
Subject: [whatwg] Offscreen canvas (or canvas for web workers).
In-Reply-To: <63df84f1003121216n72eb60edqa66dfd2e660d55a2@mail.gmail.com>
References:
<63df84f1002232204h221214cbse78623bc82cfc5c5@mail.gmail.com>
<506F5F67-F236-4995-8583-62FA9AB8861F@apple.com>
<63df84f1002240135g804e08bw5b3f706b1296aab9@mail.gmail.com>
<8E782679-17C2-400B-A781-93447617B2FD@apple.com>
<3128e0551002240745x15ad69eaq243943aefad921ad@mail.gmail.com>
<63df84f1003121216n72eb60edqa66dfd2e660d55a2@mail.gmail.com>
Message-ID:
On Fri, Mar 12, 2010 at 12:16 PM, Jonas Sicking wrote:
> On Fri, Mar 12, 2010 at 11:57 AM, David Levin wrote:
> > On Mon, Feb 22, 2010 at 3:10 PM, Jonas Sicking wrote:
> >>
> >> What is the use case for this? It seems like in most cases you'll want
> >> to display something on screen to the user, and so the difference
> >> comes down to shipping drawing commands across the pipe, vs. shipping
> >> the pixel data.
> >
> > Apologies for not including this at the start. As now mentioned in
> several
> > places in the thread, the simplest use case is resize/rotate of images.
>
> As Hixie pointed out, resize/rotate images do not seem solved by this
> API. In order to resize an image with this API you need to:
>
> 1. Load the image into an
> 3. Extract an ImageData from the
> 4. Send the ImageData to the worker thread
> 5. Import the ImageData into the worker thread canvas
> 6. Resize/rotate the image using the worker thread canvas
> 7. Extract an ImageData from the worker thread canvas
> 8. Send the ImageData to the main thread
> 9. Import the ImageData into a main thread
>
> And if you want to send the resized image to the server:
>
> 10. Extract the data in a serialized format from the
> 11. Send using XHR.
>
> Just looking at just the work happening on the main thread it sounds
> like just resizing/rotating on the main thread is faster. Not to
> mention much less complex.
>
> I'm not saying that the proposed API is bad. It just doesn't seem to
> solve the (seemingly most commonly requested) use case of
> rotating/scaling images. So if we want to solve those use cases we
> need to either come up with a separate API for that, or extend this
> proposal to solve that use case somehow.
>
If fromBlob and toBlob were on canvas, it gets rid of steps 1-3 and changes
step 4 to be send file to worker thread. I simply didn't include
fromBlob/toBlob because toBlob was already being discussed in another
thread. I thought it best to let that topic get discussed in parallel, but
it is part of this whole thing, so I am interested in that happening (and
discussing those apis further).
So it looks like this:
1. Send the File to the worker thread
2. Import the File/blob into the worker thread canvas
3. Resize/rotate the image using the worker thread canvas (to thumbnail for
instance)
4. Extract a blob from the worker thread canvas
Either
5. Send the blob using XHR in the worker.
or
5. Send the Blob to the main thread
6. Import the Blob into a main thread
(or both).
Given the blob support this would be overall a better user experience
because the loading of the image is done in the worker as well as the resize
to a much smaller size, so the i/o happening on the main thread is much
lower overall.
dave
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From oliver at apple.com Fri Mar 12 12:46:59 2010
From: oliver at apple.com (Oliver Hunt)
Date: Fri, 12 Mar 2010 12:46:59 -0800
Subject: [whatwg] Offscreen canvas (or canvas for web workers).
In-Reply-To: <63df84f1003121216n72eb60edqa66dfd2e660d55a2@mail.gmail.com>
References:
<1F24538C-4F1C-456D-B2FB-AD0433F88A7C@apple.com>
<63df84f1002232204h221214cbse78623bc82cfc5c5@mail.gmail.com>
<506F5F67-F236-4995-8583-62FA9AB8861F@apple.com>
<63df84f1002240135g804e08bw5b3f706b1296aab9@mail.gmail.com>
<8E782679-17C2-400B-A781-93447617B2FD@apple.com>
<3128e0551002240745x15ad69eaq243943aefad921ad@mail.gmail.com>
<63df84f1003121216n72eb60edqa66dfd2e660d55a2@mail.gmail.com>
Message-ID: <2FD4CE21-5A0C-48A0-A632-F73D9220F9F9@apple.com>
On Mar 12, 2010, at 12:16 PM, Jonas Sicking wrote:
> I'm not saying that the proposed API is bad. It just doesn't seem to
> solve the (seemingly most commonly requested) use case of
> rotating/scaling images. So if we want to solve those use cases we
> need to either come up with a separate API for that, or extend this
> proposal to solve that use case somehow.
Just for reference I think one thing that people are forgetting that there is a difference between
being computationally faster, and being more responsive.
If we imagine a scenario you're doing something that takes 100ms/frame, and it takes 10ms to
post the data between the main thread and a worker.
I _could_ do this all on the main thread in which case i have a fixed cost of a 100ms/frame, but
if I offload the processing to a worker my processing time per frame is now 120ms/frame.
The initial thought may be "ick slower" but the page is actually much more responsive -- when
processing on the main thread the main thread is blocked for 100ms at a time, whereas
processing on a worker means the main thread is not blocked for more than 10ms. That's the
difference between being able to scroll in realtime vs. 10fps.
That also ignores the possibility of splitting the processing among multiple workers, once again
the total cpu time may increase, but the wall clock time can decrease dramatically.
> / Jonas
--Oliver
From jonas at sicking.cc Fri Mar 12 14:35:17 2010
From: jonas at sicking.cc (Jonas Sicking)
Date: Fri, 12 Mar 2010 14:35:17 -0800
Subject: [whatwg] Offscreen canvas (or canvas for web workers).
In-Reply-To: <2FD4CE21-5A0C-48A0-A632-F73D9220F9F9@apple.com>
References:
<506F5F67-F236-4995-8583-62FA9AB8861F@apple.com>
<63df84f1002240135g804e08bw5b3f706b1296aab9@mail.gmail.com>
<8E782679-17C2-400B-A781-93447617B2FD@apple.com>
<3128e0551002240745x15ad69eaq243943aefad921ad@mail.gmail.com>
<63df84f1003121216n72eb60edqa66dfd2e660d55a2@mail.gmail.com>
<2FD4CE21-5A0C-48A0-A632-F73D9220F9F9@apple.com>
Message-ID: <63df84f1003121435t72a64756q87822b1c7abf3db0@mail.gmail.com>
On Fri, Mar 12, 2010 at 12:46 PM, Oliver Hunt wrote:
>
> On Mar 12, 2010, at 12:16 PM, Jonas Sicking wrote:
>> I'm not saying that the proposed API is bad. It just doesn't seem to
>> solve the (seemingly most commonly requested) use case of
>> rotating/scaling images. So if we want to solve those use cases we
>> need to either come up with a separate API for that, or extend this
>> proposal to solve that use case somehow.
>
> Just for reference I think one thing that people are forgetting that there is a difference between
> being computationally faster, and being more responsive.
As I mentioned in my email, if you look at the steps listed, enough of
them happen *on the main thread* that you're spending far more of the
main threads CPU cycles than you'd like. Possibly even more than doing
all the resizing on the main thread.
With the other improvements suggested by David things do definitely
look different, but those are not in a proposal yet.
/ Jonas
From levin at google.com Fri Mar 12 15:38:38 2010
From: levin at google.com (David Levin)
Date: Fri, 12 Mar 2010 15:38:38 -0800
Subject: [whatwg] Offscreen canvas (or canvas for web workers).
In-Reply-To: <63df84f1003121435t72a64756q87822b1c7abf3db0@mail.gmail.com>
References:
<506F5F67-F236-4995-8583-62FA9AB8861F@apple.com>
<63df84f1002240135g804e08bw5b3f706b1296aab9@mail.gmail.com>
<8E782679-17C2-400B-A781-93447617B2FD@apple.com>
<3128e0551002240745x15ad69eaq243943aefad921ad@mail.gmail.com>
<63df84f1003121216n72eb60edqa66dfd2e660d55a2@mail.gmail.com>
<2FD4CE21-5A0C-48A0-A632-F73D9220F9F9@apple.com>
<63df84f1003121435t72a64756q87822b1c7abf3db0@mail.gmail.com>
Message-ID:
On Fri, Mar 12, 2010 at 2:35 PM, Jonas Sicking wrote:
> On Fri, Mar 12, 2010 at 12:46 PM, Oliver Hunt wrote:
> >
> > On Mar 12, 2010, at 12:16 PM, Jonas Sicking wrote:
> >> I'm not saying that the proposed API is bad. It just doesn't seem to
> >> solve the (seemingly most commonly requested) use case of
> >> rotating/scaling images. So if we want to solve those use cases we
> >> need to either come up with a separate API for that, or extend this
> >> proposal to solve that use case somehow.
> >
> > Just for reference I think one thing that people are forgetting that
> there is a difference between
> > being computationally faster, and being more responsive.
>
> As I mentioned in my email, if you look at the steps listed, enough of
> them happen *on the main thread* that you're spending far more of the
> main threads CPU cycles than you'd like. Possibly even more than doing
> all the resizing on the main thread.
>
> With the other improvements suggested by David things do definitely
> look different, but those are not in a proposal yet.
>
There is the other scenario I mentioned, but I'll see what I can do about
separately working up a proposal for adding those methods because they were
next on my list to deal with. (fromBlob/load may be enough for this.)
dave
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From jonas at sicking.cc Fri Mar 12 16:19:55 2010
From: jonas at sicking.cc (Jonas Sicking)
Date: Fri, 12 Mar 2010 16:19:55 -0800
Subject: [whatwg] Offscreen canvas (or canvas for web workers).
In-Reply-To:
References:
<63df84f1002240135g804e08bw5b3f706b1296aab9@mail.gmail.com>
<8E782679-17C2-400B-A781-93447617B2FD@apple.com>
<3128e0551002240745x15ad69eaq243943aefad921ad@mail.gmail.com>
<63df84f1003121216n72eb60edqa66dfd2e660d55a2@mail.gmail.com>
<2FD4CE21-5A0C-48A0-A632-F73D9220F9F9@apple.com>
<63df84f1003121435t72a64756q87822b1c7abf3db0@mail.gmail.com>
Message-ID: <63df84f1003121619k4f33da4bl4a060aa20a722ddf@mail.gmail.com>
On Fri, Mar 12, 2010 at 3:38 PM, David Levin wrote:
>
>
> On Fri, Mar 12, 2010 at 2:35 PM, Jonas Sicking wrote:
>>
>> On Fri, Mar 12, 2010 at 12:46 PM, Oliver Hunt wrote:
>> >
>> > On Mar 12, 2010, at 12:16 PM, Jonas Sicking wrote:
>> >> I'm not saying that the proposed API is bad. It just doesn't seem to
>> >> solve the (seemingly most commonly requested) use case of
>> >> rotating/scaling images. So if we want to solve those use cases we
>> >> need to either come up with a separate API for that, or extend this
>> >> proposal to solve that use case somehow.
>> >
>> > Just for reference I think one thing that people are forgetting that
>> > there is a difference between
>> > being computationally faster, and being more responsive.
>>
>> As I mentioned in my email, if you look at the steps listed, enough of
>> them happen *on the main thread* that you're spending far more of the
>> main threads CPU cycles than you'd like. Possibly even more than doing
>> all the resizing on the main thread.
>>
>> With the other improvements suggested by David things do definitely
>> look different, but those are not in a proposal yet.
>
> There is the other scenario I mentioned, but?I'll see what I can do about
> separately working up a proposal for adding those methods because they were
> next on my list to deal with. (fromBlob/load may be enough for this.)
Note that the other proposals that have been made has put toBlob on
HTMLCanvasElement, not on the context. That makes the most sense for
the main-thread canvas as that way its available on all contexts.
/ Jonas
From mjs at apple.com Fri Mar 12 17:25:11 2010
From: mjs at apple.com (Maciej Stachowiak)
Date: Fri, 12 Mar 2010 17:25:11 -0800
Subject: [whatwg] Offscreen canvas (or canvas for web workers).
In-Reply-To: <63df84f1003121435t72a64756q87822b1c7abf3db0@mail.gmail.com>
References:
<506F5F67-F236-4995-8583-62FA9AB8861F@apple.com>
<63df84f1002240135g804e08bw5b3f706b1296aab9@mail.gmail.com>
<8E782679-17C2-400B-A781-93447617B2FD@apple.com>
<3128e0551002240745x15ad69eaq243943aefad921ad@mail.gmail.com>
<63df84f1003121216n72eb60edqa66dfd2e660d55a2@mail.gmail.com>
<2FD4CE21-5A0C-48A0-A632-F73D9220F9F9@apple.com>
<63df84f1003121435t72a64756q87822b1c7abf3db0@mail.gmail.com>
Message-ID: <71A64C40-E5BE-4FB6-B962-DF90CABBD034@apple.com>
On Mar 12, 2010, at 2:35 PM, Jonas Sicking wrote:
> On Fri, Mar 12, 2010 at 12:46 PM, Oliver Hunt
> wrote:
>>
>> On Mar 12, 2010, at 12:16 PM, Jonas Sicking wrote:
>>> I'm not saying that the proposed API is bad. It just doesn't seem to
>>> solve the (seemingly most commonly requested) use case of
>>> rotating/scaling images. So if we want to solve those use cases we
>>> need to either come up with a separate API for that, or extend this
>>> proposal to solve that use case somehow.
>>
>> Just for reference I think one thing that people are forgetting
>> that there is a difference between
>> being computationally faster, and being more responsive.
>
> As I mentioned in my email, if you look at the steps listed, enough of
> them happen *on the main thread* that you're spending far more of the
> main threads CPU cycles than you'd like. Possibly even more than doing
> all the resizing on the main thread.
>
> With the other improvements suggested by David things do definitely
> look different, but those are not in a proposal yet.
In general a copy is a fair bit faster than an image rotate or resize,
though I don't know if it is faster enough for reasonable image sizes
to matter.
Regards,
Maciej
From jonas at sicking.cc Fri Mar 12 18:20:52 2010
From: jonas at sicking.cc (Jonas Sicking)
Date: Fri, 12 Mar 2010 18:20:52 -0800
Subject: [whatwg] Offscreen canvas (or canvas for web workers).
In-Reply-To: <63df84f1003121619k4f33da4bl4a060aa20a722ddf@mail.gmail.com>
References:
<8E782679-17C2-400B-A781-93447617B2FD@apple.com>
<3128e0551002240745x15ad69eaq243943aefad921ad@mail.gmail.com>
<63df84f1003121216n72eb60edqa66dfd2e660d55a2@mail.gmail.com>
<2FD4CE21-5A0C-48A0-A632-F73D9220F9F9@apple.com>
<63df84f1003121435t72a64756q87822b1c7abf3db0@mail.gmail.com>
<63df84f1003121619k4f33da4bl4a060aa20a722ddf@mail.gmail.com>
Message-ID: <63df84f1003121820o43017e1bpef8ed23cfa1c664a@mail.gmail.com>
On Fri, Mar 12, 2010 at 4:19 PM, Jonas Sicking wrote:
> On Fri, Mar 12, 2010 at 3:38 PM, David Levin wrote:
>>
>>
>> On Fri, Mar 12, 2010 at 2:35 PM, Jonas Sicking wrote:
>>>
>>> On Fri, Mar 12, 2010 at 12:46 PM, Oliver Hunt wrote:
>>> >
>>> > On Mar 12, 2010, at 12:16 PM, Jonas Sicking wrote:
>>> >> I'm not saying that the proposed API is bad. It just doesn't seem to
>>> >> solve the (seemingly most commonly requested) use case of
>>> >> rotating/scaling images. So if we want to solve those use cases we
>>> >> need to either come up with a separate API for that, or extend this
>>> >> proposal to solve that use case somehow.
>>> >
>>> > Just for reference I think one thing that people are forgetting that
>>> > there is a difference between
>>> > being computationally faster, and being more responsive.
>>>
>>> As I mentioned in my email, if you look at the steps listed, enough of
>>> them happen *on the main thread* that you're spending far more of the
>>> main threads CPU cycles than you'd like. Possibly even more than doing
>>> all the resizing on the main thread.
>>>
>>> With the other improvements suggested by David things do definitely
>>> look different, but those are not in a proposal yet.
>>
>> There is the other scenario I mentioned, but?I'll see what I can do about
>> separately working up a proposal for adding those methods because they were
>> next on my list to deal with. (fromBlob/load may be enough for this.)
>
> Note that the other proposals that have been made has put toBlob on
> HTMLCanvasElement, not on the context. That makes the most sense for
> the main-thread canvas as that way its available on all contexts.
Oh, another thing to keep in mind is that if/when we add fromBlob to
the main-thread canvas, it has to be asynchronous in order to avoid
main thread synchronous IO. This isn't a big deal, but I figured I
should mention it while we're on the subject.
In general I wonder if we should add API to convert directly between
Blob and ImageData. Or at least Blob->ImageData and
ImageData->ByteArray. That could avoid overhead of going through a
canvas context. That is probably a win no matter which thread we are
on.
We could even add APIs to rotate and scale ImageData objects directly.
If those are asynchronous the implementation could easily implement
them using a background thread. I'm less sure that this is worth it
though given that you can implement this yourself using workers if we
add the other stuff we've talked about.
/ Jonas
From mjs at apple.com Fri Mar 12 22:07:15 2010
From: mjs at apple.com (Maciej Stachowiak)
Date: Fri, 12 Mar 2010 22:07:15 -0800
Subject: [whatwg] Offscreen canvas (or canvas for web workers).
In-Reply-To: <63df84f1003121820o43017e1bpef8ed23cfa1c664a@mail.gmail.com>
References:
<8E782679-17C2-400B-A781-93447617B2FD@apple.com>
<3128e0551002240745x15ad69eaq243943aefad921ad@mail.gmail.com>
<63df84f1003121216n72eb60edqa66dfd2e660d55a2@mail.gmail.com>
<2FD4CE21-5A0C-48A0-A632-F73D9220F9F9@apple.com>
<63df84f1003121435t72a64756q87822b1c7abf3db0@mail.gmail.com>
<63df84f1003121619k4f33da4bl4a060aa20a722ddf@mail.gmail.com>
<63df84f1003121820o43017e1bpef8ed23cfa1c664a@mail.gmail.com>
Message-ID: <2FC652F1-8B95-4DF3-B720-8813E2994FE2@apple.com>
On Mar 12, 2010, at 6:20 PM, Jonas Sicking wrote:
> On Fri, Mar 12, 2010 at 4:19 PM, Jonas Sicking
> wrote:
>> On Fri, Mar 12, 2010 at 3:38 PM, David Levin
>> wrote:
>>>
>>>
>>> On Fri, Mar 12, 2010 at 2:35 PM, Jonas Sicking
>>> wrote:
>>>>
>>>> On Fri, Mar 12, 2010 at 12:46 PM, Oliver Hunt
>>>> wrote:
>>>>>
>>>>> On Mar 12, 2010, at 12:16 PM, Jonas Sicking wrote:
>>>>>> I'm not saying that the proposed API is bad. It just doesn't
>>>>>> seem to
>>>>>> solve the (seemingly most commonly requested) use case of
>>>>>> rotating/scaling images. So if we want to solve those use cases
>>>>>> we
>>>>>> need to either come up with a separate API for that, or extend
>>>>>> this
>>>>>> proposal to solve that use case somehow.
>>>>>
>>>>> Just for reference I think one thing that people are forgetting
>>>>> that
>>>>> there is a difference between
>>>>> being computationally faster, and being more responsive.
>>>>
>>>> As I mentioned in my email, if you look at the steps listed,
>>>> enough of
>>>> them happen *on the main thread* that you're spending far more of
>>>> the
>>>> main threads CPU cycles than you'd like. Possibly even more than
>>>> doing
>>>> all the resizing on the main thread.
>>>>
>>>> With the other improvements suggested by David things do definitely
>>>> look different, but those are not in a proposal yet.
>>>
>>> There is the other scenario I mentioned, but I'll see what I can
>>> do about
>>> separately working up a proposal for adding those methods because
>>> they were
>>> next on my list to deal with. (fromBlob/load may be enough for
>>> this.)
>>
>> Note that the other proposals that have been made has put toBlob on
>> HTMLCanvasElement, not on the context. That makes the most sense for
>> the main-thread canvas as that way its available on all contexts.
>
> Oh, another thing to keep in mind is that if/when we add fromBlob to
> the main-thread canvas, it has to be asynchronous in order to avoid
> main thread synchronous IO. This isn't a big deal, but I figured I
> should mention it while we're on the subject.
This is part of why I think Blob is the wrong tool for the job - we
really want to use a data type here that can promise synchronous
access to the data. When you copy the canvas backing store to a new in-
memory representation, it seems silly to put that behind an interface
that's the same as data to which you can only promise async access,
such as part of a file on disk. There's nothing about copying bits
from one canvas to another that needs to be async.
(Also it's not clear to me why a Blob would be faster to copy from,
copy to, or copy cross-thread than ImageData; I thought the motivation
for adding it was to have a binary container that can be uploaded to a
server via XHR.)
> In general I wonder if we should add API to convert directly between
> Blob and ImageData. Or at least Blob->ImageData and
> ImageData->ByteArray. That could avoid overhead of going through a
> canvas context. That is probably a win no matter which thread we are
> on.
>
> We could even add APIs to rotate and scale ImageData objects directly.
> If those are asynchronous the implementation could easily implement
> them using a background thread. I'm less sure that this is worth it
> though given that you can implement this yourself using workers if we
> add the other stuff we've talked about.
Scaling and rotation can be done with just pixels if you code it by
hand, but you can get native code to do it for you if you can
manipulate actually offscreen buffers - you just establish the
appropriate transform before painting the ImageData. REally the
question is, how much slower is a scaling or rotating image paint than
an image paint with the identity transform? Is it more than twice as
expensive? That's the only way copying image data to a background
thread will give you a responsiveness win. I'd like to see some data
to establish that this is the case, if scales and rotates are the only
concrete use cases we have in mind.
Regards,
Maciej
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From jonas at sicking.cc Sat Mar 13 09:10:23 2010
From: jonas at sicking.cc (Jonas Sicking)
Date: Sat, 13 Mar 2010 09:10:23 -0800
Subject: [whatwg] Offscreen canvas (or canvas for web workers).
In-Reply-To: <2FC652F1-8B95-4DF3-B720-8813E2994FE2@apple.com>
References:
<63df84f1003121216n72eb60edqa66dfd2e660d55a2@mail.gmail.com>
<2FD4CE21-5A0C-48A0-A632-F73D9220F9F9@apple.com>
<63df84f1003121435t72a64756q87822b1c7abf3db0@mail.gmail.com>
<63df84f1003121619k4f33da4bl4a060aa20a722ddf@mail.gmail.com>
<63df84f1003121820o43017e1bpef8ed23cfa1c664a@mail.gmail.com>
<2FC652F1-8B95-4DF3-B720-8813E2994FE2@apple.com>
Message-ID: <63df84f1003130910x29307f73n179402fb184acf32@mail.gmail.com>
On Fri, Mar 12, 2010 at 10:07 PM, Maciej Stachowiak wrote:
> > On Mar 12, 2010, at 6:20 PM, Jonas Sicking wrote:
> > Oh, another thing to keep in mind is that if/when we add fromBlob to
> > the main-thread canvas, it has to be asynchronous in order to avoid
> > main thread synchronous IO. This isn't a big deal, but I figured I
> > should mention it while we're on the subject.
>
> This is part of why I think Blob is the wrong tool for the job - we really
> want to use a data type here that can promise synchronous access to the
> data. When you copy the canvas backing store to a new in-memory
> representation, it seems silly to put that behind an interface that's the
> same as data to which you can only promise async access, such as part of a
> file on disk. There's nothing about copying bits from one canvas to another
> that needs to be async.
> (Also it's not clear to me why a Blob would be faster to copy from, copy to,
> or copy cross-thread than ImageData; I thought the motivation for adding it
> was to have a binary container that can be uploaded to a server via XHR.)
There is a use case, which I suspect is quite common, for using
to manipulate files on the users file system. For example
when creating a photo uploader which does client side scaling before
uploading the images, or for creating a web based GIMP like
application.
In this case we'll start out with a File object that needs to be read
in to a . One solution could be to read the File into memory
in a ByteArray (or similar) and add a synchronous
canvas2dcontext.fromByteArray function. This has the advantage of
being more generic, but the downside of forcing both the encoded and
decoded image to be read into memory.
This is why I suggested adding a asynchronous fromBlob function.
For extracting image data from a I agree that a toBlob
function has little advantage over a toByteArray function (with the
possible exception that ByteArray so far is still vapor ware).
> In general I wonder if we should add API to convert directly between
> Blob and ImageData. Or at least Blob->ImageData and
> ImageData->ByteArray. That could avoid overhead of going through a
> canvas context. That is probably a win no matter which thread we are
> on.
>
> We could even add APIs to rotate and scale ImageData objects directly.
> If those are asynchronous the implementation could easily implement
> them using a background thread. I'm less sure that this is worth it
> though given that you can implement this yourself using workers if we
> add the other stuff we've talked about.
>
> Scaling and rotation can be done with just pixels if you code it by hand,
> but you can get native code to do it for you if you can manipulate actually
> offscreen buffers - you just establish the appropriate transform before
> painting the ImageData. REally the question is, how much slower is a scaling
> or rotating image paint than an image paint with the identity transform? Is
> it more than twice as expensive? That's the only way copying image data to a
> background thread will give you a responsiveness win. I'd like to see some
> data to establish that this is the case, if scales and rotates are the only
> concrete use cases we have in mind.
I agree that data would be great. Though for scaling I suspect that
it's complicated enough that it's worth exposing *some* built in API
for doing it. Especially considering that you want to use anti
aliasing and ideally things like gamma correction. Be that through
what we already have on 2d context, or on ImageData directly.
/ Jonas
From oliver at apple.com Sat Mar 13 12:09:33 2010
From: oliver at apple.com (Oliver Hunt)
Date: Sat, 13 Mar 2010 12:09:33 -0800
Subject: [whatwg] Offscreen canvas (or canvas for web workers).
In-Reply-To: <63df84f1003130910x29307f73n179402fb184acf32@mail.gmail.com>
References:
<63df84f1003121216n72eb60edqa66dfd2e660d55a2@mail.gmail.com>
<2FD4CE21-5A0C-48A0-A632-F73D9220F9F9@apple.com>
<63df84f1003121435t72a64756q87822b1c7abf3db0@mail.gmail.com>