On Tue, 26 Jan 2010, Michael A. Puls II wrote:
Please see the note in the object element section. It has more
detailed info. The embed and applet elements have the old, less-detailed
note.
Yeah. It turns out that trying to make the paragraph that's in the
object section fit the embed and
On Thu, 04 Feb 2010 03:47:22 -0500, Ian Hickson i...@hixie.ch wrote:
On Tue, 26 Jan 2010, Michael A. Puls II wrote:
Please see the note in the object element section. It has more
detailed info. The embed and applet elements have the old, less-detailed
note.
Yeah. It turns out that trying to
On Mon, 25 Jan 2010 20:36:27 -0500, Ian Hickson i...@hixie.ch wrote:
On Thu, 10 Dec 2009, Michael A. Puls II wrote:
Also see https://bugzilla.mozilla.org/show_bug.cgi?id=90268#c68.
Should probably add a note in the spec that the css overflow and
position properties don't affect
On Thu, 10 Dec 2009, Michael A. Puls II wrote:
Also see https://bugzilla.mozilla.org/show_bug.cgi?id=90268#c68.
Should probably add a note in the spec that the css overflow and
position properties don't affect instantiation/destroying etc.
(might as well add visibility too).
On Fri, 6 Nov 2009, Michael A. Puls II wrote:
O.K., so put simply, HTML5 should explicitly mention that the css
display property for object, embed (and applet in the handling
section) has absolutely no effect on plug-in instantiation and
destroying and has absolutely no effect
On Thu, 10 Dec 2009 09:48:55 -0500, Ian Hickson i...@hixie.ch wrote:
On Fri, 6 Nov 2009, Michael A. Puls II wrote:
O.K., so put simply, HTML5 should explicitly mention that the css
display property for object, embed (and applet in the handling
section) has absolutely no effect on
On Sun, 18 Oct 2009, Michael A. Puls II wrote:
However, if I use createDocument() to create an HTMLDocument and then
append an HTMLObjectElement to that document, the plug-in shouldn't load
as the document is not active/has no browsing context or something.
Good point. Fixed.
--
Ian
On Thu, 22 Oct 2009 08:23:33 -0400, Ian Hickson i...@hixie.ch wrote:
On Sun, 18 Oct 2009, Michael A. Puls II wrote:
However, if I use createDocument() to create an HTMLDocument and then
append an HTMLObjectElement to that document, the plug-in shouldn't load
as the document is not active/has
On Fri, 16 Oct 2009, Ben Laurie wrote:
On Thu, 6 Aug 2009, Andrew Oakley wrote:
- Should the type attribute take precedence over the Content-Type
header?
No, I believe what the spec says here is the preferred behaviour.
Unless this is incompatible with legacy content, we should try
On Mon, 14 Sep 2009 02:10:22 -0400, Ian Hickson i...@hixie.ch wrote:
On Thu, 3 Sep 2009, Michael A. Puls II wrote:
On Wed, 02 Sep 2009 17:39:00 -0400, Ian Hickson i...@hixie.ch wrote:
On Thu, 27 Aug 2009, Michael A. Puls II wrote:
Here's an example that uses a more modern plug-in that
On Sun, Oct 18, 2009 at 5:37 AM, Ian Hickson i...@hixie.ch wrote:
On Fri, 16 Oct 2009, Ben Laurie wrote:
On Thu, 6 Aug 2009, Andrew Oakley wrote:
- Should the type attribute take precedence over the Content-Type
header?
No, I believe what the spec says here is the preferred behaviour.
On Sun, 18 Oct 2009 14:21:56 +0200, Ben Laurie b...@google.com wrote:
On Sun, Oct 18, 2009 at 5:37 AM, Ian Hickson i...@hixie.ch wrote:
On Fri, 16 Oct 2009, Ben Laurie wrote:
On Thu, 6 Aug 2009, Andrew Oakley wrote:
- Should the type attribute take precedence over the Content-Type
header?
On Sun, 18 Oct 2009, Ben Laurie wrote:
On Sun, Oct 18, 2009 at 5:37 AM, Ian Hickson i...@hixie.ch wrote:
On Fri, 16 Oct 2009, Ben Laurie wrote:
On Thu, 6 Aug 2009, Andrew Oakley wrote:
- Should the type attribute take precedence over the Content-Type
header?
No, I believe what
On Sun, 18 Oct 2009, Ola P. Kleiven wrote:
On Sun, 18 Oct 2009 14:21:56 +0200, Ben Laurie b...@google.com wrote:
On Sun, Oct 18, 2009 at 5:37 AM, Ian Hickson i...@hixie.ch wrote:
On Fri, 16 Oct 2009, Ben Laurie wrote:
On Thu, 6 Aug 2009, Andrew Oakley wrote:
- Should the type
On Sun, Oct 18, 2009 at 3:47 PM, Ian Hickson i...@hixie.ch wrote:
On Sun, 18 Oct 2009, Ben Laurie wrote:
On Sun, Oct 18, 2009 at 5:37 AM, Ian Hickson i...@hixie.ch wrote:
On Fri, 16 Oct 2009, Ben Laurie wrote:
On Thu, 6 Aug 2009, Andrew Oakley wrote:
- Should the type attribute take
On Sun, 18 Oct 2009 23:48:51 +0200, Ian Hickson i...@hixie.ch wrote:
On Sun, 18 Oct 2009, Ben Laurie wrote:
but if you want a very specific type used for a plugin, you can use
embed.
So what's the difference between embed and object?
embed only allows plugins; object also allows other
On Fri, Oct 16, 2009 at 9:55 PM, Boris Zbarsky bzbar...@mit.edu wrote:
On 10/16/09 8:21 PM, Ben Laurie wrote:
The point is that if I think I'm sourcing something safe but it can be
overridden by the MIME type, then I have a problem.
Perhaps we need an attribute on object that says to only
On Fri, 16 Oct 2009 05:28:46 -0400, Ian Hickson i...@hixie.ch wrote:
On Sun, 20 Sep 2009, Michael A. Puls II wrote:
O.K., so put simply, HTML5 should explicitly mention that the css
display property for object, embed (and applet in the handling
section) has absolutely no effect on plug-in
On Thu, 3 Sep 2009, Henri Sivonen wrote:
On Sep 3, 2009, at 00:39, Ian Hickson wrote:
2. Its element must not be set to display of 'none' (and therefore
must not be part of fallback content that's not triggered yet).
This is definitely a bug; the fallback handling is done in a
On Fri, 16 Oct 2009 05:28:46 -0400, Ian Hickson i...@hixie.ch wrote:
There was also some discussion of what to do about preventing a plugin
instantiating. It seems to me that authors can do that by not creating
the
object element ahead of time.
And, if it's desired to specify the object
On Fri, 16 Oct 2009 12:10:35 +0200, Michael A. Puls II
shadow2...@gmail.com wrote:
On Fri, 16 Oct 2009 05:28:46 -0400, Ian Hickson i...@hixie.ch wrote:
There was also some discussion of what to do about preventing a plugin
instantiating. It seems to me that authors can do that by not
On Fri, 16 Oct 2009 06:19:04 -0400, Simon Pieters sim...@opera.com wrote:
On Fri, 16 Oct 2009 12:10:35 +0200, Michael A. Puls II
shadow2...@gmail.com wrote:
On Fri, 16 Oct 2009 05:28:46 -0400, Ian Hickson i...@hixie.ch wrote:
There was also some discussion of what to do about preventing a
On 10/16/09 4:12 PM, Ben Laurie wrote:
I realise this is only one of dozens of ways that HTML is unfriendly
to security, but, well, this seems like a bad idea - if the page
thinks it is embedding, say, some flash, it seems like a pretty bad
idea to allow the (possibly untrusted) site providing
On Fri, Oct 16, 2009 at 5:48 PM, Boris Zbarsky bzbar...@mit.edu wrote:
On 10/16/09 4:12 PM, Ben Laurie wrote:
I realise this is only one of dozens of ways that HTML is unfriendly
to security, but, well, this seems like a bad idea - if the page
thinks it is embedding, say, some flash, it seems
On Fri, Oct 16, 2009 at 6:04 PM, Mike Shaver mike.sha...@gmail.com wrote:
On Fri, Oct 16, 2009 at 5:56 PM, Ben Laurie b...@google.com wrote:
On Fri, Oct 16, 2009 at 5:48 PM, Boris Zbarsky bzbar...@mit.edu wrote:
This is, imo, a much bigger problem than that of people embedding content
from an
On 10/16/09 8:21 PM, Ben Laurie wrote:
The point is that if I think I'm sourcing something safe but it can be
overridden by the MIME type, then I have a problem.
Perhaps we need an attribute on object that says to only render the
data if the server provided type and @type match? That way you
On Mon, Sep 21, 2009 at 5:26 PM, Michael A. Puls II
shadow2...@gmail.com wrote:
On Mon, 21 Sep 2009 16:30:29 -0400, Boris Zbarsky bzbar...@mit.edu wrote:
Of course, if the idea is to support deferring for images, object and
embed etc. and it's not desired that that support be given through
On Tue, 22 Sep 2009 11:42:25 -0400, Tab Atkins Jr. jackalm...@gmail.com
wrote:
On Mon, Sep 21, 2009 at 5:26 PM, Michael A. Puls II
shadow2...@gmail.com wrote:
On Mon, 21 Sep 2009 16:30:29 -0400, Boris Zbarsky bzbar...@mit.edu
wrote:
Of course, if the idea is to support deferring for images,
On Sun, 20 Sep 2009 14:49:11 -0400, Boris Zbarsky bzbar...@mit.edu wrote:
On 9/18/09 6:35 PM, Michael A. Puls II wrote:
The reason I ask is that if existing web pages use multiple object's
that load videos for example, that are initially set to display: none
and only shown later, then if
On 9/20/09 3:54 PM, Michael A. Puls II wrote:
O.K., so put simply, HTML5 should explicitly mention that the css
display property for object, embed (and applet in the handling
section) has absolutely no effect on plug-in instantiation and
destroying and has absolutely no effect on @src and @data
On Mon, 21 Sep 2009 08:24:37 -0400, Boris Zbarsky bzbar...@mit.edu wrote:
On 9/20/09 3:54 PM, Michael A. Puls II wrote:
O.K., so put simply, HTML5 should explicitly mention that the css
display property for object, embed (and applet in the handling
section) has absolutely no effect on plug-in
On Mon, 21 Sep 2009 08:24:37 -0400, Boris Zbarsky bzbar...@mit.edu wrote:
On 9/20/09 3:54 PM, Michael A. Puls II wrote:
O.K., so put simply, HTML5 should explicitly mention that the css
display property for object, embed (and applet in the handling
section) has absolutely no effect on plug-in
On 9/21/09 2:01 PM, Michael A. Puls II wrote:
I think Opera even defers
the fetching of display: none images until the display is changed.
With those, I believe, it does a synchronous GET when someone asks about
things about the image that need the image data, no?
I have no problem with a
On Mon, 21 Sep 2009 16:30:29 -0400, Boris Zbarsky bzbar...@mit.edu wrote:
On 9/21/09 2:01 PM, Michael A. Puls II wrote:
I think Opera even defers
the fetching of display: none images until the display is changed.
With those, I believe, it does a synchronous GET when someone asks about
On 9/18/09 6:35 PM, Michael A. Puls II wrote:
With object style=display: none data=file.swf?vid=file.flv when
the page is parsed (or added to the document), what would happen?
Would it be something like this?:
1. Create the plug-in instance.
2. fetch file.swf
3. Give the file.swf stream to
On Sun, 20 Sep 2009 14:49:11 -0400, Boris Zbarsky bzbar...@mit.edu wrote:
On 9/18/09 6:35 PM, Michael A. Puls II wrote:
With object style=display: none data=file.swf?vid=file.flv when
the page is parsed (or added to the document), what would happen?
Would it be something like this?:
1.
On Mon, 14 Sep 2009 08:42:10 -0400, Boris Zbarsky bzbar...@mit.edu wrote:
We (Gecko) consider it a bug that a display:none object in a document
doesn't instantiate the plug-in.
BTW, what is the reason for considering it a bug? Is it because:
{
visibility: hidden;
width: 0;
height: 0;
On 9/18/09 4:57 AM, Michael A. Puls II wrote:
We (Gecko) consider it a bug that a display:none object in a
document doesn't instantiate the plug-in.
BTW, what is the reason for considering it a bug?
Because the current behavior of having the plug-in instantiation handled
by effectively the
On Fri, 18 Sep 2009 08:18:04 -0400, Boris Zbarsky bzbar...@mit.edu wrote:
On 9/18/09 4:57 AM, Michael A. Puls II wrote:
We (Gecko) consider it a bug that a display:none object in a
document doesn't instantiate the plug-in.
BTW, what is the reason for considering it a bug?
Because the
On 9/18/09 10:21 AM, Michael A. Puls II wrote:
Attaching a test.
Thanks for doing that!
In Opera:
If you switch the display to none, it destroys the plug-in instance.
Setting the display to something else again doesn't restore the previous
plug-in instance. It creates a new one that starts
On Fri, 18 Sep 2009 14:43:39 -0400, Boris Zbarsky bzbar...@mit.edu wrote:
On 9/18/09 10:21 AM, Michael A. Puls II wrote:
Attaching a test.
So, is it IE's behavior we want here, or Opera's?
In my opinion, neither. We don't want to have plug-in instantiation
depending on the CSS box model at
Ian Hickson wrote:
Since the whole point of text/plain sniffing is a workaround around a
known issue where content is reliably mis-marked as text/plain, and
since in this case there is a source of MIME information that's more
reliable than that, it's not clear to me why we want to continue
On Thu, 3 Sep 2009, Michael A. Puls II wrote:
On Wed, 02 Sep 2009 17:39:00 -0400, Ian Hickson i...@hixie.ch wrote:
On Thu, 27 Aug 2009, Michael A. Puls II wrote:
Here's an example that uses a more modern plug-in that shows what
browsers do.
window.onload = function() {
Ian Hickson wrote:
On Sun, 6 Sep 2009, Boris Zbarsky wrote:
Ian Hickson wrote:
1. Its element must be attached to the document.
I'm told this is considered a bug.
Told by whom, if I might ask?
I thought by you, but apparently I misunderstood the point you had been
making! I've changed
On Mon, 14 Sep 2009 08:42:10 -0400, Boris Zbarsky bzbar...@mit.edu wrote:
Ah. I must have been unclear. We (Gecko) consider it a bug that a
display:none object in a document doesn't instantiate the plug-in.
I'm trying to remember. Did you also say that FF makes some use of
display: none
On Mon, 14 Sep 2009 02:10:22 -0400, Ian Hickson i...@hixie.ch wrote:
On Thu, 3 Sep 2009, Michael A. Puls II wrote:
On Wed, 02 Sep 2009 17:39:00 -0400, Ian Hickson i...@hixie.ch wrote:
On Thu, 27 Aug 2009, Michael A. Puls II wrote:
Here's an example that uses a more modern plug-in that
Michael A. Puls II wrote:
I'm trying to remember. Did you also say that FF makes some use of
display: none for fallback content
It does not, but it does make use of lack of CSS boxes...
and that if FF was fixed so
display:none didn't affect plug-in instantiation, both plug-ins in the
On Mon, 14 Sep 2009 21:13:46 -0400, Boris Zbarsky bzbar...@mit.edu wrote:
Michael A. Puls II wrote:
I'm trying to remember. Did you also say that FF makes some use of
display: none for fallback content
It does not, but it does make use of lack of CSS boxes...
and that if FF was fixed so
Boris wrote:
I'm not sure where this list of (extension,type) pairs comes from,
but it looks like the plug-in provides it somehow (possibly even in that
form, looking at
http://mxr.mozilla.org/mozilla-central/source/modules/plugin/base/src/nsPluginsDirUtils.h#53).
plugins register tripples:
On Wed, 02 Sep 2009 17:39:00 -0400, Ian Hickson i...@hixie.ch wrote:
On Thu, 27 Aug 2009, Michael A. Puls II wrote:
Here's an example that uses a more modern plug-in that shows what
browsers do.
window.onload = function() {
var obj = document.createElement(object);
obj.type =
On Sep 3, 2009, at 00:39, Ian Hickson wrote:
2. Its element must not be set to display of 'none' (and therefore
must
not be part of fallback content that's not triggered yet).
This is definitely a bug; the fallback handling is done in a
different way
in HTML5, anyway.
Why is this a
On Thu, 27 Aug 2009, Michael A. Puls II wrote:
Here's an example that uses a more modern plug-in that shows what
browsers do.
window.onload = function() {
var obj = document.createElement(object);
obj.type = application/x-shockwave-flash;
obj.data =
On Tue, 25 Aug 2009, Andrew Oakley wrote:
Ian Hickson wrote:
I'm not sure exactly what change you mean. The spec already has some of
Gecko's behaviour (in particular the special-casing of certain MIME types
to enable sniffing), are there other changes you think we should include?
On Mon, 31 Aug 2009 11:08:16 +0200, Ian Hickson i...@hixie.ch wrote:
On Tue, 25 Aug 2009, Andrew Oakley wrote:
Ian Hickson wrote:
I'm not sure exactly what change you mean. The spec already has some
of
Gecko's behaviour (in particular the special-casing of certain MIME
types
to enable
Ian Hickson wrote:
On Tue, 25 Aug 2009, Andrew Oakley wrote:
So if we had a type attribute of application/x-shockwave-flash, and a
Content-Type header of image/png we would use the flash plugin.
Following the HTML5 spec we would use the image renderer.
Ah, yes, that's intentional (doing
On Mon, 24 Aug 2009 19:31:30 -0400, Ian Hickson i...@hixie.ch wrote:
On Fri, 14 Aug 2009, Michael A. Puls II wrote:
On Thu, 13 Aug 2009 22:05:26 -0400, Ian Hickson i...@hixie.ch wrote:
- Should objects exist all the time whether they are attached to
the
document or not?
Assuming you
Ian Hickson wrote:
I'm not sure exactly what change you mean. The spec already has some of
Gecko's behaviour (in particular the special-casing of certain MIME types
to enable sniffing), are there other changes you think we should include?
Boris Zbarsky wrote (near the top of this thread):
On Fri, 14 Aug 2009, Andrew Oakley wrote:
- Should the type attribute take precedence over the Content-Type header?
No, I believe what the spec says here is the preferred behaviour.
Unless this is incompatible with legacy content, we should try to move
towards this behaviour.
OK,
On Fri, 14 Aug 2009, Michael A. Puls II wrote:
On Thu, 13 Aug 2009 22:05:26 -0400, Ian Hickson i...@hixie.ch wrote:
- Should objects exist all the time whether they are attached to the
document or not?
Assuming you mean the plugins, as opposed to the elements themselves, then
the way
- Should the type attribute take precedence over the Content-Type header?
No, I believe what the spec says here is the preferred behaviour. Unless
this is incompatible with legacy content, we should try to move towards
this behaviour.
OK, should the spec mention the change that Boris
On Thu, 13 Aug 2009 22:05:26 -0400, Ian Hickson i...@hixie.ch wrote:
- Should objects exist all the time whether they are attached to the
document or not?
Assuming you mean the plugins, as opposed to the elements themselves,
then
the way the spec is written, the plugin instantiates regardless
On Thu, 6 Aug 2009, Andrew Oakley wrote:
The rules in the HTML5 spec for which plugin to load for an object do
not seem to be followed by any browser, and in some cases are different
to behavior that is common to Opera, Webkit and Gecko (I haven't tested
with IE due to its lack of nsplugin
Andrew Oakley wrote:
Most notably HTML5 says that the Content-Type header is used in
preference to the type attribute, whereas the browsers seem to honour
the attribute in preference to the header.
Firefox hasn't done that (at least across the board) since Firefox 3.0
shipped.
Note that the
63 matches
Mail list logo
