Re: [whatwg] object behavior
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 browsers start fetching all these files as soon as the page loads They already have to do that, and will continue to, because the HTTP headers from the response are needed to determine how to handle the data. Actually. I see more what you're saying now. But, I wasn't totally clear before. See the attached. In Opera and Safari, display: none acts like a defer for both object (one a text/html page, the other a flash page) where there's no network activity until you change the display from none. So, they don't do any determining until after you change the display. It's like a dead object at first. Now, in IE and Firefox on the other hand, they do indeed request things right away like you say. I somehow missed that IE and Firefox did that. I was concerned that making browsers (only Opera and Safari now) change that defer behavior would badly affect web pages. But, if IE and Firefox already make requests when the display is none, I guess it's O.K. for Safari and Opera to do so too. Although, I think I like Opera and Safari's behavior better. At any rate, would definitely like to see browsers align on all this stuff. -- Michael Show first objectShow second object
Re: [whatwg] object behavior
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 resource fetching. Imo, yes. Especially given your HTML example, where the behavior difference is easy to stumble on by trying to get the contentDocument of the object and work with it. -Boris
Re: [whatwg] object behavior
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 instantiation and destroying and has absolutely no effect on @src and @data resource fetching. Imo, yes. Especially given your HTML example, where the behavior difference is easy to stumble on by trying to get the contentDocument of the object and work with it. Ah, indeed. After window.onload, I get null in Opera and undefined in Safari for the contentDocument while I get the document in Firefox. -- Michael
Re: [whatwg] [html5] r3927 - [gow] (2) Update the rendering section to handle media elements' controls='' att [...]
On Mon, 21 Sep 2009 12:22:03 +0200, wha...@whatwg.org wrote:
Author: ianh
Date: 2009-09-21 03:22:02 -0700 (Mon, 21 Sep 2009)
New Revision: 3927
Modified:
index
source
Log:
[gow] (2) Update the rendering section to handle media elements'
controls='' attribute in a more correct way.
Fixing http://www.w3.org/Bugs/Public/show_bug.cgi?id=7403
Modified: source
===
--- source 2009-09-21 10:05:44 UTC (rev 3926)
+++ source 2009-09-21 10:22:02 UTC (rev 3927)
@@ -84559,9 +84559,9 @@
pre class=css@namespace url(http://www.w3.org/1999/xhtml);
-[hidden], area, audio:not([controls]), base, basefont, command,
-datalist, head, input[type=hidden], link, menu[type=context], meta,
-noembed, noframes, param, rp, script, source, style, title {
+[hidden], area, base, basefont, command, datalist, head,
+input[type=hidden], link, menu[type=context], meta, noembed, noframes,
+param, rp, script, source, style, title {
display: none;
}
@@ -85576,13 +85576,16 @@
elements are expected to be treated as ordinary elements in the
rendering model./p
- pThe codeaudio/code element, when it has a code
- title=attr-media-controlscontrols/code attribute, is expected
- to be treated as a replaced element about one line high, as wide as
- is necessary to expose the user agent's user interface features./p
+ pThe codeaudio/code element, when it is span title=expose a
+ user interface to the userexposing a user interface/span, is
+ expected to be treated as a replaced element about one line high, as
+ wide as is necessary to expose the user agent's user interface
+ features. When an codeaudio/code element is not span
+ title=expose a user interface to the userexposing a user
+ interface/span, it is expected to render as an empty element./p
Why did you change from display:none to an empty element? Browsers have
already implemented it as display:none, and I think it's a nicer behavior
for authors who want to style audio elements that expose controls (e.g.
giving a border) without affecting audio elements without controls.
I suggest forcing display:none, like with noscript.
- pThe codevideo/code element's code
- title=attr-media-controlscontrols/code attribute is not
+ pWhether a codevideo/code element is span title=expose a
+ user interface to the userexposing a user interface/span is not
expected to affect the size of the rendering; controls are expected
to be overlaid with the page content without causing any layout
changes, and are expected to disappear when the user does not need
--
Simon Pieters
Opera Software
[whatwg] Question on the element's Document
Section 2.6, item 3 says [1]: When fetching resources for an element The element's Document. Is that supposed to be the element's ownerDocument? Or something else? The term seems to be underdefined. It's also not defined whether the document is to be examined at the moment when running the fetch steps or at the time convenient to the user and the user agent when the download happens. This might matter for, e.g. script that does something like: var img = doc1.createElement(img); img.src = something; doc2.adoptNode(img); [1] http://www.whatwg.org/specs/web-apps/current-work/multipage/urls.html#fetching-resources
Re: [whatwg] the cite element
On Sun, Sep 20, 2009 at 4:09 AM, Smylers smyl...@stripey.com wrote: Erik Vorhes writes: A use-case for person's name in the context of cite: In reference to many Classical texts one will often refer to the author in lieu of the title (or in some cases that author's corpus). That isn't an argument for people's names _in general_ being marked up; it's an argument for marking them up in the specific case where they are used as (nicknames of) titles of works. I never suggested otherwise. I want to be able to mark up names, etc., not just titles of works, with cite when the context is appropriate. That is, I want to mark up these things when they function as an attribution. (As I have previously detailed.) E.g.: pYou should read citeHerodotus/cite./p That's using Herodotus as the title of a work. In many fields it's common to refer to well-known works by nicknames, such as 'Smith Thomas', 'The Dragon Book', 'The Red Book', or 'The White Album'. So cite should be used for them. I feel here that you're stretching the definition of title of work beyond its usefulness. If we can use aliases within cite, great, but that seems to make more apparent the usefulness of having cite be for more than just title of work. Indeed, titles of works and these other examples more readily fall under the rubric of something for attribution. (I'm working on more specific wording but wanted to get this out there.) But it doesn't follow that cite should be used for any other occurrences of those terms -- the people Smith and Thomas, or a book which just happens to be red. Really? ;) Erik
Re: [whatwg] notation for typographical uncertainty
ddailey wrote on 9/20/2009 7:43 PM: I'm saying to son: if you can't figure out what it says, type the characters you are sure about. Use '?' marks for the letters that you aren't sure about. You might consider using the Unicode Replacement Character, which is used by Unicode to replace an incoming character whose value is unknown or unrepresentable in Unicode: http://www.fileformat.info/info/unicode/char/fffd/index.htm - Bil
Re: [whatwg] object behavior
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 instantiation and destroying and has absolutely no effect on @src and @data resource fetching. Imo, yes. Especially given your HTML example, where the behavior difference is easy to stumble on by trying to get the contentDocument of the object and work with it. What about mobile browsers specifically? Using display: none as a defer might be a good thing. Maybe that's why webkit and Opera do what they do in the first place. It's like load on demand. I think Opera even defers the fetching of display: none images until the display is changed. There is @declare on object, but you have to have another object point to it to get it going. And, @declare isn't really supported. 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. (As for display: none destroying, I don't know if that's ever needed on mobile) 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 don't know. Whatever everyone thinks is best. Just giving ideas and trying to think of all the cases. -- Michael
Re: [whatwg] object behavior
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 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. 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)? 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. -Boris
Re: [whatwg] object behavior
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 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
[whatwg] Navigation events generated during unload
I looked around in the HTML5 draft, but it wasn't obvious to me if it explains how to handle navigation events generated during the unload event. As far as I can tell by testing browsers, these navigation events are ignored. Adam
