Re: [whatwg] about:blank synchronicity

2010-01-14 Thread Henri Sivonen
On Jan 13, 2010, at 19:08, Boris Zbarsky wrote:

 On 1/13/10 11:52 AM, Maciej Stachowiak wrote:
 It seems like if Gecko truly wanted to make about:blank synchronous, it
 should be possible simply by special-casing its load and performing a
 series of DOM calls right then and there, without ever involving the
 parser.
 
 Turns out this actually breaks at least some things that expect 
 (asynchronous) onload events and the like for the about:blank load, at least 
 when Henri tried doing exactly that.  I _think_ this was for cases where an 
 explicit about:blank was listed as the src.

I did it after absent or empty src had been defaulted to about:blank: so empty, 
absent and explicit about:blank were all covered. Also, I did it for all 
browsing contexts--not just iframes.

The most obvious test case that broke was testing history navigation in a 
top-level browsing context (i.e. created in XUL--not as an iframe).

It is plausible that my attempt to fix was too naïve and additional tweaking of 
the events could work. (It is indeed very likely that my attempted fix was too 
naïve.) Also, making the change only for frames but not for top-level browsing 
contexts might be worth considering if changing this for top-level browsing 
contexts is too disruptive.

Which leads to the question: Are there known Web compat constraints on 
navigating a non-framed browsing context to about:blank via window.open() or 
window.location.href in a previously open()ed window?

-- 
Henri Sivonen
hsivo...@iki.fi
http://hsivonen.iki.fi/




Re: [whatwg] video abort and error should bubble for simplicity

2010-01-14 Thread Philip Jägenstedt
On Wed, 11 Nov 2009 16:36:35 +0100, Philip Jägenstedt phil...@opera.com  
wrote:


Since we are no longer using progress events for media elements we don't  
have the external requirement that abort/error shouldn't bubble. I'd  
like them to bubble, because:


1. error events fired on source will bubble to video, which is quite  
useful if one doesn't particularly care which source failed (one need  
not register an event handler on each individual source attribute)


2. Implementors don't have to deal with the possibility that events of  
the same name and type sometimes bubbles and sometimes not.


3. It's the same as for img, which all else equals seems nice and  
simple.


I'll note that video abort/error events in Firefox already seems to  
bubble while they apparently don't in Safari. We'd like to align with  
Firefox and have the spec changed.


It looks like I was wrong. As far as I can see error/abort doesn't bubble  
in any other scenario and it seemed to be that way in Firefox because the  
error event is fired on the video element, or something. No spec change  
needed.


--
Philip Jägenstedt
Core Developer
Opera Software


Re: [whatwg] HTMLCanvasElement.toFile()

2010-01-14 Thread David Levin
It seems like it the method should be toBlob.

 This doesn't address my concern that you won't know the mime type of
 the blob returned.

This makes a good case to move the readonly attrbiute DOMString type from
File to Blob.

dave


Re: [whatwg] HTMLCanvasElement.toFile()

2010-01-14 Thread Darin Fisher
On Thu, Jan 14, 2010 at 12:10 PM, David Levin le...@google.com wrote:

 It seems like it the method should be toBlob.

  This doesn't address my concern that you won't know the mime type of
  the blob returned.

 This makes a good case to move the readonly attrbiute DOMString
 type from File to Blob.

 dave



I like this suggestion.  It seems reasonable for a Blob, which is just a
handle to data, to have an associated media type.

-Darin


Re: [whatwg] HTMLCanvasElement.toFile()

2010-01-14 Thread Ian Hickson
On Thu, 14 Jan 2010, Darin Fisher wrote:
 On Thu, Jan 14, 2010 at 12:10 PM, David Levin le...@google.com wrote:
  
  It seems like it the method should be toBlob.
 
   This doesn't address my concern that you won't know the mime type of 
   the blob returned.
 
  This makes a good case to move the readonly attrbiute DOMString type 
  from File to Blob.
 
 I like this suggestion.  It seems reasonable for a Blob, which is just a 
 handle to data, to have an associated media type.

What type should a blob have if it is the result of slicing another file?

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