On Mon, 21 Sep 2009 16:30:29 -0400, Boris Zbarsky <[email protected]> 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
things about the image that need the image data, no?
If you mean like asking for img.width, it just shows 0. As in, the <img>
is dead until you change its display. Safari doesn't do this though.
I have no problem with a load-on-demand setup as long as it's
transparent to content...
So, I'm thinking HTML5 should say that display: none specifically (not
other display values) "SHOULD NOT" affect... instead of "MUST NOT"
affect... because there might be cases where display: none deferring is
desired.
I think that makes the model very confusing for authors, but maybe
that's just me.
Yeh, it doesn't sound ideal. That's for sure.
How do you envision an audio object inside <head> working with this
setup? Or would it have to go inside <body>, per spec? What about
wanting an object that has no rendering at all but lets you interact
with it via script and does something useful for you (say S/MIME stuff
for a webmail client)?
Good questions. I envision the object doing whatever I tell to do or not
to do :). And, being able to tell it what to do or not to do and have it
listen would be great. See below.
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
css, perhaps there should be some attribute that does that. <img
disabled> <object disabled> <embed disabled> etc. where .disabled =
false brings them alive.
I would prefer something like this. Using CSS for this purpose seems
wrong.
Sounds good. If it is an attribute, I wonder what would be a good name.
'disabled' might be likely to conflict with some plug-in param and might
conflict with <object> and <img> when they are form controls.
--
Michael
