On Tue, Jul 31, 2012 at 10:24 PM, Robert O'Callahan
rob...@ocallahan.org wrote:
On Wed, Aug 1, 2012 at 10:33 AM, Adam Barth w...@adambarth.com wrote:
It's not clear to me from the spec how the allowfullscreen attribute
works. It appears to be mentioned only in the security and privacy
On Wed, Aug 1, 2012 at 12:33 AM, Adam Barth w...@adambarth.com wrote:
Main frame: a.html
- iframe src=b.html
- iframe src=c.html allowfullscreen
Can c.html go full screen? Where is that specified?
https://www.w3.org/Bugs/Public/show_bug.cgi?id=17838
I did not want to define new HTML
On Wed, Aug 1, 2012 at 11:04 AM, Anne van Kesteren ann...@annevk.nl wrote:
https://www.w3.org/Bugs/Public/show_bug.cgi?id=17838
I did not want to define new HTML features in a separate draft.
So Vincent, if you want to argue for a different design, that bug
would be the place I think. I do not
Hi all,
with the likes of postMessage and Web Intents that we are getting access to
now, it is increasingly common that data may flow from a server to an
in-browser page, that may then pass that data on to another in-browser page
(typically running at a different origin). In a many cases, such
On Wed, Aug 1, 2012 at 9:59 AM, Robin Berjon ro...@berjon.com wrote:
var bb = new BlobBuilder()
, blob = bb.getBlobFromURL(http://specifiction.com/kitten.png;, GET, {
Authorization: Basic DEADBEEF });
Everything is the same as the previous version but the method and some
headers can be
On Wed, Aug 1, 2012 at 9:44 AM, Glenn Maynard gl...@zewt.org wrote:
On Wed, Aug 1, 2012 at 9:59 AM, Robin Berjon ro...@berjon.com wrote:
var bb = new BlobBuilder()
, blob = bb.getBlobFromURL(http://specifiction.com/kitten.png;, GET,
{ Authorization: Basic DEADBEEF });
Everything is the
On Wed, Aug 1, 2012 at 10:46 AM, Florian Bösch pya...@gmail.com wrote:
On Wed, Aug 1, 2012 at 6:40 PM, Glenn Adams gl...@skynav.com wrote:
Why restrict to XHR? How about WebSocket as data source?
Websockets support array buffers and therefore by extension any blob/file
object. However as a
Thank you Adam, ROC, Anne. I commented on issue.
On Wed, Aug 1, 2012 at 2:05 AM, Anne van Kesteren ann...@annevk.nl wrote:
On Wed, Aug 1, 2012 at 11:04 AM, Anne van Kesteren ann...@annevk.nl
wrote:
https://www.w3.org/Bugs/Public/show_bug.cgi?id=17838
I did not want to define new HTML
On Wed, Aug 1, 2012 at 11:13 AM, Florian Bösch pya...@gmail.com wrote:
On Wed, Aug 1, 2012 at 6:51 PM, Glenn Adams gl...@skynav.com wrote:
I'm questioning defining a LazyBlob that is solely usable with XHR. It
would be better to have a more generic version IMO.
Websockets have no content
On Aug 1, 2012, at 8:44 AM, Glenn Maynard gl...@zewt.org wrote:
On Wed, Aug 1, 2012 at 9:59 AM, Robin Berjon ro...@berjon.com wrote:
var bb = new BlobBuilder()
, blob = bb.getBlobFromURL(http://specifiction.com/kitten.png;, GET, {
Authorization: Basic DEADBEEF });
Everything is the same
On Wed, Aug 1, 2012 at 12:03 PM, Florian Bösch pya...@gmail.com wrote:
On Wed, Aug 1, 2012 at 7:57 PM, Glenn Adams gl...@skynav.com wrote:
blob =
bb.getBlobFromURL(ws://specifiction.com/image/kitten.pnghttp://specifiction.com/kitten.png
)
There is no application layer transfer protocol
Maybe another XHR based way to phrase this: define a new response type for
XHR that results in the construction of a lazyBlob. I guess that's similar
to the more explicit xhr.makeLazyBlob() method, but allows its construction
to be async, and for greater reuse of the same signaling for progress
On Wed, Aug 1, 2012 at 1:36 PM, Florian Bösch pya...@gmail.com wrote:
On Wed, Aug 1, 2012 at 9:26 PM, Glenn Adams gl...@skynav.com wrote:
So? Why should lazy blob be specific to HTTP specific semantics when an
arbitrary URL is not specific to HTTP?
So if you want to have a lazy reader on
On Wed, Aug 1, 2012 at 1:47 PM, Glenn Adams gl...@skynav.com wrote:
On Wed, Aug 1, 2012 at 1:36 PM, Florian Bösch pya...@gmail.com wrote:
On Wed, Aug 1, 2012 at 9:26 PM, Glenn Adams gl...@skynav.com wrote:
So? Why should lazy blob be specific to HTTP specific semantics when an
arbitrary
Can we please stop saying lazy blob? It's a confused and confusing
phrase. Blobs are lazy by design.
On Wed, Aug 1, 2012 at 2:26 PM, Glenn Adams gl...@skynav.com wrote:
So? Why should lazy blob be specific to HTTP specific semantics when an
arbitrary URL is not specific to HTTP?
XHR is no
On Wed, Aug 1, 2012 at 1:54 PM, Florian Bösch pya...@gmail.com wrote:
On Wed, Aug 1, 2012 at 9:50 PM, Glenn Adams gl...@skynav.com wrote:
Further, a default behavior in the absence of such an injection might be
defined simply to read data from the WS and stuff into the blob.
Which kind of
On Wed, Aug 1, 2012 at 2:04 PM, Glenn Maynard gl...@zewt.org wrote:
Can we please stop saying lazy blob? It's a confused and confusing
phrase. Blobs are lazy by design.
On Wed, Aug 1, 2012 at 2:26 PM, Glenn Adams gl...@skynav.com wrote:
So? Why should lazy blob be specific to HTTP
On 8/1/12 11:44 AM, Glenn Maynard wrote:
Ideally, a new responseType could be added to XHR which operates like
blob, except instead of reading the whole resource, it just performs a
HEAD to retrieve the response length and immediately returns the Blob,
which can be read to perform further
On Wed, Aug 1, 2012 at 8:16 PM, Boris Zbarsky bzbar...@mit.edu wrote:
Unless the server is one of the common ones with broken HEAD handling. Or
unless the resource is served with Content-Encoding:gzip, in which case
your Content-Range is all sorta broken. :(
Those could fall back on
On Wed, Aug 1, 2012 at 2:35 PM, Florian Bösch pya...@gmail.com wrote:
On Wed, Aug 1, 2012 at 10:13 PM, Glenn Adams gl...@skynav.com wrote:
The subject line says Lazy Blob, not Lazy Blob and XHR. For the record, I
will object to a LazyBlob solution that is tied solely to XHR, so deal with
it
On Wed, Aug 1, 2012 at 9:54 PM, Glenn Adams gl...@skynav.com wrote:
I don't particularly care if a default behavior for WS is provided that
buffers the entire read stream.
Sorry, but that doesn't make sense. You don't access a message-based
protocol (Web Sockets) using a character-based API
On Wed, Aug 1, 2012 at 9:35 PM, Glenn Maynard gl...@zewt.org wrote:
On Wed, Aug 1, 2012 at 9:54 PM, Glenn Adams gl...@skynav.com wrote:
I don't particularly care if a default behavior for WS is provided that
buffers the entire read stream.
Sorry, but that doesn't make sense. You don't
On 8/1/12 9:50 PM, Glenn Maynard wrote:
(if the broken HEAD cases are detectable, anyway)
I wish.
Some of them are, but a lot are not. We used to use HEAD for things
like save link as in Firefox (for prompting the user for a filename
and such), but had to stop because it was broken so
On Wed, Aug 1, 2012 at 2:13 PM, Glenn Adams gl...@skynav.com wrote:
On Wed, Aug 1, 2012 at 2:04 PM, Glenn Maynard gl...@zewt.org wrote:
Can we please stop saying lazy blob? It's a confused and confusing
phrase. Blobs are lazy by design.
On Wed, Aug 1, 2012 at 2:26 PM, Glenn Adams
On Wed, 1 Aug 2012, Glenn Adams wrote:
Of course, implementers are free to ignore whatever they want, but last
time I checked, the W3C was a consensus based standards organization
which means agreement needs to be reached on what specs go out the door
and what are in those specs.
Doesn't
25 matches
Mail list logo
