[whatwg] input[type=date] placeholder attribute and displayed date format
I've recently been implementing date controls for a web application to be primarily used on mobile browsers, and discovered that the placeholder attribute is considered forbidden for use on input[type=date] elements. I would like to propose that this be changed. Since the spec does not (and should not) mandate the specific implementation of the interface to a date element, not permitting a placeholder means that where a browser chooses to implement the control in a similar vein to an ordinary text input (i.e. with free text entry), this control can't follow the same pattern of label + example via placeholder. I've mocked this up with a use case which I foresee as being relatively common where the browser implements the control like this: https://img.skitch.com/20120117-tmh1bu3wxcarxr94kyk147h3k2.png Another issue with input[type=date] elements relates to how the *value* of the date and how it is *displayed* may want to be different. In iOS 5.0, Mobile Safari implements the input[type=date] control with a native spin control, but as this is independent of how the control is displayed within the webpage itself (unlike the more text input-like approach), it also formats the date in a different format to the ISO format that input[type=date] mandates (example: https://img.skitch.com/20120117-grwdr7ebd56iww617ypatqqa88.png). The ISO date format has the advantage over different local date formats in that it is unambiguous, but it isn't necessarily the most user friendly. I would like therefore to propose that an optional dateformat attribute be added to the input element, to permit different formats to be used to * display* a selected date. My initial feeling is that some flavour of the strftime syntax implemented by several languages (e.g. http://ruby-doc.org/core-1.9.3/Time.html#method-i-strftime) is probably the best way of specifying the format within this attribute. An example usage of this might thus be: input type=date name=dateofbirth dateformat=%-d %b, %Y This would then create a date input whose selected date would be formatted as per the screenshot above. Comments or observations of important points I've missed welcomed! ~B
Re: [whatwg] should we add beforeload/afterload events to the web platform?
On Sun, Jan 15, 2012 at 11:23 PM, Boris Zbarsky bzbar...@mit.edu wrote: Preventing _all_ loads for a document based on some declarative thing near the start of the document, on the other hand, should not be too bad. A page-wide disable optimizations flag could easily be cargo-culted into something harmful. Consider if the narrative becomes that setting such a flag is good for mobile or something. A per-element disable optimizations attribute would be slightly less dangerous, since authors couldn't just set it once and forget it. If that plus a beforeprocess event addresses the majority of the web-facing use cases, we should consider adding that. So what are the Web-facing use cases? As in: What are people trying to accomplish with client-side transformations? -- Henri Sivonen hsivo...@iki.fi http://hsivonen.iki.fi/
Re: [whatwg] should we add beforeload/afterload events to the web platform?
On 1/17/12 7:49 AM, Henri Sivonen wrote: On Sun, Jan 15, 2012 at 11:23 PM, Boris Zbarskybzbar...@mit.edu wrote: Preventing _all_ loads for a document based on some declarative thing near the start of the document, on the other hand, should not be too bad. A page-wide disable optimizations flag could easily be cargo-culted into something harmful. Consider if the narrative becomes that setting such a flag is good for mobile or something. Who said anything about disable optimizations? I suggested a flag to prevent all subresource loads, not just speculative preloads. Basically a treat this as a data document flag. If that plus a beforeprocess event addresses the majority of the web-facing use cases, we should consider adding that. So what are the Web-facing use cases? As in: What are people trying to accomplish with client-side transformations? Well, what mobify is apparently trying to accomplish is take an existing (not-mobile-optimized, or in other words typically ad-and-float-and-table-laden) page and modify it to look reasonable on a small screen. That includes not loading some of the stylesheets and various changes to the DOM, as far as I can tell. -Boris
[whatwg] HTML Audio Element removal from DOM
When an audio element is removed from the DOM while playing, is that element paused? That seems to be the behavior in Chrome. I'm looking for clarification. -Charles
Re: [whatwg] HTML Audio Element removal from DOM
On Tue, Jan 17, 2012 at 1:19 PM, Charles Pritchard ch...@jumis.com wrote: When an audio element is removed from the DOM while playing, is that element paused? That seems to be the behavior in Chrome. I'm looking for clarification. I was able to repro this in both Safari 5.1.1 and Chrome 17.0.963.26 dev so perhaps it's a bug in WebKit as the spec states the following: Media elements that are potentially playing while not in a Document must not play any video, but should play any audio component. Media elements must not stop playing just because all references to them have been removed; only once a media element is in a state where no further audio could ever be played by that element may the element be garbage collected. Andrew
Re: [whatwg] HTML Audio Element removal from DOM
On Tue, Jan 17, 2012 at 1:19 PM, Charles Pritchard ch...@jumis.com wrote: When an audio element is removed from the DOM while playing, is that element paused? That seems to be the behavior in Chrome. I'm looking for clarification. Does this only apply to elements that were previously in the DOM and then removed, or also those that started out outside the DOM? I agree with Andrew - this appears to be a webkit bug. ~TJ
Re: [whatwg] HTML Audio Element removal from DOM
On Jan 17, 2012, at 1:32 PM, Andrew Scherkus wrote: On Tue, Jan 17, 2012 at 1:19 PM, Charles Pritchard ch...@jumis.com wrote: When an audio element is removed from the DOM while playing, is that element paused? That seems to be the behavior in Chrome. I'm looking for clarification. I was able to repro this in both Safari 5.1.1 and Chrome 17.0.963.26 dev so perhaps it's a bug in WebKit as the spec states the following: Media elements that are potentially playing while not in a Document must not play any video, but should play any audio component. Media elements must not stop playing just because all references to them have been removed; only once a media element is in a state where no further audio could ever be played by that element may the element be garbage collected. That is for an element that is playing when it is not in the document. Look at the end of http://www.whatwg.org/specs/web-apps/current-work/multipage/the-video-element.html#playing-the-media-resource for the definition of what to do when an element is removed from the DOM: When a media element is removed from a Document, the user agent must run the following steps: 1. Asynchronously await a stable state, allowing the task that removed the media element from the Document to continue. The synchronous section consists of all the remaining steps of this algorithm. (Steps in the synchronous section are marked with.) 2. If the media element is in a Document, abort these steps. 3. If the media element's networkState attribute has the value NETWORK_EMPTY, abort these steps. 4. Pause the media element. eric
Re: [whatwg] HTML Audio Element removal from DOM
On Tue, Jan 17, 2012 at 1:38 PM, Eric Carlson eric.carl...@apple.comwrote: On Jan 17, 2012, at 1:32 PM, Andrew Scherkus wrote: On Tue, Jan 17, 2012 at 1:19 PM, Charles Pritchard ch...@jumis.com wrote: When an audio element is removed from the DOM while playing, is that element paused? That seems to be the behavior in Chrome. I'm looking for clarification. I was able to repro this in both Safari 5.1.1 and Chrome 17.0.963.26 dev so perhaps it's a bug in WebKit as the spec states the following: Media elements that are potentially playing while not in a Document must not play any video, but should play any audio component. Media elements must not stop playing just because all references to them have been removed; only once a media element is in a state where no further audio could ever be played by that element may the element be garbage collected. That is for an element that is playing when it is not in the document. Look at the end of http://www.whatwg.org/specs/web-apps/current-work/multipage/the-video-element.html#playing-the-media-resourcefor the definition of what to do when an element is removed from the DOM: When a media element is removed from a Document, the user agent must run the following steps: 1. Asynchronously await a stable state, allowing the task that removed the media element from the Document to continue. The synchronous section consists of all the remaining steps of this algorithm. (Steps in the synchronous section are marked with.) 2. If the media element is in a Document, abort these steps. 3. If the media element's networkState attribute has the value NETWORK_EMPTY, abort these steps. 4. Pause the media element. Ah yes! I got the scenarios mixed up. The section I quoted is for programatically creating elements outside of the DOM (i.e., new Audio()). Andrew
Re: [whatwg] Media Player Seek Bars: Problems and Suggestions
On Fri, Jan 13, 2012 at 1:58 AM, Hugh Guiney hugh.gui...@gmail.com wrote: - A preChange event that fires while a range input is hovered over, as the coordinate of a pointing device is advanced in either direction along the input's axis. - A readonly attribute preValue that holds the value that corresponds to the input's currently pointed-to coordinate. That way, an author could write a script that modifies a range input's title attribute, etc., with the prospective time. I'd like either of these! They'd be useful for lots of things other than video seeking - knowing what value you're about to switch to is useful in lots of things that use a range input. The second problem is that at present, range inputs are not quite sufficient semantically for marking up seek bars. Seek bars typically display not only a thumb, but also a progress bar that displays what percentage of the video is loaded. Obviously, we have progress for this, and so theoretically one could use both a range input and a progress bar together, this falls short for a few reasons: - They are separate elements when seeking UI is almost universally represented as a single control. Although it's possible to position a range input on top of a progress bar using CSS, for users with CSS off, it takes up twice as much space as it needs to. - Seek bars typically have 3 distinct progress indicators: not buffered (transparent/no color), buffered (translucent color), and buffered + played (opaque color). Currently, progress bars can only display 2 styles: translucent and opaque. - When seeking to points that have not yet been buffered, some seek bars will leave the unbuffered portions translucent, starting the played + buffered color not from the minimum value point but from wherever the user seeks to. Advancements in CSS would not address this as there's only min, value, and max to work with; there's no way to specify [a] concurrent value(s) to represent the discontinuous progression. Possible solutions would be to address these shortcomings in progress and then somehow specify that a range input and a progress bar are connected and should be rendered as a single UI in supporting UAs and separately as fallback; or, more simply: introduce input type=seek explicitly for controlling media elements. I support this, as it's also useful outside of video seeking. Specifically, I support: (a) the ability to specify multiple non-contiguous or overlapping progress ranges on a range input (b) exposing these ranges to CSS for styling Implementing this by combining input type=range and multiple progress elements isn't ideal, because you want the progress ranges to display above the input's background but below the grabber. (In the typical UI pattern, you want them to appear in the track that the grabber slides in.) ~TJ
Re: [whatwg] Should events be paused on detached iframes?
On Tue, 12 Jul 2011, Boris Zbarsky wrote: On 6/13/11 8:09 PM, Ian Hickson wrote: It's possible to switch these relevant checks to walk the ownerDocument chain instead, say. Then we need to audit all the callsites to make sure this makes sense at them and figure out what to do for the ones where it doesn't. (For example, should window.alert on the window of an iframe not in the DOM put up a dialog in a tab based on the ownerDocument of the iframe? Or not put one up at all?) It should put it up in the context of the top-level browsing context of the script that led to that point (the first script). This is the same as if someone in one tab calls another tab's script and that script calls alert(). Is that last what browsers actually do? I'm pretty sure that's not what Gecko does... If there's specific features in the spec that are incorrectly specified, I'm happy to address them. Send mail with a test case showing the problem. There are also issues in terms of network loads that are live when an iframe is removed from its document, whether network loads can _start_ in such a removed iframe, what the styling behavior, if any, is (e.g. how should media query matching work?), layout behavior, if any (what's the initial containing block size?). What should happen if click() is called on anchors? Or is that covered by the events thing above? Basically, pretty much every single aspect of the platform's behavior needs to be sanity-checked in this context... Well, I'm not sure I'm up for sanity checking the entire spec, especially for edge case areas like this where interop isn't really present anyway so it's not clear what a wrong answer would be. I'm also a little saddened that there has been absolutely no feedback so far from the people who've been implementing this, even in cases when the current spec doesn't really cover behavior We're not going to get to interop that way. Indeed. The best way forward here might be just to add tests to the test suite and see who complains... -- 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 Sun, Jan 15, 2012 at 1:23 PM, Boris Zbarsky bzbar...@mit.edu wrote: On 1/12/12 9:22 AM, Boris Zbarsky 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 Thinking back on this, this still has the issue of not preventing preloads. Again, preventing preloads on a per-load basis is a hard problem if you want to have sane parallelism. Preventing _all_ loads for a document based on some declarative thing near the start of the document, on the other hand, should not be too bad. Even this scheme doesn't work with a model like SPDY push or other bundling techniques or with more aggressive preloading that initiates loads before the main resource is loaded. It seems like there are two use cases: 1.) Monitoring/modifying/preventing network activity for a given resource load 2.) Monitoring/modifying/preventing DOM modifications that occur as the result of a resource load For (1) I can't think of any web-facing needs. For extensions, I believe this is better addressed by APIs that target the network layer more directly - for example proxy auto config scripts, or things like http://code.google.com/chrome/extensions/trunk/webRequest.html. For (2) I think this would be better addressed by using next-generation mutation events to observe (and potentially react) to the changes that occur when an img is loaded, for example. I struggle to think of good web-facing use cases for this, though. In any event I think that beforeload as it exists today is a bad API for the web and hope that we can stop exposing it to the web in WebKit (although I suspect it'll stick around for extension contexts, which is more acceptable in my view). - James If that plus a beforeprocess event addresses the majority of the web-facing use cases, we should consider adding that. -Boris
Re: [whatwg] should we add beforeload/afterload events to the web platform?
On 1/17/12 7:24 PM, James Robinson wrote: Even this scheme doesn't work with a model like SPDY push or other bundling techniques or with more aggressive preloading that initiates loads before the main resource is loaded. Er... you mean it initiates loads before it has any idea whether the main resource might have changed such that it no longer links to the objects in question? I agree that such aggressive preloading is impossible to control from the source document; an interesting question is whether it's desirable. I know that in the past when Gecko preloaded too aggressively we got huge complaints from various ad providers about bogus impressions 1.) Monitoring/modifying/preventing network activity for a given resource load 2.) Monitoring/modifying/preventing DOM modifications that occur as the result of a resource load For (1) I can't think of any web-facing needs. I believe mobify does in fact want (1) as much as it can to conserve bandwidth... In any event I think that beforeload as it exists today is a bad API for the web Good, we agree on that. ;) (although I suspect it'll stick around for extension contexts, which is more acceptable in my view). It's obviously just fine from my pov at that point. ;) -Boris
Re: [whatwg] should we add beforeload/afterload events to the web platform?
On Tue, Jan 17, 2012 at 4:29 PM, Boris Zbarsky bzbar...@mit.edu wrote: On 1/17/12 7:24 PM, James Robinson wrote: Even this scheme doesn't work with a model like SPDY push or other bundling techniques or with more aggressive preloading that initiates loads before the main resource is loaded. Er... you mean it initiates loads before it has any idea whether the main resource might have changed such that it no longer links to the objects in question? SPDY push allows the server to send down additional resources along with the main resource, before the client actually requests them. (The server, ideally, should know what resources the main resource links to.) ~TJ
Re: [whatwg] should we add beforeload/afterload events to the web platform?
On Tue, Jan 17, 2012 at 4:29 PM, Boris Zbarsky bzbar...@mit.edu wrote: On 1/17/12 7:24 PM, James Robinson wrote: Even this scheme doesn't work with a model like SPDY push or other bundling techniques or with more aggressive preloading that initiates loads before the main resource is loaded. Er... you mean it initiates loads before it has any idea whether the main resource might have changed such that it no longer links to the objects in question? The way that these sorts of schemes work is that the server knows that a set of resources are needed in addition to the main resource and it starts sending them down before the client has received/parsed the main resource. The server serving foo.html can have a pretty good idea about whether foo.html contains the string script src=foo.js so there isn't any real reason for it to not serve foo.js at the same time assuming that the underlying protocol can handle such a thing. In situations with high RTTs and reasonable bandwidth (like common mobile networks) this can be a big win. I bring this up to make sure that we aren't making promises about resource loads that we can't keep. - James I agree that such aggressive preloading is impossible to control from the source document; an interesting question is whether it's desirable. I know that in the past when Gecko preloaded too aggressively we got huge complaints from various ad providers about bogus impressions 1.) Monitoring/modifying/**preventing network activity for a given resource load 2.) Monitoring/modifying/**preventing DOM modifications that occur as the result of a resource load For (1) I can't think of any web-facing needs. I believe mobify does in fact want (1) as much as it can to conserve bandwidth... In any event I think that beforeload as it exists today is a bad API for the web Good, we agree on that. ;) (although I suspect it'll stick around for extension contexts, which is more acceptable in my view). It's obviously just fine from my pov at that point. ;) -Boris
Re: [whatwg] should we add beforeload/afterload events to the web platform?
On 1/17/12 7:37 PM, Tab Atkins Jr. wrote: SPDY push allows the server to send down additional resources along with the main resource, before the client actually requests them. (The server, ideally, should know what resources the main resource links to.) Ah, ok. Yeah, there's obviously no way the client can prevent that, nor should it try. -Boris
Re: [whatwg] should we add beforeload/afterload events to the web platform?
On 1/17/12 7:37 PM, James Robinson wrote: The way that these sorts of schemes work is that the server knows that a set of resources are needed in addition to the main resource and it starts sending them down before the client has received/parsed the main resource. The server serving foo.html can have a pretty good idea about whether foo.html contains the string script src=foo.js so there isn't any real reason for it to not serve foo.js at the same time assuming that the underlying protocol can handle such a thing. In situations with high RTTs and reasonable bandwidth (like common mobile networks) this can be a big win. I bring this up to make sure that we aren't making promises about resource loads that we can't keep. Yeah, makes sense. Such promises are precisely what I'd like to avoid, yes. -Boris
Re: [whatwg] HTML Audio Element removal from DOM
On Tue, 17 Jan 2012 16:19:37 -0500, Charles Pritchard ch...@jumis.com
wrote:
When an audio element is removed from the DOM while playing, is that
element paused?
That seems to be the behavior in Chrome. I'm looking for clarification.
It's the behavior in Firefox and Opera too.
In both cases below, the audio is paused when removed from the document.
When added back it's still paused and when you call play(), it continues
playing from where it left off.
!DOCTYPE html
html lang=en
head
meta charset=utf-8
title/title
script
window.addEventListener(DOMContentLoaded, function() {
var player = document.createElement(audio);
player.controls = true;
player.autoplay = true;
player.src = test.oga;
document.body.appendChild(player);
setTimeout(function() {
document.body.removeChild(player);
setTimeout(function() {
document.body.appendChild(player);
player.play();
}, 3000);
}, 7000);
}, false);
/script
/head
body
/body
/html
!DOCTYPE html
html lang=en
head
meta charset=utf-8
title/title
script
window.addEventListener(DOMContentLoaded, function() {
var player = document.getElementsByTagName(audio)[0];
setTimeout(function() {
player = document.body.removeChild(player);
setTimeout(function() {
player = document.body.appendChild(player);
player.play();
}, 3000);
}, 7000);
}, false);
/script
/head
body
audio controls autoplay src=test.oga/audio
/body
/html
--
Michael
Re: [whatwg] HTML Audio Element removal from DOM
The issue I'm having with webkit is with running play() immediately after
removeChild. Are you hearing an audible pause when doing so in Opera and FF? I
believe there should be no audible pause even though there is an event pause
and a loop/queue cycle.
-Charles
On Jan 17, 2012, at 9:54 PM, Michael A. Puls II shadow2...@gmail.com wrote:
On Tue, 17 Jan 2012 16:19:37 -0500, Charles Pritchard ch...@jumis.com wrote:
When an audio element is removed from the DOM while playing, is that
element paused?
That seems to be the behavior in Chrome. I'm looking for clarification.
It's the behavior in Firefox and Opera too.
In both cases below, the audio is paused when removed from the document. When
added back it's still paused and when you call play(), it continues playing
from where it left off.
!DOCTYPE html
html lang=en
head
meta charset=utf-8
title/title
script
window.addEventListener(DOMContentLoaded, function() {
var player = document.createElement(audio);
player.controls = true;
player.autoplay = true;
player.src = test.oga;
document.body.appendChild(player);
setTimeout(function() {
document.body.removeChild(player);
setTimeout(function() {
document.body.appendChild(player);
player.play();
}, 3000);
}, 7000);
}, false);
/script
/head
body
/body
/html
!DOCTYPE html
html lang=en
head
meta charset=utf-8
title/title
script
window.addEventListener(DOMContentLoaded, function() {
var player = document.getElementsByTagName(audio)[0];
setTimeout(function() {
player = document.body.removeChild(player);
setTimeout(function() {
player = document.body.appendChild(player);
player.play();
}, 3000);
}, 7000);
}, false);
/script
/head
body
audio controls autoplay src=test.oga/audio
/body
/html
--
Michael
Re: [whatwg] HTML Audio Element removal from DOM
On Wed, 18 Jan 2012 00:58:11 -0500, Charles Pritchard ch...@jumis.com
wrote:
The issue I'm having with webkit is with running play() immediately
after removeChild. Are you hearing an audible pause when doing so in
Opera and FF? I believe there should be no audible pause even though
there is an event pause and a loop/queue cycle.
In that situation (shown below), I hear a very quick blip in both Opera
and Chrome. In Firefox, I don't. In Firefox, it's completely seamless (as
good as if it were never paused).
!DOCTYPE html
html lang=en
head
meta charset=utf-8
title/title
script
window.addEventListener(DOMContentLoaded, function() {
var player = document.getElementsByTagName(audio)[0];
setTimeout(function() {
player = document.body.removeChild(player);
player.play();
}, 7000);
}, false);
/script
/head
body
audio controls autoplay src=test.oga/audio
/body
/html
--
Michael
