Re: [whatwg] Color attributes
On Fri, 17 Oct 2008 00:01:02 +0200, Andy Lyttle [EMAIL PROTECTED] wrote: While the first item's length in segments is greater than 2 and the first character in each item in segments is a U+0030 DIGIT ZERO character, remove the first character from each item in segments. Does this mean, if the length of the first item in segments is greater than 2 then loop through each item in segments, and if the first character is 0 then remove it? Or does it mean, if the length of the first item in segments is greater than 2 and the first character of every item in segments is 0, then loop through each item and delete the first character, but if the first character of any item is not 0 then leave the whole thing alone? I'm assuming you meant #1, but your wording isn't perfectly clear. I meant #2. Reworded. Has it occurred to you that while your algorithm makes the string foo return an error, the string l33tsp34k is converted to a dark purple? Yes. I thought it matched webkit. But further testing shows that it does not. :-( 999 - #000999 aaa - #aa aax - #00 #999 - #99 #aax - #00 I've made the algorithm return input if it's correct #rgb and otherwise continue the algorithm (which will instead match IE). So the above would instead be: 999 - #090909 aaa - #0a0a0a aax - #0a0a00 #999 - #99 #aax - #0a0a00 Thanks! -- Simon Pieters Opera Software
Re: [whatwg] Whatwg Social Meeting This Month
On Fri, 17 Oct 2008 04:16:17 +0200, Michael Carter [EMAIL PROTECTED] wrote: I've received a number of responses, and it looks like Thursday, 10/28, is the best date. I think that 7pm is the best time, but if someone has any pressing arguments for an earlier time (like, most whatwg contributors don't have have real jobs anyway =) then feel free to send them my way. In a couple of days after I've finalized the details, I'll put this information up somewhere. I blogged about it so people not reading the mailing list but following the blog get a chance to sign up: http://blog.whatwg.org/october-2008-meetups I suggest that when details are final we do another blog entry there. -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: [whatwg] input type=hidden outside phrasing content
Anne van Kesteren wrote: I'd suggest playing with validator.nu. Out the top of my head: Ah, thanks for the link. I tried the different examples and your hunch was correct for all of them (tables and lists having problems). For the table and lists cases, is there a good use case for complicating their content model This being a good or important use case is hard to say - I guess it is one of these real-world annoyances that both webdevs and browsers have learnt to cope with. As part of the HTML5 initiative is based on real-world browser behaviour I was thinking this may be a candidate for some spec adjustment in some form (maybe just defining graceful migration). or could you just as well put the input either before or after the table or list? For hand-coding I certainly could, I see no real reason to do what I suggest here when you are in control of the complete markup. But it gets harder for the scenario I was mentioning in my initial mail: [some incarnations of] server-side templating. Many templating systems work with the whole page at once to specify what markup to generate for specific data, but for more decoupled systems you may want to specify a HTML snippet per object type or similar - and then apply recursive view rendering on an object graph. Along the way the system may want to insert hidden state that it wants posted back later, and the easiest way to accomplish this is something like inserting a hidden input just after the respective snippet's top element. (If there are snippets designed for actually editing the data these will have been hand-coded to include inputs in valid places so this is not an issue.) So, for an example hierarchical object structure: obj1 obj2 obj3 we may have the following associated HTML snippets: obj1 - TABLE... obj2 - TR... obj3 - TD... If we want the system to insert hidden state along the way the naive solution would look like this: TABLE INPUT obj1 state TR INPUT obj2 state TD INPUT obj3 state which is not valid. We could make this smarter by moving TABLE's state before the element instead of as first child, but the TR is harder to fix. We could have the system add an extra TD to hold the state for the row object but this is starting to affect the rest of the page a bit much. Andy Lyttle wrote: This is something I wanted to do recently. I was building HTML in a Perl script, adding table rows in a loop, and I wanted some rows to contain text field with user-editable value, while for other rows I wanted the value to be displayed but not editable Yes, this is sort of similar to my scenario above, and you were able to workaround it being in control of the whole markup in one place (and not completely decoupled as I describe above). I think this is one of those things that webdevs keep hitting every now and then, and it is caused by a kind of inter- mingling of document structure and POSTable state in HTML/DOM. Kristof Zelechovski wrote: So, where a paragraph is not allowed, neither is the INPUT control; inserted where it does not belong, it migrates; the document is invalid but it can be rescued. I had a look at migration in a TABLE structure for a few different browsers (by inspecting the DOM) and the results are sort of interesting: Firefox 3: Hidden INPUTs are kept in their exact place where they were specified but visible INPUTs in invalid locations are moved up and in front of their parent element(s) until they have a valid position. Safari 2: Visible INPUTs in invalid locations are moved up and in front of their parent(s) and hidden INPUTs are moved up and behind their parent(s). Though, POST parameter order is preserved and not affected by the INPUT reorganization in the DOM. Safari 3 and Chrome: All INPUTs in invalid locations are moved up and in front of their parent(s). Opera 9.60: All INPUTs in invalid locations are kept in the exact place they were specified in and no migration is done. (And visible fields are still displaying correctly.) IE6 and IE7: All INPUTs in invalid locations are (sort of) kept in place but are wrapped with an extra unnamed element, f ex: TABLE INPUT TR ... Summing this up I think FF3 has an interesting behaviour as they sort of already do what I am suggesting. Visible INPUTs should be placed where their element is allowed to be rendered, but hidden INPUTs could really be placed anywhere. Best regards Mike Wilson
[whatwg] Web-based dynamic audio apps - WAS: Re: video tag : loop for ever
Eric Carlson wrote: Imagine e.g. an audio editor in a browser and the task play this selection of the oscillogram... Why should such use cases be left to the Flash 10 crowd (http://www.adobe.com/devnet/flash/articles/dynamic_sound_generation.html)? I for one want to see them become possible with open web standards! I am anxious to see audio-related web apps appear too, I just don't think that including 'start' and 'end' attributes won't make them significantly easier to write. I did a tiny prototype of the above use case - audio editor in a browser - and it would have been significantly easier to write, if not Apple's Safari had a bad and still unfixed bug in the implementation of 'end' ... (http://bugs.webkit.org/show_bug.cgi?id=19305) In addition, cutting down on number of HTTP transfers is generally advocated as a performance booster, so the ability to play sections of a larger media file using only client-side means might be of independent interest. The 'start' and 'end' attributes, as currently defined in the spec, only limit the portion of a file that is played - not the portion of a file that is downloaded. I know that, but for me that's not the issue at all. The issue is _latency_. How long from a user action to audible playback - that's what's relevant to any end user. You can't do responsive audio manipulation in the browser without fast, low-latency client-side computation. All the server-side proposals miss this crucial point. For another use case, consider web-based tools for DJs, for mixing and combining audio clips. There's a lot of clips on the web. But if manipulating them is not realtime enough, people won't care. For another use case, consider web-based games with dynamic audio, etc. Robert O'Callahan wrote: On Fri, Oct 17, 2008 at 5:24 AM, Dr. Markus Walther [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Imagine e.g. an audio editor in a browser and the task play this selection of the oscillogram... Why should such use cases be left to the Flash 10 crowd (http://www.adobe.com/devnet/flash/articles/dynamic_sound_generation.html)? If people go in that direction they won't be using cue ranges etc, they'll be using dynamic audio generation, which deserves its own API. And I proposed the beginnings of such an API in several postings on this list under the topic 'audio canvas', but it seemingly met with little interest. Now Flash 10 has some of the things I proposed... maybe that's a louder voice? OK, in principle you could use audio with data:audio/wav, but that would be crazy. Then again, this is the Web so of course people will do that. I did exactly that in my tiny audio-editor prototype for proof-of-concept purposes - I guess I must be crazy :-) Actually it was partly a workaround for browser bugginess, see above. Give me an API with at least float getSample(long samplePosition) putSample(long samplePosition, float sampleValue) play(long samplePositionStart, unsigned long numSamples), and sanity will be restored ;-) The current speed race w.r.t. the fastest JavaScript on the planet will then take care of the rest. Silvia Pfeiffer wrote: Linking to a specific time point or section in a media file is not something that needs to be solved by HTML. It is in fact a URI issue and is being developed by the W3C Media Fragments working group. If you use a URI such as http://example.com/mediafile.ogv#time=12-30 in the src attribute of the video element, you will not even have to worry about start and end attributes for the video element. Unless Media Fragments can be a) set dynamically for an already downloaded media file _without triggering re-download_, b) time specification can be accurate to the individual sample for the case of audio, c) W3C finishes this quickly enough and d) browsers take the W3C recommendation seriously, it is not an alternative for my use cases. It's all about dynamic audio and the future. By the time the spec hits the market, static media is not the only thing on the web anymore. Jonas Sicking wrote: The problem with relying on cues is that audio plays a lot faster than we can gurentee that cue-callbacks will happen. So if you for example create a audio file with a lot of sound effects back to back it is possible that a fraction of a second of the next sound will play before the cue-callback is able to stop it. If I understand this correctly, cue callback delay would potentially make it impossible to have precise audio intervals, needed for the above use cases. But _then_ replacing 'start' and 'end' with cue ranges and 'currentTime' is NOT possible, because they are no longer guaranteed to be equivalent in terms of precision. It seems the arguments are converging more towards keeping 'start' and 'end' in the spec. -- Markus
Re: [whatwg] Can AUDIO/VIDEO element have a balance attribute
Biju [EMAIL PROTECTED] wrote: Can AUDIO/VIDEO tag have a balance attribute like? http://developer.mozilla.org/En/HTML/Element/Bgsound What's the use case you're trying to address or the problem you're trying to solve with it? It seems to me that the correct way for an author to handle balance is within the audio file itself, or for the user to adjust their own sound system preferences, as needed based on their environment/equipment. -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
Re: [whatwg] Web-based dynamic audio apps - WAS: Re: video tag : loop for ever
On Fri, Oct 17, 2008 at 9:38 PM, Dr. Markus Walther [EMAIL PROTECTED] wrote: Eric Carlson wrote: You can't do responsive audio manipulation in the browser without fast, low-latency client-side computation. All the server-side proposals miss this crucial point. It's not about one or the other. It's about having functionality that allows download of just a segment of audio/video from an origin server to the UA, *and* about the ability to manipulate audio/video locally on the client. The latter one is not so difficult - you can do a lot of things in javascript. The first one is the one that requires setup of standard URIs and mechanisms to support Web proxies with such media fragments etc. For another use case, consider web-based tools for DJs, for mixing and combining audio clips. There's a lot of clips on the web. But if manipulating them is not realtime enough, people won't care. Your biggest problem with this use case are compressed files and the multitude of codec formats that will need to be supported. If think if you are really keen for such an application on the web, you would fully download your audio clips and fully decode them to wav and then apply your manipulations. The manipulations can then be done in realtime client-side - no further interaction with the Web and no further interactions with codecs are necessary. Robert O'Callahan wrote: On Fri, Oct 17, 2008 at 5:24 AM, Dr. Markus Walther [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Imagine e.g. an audio editor in a browser and the task play this selection of the oscillogram... Why should such use cases be left to the Flash 10 crowd (http://www.adobe.com/devnet/flash/articles/dynamic_sound_generation.html)? If people go in that direction they won't be using cue ranges etc, they'll be using dynamic audio generation, which deserves its own API. And I proposed the beginnings of such an API in several postings on this list under the topic 'audio canvas', but it seemingly met with little interest. Now Flash 10 has some of the things I proposed... maybe that's a louder voice? May be a bit early for that. Let's get audio and video into the Web first. Silvia Pfeiffer wrote: Linking to a specific time point or section in a media file is not something that needs to be solved by HTML. It is in fact a URI issue and is being developed by the W3C Media Fragments working group. If you use a URI such as http://example.com/mediafile.ogv#time=12-30 in the src attribute of the video element, you will not even have to worry about start and end attributes for the video element. Unless Media Fragments can be a) set dynamically for an already downloaded media file _without triggering re-download_, b) time specification can be accurate to the individual sample for the case of audio, c) W3C finishes this quickly enough and d) browsers take the W3C recommendation seriously, it is not an alternative for my use cases. a) is about choice. If you fully download a video, then you can most certainly do all sorts of local dynamic manipulation of it. The use case of remote media fragments is e.g. for search, where you are looking for a particular segment out of a long file (e.g. 8 hours of parliamentary sitting recorded) and don't want to wait until the full file has downloaded to just play the bit you are interested in. Your use cases don't fit that need - initial download time is irrelevant to you, but interactivity is of importance. b) time specifications will never give you sample accuracy for a compressed codec. A compressed codec can only really address based on encoding blocks. For your needs, you will probably always have to decode your audio to a raw format to do the rich manipulations you are after. c) a temporal media fragment addressing scheme is due within a year http://www.w3.org/2008/01/media-fragments-wg.html . d) it's not only the browser vendors that have to do work - it's the media formats that will need to write client-side support for media fragment delivery that have the most work to do. Cheers, Silvia.
Re: [whatwg] video tag javascript library for contemporary browsers
In principal there is no reason why overlays could not be applied to hardware accelerated video with styled css elements on top. It may require re-tooling some of the html rendering architectures .. but that is eventually the way things have to go anyway. Flash 10 for example supports GPU Compositing which greatly accelerates combining images, filters, and video. It also uses GPU Blitting allowing accelerated rendering (like what used to happen in flash full screen mode) rendered right to the browsers. http://labs.adobe.com/technologies/flashplayer10/releasenotes.html There is no reason why browsers should not head in that direction as soon as possible if they want to support the same type of hardware accelerated user experience soon to be available via flash. --michael Robert O'Callahan wrote: On Fri, Oct 17, 2008 at 5:15 AM, Michael A. Puls II [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: That would be cool to do it automatically. But, does using an overlay guarantee that other elements can't be placed on top of it? If so, then only the author of the page would know (by testing) that nothing needs to go over the top of it. Or, is it trivial to code the browser to look at the css applied on the page (and any behavior that might later apply css) to determine that an overlay won't interfere with any thing? If not, it seems like doing it automatically might break things. But, like you said if that makes sense. What I mean by automatically is that we can detect when using an overlay won't break things, and use it when it won't break things. Rob -- He was pierced for our transgressions, he was crushed for our iniquities; the punishment that brought us peace was upon him, and by his wounds we are healed. We all, like sheep, have gone astray, each of us has turned to his own way; and the LORD has laid on him the iniquity of us all. [Isaiah 53:5-6]
[whatwg] Caching offline Web applications
This e-mail is an attempt to respond to all the outstanding feedback on the offline cache features in HTML5. Summary of changes: * Made the online whitelist be prefix-based instead of exact match. * Removed opportunistic caching, leaving only the fallback behavior part. * Made fallback URLs be prefix-based instead of only path-prefix based (we no longer ignore the query component). * Made application caches scoped to their browsing context, and allowed iframes to start new scopes. By default the contents of an iframe are part of the appcache of the parent, but if you declare a manifest, you get your own cache. * Made fallback pages have to be same-origin (security fix). * Made the whole model treat redirects as errors to be more resilient in the face of captive portals when offline (it's unclear what else would actually be useful and safe behavior anyway). * Fixed a bunch of race conditions by redefining how application caches are created in the first place. * Made 404 and 410 responses for application caches blow away the application cache. * Made checking and downloading events fire on ApplicationCache objects that join an update process midway. * Made the update algorithm check the manifest at the start and at the end and fail if the manifest changed in any way. * Made errors on master and dynamic entries in the cache get handled in a non-fatal manner (and made 404 and 410 remove the entry). * Changed the API from .length and .item() to .items and .hasItem(). On Wed, 28 May 2008, Anders Carlsson wrote: one problem with the online whitelist in cache manifest files is that it matches on whole URLs only. Fixed. I also changed the order in which the lists are examined, so that this: HTTP://EXAMPLE.COM:80/c ...in the online whitelist doesn't mean that this: http://example.com/contact.html ...wouldn't ever get served from the cache. That is, if the resource is in the cache, it's used from the cache, and the online whitelist isn't examined. Also, fallback namespaces now override the online whitelist namespaces. On Fri, 13 Jun 2008, Honza Bambas wrote: I was talking with my colleague about it and we both agree it would be useful (and more easy to implement) for ANY resource being fetched inside of browsing context associated with an application cache to opportunistically cache it and not just do it for results of navigation, i.e. top-level document, iframe source and frame source. A set o pictures/icons/css styles could be easily cached this way w/o explicitly listing them in the manifest. At this point it would be good to say what really is intention/motivation of opportunistic caching itself. Maybe I am missing the purpose and potentially open a security hole or a kind of attack this way. The main goal of opportunistic caching was to allow Flickr or Bugzilla to continue using URLs on a per-entry basis, so that while offline, if you try to go to a page that hasn't yet been seen before, the application can catch the navigation attempt and display fallback content (such as an error message) instead of the UA saying file not found. In particular, there is no feature intended to automatically capture resources that aren't in the manifest -- experience has shown that such features lead to difficult-to-debug mistakes (resources that aren't used every time end up missing in the cache only when they haven't been tested). I've changed the spec to make opportunistic caching never cache without a manifest. On Wed, 16 Jul 2008, Honza Bambas wrote: When application cache update is invoked by document load that is completely fetched from offline application cache while the browser is in offline mode what exactly should happen? Let's say we always want to have one of the onxxx events on applicationCache object get called. In case the browser is in offline mode (including user switch to offline mode manually) the only reasonable event seems to be onerror call because the server could not actually be reached. The spec says nothing in particular about behavior of the update process while browser is offline. I'm not really sure I follow. There are all kinds of events fired during the cache update process. While offline, you get checking followed by error. What's the problem? On Tue, 5 Aug 2008, Aaron Boodman wrote: Some quick notes/questions... - I think the manifest should be some structured, extensible format such as XML or JSON. The current text-based format is going to quickly turn into a mess as we add additional fields and rows. The problem with XML is that it _dramatically_ increases the complexity of the code that has to deal with the manifest. You have to check namespaces, tag names, node types, etc, just to handle the many bazillion kinds of errors that XML enables (and I'm only talking about well-formed XML). JSON isn't quite as bad, but it still
