Re: [whatwg] Offline Web Apps
On Oct 11, 2007, at 6:47 PM, Robert O'Callahan wrote: On Oct 12, 2007 12:53 PM, Ian Hickson [EMAIL PROTECTED] wrote: The problem with isLocallyAvailable() -- as noted by Maciej on IRC -- is mostly one of race conditions. What if the resource was removed in between you asking for it and using it? Or added? In the contexts for which it was requested, race conditions are tolerable. For example in a mapping application, if you choose the wrong tile as a template for zooming, then you get an ugly transition but that's all. Seems like wrongly choosing one that is not actually locally available would leave a hole in your map. Or you might have a button that opens another offline application, and you want to disable the button if you think that application is not available; here a race condition would probably mean that the button is enabled but pressing it gives you an error page. In these cases isLocallyAvailable can be a useful hint even if it's occasionally wrong. Or what if you go offline (thus changing the rules) in between checking for and using the resource? That's why we have the 'whenOffline' parameter. I don't see how the whenOffline parameter addresses that problem that your online/offline state may change between the time you do the check and the time you try to load the resource. In fact, I'm not really sure how it is helpful, compared to just basing the check on the current online/offline state always. I'm going to punt on this for now, pending implementation and author experience. I'm certainly open to suggestions though. That's fine. A race-free API seems difficult to design. Because loads are typically asynchronous, I doubt you can do much better than start a regular load, and set a timer to go off and cancel the load and take other action if the load doesn't complete fast enough. The race-free approach would be to provide APIs to load resources only from the cache and to error out immediately if the the request can't be served locally. The problem with this is that there are a huge number of APIs to trigger a load: frame src, iframe src, window.location assignment, window.location.replace, img src, script src, link for a stylesheet, XMLHttpRequest, and that's just the obvious ones. I think a way to do an XMLHttpRequest that will only succeed if the data is cached would cover many cases, and is probably a reasonable extension to XHR (given the text of an html document, script or stylesheet, you can insert it into an appropriate element for use). The problem is binary formats, since XHR has no good way of returning the data yet and the elements that would consume them (img, video, audio, object) have no way to pass in raw bytes (using a data: URL to encode it would be poor form for image and probably unworkable for video). However, if those elements were extended with some way to set raw data then such an approach could work. At that point, isLocallyAvailable might possibly be useful solely as a UI hint, much as the POSIX access() / stat() calls are only useful as UI hints for openability. In fact, this is pretty much analogous to the potential pitfalls of access() vs. open(). You need to check whether open() succeeds, and pass it the right parameters to make sure it will fail if it shouldn't succeed, rather than trusting a pre-check with access() or stat(). Regards, Maciej
Re: [whatwg] Comments/questions on 4.6 Offline Web applications
Ian Hickson wrote: On Sat, 6 Oct 2007, Adam Roben wrote: Here are some comments and questions about section 4.6 Offline Web applications: Thanks for the feedback! It was very useful in making the spec better. Please do continue reviewing the spec! Glad to hear it! Can javascript: URIs be specified in the manifest? I guess currently this is allowed... I'm not sure how to work around this. Blacklisting them is a bad idea, as we'll forget some scheme that should be black-listed (e.g. vbscript:). Should we just say that you can only cache files that have the same scheme as the manifest? I've said that for now. That sounds reasonable to me. It may be worth stating in this section what the behavior is when a section or opportunistic caching namespace appears multiple times. The parsing algorithm makes this clear, but it would be clearer still to also state the behavior in this section. Well, that would be non-conforming. I'm not sure we want to tell authors what the error handling behaviour is when they ignore the conformance requirements... do we? I see. I was not looking at this part of the spec from an application author's perspective. In light of that, I think the current level of detail is appropriate. 4.6.4 - Steps 8.2 and 19.3.2 say that the user agent should discard cache. What does discard cache mean (in the case of an upgrade attempt, cache is a possibly in-use cache)? The discard cache step is never reached when cache is in use. Is the meaning really ambiguous? I'm not sure how else to say it. Somehow my eyes skipped over the phrase If this is a cache attempt. In the case of a cache attempt, I think discard is perfectly clear. Step 19 should specify what should happen if a URI that is already in the cache's online whitelist is to be added as an explicit, fallback, or dynamic entry. (Now step 20.) It does. Which is to say, it being on the online whitelist has no effect. Should it have an effect? We can omit the caching of such files if you want. Given that section 4.6.5.1 says that resources in the online whitelist are always fetched from the network, it seems that caching any resource that is in the online whitelist is simply a waste of time and space. I guess there's no need to explicitly state that such resources should not be cached -- implementors could design their implementation that way as an optimization. -Adam
Re: [whatwg] executeSql API is synchronous
On Tue, 25 Sep 2007, Maciej Stachowiak wrote:
I agree that the actual I/O to the database should be done up front.
However, it should be possible to make the conversion from SQLite's
native data types to JavaScript datatypes lazy (such type conversion can
have nontrivial cost, especially in bulk). To do that and get Array-like
behavior, you need either a custom Array subclass, or a class that
doesn't inherit the Array implementation but does have the Array
prototype in its prototype chain. But the current spec rules this out by
requiring the result to be a native Array. Furthermore, being a
native Array requires support for mutation, which again makes custom
strategies involving lazy type conversion more challenging.
I would propose requiring that the row list object must have
number-named properties for the contents, a read-only length property,
and all Array prototype functions that do not modify the array somewhere
in its prototype chain (this would include filter, forEach, map, but not
sort or pop). I am not even sure the last part is necessary, because
using Array.forEach is not *that* much more convenient than a for loop
and is likely to be less efficient in many JS implementations. But if we
want Array operations to be available, I'd suggest doing it in a way
that does not constrain implementations to use a native Array.
On Tue, 25 Sep 2007, Aaron Boodman wrote:
Ah, that makes sense. A special purpose class for the rows property is
fine with me. I don't feel that strongly about forEach and friends.
Done (without the Array methods).
On Tue, 25 Sep 2007, Dimitri Glazkov wrote:
Speaking of forEach, what do you think of (pardon any syntax errors,
writing straight into gmail window):
db.forEach(SELECT * FROM pages;, function(row) {
this.innerHTML += lia href=\ + row.url + \ + row.title +
/a/li;
}, document.getElementById(pages))
and...
document.getElementById(pages).innerHTML = ul + db.map(SELECT *
FROM pages, function(row) {
return lia href=\ + row.url + \ + row.title + /a/li
}).join() + /ul;
Why expose rows collection at all?
I think the above API would be must less flexible to the author. What if
you just want the third row or something?
On Fri, 5 Oct 2007, Scott Hess wrote:
If app developers, users, and browsers all agree that they want to run
some app with a substantial local database footprint, one could imagine
an accidental select * from blog_postings_Ive_read taking 2GB of
memory encoded as UTF-16. Obviously this would be a mistake, which a
developer would want to work around by using LIMIT or something of the
sort in the query, but you're possibly still stuck killing your browser
to get out from underwater.
Indeed. The new model gets around this by doing all the heavy lifting in
the background and only invoking the callback once we have data ready.
If the callback received a result object which could be iterated over,
and had isValidRow() and isRowAvailable() both, then it could buffer
things AND break things into blocks, but that's probably annoying to
spec and code to.
Yeah, I think in v1 if browsers want to safeguard against multi-gigabyte
results sets they should just raise implementation-dependent exceptions
like out of memory.
It may be worthwhile to have explicit support for an error on the order
of result set too large, without defining what too large might mean.
That could be a per-user-agent preference (or constant), and the error
mainly exists so that you can tell that you have a problem and provide a
lightweight code path if you want to support that user-agent.
Regardless, if gives the implementation the latitude to say This far,
and no farther.
Certainly that would be reasonable. I have added it. People should let me
know if they want me to remove or add error codes, by the way.
--
Ian Hickson U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Comments/questions on 4.6 Offline Web applications
On Oct 12, 2007, at 9:42 AM, Adam Roben wrote: Darin Adler wrote: On Oct 12, 2007, at 6:11 AM, Adam Roben wrote: It may be worth stating in this section what the behavior is when a section or opportunistic caching namespace appears multiple times. The parsing algorithm makes this clear, but it would be clearer still to also state the behavior in this section. Well, that would be non-conforming. I'm not sure we want to tell authors what the error handling behaviour is when they ignore the conformance requirements... do we? I see. I was not looking at this part of the spec from an application author's perspective. In light of that, I think the current level of detail is appropriate. Our experience with HTML has taught us that authors don't necessarily read the specifications nor conform. The behavior of web browsers when application authors ignore conformance requirements may be quite important to compatibility in practice; if it's not specified then the applications end up relying on the behavior of the implementation they test with. So I think it's worth considering being explicit about the error handling. Not necessarily for the authors, but for the benefit of the web browser implementers. The error handling behavior is explicit in the parsing algorithm. Perhaps it's not explicit as you would like, though? OK. Sorry, I misunderstood. -- Darin
Re: [whatwg] Comments/questions on 4.6 Offline Web applications
Darin Adler wrote: On Oct 12, 2007, at 6:11 AM, Adam Roben wrote: It may be worth stating in this section what the behavior is when a section or opportunistic caching namespace appears multiple times. The parsing algorithm makes this clear, but it would be clearer still to also state the behavior in this section. Well, that would be non-conforming. I'm not sure we want to tell authors what the error handling behaviour is when they ignore the conformance requirements... do we? I see. I was not looking at this part of the spec from an application author's perspective. In light of that, I think the current level of detail is appropriate. Our experience with HTML has taught us that authors don't necessarily read the specifications nor conform. The behavior of web browsers when application authors ignore conformance requirements may be quite important to compatibility in practice; if it's not specified then the applications end up relying on the behavior of the implementation they test with. So I think it's worth considering being explicit about the error handling. Not necessarily for the authors, but for the benefit of the web browser implementers. The error handling behavior is explicit in the parsing algorithm. Perhaps it's not explicit as you would like, though? -Adam
Re: [whatwg] Offline Web Apps
On Fri, 12 Oct 2007, Maciej Stachowiak wrote: The race-free approach would be to provide APIs to load resources only from the cache and to error out immediately if the the request can't be served locally. That's what the offline caching system does right now for any URI not on the whitelist. We could have some sort of API (I'm not sure exactly what it would look like) to modify the whitelist, adding items temporarily or something? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Comments/questions on 4.6 Offline Web applications
On Oct 12, 2007, at 6:11 AM, Adam Roben wrote: It may be worth stating in this section what the behavior is when a section or opportunistic caching namespace appears multiple times. The parsing algorithm makes this clear, but it would be clearer still to also state the behavior in this section. Well, that would be non-conforming. I'm not sure we want to tell authors what the error handling behaviour is when they ignore the conformance requirements... do we? I see. I was not looking at this part of the spec from an application author's perspective. In light of that, I think the current level of detail is appropriate. Our experience with HTML has taught us that authors don't necessarily read the specifications nor conform. The behavior of web browsers when application authors ignore conformance requirements may be quite important to compatibility in practice; if it's not specified then the applications end up relying on the behavior of the implementation they test with. So I think it's worth considering being explicit about the error handling. Not necessarily for the authors, but for the benefit of the web browser implementers. -- Darin
Re: [whatwg] database full error (was: Re: executeSql API is synchronous)
On 10/12/07, Anne van Kesteren [EMAIL PROTECTED] wrote: On Fri, 12 Oct 2007 20:46:52 +0200, Ian Hickson [EMAIL PROTECTED] wrote: Certainly that would be reasonable. I have added it. People should let me know if they want me to remove or add error codes, by the way. I think there should be an error code for the database being full. For some platforms there's not much storage space available and knowing whether or not there's some space left is useful. So you can decide to only store the critical data for instance. My counter-argument to this is that by the time you get the database is full error, you're probably already sunk. Most likely there won't be anywhere to store the critical data, either. Assuming your database has transactional semantics, you may not be able to delete any data, because it will need more space while implementing the delete. You MAY be able to delete an entire database, except that there's currently no API to do that, and on some platforms even that may be challenging (on some systems, anyone with an open connection to the database will likely prevent deletion. On others, anyone with an open connection will likely prevent reclaiming of the deleted space). I think what you're really asking for, above, is a means of saying How much data can I store?, so that you can make decisions about what to store. In the limit, that's hard for the browser to guarantee, of course. -scott
[whatwg] database full error (was: Re: executeSql API is synchronous)
On Fri, 12 Oct 2007 20:46:52 +0200, Ian Hickson [EMAIL PROTECTED] wrote: Certainly that would be reasonable. I have added it. People should let me know if they want me to remove or add error codes, by the way. I think there should be an error code for the database being full. For some platforms there's not much storage space available and knowing whether or not there's some space left is useful. So you can decide to only store the critical data for instance. -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: [whatwg] Comments/questions on 4.6 Offline Web applications
On Fri, 12 Oct 2007, Adam Roben wrote: (Now step 20.) It does. Which is to say, it being on the online whitelist has no effect. Should it have an effect? We can omit the caching of such files if you want. Given that section 4.6.5.1 says that resources in the online whitelist are always fetched from the network, it seems that caching any resource that is in the online whitelist is simply a waste of time and space. I guess there's no need to explicitly state that such resources should not be cached -- implementors could design their implementation that way as an optimization. Actually, I just realised that there is one time where the resource might get used: when it's opened from a top-level browsing context. The top-level browsing context loads don't check the online whitelist, they just look for a cache with that resource, and load the file directly from that cache, without going through the online whitelist check. So there's not really an optimisation that can be done. On Fri, 12 Oct 2007, Darin Adler wrote: Our experience with HTML has taught us that authors don't necessarily read the specifications nor conform. The behavior of web browsers when application authors ignore conformance requirements may be quite important to compatibility in practice; if it's not specified then the applications end up relying on the behavior of the implementation they test with. So I think it's worth considering being explicit about the error handling. Not necessarily for the authors, but for the benefit of the web browser implementers. I basically pioneered the concept of defining error handling in Web specs. Don't worry, the spec has error handling defined. :-P There are two sections for the cache manifest; one is for authors and conformance checkers, and the other is for Web browser implementors. Cheers, -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Bookmarking videos
On Wed, 21 Mar 2007, Kornel Lesinski wrote: This however is a little help to users who want to bookmark videos or share links to certain parts of them - without a standard way of doing it UA's won't be able to provide UI for it. Even if you implement that for yourself using UserJS, you won't be able to share those links, etc. There are RFCs that cover fragment identifiers for videos which may be of interest here. I'm not sure that it's really within the scope of HTML5, though. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Full screen for the video element
On Wed, 21 Mar 2007, Mihai Sucan wrote: Shouldn't the video API include a way to toggle full screen on/off? This is a rather basic feature of videos. If it will not be available, video sites will hack around missing full screen support. The current spec doesn't define it. Currently, the spec recommends that user agents provide a way to switch the view of the video to full-screen. We can't provide a programatic way of doing it because it is too easily abused. (Can you imagine if every time you went to a new site, a full-window or full-screen advert played?) -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Full screen for the video element
On Wed, 21 Mar 2007, Martin Hassman wrote: I feel conflict here: a) UA provide some Fullscreen item in popup menu (from the discussion seems for me that there shouldn't be any UA-GUI in page than popup menu) b) web author give some Fullscreen button inside his video controls (to look it like youtube etc.) If for b) author doesn't have API and make it owns way, there will be two independent fullscreens for every video. 1st way the browser allows fullscreen and 2nd way the page author make fullscreen. I would posit that if user agents provided for a native full-screen mode, sites would stop providing their own workaround. Fullscreen here does not necessary mean switching browser to fullscreen mode, look e.g. like youtube has it. I'm sure YouTube would _rather_ just have a way to go fullscreen, though. The current feature is but a poor workaround. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Full screen for the video element
On Wed, 21 Mar 2007, Kornel Lesinski wrote:
Couldn't this be protected in a similar way pop-up blocking works? If
not, browsers could simply display confirmation dialog box before
entering fullscreen (some sort of protection is neccessary to protect
against phishing and annoyance).
The popup blocking is highly inadequate, sadly. It isn't a model we really
want to follow.
Displaying a confirmation dialog is considered poor UI.
I think Mihai has a valid point here -- if there's no API for
fullscreen, custom players won't be able to provide UI for it or will
try to fake it.
Why would the UA's own fullscreen UI not be eough?
I suggest adding fullscreen() (toggleFullscreen? enterFullscreen?)
method that returns false if UA refused to enter fullscreen:
if (!video.fullscreen())
{
openVideoInLargePopupInstead();
}
In practice such an API would simply always return false.
On Thu, 22 Mar 2007, Gervase Markham wrote:
Indeed. But it would be good to have an event which triggers when the
user chooses to go full screen, so the page can e.g. hide headers and
borders. (Or perhaps the onresize() event on the body already does
that?).
The 'projection' media type is probably the best solution for this.
--
Ian Hickson U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Apple Proposal for Timed Media Elements
On Wed, 21 Mar 2007, Robert Brodrecht wrote (in response to Apple's proposal, quoted): If the presentation of timed media by the user agent has been disabled, if the resource has an unsupported type, or if the preparations for its presentation fail either because of a protocol failure or because the format of the media is unrecognized, the user agent must fire an error event on the element and display the element's fallback content, if available. So, we have some fallback control. That is good, as it is lacking from WHAT WG at the moment and was something I'm concerned about. This is how I intuitively felt it should work. I'm glad that is specified. The way the video element now works in the HTML5 proposal is not quite this -- the fallback is only used if the browser doesn't support video at all, not if it doesn't support the codec. The primary reasons for this is to stop the bouncing around of content. This is similar to how iframe works. Fallback to different formats is provided via source. The controller attribute is a boolean attribute. If the attribute is present, the user agent must display a user interface which allows the user to control the media element. The height attribute on the element does not include the size of the controller, it is the size of the video element only I like being able to specify this, but the height of the controller needs to: 1) Be set normatively in this specification. If the height of the controller area changes across browsers, it's going to be a source of irritation for developers. 2) Be set in CSS (as well as positioning options... I'd guess through a pseudo element like :controller?). We'll address this in the rendering section in due course. When the src attribute is set, the user agent must immediately begin to download the specified resource unless the user agent cannot support video/audio, or its support for video/audio has been disabled One reason I like YouTube is that the download is user-initiated. If I include YouTube content on my site, they see a nice thumbnail from the video and a big play button. If they are on dial-up, they don't have to download it. Autodownload, to me, is flawed. I know I can set up the image and video stuff with JavaScript to work like YouTube. But if the user DOESN'T have JavaScript on, they are stuck with nothing. I would love to see an autodownload attribute to complement autoplay or use autoplay=0 to disable the auto download. A way to add a thumbnail would be nice while not auto downloading. The spec has an autoplay= attribute now, and can stall downloading the content for as long as the user desires. The DOM attribute currentRate is the rate at which a media element is currently playing. I'm guessing this would be in frames per second? Is it the frames per second it is playing or the available frames per second encoded in the video? In the spec it's a multiple of the native rate. On Thu, 22 Mar 2007, Chris Double wrote: Looping is useful for more presentational uses of video. Start and end time are useful in case you want to package a bunch of small bits of video in one file and just play different segments, similar to the way content authors sometimes have one big image and use different subregions. Or consider looping audio, or a single audio file with multiple sound effects. These are two examples. Could the looping be done via javascript rather than having explicit support for it with loopStartTime, etc? If an event is raised when the video reaches endTime then event handler could then restart it. On Sat, 24 Mar 2007, Kevin Marks wrote: For smooth looping, you need to have the next buffer ready and cued up when the previous one finishes. Doing this consistently with a roundtrip through javascript events is going to stutter or gap. For video at 30fps, you can make the interval, but audio at 48khz means you are more likely to hear a click or gap. The spec now does it declaratively. On Wed, 21 Mar 2007, Eric Carlson wrote: I'm guessing this would be in frames per second? Is it the frames per second it is playing or the available frames per second encoded in the video? No, it is a multiple of the file's intrinsic (or natural) rate. Frames per second loses meaning quickly with digital media files, where individual frames can have arbitrary duration (true even for animated GIF files). Right. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Offline Web Apps
On Oct 12, 2007, at 12:16 PM, Ian Hickson wrote: On Fri, 12 Oct 2007, Maciej Stachowiak wrote: The race-free approach would be to provide APIs to load resources only from the cache and to error out immediately if the the request can't be served locally. That's what the offline caching system does right now for any URI not on the whitelist. We could have some sort of API (I'm not sure exactly what it would look like) to modify the whitelist, adding items temporarily or something? That's a good point. However, it seems like the most likely candidate for a resource to use only if local is one that's in an opportunistic caching namespace in the manifest. At least, that is how I see Robert's map scenario working. And you wouldn't want either a real version loaded from the network or the fallback resource. One possible approach would be an API to temporarily turn an opportunistic caching namespace into cache-only, such that any loads initiated while in this mode are served only if cached and fail otherwise, bypassing the possibility of network load or getting the fallback resources. Then you can handle the error in case the load fails. Regards, Maciej
Re: [whatwg] Apple Proposal for Timed Media Elements
On Wed, 21 Mar 2007, Robert Sayre wrote: My two cents: we should put off events and other API pieces that address editing applications. It is possible to write web versions of things like iMovie and SoundEdit in Flash right now, but I don't think it is realistic to capture that stuff in a first effort. We should focus on playback and consumption for v1. So my question for any proposal right now would be: why is the feature needed for something analogous to a VCR or YouTube screen? Agreed. For audio in general, there's been very little demand for audio other than from people suggesting that it makes abstract logical sense I disagree. It's been pointed out by multiple people that video will be used for audio. That could be quite likely if the page authors wants to send ogg vorbis audio. We have audio now. * What's the use case for hasAudio or hasVideo? Wouldn't the author know ahead of time whether the content has audio or video? That depends. If you are displaying one fixed piece of media, then sure. If you are displaying general user-selectable content... This reasoning seems sound to me. In general, I am weary of proposals that require control over both sides of the wire to be effective. Right now you can tell if you have video content by checking the videoWidth and videoHeight attributes. There is no equivalent for audio. We have included a mechanism for static fallback based on container type and codec, so that it's possible to choose the best video format for a client even if user agent codec support varies. What existing markup leads us to believe this will be an effective method for content negotiation? source gets around this by moving the selection to the client. On Thu, 22 Mar 2007, Martin Atkins wrote: To me, the distinction between the audio element and the Audio object is that the former has a place in the document where that audio content logically belongs, while the former is more of a global trigger for web application sound effects. audio could, for example, be rendered in-line with surrounding text in an aural browser. A visual browser would presumably provide some kind of representation in the document of the audio which the user can interact with. In other words, audio should be like img for sound. Of course, what the visual representation of audio should be is not an easy decision. It's even harder than video, because there's no inherent visual content to overlay a UI on top of. I have tried to make the spec reflect this. On Thu, 22 Mar 2007, Maciej Stachowiak wrote: I generally agree, but note that new Image() makes an img element, so new Audio() could work analogously. Yes, this is what the spec now says. I think audio is useful for foreground/semantic audio, as opposed to purely presentational sound effects, because non-browser tools analyzing a document would have a harder time finding audio referenced only from script. (Imagine a most-linked MP3s on the web feature in a search engine.) Maybe. Of course, what the visual representation of audio should be is not an easy decision. It's even harder than video, because there's no inherent visual content to overlay a UI on top of. I think it would be no visual representation by default with no controller, and just controls otherwise. That's what the spec now says, I believe. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] img element comments
On Sat, 4 Nov 2006, Anne van Kesteren wrote: On Sat, 04 Nov 2006 07:37:32 +0100, Ian Hickson [EMAIL PROTECTED] wrote: * It should probably mention 'img.src = foo' (that loading directly starts). I thought that 'img.setAttribute(src, foo)' even did different things in browsers (when the element is not yet inserted into the document) so reflect might not be accurate. I couldn't find a difference. Any idea what it was? From what I recall setting the DOM attribute on a newly created element (not appending it to the DOM) would cause download immediately in all browsers, but some browsers acted differently when the src content attribute was set on the newly created element. As in, the download started the moment it was appended to the DOM, not before (no load event would fire). Is this required for compat or can we leave it as is? How widely is it implemented? * The height and width attributes as defined are completely presentational. I don't really see any value in keeping them. Now I suppose they have to be supported anyway, but so does body bgcolor=. I'm thinking of only allowing integer values, and requiring them to be equal to the dimensions of the image, if present (and requiring both to be present if either is present). Would people be ok with that? If you require this only for images with known intrinsic dimensions than that would be fine with me (as in, for some cases of SVG the requirements are likely different). Is the way it is phrased now acceptable? On Sat, 4 Nov 2006, Henri Sivonen wrote: What about non-square pixels in the image file? Both GIF and PNG allow pixel aspect ratios other than 1:1. I don't have test cases and I don't know what browsers do. The spec sidesteps this by defining the dimensions as CSS pixels. Also, such a requirement would make document conformance dependent on resources other than the (X)HTML5 file itself. Is that a good idea? Is the document conforming, not conforming or undecided if there are no other errors but the image cannot be retrieved? I think we're going to have to work this out -- maybe there should be two things, document conformance and related resource conformance. What image formats should a conformance checker know about? GIF, PNG and JFIF? Same as browsers, I guess. On Tue, 7 Nov 2006, Shadow2531 wrote: Yeh, in example method, this is the suggestion: (at least from what I got out of the proposal) [conforming] img src=276x110.png alt=fallback text title=description img src=276x110.png width=276 height=110 alt=fallback text title=description [non-conforming] img src=276x110.png width=400 height=200 alt=fallback text title=description img src=276x110.png width=50% height=50% alt=fallback text title=description Agreed. img src=276x110.png width=276 alt=fallback text title=description This is fine in the spec as it is today. On Tue, 7 Nov 2006, Andreyka Lechev wrote: Don't forget that percentage values are relative values. And in current browser implementations, setting those values via CSS-rules or using width- and height-attributes are leading to different results! It's due to different parents to calculate actual (pixel) values from! This doesn't seem to be true. CSS values are relative to the the parent element in HTML tree: div style=width: 100px; height: 100px; img src=276x110.png style=width: 50%; height: 50%; /div = displays image 50x50px. Attributes values are relative to the actual size of the image: img src=276x110.png width=50% height=50% = displays image 138x55px. That may be very useful in many cases, so as a HTML-coder, I don't think anybody should change that behavior without proposing something to replace it. I couldn't reproduce the behaviour you give above. Do you have test cases showing this? On Tue, 7 Nov 2006, Greg Kilwein wrote: Also, if only one of either the width or height attributes is set, some browsers will scale the other dimension automatically. Consider this example: img src=100x50.png width=50 Some browsers will scale height to be 25 in this instance, given an image with a width of 100 pixels and a height of 50 pixels. This is quite useful when the height or width of an image needs to be fixed without distorting the aspect ratio. This will be defined in the rendering section in due course. On Sat, 4 Nov 2006, Matthew Raymond wrote: Lachlan Hunt wrote: The style attribute is far more presentational than the height and width attributes. I don't see how either is more or less presentational. The |height| and |width| attributes are entirely presentational, since their sole purpose is to define the sizing of the image in the document layout. I agree that style=height: 100px is different from height=100 only in a syntactical fashion, from a semantic standpoint. On Sun, 5 Nov 2006, Lachlan Hunt wrote: Using attributes
Re: [whatwg] Offline Web Apps
On Oct 12, 2007 9:39 PM, Maciej Stachowiak [EMAIL PROTECTED] wrote: On Oct 11, 2007, at 6:47 PM, Robert O'Callahan wrote: On Oct 12, 2007 12:53 PM, Ian Hickson [EMAIL PROTECTED] wrote: The problem with isLocallyAvailable() -- as noted by Maciej on IRC -- is mostly one of race conditions. What if the resource was removed in between you asking for it and using it? Or added? In the contexts for which it was requested, race conditions are tolerable. For example in a mapping application, if you choose the wrong tile as a template for zooming, then you get an ugly transition but that's all. Seems like wrongly choosing one that is not actually locally available would leave a hole in your map. This case was for an online app. The assumption is that either tile chosen would load eventually; the app would choose to base its transition effect on whichever tile was most likely to be available. I'm told that right now, they use heuristics based on a completely naive model of the browser cache! Or what if you go offline (thus changing the rules) in between checking for and using the resource? That's why we have the 'whenOffline' parameter. I don't see how the whenOffline parameter addresses that problem that your online/offline state may change between the time you do the check and the time you try to load the resource. In fact, I'm not really sure how it is helpful, compared to just basing the check on the current online/offline state always. Some apps may find it helpful to be able to predict their offline capabilities even while they're online. For example, an app might want to indicate what the user will be able to do if they go offline right now. A race-free API seems difficult to design. Because loads are typically asynchronous, I doubt you can do much better than start a regular load, and set a timer to go off and cancel the load and take other action if the load doesn't complete fast enough. The race-free approach would be to provide APIs to load resources only from the cache and to error out immediately if the the request can't be served locally. The problem with this is that there are a huge number of APIs to trigger a load: frame src, iframe src, window.location assignment, window.location.replace, img src, script src, link for a stylesheet, XMLHttpRequest, and that's just the obvious ones. Indeed. Another problem is that if you want to offer a hard guarantee that the resource will load, you probably want to check not just whether it's in the cache but also that no other error will occur before the load completes (e.g. due to a change in the browser state during a load). This might be simple, or it might not, depending on the browser implementation. In other words, the race window doesn't end when the load starts, it actually ends when the load ends IMHO. I think a way to do an XMLHttpRequest that will only succeed if the data is cached would cover many cases, and is probably a reasonable extension to XHR (given the text of an html document, script or stylesheet, you can insert it into an appropriate element for use). The problem is binary formats, since XHR has no good way of returning the data yet and the elements that would consume them (img, video, audio, object) have no way to pass in raw bytes (using a data: URL to encode it would be poor form for image and probably unworkable for video). However, if those elements were extended with some way to set raw data then such an approach could work. Yes, but I think you'd want this API to be synchronous for the above reasons. At that point, isLocallyAvailable might possibly be useful solely as a UI hint, much as the POSIX access() / stat() calls are only useful as UI hints for openability. In fact, this is pretty much analogous to the potential pitfalls of access() vs. open(). You need to check whether open() succeeds, and pass it the right parameters to make sure it will fail if it shouldn't succeed, rather than trusting a pre-check with access() or stat(). Agreed. Rob -- Two men owed money to a certain moneylender. One owed him five hundred denarii, and the other fifty. Neither of them had the money to pay him back, so he canceled the debts of both. Now which of them will love him more? Simon replied, I suppose the one who had the bigger debt canceled. You have judged correctly, Jesus said. [Luke 7:41-43]
Re: [whatwg] Apple Proposal for Timed Media Elements
On Thu, 22 Mar 2007, Sander Tekelenburg wrote: http://webkit.org/specs/HTML_Timed_Media_Elements.html I'm worried about The controller attribute is a boolean attribute. If the attribute is present, the user agent must display a user interface which allows the user to control the media element. If this is to be taken as if an author provides no controller attribute, the UA is to not provide a UI, I'd have to vote against that (for reasons mentioned earlier ;)). The alternative -- having an attribute to hide the controls -- is what I'd prefer, but there isn't really a clean way to do that without double negatives like: video nocontrols ...with the corresponding: video.nocontrols = false; ...to enable controls, which is very confusing. What about instead allowing authors to set controller to display:none? That would give authors the freedom to suggest present movies controllerless, but leave the end user the option to override that, as I think it should be. It's not really a style-level thing -- if the content wants to control the video, it makes no sense to have the controls present as well. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Apple Proposal for Timed Media Elements
On Thu, 22 Mar 2007, Dave Raggett wrote: From an accessibility perspective the proposal lacks support for captioning. There should be a mechanism for enabling/disabling captions to avoid disadvantaging people who have difficulties with hearing the audio. It should further be possible to control the font size for captions to avoid disadvantaging people who don't find small font sizes intelligible. I don't think that the Web Accessibility folks will find the fall back text to be a compelling solution, and it is no longer acceptable to ignore accessibility. I've added text to indicate that user agents should make subtitles available to the user. p.s. the step function refers to frames but I was unable to find out whether the interface provides the current frame rate. This would appear to be an oversight. I've removed step(). Cheers, -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] video, object, Timed Media Elements
On Thu, 22 Mar 2007, ddailey wrote: As a newcomer to this group, please forgive my ignorance of discussions that, undoubtedly, have already taken place, but as I have been reading these threads on video and timed media and object, a couple of questions have come to mind: 1. why not just include SMIL as a part of HTML, much in the same way that it is integrated with SVG? It is an existing W3C reco. SMIL was considered, but several factors led to us deciding not to use it in HTML5: - We got strong feedback from existing producers of video on the Web that their experience with SMIL had been universally disappointing. - The SMIL model is based around XML and namespaces, which isn't really compatible with text/html and HTML5. - SMIL's conceptual model wasn't a good fit for the requirements we had in mind for video. 2. For content such as XML, MathML, SVG, ChemML... that one would like to embed in an HTML document could there not be some sort of tag (object was supposed to work, but doesn't in some browsers) like say dom data=some.xml id=D for which the DOM associated with the XML content would be easily accessible through script as with: XMLDoc=document.getElementById(D).getXMLDocument. It seems as though external things which have DOMs are quite different that other sorts of media and may deserve their own tag. For XML content you can use object or iframe and the contentDocument attribute to obtain the Document object. HTH, -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Apple Proposal for Timed Media Elements
On Thu, 22 Mar 2007, Nicholas Shanks wrote: Volume has the range 0-100 in the DOM interface, but 0.0-1.0 in CSS. These should be consistent (I favour zero to one and allowing percentages). The spec now uses a float and 0.0 .. 1.0. I think that the ERROR state attribute should have a value of -1 not +1 since it is a worse state than uninitalised�you know it's bad rather that being unsure (and the state constants be defined as signed rather than unsigned) http://webkit.org/specs/HTML_Timed_Media_Elements.html#state-attributes The spec doesn't have an ERROR state now, so this is sidestepped somewhat. Should the DOM attribute be called mediaStatus or mediaState? I think the terminology should match regardless of whether status or state is used. Should media-play-state be renamed to avoid confusion with values for mediaStatus? This has been split into networkState and readyState. HTH, -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Apple Proposal for Timed Media Elements
At 0:30 + 13/10/07, Ian Hickson wrote:
On Thu, 22 Mar 2007, Dave Raggett wrote:
From an accessibility perspective the proposal lacks support for
captioning. There should be a mechanism for enabling/disabling captions
to avoid disadvantaging people who have difficulties with hearing the
audio. It should further be possible to control the font size for
captions to avoid disadvantaging people who don't find small font sizes
intelligible. I don't think that the Web Accessibility folks will find
the fall back text to be a compelling solution, and it is no longer
acceptable to ignore accessibility.
I've added text to indicate that user agents should make subtitles
available to the user.
I (we) agree completely that accessibility is both important and
should be explicitly addressed in the spec. I don't think it makes
sense to talk only about one kind, however. We've sent a previous
email outlining how a user could express their accessibility needs
('i need captions'), and how source selection and/or content-specific
enabling could supply them.
Some content has captions 'burned in', and to get them, you need to
select the content with the burned-in captions. Other systems have
provision for enable-able captions, and in that case, the same soyrce
serves, and it should enable the captions in response to the user's
wish.
I know it's ugly to have the ability to 'get captions' at two layers
(HTML source selection, media player feature enablement). But
captions known as such within the media player have superior
characteristics to burned-in ones (e.g. they can also respond to
bigger/smaller requests), but not all systems support true
(non-burned-in) captions.
--
David Singer
Apple/QuickTime
Re: [whatwg] video, object, Timed Media Elements
At 0:34 + 13/10/07, Ian Hickson wrote:
On Thu, 22 Mar 2007, ddailey wrote:
As a newcomer to this group, please forgive my ignorance of discussions
that, undoubtedly, have already taken place, but as I have been reading
these threads on video and timed media and object, a couple of
questions have come to mind:
1. why not just include SMIL as a part of HTML, much in the same way
that it is integrated with SVG? It is an existing W3C reco.
SMIL was considered, but several factors led to us deciding not to use it
in HTML5:
- We got strong feedback from existing producers of video on the Web that
their experience with SMIL had been universally disappointing.
- The SMIL model is based around XML and namespaces, which isn't really
compatible with text/html and HTML5.
- SMIL's conceptual model wasn't a good fit for the requirements we had
in mind for video.
I agree. I also believe that SMIL is addressing a level and degree
of functionality more than HTML should. A SMIL file should be a
value source for video or audio, but the whole question of media
*integration* ('play this in parallel with that in these two regions,
and then play this other in a third region') should be deferred to
SMIL.
SVG integrated parts of SMIL and there has been some criticism that
the integration made some odd corners. This might have been
necessary in SVG, I'd rather not go there but maintain a clean
layering, which we can do in this case.
--
David Singer
Apple/QuickTime
Re: [whatwg] video, object, Timed Media Elements -- Part I SMIL
On Thu, 22 Mar 2007, Dan Brickley wrote: I've not followed it, ... but there's a SMIL subset integrated with XHTML at http://www.w3.org/TR/XHTMLplusSMIL/ ... if you find SMIL too large, perhaps this or another profile is less intimidating? This profile doesn't seem to define error handling, nor does it have a corresponding DOM API... and it is far more complex than the video element currently in the HTML5 draft. At least, that was my impression. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] source
On Fri, 23 Mar 2007, Anne van Kesteren wrote: I don't really like this element. The name is confusing especially with an attribute named src=. It also introduces yet another void element, can't we just reuse param? The value= attribute of param would point to a resource and the type= attribute (which has been dropped) would be added back. I suppose it might be considered overloading, but in a way we're just defining how the processing model of a plugin could also work... I actually tried param at some point, but having param do double duty with two sets of attributes was quite confusing. On Fri, 23 Mar 2007, Maciej Stachowiak wrote: So to be sure I understand your proposal, you're suggesting that instead of source type=audio/mpeg src=mysong.mp3 You'd say: param type=audio/mpeg value=mysong.mp3 I think the latter is a lot less clear. Also, param would end up having two uses which differ in the following ways: 1) Do you have type/value or name/value as allowed attributes? 2) Which object can contain it? 3) Do you process all of them, or only the first one to match some criteria? They would effectively be different elements since the processing model and criteria for a valid document would differ. Indeed. I agree the repetition of source/src is a little weird. Another possibility that was discussed is to still have the type attribute on audio/video, and let it be the first item considered for fallback, and name the new element something like alt so you could write: audio type=audio/mpeg src=mysong.mp3 alt type=audio/x-aiff src=mysong.aif alt type=audio/wav src=mysong.wav /audio Or, if you want symmetry: audio alt type=audio/mpeg src=mysong.mp3 alt type=audio/x-aiff src=mysong.aif alt type=audio/wav src=mysong.wav /audio I think that would be confusing due to its similarity yet difference with img alt=. One nice thing about using alt is that it makes it more clear that only one source will apply. Another nice thing about it is that it could more naturally be extended to supporting playlists, where a single element is declaratively set up to play multiple media files (this is better than using script for this, since you can start buffering the second and subsequent files early). audio li alt type=audio/mpeg src=mysong.mp3 alt type=audio/x-aiff src=mysong.aif alt type=audio/wav src=mysong.wav /li li alt type=audio/mpeg src=othersong.mp3 alt type=audio/x-aiff src=othersong.aif alt type=audio/wav src=othersong.wav /li /audio Perhaps reusing li like that is too cute and there should be some more specific element for a playlist item. But I guess you could use this syntax with source just as well. Indeed. I'm not convinced this is much better. :-) On Fri, 23 Mar 2007, Dean Edwards wrote: Why not call the element content instead of source? That way the src and type attributes make more sense. I'm not convinced it would be that much better, and I'd prefer if we kept the name content available for other things later. On Fri, 23 Mar 2007, Anne van Kesteren wrote: By the way, people also suggested using an external file to contain the playlist. That makes sense to me. On Sat, 24 Mar 2007, Alexey Feldgendler wrote: If you put it inside object fallback content, it will be misunderstood by the current browsers as pertaining to the object. That is indeed another reason to avoid param; though why you'd put video inside object instead of the other way around, I'm not sure. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] source
On Fri, 23 Mar 2007, Nicholas Shanks wrote: How about: playlistol liaudio src=foo type=...Audio fallback/audio/li livideo src=bar type=...Video fallback/video/li /ol/playlist User agents that don't support playlist, audio and video just get an ordered list of fallback text. UAs that do support them also benefit in being able to negotiate each variant individually instead of getting whatever collection of media files the playlist movie decides upon. And perhaps playlists with a ul child can play the media in any order, not necessarily source order, presumably whatever item becomes available first. But I have been arguing against element proliferation in another thread and here I am suggesting new ones :-) :-) I think we'll punt on playlists for now. Feature creep is a real danger! On Sat, 24 Mar 2007, Silvia Pfeiffer wrote: There is an existing xml specification for playlists at http://www.xspf.org/ . I suggest treating playlists as objects in their own rights, so they can be shared across different web pages. Thus, a playlist should rather be embedded like this: playlist src=playlist.xspf Or video src=playlist.xspf I guess, yeah. That would be a good way to go forward if implementors want to support playlists. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Media protocols and state
On Mon, 2 Apr 2007, Kevin Calhoun wrote: I've been evaluating the behavior of the HTMLMediaElement in the current working draft in light of the various network protocols and player behaviors that I'm familiar with, and I think the current specification of loading behavior and the definitions of the buffering, buffered, and bufferingRate attributes are too restrictive. Players can be divided roughly into two classes according to their handling of data transfer: 1. Data availability precedes playability, seekability, etc. Typical case: the client requests a media resource via a transfer protocol such as http and caches the data it receives. It defers playback until enough of the resource is cached for playback to proceed without interruption. Seeking is limited to the range of the media that's available locally. 2. Data is loaded on demand in response to a request to perform an operation, e.g. play or seek Typical case: in response to a request to play a media resource, the client negotiates with a server to initiate a streaming session, such as an rtp session. Playback proceeds as soon as a minimal amount of data is buffered. Seeking may occur within the full range of the media; when it occurs the client asks the server to stream from the new media time. Of course many variants and elaborations of these two strategies are possible. In particular I don't mean to suggest that file transfer protocols are suitable only for the former category or that streaming protocols are suitable only for the latter. In the discussions that led to Apple's proposal for media states we made an effort to accommodate a variety of media access protocols. For example, in order to permit appropriate restrictions on seeking operations we expose the notion of the range of media that's available, not the range of media that's buffered, and leave the definition of availability up to the UA to accord with the transfer protocol and caching scheme in use. We also tried to stay away from the term download, as it implies a file transfer. Clearly the two broad classes I mention above are very general; would it be helpful to discuss player behaviors in more depth? How well does the current proposal succeed in allowing custom controllers to be implemented that work with a variety of protocols? As far as I can tell, both of the cases above are in fact handled by the current specification. Could you elaborate on how you think the current spec is too restrictive? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
