Re: [whatwg] should we add beforeload/afterload events to the web platform?
On Wed, 11 Jan 2012 15:51:47 +0100, Boris Zbarsky bzbar...@mit.edu wrote: On 1/11/12 6:59 AM, Simon Pieters wrote: http://software.hixie.ch/utilities/js/live-dom-viewer/saved/1297 Might not be cross-browser yet (e.g. Opera seems to run the image's onload handler), but should work per spec I think. Well, the load can't be prevented if it's speculatively loaded it before the script has executed, but maybe that's fine for the use case. This also doesn't prevent rendering (which can easily start before DOMContentLoaded), doesn't prevent execution of script in the document that's being loaded, etc. Sure it does (or at least should, and does in Firefox). Note that it removes the root element when the script element is executed, not at DOMContentLoaded. It does the transformation and puts the root element *back* at DOMContentLoaded. Scripts don't run when parsed into the other document since it is a different document than the one the HTML parser runs on. They don't run when the root element is put back, either, since they are marked as already-executed, I think. The only way something could be rendered with the above script before it runs is in Opera with DSE enabled. Again, the hard part of doing a transformation on HTML is not doing the transformation; it's preventing the transformation source document from being treated as usual. -- Simon Pieters Opera Software
Re: [whatwg] should we add beforeload/afterload events to the web platform?
On 1/12/12 5:16 AM, Simon Pieters wrote: Note that it removes the root element when the script element is executed, not at DOMContentLoaded. Ah, I missed that. I guess the HTML5 parsing algorithm means that now the elements are parsed into the other document, eh? That's actually pretty cute. I wonder whether we can get the mobify folks to switch to this -Boris
[whatwg] video element not ready for prime time
A few comments about the video element from the point of view of an HTML author. Currently it is not particularly useful, and there is nothing to encourage me to use it rather than embed Firstly if I use a video with the src attribute e.g. video src='myvideo.mp4' controls and my user agent does not support the format, all I get (in my versions of Opera and Firefox) is a blank screen. No message (as I would get with embed) and as far as I can see there is no way for me as an author to know that the video is not being played so I cannot code a 'write around'. The option is to make several formats of the same video, e.g. myvideo.mp3, myvideo.mp4, myvideo.ogg etc. and place them in child source elements in the hope that one of the formats will be displayed. Even here I have a problem. In which order does the user-agent check the source files (in Chrome it seems to be in the order in which they are written, but there is no guidance here in the spec. Also will my user agent down-load the file that it cannot play, thus using up band-width? I think these questions need to be resolved before authors will start using video for regular pages. The same comments go for the audio element. Frank Boumphrey
Re: [whatwg] should we add beforeload/afterload events to the web platform?
On Thu, Jan 12, 2012 at 6:22 AM, Boris Zbarsky bzbar...@mit.edu wrote: On 1/12/12 5:16 AM, Simon Pieters wrote: Note that it removes the root element when the script element is executed, not at DOMContentLoaded. Ah, I missed that. I guess the HTML5 parsing algorithm means that now the elements are parsed into the other document, eh? That's actually pretty cute. I wonder whether we can get the mobify folks to switch to this This only works for the initial page load, no?
Re: [whatwg] video element not ready for prime time
On 1/12/12 12:46 PM, Francis Boumphrey wrote: and as far as I can see there is no way for me as an author to know that the video is not being played If true, this should be simple to fix. But I would think that there was a way to detect this via the readyState or error properties. In particular, if the error.code is MEDIA_ERR_SRC_NOT_SUPPORTED that would seem to be a strong indication that the format could not be played, right? Even here I have a problem. In which order does the user-agent check the source files (in Chrome it seems to be in the order in which they are written, but there is no guidance here in the spec. http://www.whatwg.org/specs/web-apps/current-work/multipage/the-video-element.html#concept-media-load-algorithm step 3 says: Otherwise, if the media element does not have a src attribute but has a source element child, then let mode be children and let candidate be the first such source element child in tree order. and same section starting at Otherwise, the source elements will be used; run these substeps: explicitly talks about trying the source elements in document order. So what Chrome is doing is exactly what the spec requires. Also will my user agent down-load the file that it cannot play, thus using up band-width? That's up to the to some extent UA, but I'd think that if you list a type=whatever and the UA doesn't support the type, any sane UA would skip the download. Specifically, see substep 5 of the run these substeps section mentioned above: 5. If candidate has a type attribute whose value, when parsed as a MIME type (including any codecs described by the codecs parameter, for types that define that parameter), represents a type that the user agent knows it cannot render, then end the synchronous section, and jump down to the failed step below. So the only way for a UA to not skip the source is if it doesn't know it can't render the type. -Boris
Re: [whatwg] should we add beforeload/afterload events to the web platform?
On 1/12/12 1:27 PM, Ojan Vafai wrote: This only works for the initial page load, no? Yes, but does mobify use the beforeload handler after the initial page load? They're generating new content and document.writing it back into the document, and that new content needs to perform loads, so I would think they aren't so much. -Boris
Re: [whatwg] input type=date
Hey all, Asked this on IRC and got no response so here goes: Is there a way to specify the locale input type=daye should use or does it simply use the current locale? If so, does it choose the server locale or the user locale? Kind Regards, Schalk Web Developer @ Mozilla
Re: [whatwg] video element not ready for prime time
On Thu, Jan 12, 2012 at 9:46 AM, Francis Boumphrey boumphre...@gmail.comwrote: In which order does the user-agent check the source files (in Chrome it seems to be in the order in which they are written, but there is no guidance here in the spec. The spec does specify this, and chrome fails to follow the spec. See http://webk.it/75154 for details. Cheers, -a
Re: [whatwg] input type=date
I think the following note answers your question: Note: The format shown to the user is independent of the format used for form submission. Browsers are encouraged to use user interfaces that present dates according to the conventions of the user's preferred locale. - http://www.whatwg.org/specs/web-apps/current-work/multipage/states-of-the-type-attribute.html#date-state-(type=date) On Thu, Jan 12, 2012 at 1:33 PM, Schalk Neethling sneethl...@mozilla.comwrote: Hey all, Asked this on IRC and got no response so here goes: Is there a way to specify the locale input type=daye should use or does it simply use the current locale? If so, does it choose the server locale or the user locale? Kind Regards, Schalk Web Developer @ Mozilla
Re: [whatwg] input type=date
yep, that answers my question but, is there any work done to perhaps add an attribute where the author can specify the date format they require/want? Thanks, Scott - Original Message - From: Scott González scott.gonza...@gmail.com To: Schalk Neethling sneethl...@mozilla.com Cc: whatwg@lists.whatwg.org Sent: Thursday, January 12, 2012 8:39:21 PM Subject: Re: [whatwg] input type=date I think the following note answers your question: Note: The format shown to the user is independent of the format used for form submission. Browsers are encouraged to use user interfaces that present dates according to the conventions of the user's preferred locale. - http://www.whatwg.org/specs/web-apps/current-work/multipage/states-of-the-type-attribute.html#date-state-(type=date) On Thu, Jan 12, 2012 at 1:33 PM, Schalk Neethling sneethl...@mozilla.com wrote: Hey all, Asked this on IRC and got no response so here goes: Is there a way to specify the locale input type=daye should use or does it simply use the current locale? If so, does it choose the server locale or the user locale? Kind Regards, Schalk Web Developer @ Mozilla
Re: [whatwg] input type=date
I don't believe so. I also don't think there's any way to do the equivalent in JavaScript, e.g., asking for a Date object to generate a string representation in some other locale (aside from UTC). From personal experience, I've found that when users need to enter times for timezones other than their own, the chance of error is high. 2012/1/12 Schalk Neethling sneethl...@mozilla.com yep, that answers my question but, is there any work done to perhaps add an attribute where the author can specify the date format they require/want? Thanks, Scott - Original Message - From: Scott González scott.gonza...@gmail.com To: Schalk Neethling sneethl...@mozilla.com Cc: whatwg@lists.whatwg.org Sent: Thursday, January 12, 2012 8:39:21 PM Subject: Re: [whatwg] input type=date I think the following note answers your question: Note: The format shown to the user is independent of the format used for form submission. Browsers are encouraged to use user interfaces that present dates according to the conventions of the user's preferred locale. - http://www.whatwg.org/specs/web-apps/current-work/multipage/states-of-the-type-attribute.html#date-state-(type=date) On Thu, Jan 12, 2012 at 1:33 PM, Schalk Neethling sneethl...@mozilla.com wrote: Hey all, Asked this on IRC and got no response so here goes: Is there a way to specify the locale input type=daye should use or does it simply use the current locale? If so, does it choose the server locale or the user locale? Kind Regards, Schalk Web Developer @ Mozilla
Re: [whatwg] input type=date
On 12/01/2012, at 6:44 PM, Schalk Neethling wrote: yep, that answers my question but, is there any work done to perhaps add an attribute where the author can specify the date format they require/want? Thanks, Scott Yes, there is an open bug about this. It is recommended that UAs should use the element's language for formatting into localized strings: https://www.w3.org/Bugs/Public/show_bug.cgi?id=13408 Also note that there is another open bug regarding the application of calendars to date\time controls with a proposed fix to apply the unicode extensions: https://www.w3.org/Bugs/Public/show_bug.cgi?id=15278 Thanks, Cameron Jones
Re: [whatwg] input type=date
Hey Scott, There will need to be a js, or server side function if js is not available, function that converts whatever you get to the format you require/expact. I was just curious what the default behavior would be for the input element and, whether there would be a way to indicate which format you wish returned. Schalk - Original Message - From: Scott González scott.gonza...@gmail.com To: Schalk Neethling sneethl...@mozilla.com Cc: whatwg@lists.whatwg.org Sent: Thursday, January 12, 2012 8:53:13 PM Subject: Re: [whatwg] input type=date I don't believe so. I also don't think there's any way to do the equivalent in JavaScript, e.g., asking for a Date object to generate a string representation in some other locale (aside from UTC). From personal experience, I've found that when users need to enter times for timezones other than their own, the chance of error is high. 2012/1/12 Schalk Neethling sneethl...@mozilla.com yep, that answers my question but, is there any work done to perhaps add an attribute where the author can specify the date format they require/want? Thanks, Scott - Original Message - From: Scott González scott.gonza...@gmail.com To: Schalk Neethling sneethl...@mozilla.com Cc: whatwg@lists.whatwg.org Sent: Thursday, January 12, 2012 8:39:21 PM Subject: Re: [whatwg] input type=date I think the following note answers your question: Note: The format shown to the user is independent of the format used for form submission. Browsers are encouraged to use user interfaces that present dates according to the conventions of the user's preferred locale. - http://www.whatwg.org/specs/web-apps/current-work/multipage/states-of-the-type-attribute.html#date-state-(type=date) On Thu, Jan 12, 2012 at 1:33 PM, Schalk Neethling sneethl...@mozilla.com wrote: Hey all, Asked this on IRC and got no response so here goes: Is there a way to specify the locale input type=daye should use or does it simply use the current locale? If so, does it choose the server locale or the user locale? Kind Regards, Schalk Web Developer @ Mozilla
[whatwg] should we add beforeload/afterload events to the web platform?
On Jan 12 10:32, Boris Zbarsky wrote: Yes, but does mobify use the beforeload handler after the initial page load? They're generating new content and document.writing it back into the document, and that new content needs to perform loads, so I would think they aren't so much. At the moment, we are capturing raw page HTML by containing it within style with nonstandard type or textarea elements. If we know that a page is well-behaved and has no textareas in head or styles in body, we can document.write an opening textarea to capture what's in head, and capture page body with a similarly written style. Once we capture raw HTML text, we rename resource-loading attributes (src, href), allowing us to build and process DOM representation without any external requests firing. Beforeload comes in when our assumptions are violated. If the page has a style.../style within body and we don't take preventive measures, our capturing method will allow everything after /style to leak into DOM. So, we use beforeload (along with some other tricks) to block resources that elude capture. We don't need beforeload after that, as we control all HTML we return into the page. Now that Henri Sivonen showed us that plaintext can be used for capturing, we could get away with not using beforeload at all. However, it may be useful for folks who use smaller, more controlled transformations. For example, @media-controlled mobile view of a page originally designed for desktop will typically include all desktop assets. beforeload can fix that, as desktop resource loads could be cancelled or even replaced with mobile-specific ones without complete HTML reconstruction. -- Roman Rudenko
Re: [whatwg] should we add beforeload/afterload events to the web platform?
On 1/12/12 2:19 PM, Roman Rudenko wrote: For example, @media-controlled mobile view of a page originally designed for desktop will typically include all desktop assets. beforeload can fix that, as desktop resource loads could be cancelled or even replaced with mobile-specific ones without complete HTML reconstruction. Except they can't, because beforeload fires after the load has started in many cases, right? -Boris
Re: [whatwg] input type=date
On 12/01/2012, at 7:20 PM, Schalk Neethling wrote: Ok, so reading some of the discussion, maybe being more precise with our html lang= would help or, is this not inherited down the chain so, when declaring input type=date, one needs to specify lang=en-US? Will that have the desired effect as described earlier in the thread? Schalk No, the current state is that the user's preferred locale will always be used for localization. If the language resolution algorithm was being used you would be able to define it through the lang attribute or through http headers. If you want to have specific localization you will have to roll your own, you could still define the language on the attribute but you would need to perform the formatting yourself using javascript. Thanks, Cam
[whatwg] ProgressEvents for Images
A group of us at Adobe has been looking into adding support for ProgressEvents to images. The overall goal is to simplify image download progress reporting by supporting roughly the same progress events as XHR and the File API for image elements. For example one could connect an image to a progress element like this: img id=image src=sample.jpg onloadstart=showProgressBar() onprogress=updateProgressBar(event) onloadend=hideProgressBar()/ Developers have taken various tacks to enable progress reporting, for example in some cases XHR can be used to download image files. Max Vujovic just published a blog about the practicalities of doing so: http://blogs.adobe.com/openweb/2012/01/13/html5-image-progress-events/. We think it would be preferable to provide support for image progress events directly. We're working on a prototype implementation for WebKit and have filed a bug that explains what we're up to in a little more detail: https://bugs.webkit.org/show_bug.cgi?id=76102). It's probably worth pointing out that the beforeload event, which is currently under discussion, addresses a different use case. Our proposal is intended to enable applications to give the user feedback about image download progress, it's not intended to enable security or efficiency by preemptively blocking or transforming image downloads. We'd appreciate feedback on this proposal.
Re: [whatwg] Readiness of script-created documents
On Mon, 20 Jun 2011, Henri Sivonen wrote: http://software.hixie.ch/utilities/js/live-dom-viewer/saved/1039 It says complete in Firefox, loading in Chrome and Opera and uninitialized in IE. The spec requires complete. readyState is originally an IE API. Why doesn't the spec require uninitialized? (The implementation in Gecko is so recent that it's quite possible that Gecko followed the spec and the spec just made stuff up as opposed to the spec following Gecko.) On Mon, 20 Jun 2011, Jonas Sicking wrote: complete seems like the most useful and consistent value which would seem like a good reason to require that. Jonas is correct. Since there was no interop here I figured we might as well go with what made sense. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] video element not ready for prime time
On 13/01/2012, at 4:46 AM, Francis Boumphrey wrote: Firstly if I use a video with the src attribute e.g. video src='myvideo.mp4' controls and my user agent does not support the format, all I get (in my versions of Opera and Firefox) is a blank screen. No message (as I would get with embed) and as far as I can see there is no way for me as an author to know that the video is not being played so I cannot code a 'write around'. I brought up this same concern in Dec 2009 and Hixie seemed to concur: On 9/02/2010, Ian Hickson wrote: Indeed, if we can't get a common codec, the spec as written today is not a particularly good design. If we really can't solve this problem, then we'll have to introduce a declarative way of saying if you can't play any of the videos, here's what I want you to do instead -- but hopefully we won't have to go there. (see http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2010-February/025028.html) I'd argue that while we did receive in WebM a common codec it does not enjoy the sort of universal adoption required to be able to mandate its support in the spec, so on that logic, I think establishing a declarative fallback mechanism is probably required to prevent a situation where you cannot write a robust HTML5 page with video and without resorting to JS. —Kit Grose
Re: [whatwg] ProgressEvents for Images
I've wanted this before. It would be useful for more granular loading progress indicators for eg. WebGL apps, for example, and anything else that loads images without displaying them as they load. On Jan 12, 2012 4:20 PM, Hans Muller hmul...@adobe.com wrote: A group of us at Adobe has been looking into adding support for ProgressEvents to images. The overall goal is to simplify image download progress reporting by supporting roughly the same progress events as XHR and the File API for image elements. For example one could connect an image to a progress element like this: img id=image src=sample.jpg onloadstart=showProgressBar() onprogress=updateProgressBar(event) onloadend=hideProgressBar()/ Developers have taken various tacks to enable progress reporting, for example in some cases XHR can be used to download image files. Max Vujovic just published a blog about the practicalities of doing so: http://blogs.adobe.com/openweb/2012/01/13/html5-image-progress-events/. We think it would be preferable to provide support for image progress events directly. We're working on a prototype implementation for WebKit and have filed a bug that explains what we're up to in a little more detail: https://bugs.webkit.org/show_bug.cgi?id=76102). It's probably worth pointing out that the beforeload event, which is currently under discussion, addresses a different use case. Our proposal is intended to enable applications to give the user feedback about image download progress, it's not intended to enable security or efficiency by preemptively blocking or transforming image downloads. We'd appreciate feedback on this proposal.
Re: [whatwg] video element not ready for prime time
On Thu, Jan 12, 2012 at 12:46 PM, Francis Boumphrey boumphre...@gmail.com wrote: e.g. video src='myvideo.mp4' controls and my user agent does not support the format, all I get (in my versions of Opera and Firefox) is a blank screen. No message (as I would get with embed) and as far as I can see there is no way for me as an author to know that the video is not being played so I cannot code a 'write around'. Boris answered the rest of your questions, but here's a way to detect errors: data:text/html,!doctype html video src='nonexistent.mp4' controls onerror='alert(error)'/video If you use source, the error event is fired at the source element instead and doesn't bubble (why not?), so you have to put onerror on the source element instead. I don't know why UAs don't provide their own error messages, though. They provide error icons for failed image loads.
Re: [whatwg] What it means for attributes of input to apply or not apply
On Wed, 22 Jun 2011, Edward O'Connor wrote: When adding the placeholder= attribute to input type=number, one of our engineers asked me about the behavior of content attributes that don't apply to certain input types. Consider for example input type=range. The spec says [t]he following content attributes *must not be specified* and *do not apply* to the element: [�] placeholder[�] (emphasis mine). The first bit (must not be specified) is clear: it's an authoring conformance requirement. The second bit (does not apply to the element), however, isn't clear. Is it a UA conformance requirement? What does it mean? I *think* it means that the placeholder= attribute has no effect on the rendering of input type=range. Does it also mean that the placeholder= content attribute shouldn't be reflected as an IDL attribute on input elements of type=range? In Safari 5, Firefox 4, and Opera 11, placeholder= gets reflected as an IDL attribute, regardless of the value of type=. On Wed, 22 Jun 2011, Aryeh Gregor wrote: It's reflected regardless of the type: http://www.whatwg.org/specs/web-apps/current-work/multipage/the-input-element.html#dom-input-placeholder does not apply to the element could use clarification, though. On Thu, 23 Jun 2011, Ian Hickson wrote: It's a hook used here: http://www.whatwg.org/specs/web-apps/current-work/complete.html#common-input-element-attributes I'll add a hyperlink or something to make it clearer. Now done. Let me know if it's still confusing. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Outdated Implementation Statuses?
On Thu, 23 Jun 2011, Etienne Levesque Guitard wrote: As I mentioned on http://forums.whatwg.org/bb3/viewtopic.php?f=1t=4663, it seems that many of the implementation statuses on the spec documents are outdated. Example: Isn't the header element already supported by many browsers? I can confirm Firefox and Chromium being able to style this element. Anyone has any idea on this? On Thu, 23 Jun 2011, Tab Atkins Jr. wrote: The implementation statuses are not automatically generated - they're updated when someone cares enough to update them. Anyone can do so, though it's not very discoverable. Hold down Ctrl+Alt and double-click the status box, and it'll pop up a login prompt. Make an account, then you can change the statuses however you want. Indeed. On Fri, 24 Jun 2011, Aryeh Gregor wrote: Maybe this should be documented clearly through a how to update link on the status boxes or such? On Fri, 24 Jun 2011, Etienne Levesque Guitard wrote: Except that having it not documented might be a good idea in reducing unwanted changes; as in only someone who's really interested will make the efforts of signing up to the mailing list and asking how it's done. I made a change a few weeks ago to try to improve matters without going too far, so now if you hover over the boxes you get an edit link. Hopefully that helps a little... -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] should we add beforeload/afterload events to the web platform?
On Thu, Jan 12, 2012 at 11:32 AM, Boris Zbarsky bzbar...@mit.edu wrote: For example, @media-controlled mobile view of a page originally designed for desktop will typically include all desktop assets. beforeload can fix that, as desktop resource loads could be cancelled or even replaced with mobile-specific ones without complete HTML reconstruction. Except they can't, because beforeload fires after the load has started in many cases, right? Blocking is possible under some circumstances. Webkit differentiates between normal parser and speculative parser. Speculative parser is launched only if normal parser is blocked on execution of a script. So, one could use beforeload to block resources in Webkit, for as long as no synchronous scripts are allowed to slip through. Unfortunately, one runaway script blocks the parser and spoils blocking for anything after itself. This might not work as nicely in Firefox, which, according to Boris, does not maintain separation between main and speculative parser. Even if that does not work, beforeload can prevent processing of needlessly fetched resource (which makes it behave more like 'beforeprocess', suggested by Boris). -- Roman Rudenko
Re: [whatwg] should we add beforeload/afterload events to the web platform?
On 1/12/12 9:23 PM, Roman Rudenko wrote: Blocking is possible under some circumstances. Webkit differentiates between normal parser and speculative parser. Speculative parser is launched only if normal parser is blocked on execution of a script. So, one could use beforeload to block resources in Webkit, for as long as no synchronous scripts are allowed to slip through. Unfortunately, one runaway script blocks the parser and spoils blocking for anything after itself. I just thought about this some more... This caveat makes beforeload not very helpful for blocking or redirecting loads from only part of a document, and for blocking loads from the whole document there are the better solutions mentioned earlier in this thread. -Boris
