philipj at opera.com
Mon Feb 14 07:01:22 PST 2011
On Thu, 10 Feb 2011 04:12:09 +0100, Ian Hickson <ian at hixie.ch> wrote:
> On Mon, 15 Nov 2010, Boris Zbarsky wrote:
>> On 11/15/10 8:15 PM, Ian Hickson wrote:
>> > > Gecko's currently-intended behavior is to do what [the spec]
>> > > describes in all cases except:
>> > >
>> > What does it do for those cases if it doesn't match the spec?
>> For <iframe> the behavior in Gecko currently is different in terms of
> How does it differ? As far as I can tell, it works the same as the spec
> says (the document.location is "about:blank" in the example above).
>> For the others, I believe we execute them in the script environment of
>> owner document of the object/embed/applet, whereas the spec requires
>> them to
>> execute in a sandbox, as far as I can tell.
> Ah, interesting. For <object>, this seems to be a unique feature of
> Firefox. Opera also executes the script in the context of the owner, but
> then ignores the results as far as I can tell. Other browsers don't seem
For the record, I removed Opera's "support" (I assume it was an unintended
time when I wrote my previous mail in this thread. This intentionally
doesn't match what the spec says. (Disclaimer: this is only my opinion on
something that isn't really my area of expertise, so others at Opera might
decide that the spec is great and push in the opposite direction. It seems
unlikely at this point, though.)
> On Thu, 25 Nov 2010, Philip Jägenstedt wrote:
>> Based on this, unless there are corner-cases I've missed, it seems
>> unlikely that there's a large body of web content that depends on inline
>> be the simplest to implement and the fastest way to reach
>> in more contexts, which, even if sandboxed, doesn't seem particularly
> There's a minor body of work on the Web that is based on using
> URLs to generate bitmaps, and I don't really see any harm with this.
Even if there's no harm, it's unneeded complexity that so far doesn't seem
to be needed for web compat, since it currently would only work in Firefox.
>> I'll keep you posted if there are any compatibility issues that come up
>> with this. Assuming (boldly) there is not, would there be support from
>> other browsers to move in this direction and change the spec to match?
> What the spec currently specs seems to be a reasonable compromise between
> security, compatibility needs based on what browsers do today, use cases,
> and consistency across the platform (usability), in that order.
What compatibility needs? The only thing I'm aware of is using <img
examples would break if the execution was sandboxed as per the spec.
> Obviously if browsers implement something different, then I'll happily
> move the spec to match, but it would be sad to just close off these
> features without good reason.
not very useful at all, so IMO the only reason to keep it would be for
legacy compat. I'll follow up on this again once the change to block
hopefully reporting that no compat issues have arisen.
More information about the whatwg