Re: [whatwg] Mathematics in HTML5

I'll speak up as one of the Mozilla layout developers, but speaking only for myself.Since we already have a MathML implementation --- which works fairly well in my experience --- I think it makes more sense from our point of view to fix/improve MathML than to deal with new CSS extensions to get dec

[whatwg] Codecs (was Re: Apple Proposal for Timed Media Elements)

- As mentioned above, some devices may have a much harder time implementing Ogg than other codecs. Although a SHOULD-level requirement would excuse them, I'm not sure it's appropriate to have it if it might be invoked often. OK, let's assume Theora is a bad format for some devices. If someone wa

[whatwg] Google Gears and HTML5

*Maciej Stachowiak wrote:* Now that Google Gears has been announced, I'd like to see the features in it added to the HTML5 spec, since these are features that should ultimately be a part of basic web technology, not an extension. Agreed... Ian has already added a S

Re: [whatwg] Google Gears and HTML5

On 5/31/07, Maciej Stachowiak <[EMAIL PROTECTED]> wrote: On May 30, 2007, at 8:32 PM, Robert O'Callahan wrote: On the plus side, JAR files make versioning and and consistency incredibly simple. It's not clear what the Gears ManagedStore does if it gets a 404 or some other

[whatwg] Offline Resources

*Maciej Stachowiak wrote: * I think the Google Gears design for this works better than the Mozilla design, because it lets offline mode use all the same URIs as regular mode, so the offline support can be cleanly factored from the rest of the web app. It's not that bad, if your app avoids using

[whatwg] Google Gears and HTML5

Chris Prince wrote: Gears returns an error when you first try to setup an ambiguous capture. How do you do that when an ambiguity is discovered during a manifest update? Since you're here, I'm curious about the motivation for a few of the Gears features. In particular, what's the use case for

Re: [whatwg] Google Gears and HTML5

On 6/12/07, Chris Prince <[EMAIL PROTECTED]> wrote: > what's the use case for "remove" Without it, once you put a given URL in the ResourceStore, it would be served from there forever. Also, remember that the ResourceStore doesn't auto-update URL contents like the ManagedResourceStore does. >

Re: [whatwg] Google Gears and HTML5

On 6/12/07, Aaron Boodman (Google) <[EMAIL PROTECTED]> wrote: On 6/11/07, Robert O'Callahan <[EMAIL PROTECTED]> wrote: > Chris Prince wrote: > How do you do that when an ambiguity is discovered during a manifest update? That's a good point, i think all we coul

[whatwg] Gears design goals

Aaron Boodman wrote: * To support seamless (non-modal) transitions between online, offline, and the browser-is-confused-and-thinks-you're-online-but-really-you're-not (wireless that you have to login to, slow DNS, and crashed servers that are serving 500s are all good examples of this last situa

Re: [whatwg] The issue of interoperability of the element

On 6/27/07, Jerason Banes <[EMAIL PROTECTED]> wrote: The question that I hate to ask (because it goes against my own grain to ask it) is, which is more useful to the web market: Asking Windows users to install Ogg/Theora codecs Actually, we just ask them to install Firefox :-) or asking Linu

Re: [whatwg] Gears design goals

On 6/27/07, Aaron Boodman <[EMAIL PROTECTED]> wrote: Great! So where do we differ on the implementation of those goals? Is there an up-to-date spec I can read? http://www.campd.org/stuff/Offline%20Cache.html Right now I think we're missing just one thing from your list of goals (excluding th

Re: [whatwg] The issue of interoperability of the element

On 6/27/07, Nicholas Shanks <[EMAIL PROTECTED]> wrote: On 27 Jun 2007, at 09:28, Maik Merten wrote: > Browsers don't rely on the OS to decode JPEG or PNG or GIF either In my experience that seems to be exactly what they do do—rely on the OS to provide image decoding (as with other AV media). I

Re: [whatwg] The issue of interoperability of the element

On 6/28/07, Nicholas Shanks <[EMAIL PROTECTED]> wrote: For your future reference, Robert, the browsers I am familiar with and was referring to in my statement about image decoders are WebKit-based browsers, OmniWeb 4.5 (historically), Camino and iCab 3. I avoid FireFox and Opera due to their non

Re: [whatwg] Gears design goals

On 6/30/07, Andy Palay <[EMAIL PROTECTED]> wrote: So I don't know why one would want to maintain atomicity at the domain level as opposed to the application level. When I run an application I want to make sure I get the latest version of the application. Not sure why it would mean that I want to

Re: [whatwg] Gears design goals

On 6/30/07, Andy Palay <[EMAIL PROTECTED]> wrote: On Jun 26, 2007 4:26 PM, Robert O'Callahan <[EMAIL PROTECTED]> wrote: > Sure they can. The user can only have one active login per browser session > anyway, so the app just swaps in a whole new set of resources when th

Re: [whatwg] Gears design goals

On 6/30/07, Aaron Boodman <[EMAIL PROTECTED]> wrote: On 6/26/07, Robert O'Callahan <[EMAIL PROTECTED]> wrote: > Right now I think we're missing just one thing from your list of goals > (excluding the vexatious "multiple resources for one URI" goal): a w

Re: [whatwg] Gears design goals

On 6/30/07, Aaron Boodman <[EMAIL PROTECTED]> wrote: I think as you tried more and more languages, you'd get more resources associated with the domain. And so the number of resources that would need to get revalidated on each view of the app would get larger. I don't think so --- just serve a

Re: [whatwg] Gears design goals

On 6/30/07, Aaron Boodman <[EMAIL PROTECTED]> wrote: On 6/29/07, Robert O'Callahan <[EMAIL PROTECTED]> wrote: > On 6/30/07, Aaron Boodman <[EMAIL PROTECTED]> wrote: > > I think as you tried more and more languages, you'd get more resources > > assoc

Re: [whatwg] Gears design goals

On 6/30/07, Andy Palay <[EMAIL PROTECTED]> wrote: But it does place a very large burdon on the servers. Google would expect to have quite a few applications and my guess is the last thing we would want is to keep pinging every application to see if it up to date whenever any application is used.

Re: [whatwg] Gears design goals

On 6/30/07, Robert O'Callahan <[EMAIL PROTECTED]> wrote: If it is, then I would suggest simply allowing consistency to be partitioned by directory as well. I'm not sure of the best way for the server to configure that, though. One option would be to use an HTTP header to all

Re: [whatwg] Gears design goals

On 7/1/07, Aaron Boodman <[EMAIL PROTECTED]> wrote: On 6/29/07, Robert O'Callahan <[EMAIL PROTECTED]> wrote: > > Manifest? I thought we were talking about the Mozilla proposal. > > I mentioned earlier that to get consistent updates without JARs, we have to &g

Re: [whatwg] Gears design goals

On 7/1/07, Andy Palay <[EMAIL PROTECTED]> wrote: As for the burden to put apps in their own domain - First it seems to be an unnecessary requirement. I build an app, I choose a URL as I normally would and I would hope everthing would work out fine. Second it doesn't work well for environments w

Re: [whatwg] Gears caching at identical URIs (was: Gears design goals)

On 7/2/07, Robert Sayre <[EMAIL PROTECTED]> wrote: Basically, I think offline caches should respect the Vary: HTTP header, and maybe more. Applications will need to do this right anyway, if they want to function correctly in the presence of ISP HTTP proxies (AOL, TMobile, etc), corporate firewa

Re: [whatwg] Gears caching at identical URIs (was: Gears design goals)

On 7/3/07, Robert Sayre <[EMAIL PROTECTED]> wrote: On 7/2/07, Robert O'Callahan <[EMAIL PROTECTED]> wrote: > On 7/2/07, Robert Sayre <[EMAIL PROTECTED]> wrote: > > > Basically, I think offline caches should respect the Vary: HTTP > > header, and mayb

Re: [whatwg] Gears caching at identical URIs (was: Gears design goals)

On 7/3/07, Robert Sayre <[EMAIL PROTECTED]> wrote: On 7/2/07, Robert O'Callahan <[EMAIL PROTECTED]> wrote: > On 7/3/07, Robert Sayre <[EMAIL PROTECTED]> wrote: > > On 7/2/07, Robert O'Callahan <[EMAIL PROTECTED]> wrote: > > &g

Re: [whatwg] Offline Web Apps

On 8/24/07, Ian Hickson <[EMAIL PROTECTED]> wrote: > > * Do we really need a way to ignore the query parameters when >fetching and serving from cache when offline? (The idea below assumes >not. I don't really understand the use case if the answer is yes.) Yes. Suppose Bugzilla had offline

Re: [whatwg] Offline Web Apps

On 9/8/07, Ian Hickson <[EMAIL PROTECTED]> wrote: > > Given that you'd have to radically rewrite the app anyway to use an > offline database instead of just using HTTP, why would we reuse the URI > query syntax feature? It seems like it'd be better (from a consistency > with existing specs point of

Re: [whatwg] Offline Web Apps

On 9/10/07, Ian Hickson <[EMAIL PROTECTED]> wrote: > > On Mon, 10 Sep 2007, Robert O'Callahan wrote: > > That's an option, but then you can't use the fragment identifier for its > > scroll-to behaviour when you use it to pass parameters. > > You ca

Re: [whatwg] Offline Web Apps

On 9/10/07, Ian Hickson <[EMAIL PROTECTED]> wrote: > > Why wouldn't you just offline-cache the >https://bugzilla.mozilla.org/show_bug.cgi?id=389437 > ...file? I might be storing its data in a local database so I can make changes to it locally while I'm offline. Rob -- "Two men owed money to

Re: [whatwg] Offline Web Apps

On 9/11/07, Dimitri Glazkov <[EMAIL PROTECTED]> wrote: > > Since, AFAIK, the fragment identifier is not passed onto the server by > the UA, I can't see how an application could be designed with proper > noscript degradation and reliance frament ids for query communication. > > Besides, using query

Re: [whatwg] Offline Web Apps with Open-Ended URI Spaces (was Re: Offline Web Apps)

On 9/20/07, Maciej Stachowiak <[EMAIL PROTECTED]> wrote: > 2) Many offline web apps will let you want to make changes, including > not just changing existing items, but also creating new items. To do > this, at minimum there needs to be an API to inject a new resource > into the offline cache prog

Re: [whatwg] Offline Web Apps

I haven't had time to study Ian's proposal properly yet, sorry. But some easy comments: On 9/20/07, Maciej Stachowiak <[EMAIL PROTECTED]> wrote: > > > Upgrader: > > Create a hidden browsing context. > > Load the upgrader in it. > > I don't like this whole upgrader idea. Parsing HTML and CSS and >

Re: [whatwg] Latest proposal for offline web app API

On 9/21/07, Ian Hickson <[EMAIL PROTECTED]> wrote: > > Provide methods and/or properties for the following: > > * Add a resource to the cache. The resource persists (it's a >permanent addition to the manifest.) So if an update retrieves a new version of the manifest from the server, what will

Re: [whatwg] Offline Web Apps

On 9/23/07, Maciej Stachowiak <[EMAIL PROTECTED]> wrote: > > Obviously, if the way to get the contents as text requires providing > the encoding, then it has to be a method. My comment was about the no- > argument methods. But you have a point that reading from disk is not a > simple get operation.

Re: [whatwg] Offline Web Apps

Ooops On 9/25/07, Maciej Stachowiak <[EMAIL PROTECTED]> wrote: > On Sep 24, 2007, at 10:45 PM, Robert O'Callahan wrote: > So I suspect that, much like synchronous XMLHttpRequest, synchronous file > reads will lead to excessive UI lockups in bad circumstances unanticipated

Re: [whatwg] Offline Web Apps

On 10/10/07, Ian Hickson <[EMAIL PROTECTED]> wrote: > On Fri, 21 Sep 2007, Robert O'Callahan wrote: > > -- Several Web app authors have asked for the ability to test whether a > > resource is cached, for their online apps. For example, when you're > > zooming

Re: [whatwg] Offline Web Apps

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 r

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

Re: [whatwg] When to stop elements from playing

On Oct 20, 2007 1:46 PM, fantasai <[EMAIL PROTECTED]> wrote: > Robert O'Callahan wrote: > > A related question is whether display:none audio and video elements > > should produce sound. > > No. "display: none" is defined to affect all media, and that cer

Re: [whatwg] When to stop elements from playing

On Oct 20, 2007 1:36 PM, Jonas Sicking <[EMAIL PROTECTED]> wrote: > Robert O'Callahan wrote: > > After some discussion on IRC, I think Jonas, Hixie and I agreed that > > we're OK with the following approach: > > -- sound is produced for display:none e

Re: [whatwg] When to stop elements from playing

After some discussion on IRC, I think Jonas, Hixie and I agreed that we're OK with the following approach: -- sound is produced for display:none elements and elements not in the DOM -- removing an element from the DOM automatically calls stop() on that element -- tearing down the owner document alw

[whatwg] When to stop elements from playing

Suppose a script creates a element, adds it to the document, starts it playing, then removes the element from the document and drops all references to it. When should the element stop playing? -- when the element leaves the document? -- when all JS references to the element have been dropped (and

Re: [whatwg] When to stop elements from playing

On Oct 19, 2007 11:55 AM, Geoffrey Garen <[EMAIL PROTECTED]> wrote: > > Suppose a script creates a element, adds it to the document, > > starts it playing, then removes the element from the document and > > drops all references to it. When should the element stop playing? > > > -- when the elemen

Re: [whatwg] When to stop elements from playing

On Oct 19, 2007 9:03 PM, Anne van Kesteren <[EMAIL PROTECTED]> wrote: > var soundeffect = new Audio("sound.wav") > soundeffect.onload = function() { this.play() } > > which is what was possible with the old Audio API (became ) Opera > implemented. > When would the Opera stop playing that soun

Re: [whatwg] When to stop elements from playing

On Oct 23, 2007 10:02 AM, Geoffrey Garen <[EMAIL PROTECTED]> wrote: > > -- sound is produced for display:none elements and elements not in > > the DOM > > Does this statement imply that elements producing sound must be > explicitly protected from garbage collection? > Yes. Rob -- "Two men owed

Re: [whatwg] Full screen for the element

On Oct 30, 2007 9:20 PM, Dave Singer <[EMAIL PROTECTED]> wrote: > I think if you can collect keystrokes then phishing is also on the cards, > alas. > FWIW, Flash and Silverlight try to address this by leaving full-screen mode when keys are pressed. Rob -- "Two men owed money to a certain moneyl

Re: [whatwg] several messages regarding Ogg in HTML5

On Dec 12, 2007 9:47 PM, Ian Hickson <[EMAIL PROTECTED]> wrote: > > The way i see it there are 3 possibilities so far: > > - use ogg, possible (but negligable) risk of submarine patents > > This is basically as acceptable to companies like Apple as H.264 is to the > free software community. > I d

Re: [whatwg] More random comments on the putImageData definition

On Jan 26, 2008 11:57 AM, Oliver Hunt <[EMAIL PROTECTED]> wrote: > Another thing that we need is some way to determine what the device > pixel->css pixel ratio is. Currently there's isn't even a real way to > tell that it's 1:1 -- you would have do do a fillRect(width-1, > height-1, 1, 1),; then

Re: [whatwg] More random comments on the putImageData definition

On Feb 10, 2008 10:07 PM, Oliver Hunt <[EMAIL PROTECTED]> wrote: > That said, basically what you're saying is that canvas should not support > hidpi. At all. There is no need to request the dpi of a canvas, but (and > here's the critical bit) you can't have get/putImageData work at a different >

Re: [whatwg] More random comments on the putImageData definition

On Feb 11, 2008 11:37 AM, Oliver Hunt <[EMAIL PROTECTED]> wrote: > > On Feb 10, 2008, at 2:26 PM, Robert O'Callahan wrote: > > On Feb 10, 2008 10:07 PM, Oliver Hunt <[EMAIL PROTECTED]> wrote: > > > That said, basically what you're saying is that canvas s

Re: [whatwg] createImageData -> new ImageData() ?

On Feb 10, 2008 11:14 PM, Anne van Kesteren <[EMAIL PROTECTED]> wrote: > That would mean that passing ImageData around between two > elements doesn't always work as expected. I think that's highly > undesirable. Is there any implementation where we know this will the case? > Not yet, but in Geck

Re: [whatwg] More random comments on the putImageData definition

On Feb 11, 2008 11:49 AM, Ian Hickson <[EMAIL PROTECTED]> wrote: > If we have one API, high-res only: > > People who use it correctly: > get good results both today and tomorrow. > People who use it wrongly: > get good results today. > will get cropped or visibly wrong results t

Re: [whatwg] More random comments on the putImageData definition

On Feb 11, 2008 1:05 PM, Oliver Hunt <[EMAIL PROTECTED]> wrote: > > i was thinking having a style property, say, canvas-dpi: auto|device or > something, where the default auto value automagically does the evil > downsampling the moment a data routine is used, and device would result in > the right

Re: [whatwg] More random comments on the putImageData definition

On Feb 11, 2008 12:51 PM, Oliver Hunt <[EMAIL PROTECTED]> wrote: > > > > and the cost of sub-/super-sampling removes the whole "speed" thing > > that the API was originally added for. > > > > Not so sure about this. Script manipulation of pixel data probably isn't > going to be faster than native

Re: [whatwg] More random comments on the putImageData definition

On Feb 11, 2008 2:57 PM, Oliver Hunt <[EMAIL PROTECTED]> wrote: > > On Feb 10, 2008, at 5:44 PM, Robert O'Callahan wrote: > > On Feb 11, 2008 1:05 PM, Oliver Hunt <[EMAIL PROTECTED]> wrote: > > > > i was thinking having a style property, say, canvas-dpi

Re: [whatwg] Workers in HTML5

On Wed, Feb 20, 2008 at 3:05 PM, Maciej Stachowiak <[EMAIL PROTECTED]> wrote: > If XMLHttpRequest is one of the APIs available on background threads, > does that include its XML parsing/serialization features (responseXML > and the ability to pass a Document as the post data)? If so, then > effect

Re: [whatwg] Usemap and ismap for canvas tag

Wouldn't it make more sense just to use SVG? 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 LO

Re: [whatwg] Some questions

On Thu, May 15, 2008 at 12:43 AM, Ian Hickson <[EMAIL PROTECTED]> wrote: > > > Here's a precise scenario: A user creates an HTML5 page, and of course > > uses the element to embed their Windows Media content. They're > > rude, and could care less about Mac or Linux support. > > > > Will Safari

Re: [whatwg] WebIDL vs HTML5 storage changes

If "storage.keyName = 'value';" can create a new storage item (persistently), won't authors expect "delete storage.keyName;" to remove it (persistently), as a matter of consistency? If overloading "delete" is too quirky or too hard to implement, then it seems none of the other shorthands should be

Re: [whatwg] WebIDL vs HTML5 storage changes

On Tue, May 20, 2008 at 3:50 PM, Maciej Stachowiak <[EMAIL PROTECTED]> wrote: > > On May 19, 2008, at 4:54 PM, Robert O'Callahan wrote: > > If "storage.keyName = 'value';" can create a new storage item >> (persistently), won't

Re: [whatwg] WebIDL vs HTML5 storage changes

On Wed, May 21, 2008 at 10:34 AM, Maciej Stachowiak <[EMAIL PROTECTED]> wrote: > style.opacity = ... certainly triggers DOM API even if opacity was not > previously set on that style. > The property was always there, though, from the JS point of view. And there is even a plausible mapping for de

Re: [whatwg] [canvas] imageRenderingQuality property

On Tue, Jun 3, 2008 at 9:34 AM, Vladimir Vukicevic <[EMAIL PROTECTED]> wrote: > > Yeah, I agree -- I thought that there was some plan somewhere to uplift a > bunch of these SVG CSS properties into general usage? I know that Gecko > uplifted text-rendering, we should figure out what else makes sen

Re: [whatwg] [canvas] imageRenderingQuality property

On Tue, Jun 3, 2008 at 9:39 AM, Oliver Hunt <[EMAIL PROTECTED]> wrote: > That's exactly what i would be afraid of people doing. If I have a fast > system why should i have to experience low quality rendering? It should be > the job of the platform to determine what level of performance or qualit

Re: [whatwg] [canvas] imageRenderingQuality property

On Wed, Jun 11, 2008 at 10:34 PM, Ian Hickson <[EMAIL PROTECTED]> wrote: > Why not just have the UA run in a high quality mode the first time it is > painted on, but if the script tries to paint again within a certain amount > of time, switch to high speed? > This makes sense. However, there is

Re: [whatwg] more drag/drop feedback

On Thu, Jun 19, 2008 at 9:31 AM, Thomas Broyer <[EMAIL PROTECTED]> wrote: > On Wed, Jun 18, 2008 at 4:46 PM, Neil Deakin wrote: > > We have a need to be able to support both dragging multiple items, as > well > > as dragging non-string data, for instance dragging a set of files as a > set > > of F

Re: [whatwg] Proposed additions to ClientInformation interface

On Tue, Jul 8, 2008 at 10:04 AM, Ian Hickson <[EMAIL PROTECTED]> wrote: > One possibility for addressing these requirements would be an element that > acts as a link, button, or icon, or some such, and which invokes user > agent features. Something like: > > > It's an interesting idea. You'd h

Re: [whatwg] Proposed additions to ClientInformation interface

On Tue, Jul 8, 2008 at 11:06 AM, Ian Hickson <[EMAIL PROTECTED]> wrote: > Indeed. (This isn't unique to this proposal; the original idea of an API > would be even more vulnerable to this, since scripts could just invoke it > at any time they please.) > Of course, but that can be seen as an advant

Re: [whatwg] Application deployment

The offline app cache can be used to accelerate online apps this way. The jar: protoocol works pretty well too. However, any mechanism that lets you reference the contents of a ZIP file requires care to avoid XSS attacks. Rob -- "He was pierced for our transgressions, he was crushed for our iniq

Re: [whatwg] Application deployment

On Mon, Jul 28, 2008 at 7:55 PM, Adam Barth <[EMAIL PROTECTED]> wrote: > I suspect > the reason the Firefox developers chose ! to separate the URL to the > JAR from the path within the JAR is that ! is not a valid URL > character. > I think Java invented the syntax, actually. The main value of u

Re: [whatwg] Application deployment

On Mon, Jul 28, 2008 at 8:56 PM, Adrian Sutton <[EMAIL PROTECTED]>wrote: > It's also worth noting that the jar: scheme will allow you to target > anchors > in a HTML document that's within the archive where as the fragment > identifier syntax would not, unless you used two fragment identifiers: >

Re: [whatwg] Application deployment

On Tue, Jul 29, 2008 at 8:02 AM, Dave Singer <[EMAIL PROTECTED]> wrote: > > c) that the contents of the container, once fetched and un-packed, > logically 'shadow' the directory where the container came from. > It sounds like that affects all loads, which leads to issues: So if I load http://ww

Re: [whatwg] Application deployment

On Tue, Jul 29, 2008 at 6:21 AM, Kristof Zelechovski <[EMAIL PROTECTED]>wrote: > My complaint was about how the jar URL scheme wannabe conceptually > differs from the schemes we already officially have, not about how ugly it > is to have two consecutive colons. It is ugly but it does not matter.

Re: [whatwg] Application deployment

On Tue, Jul 29, 2008 at 5:59 AM, Russell Leggett <[EMAIL PROTECTED]>wrote: > Yes, the one major hang up that I foresee is how a browser should handle > asynchronous loading. How would it know the contents of the archive before > it loaded the archive so it did not try to load the same files direct

Re: [whatwg] Application deployment

On Tue, Jul 29, 2008 at 2:52 AM, Kristof Zelechovski <[EMAIL PROTECTED]>wrote: > Archive: is not generic enough but perhaps you could bend the URL > notation to embrace something like inside:. I still would not recommend it > but it would not make me that sore. > > How about http://www.site.com/

Re: [whatwg] Application deployment

On Tue, Jul 29, 2008 at 11:20 AM, Dave Singer <[EMAIL PROTECTED]> wrote: > Caching is on a full URL basis, of course. Once that is decided, then yes, > I think that pre-cached items for a given URL are in the general cache for > that site. > A site that uses this feature is likely to be fragile.

[whatwg]

Currently the spec doesn't say anything about the rendering of the element. Webkit makes without "controls" display:none by default, which seems reasonable, but it would be nice if spec recommended this behaviour. When "controls" is added, the element needs to be visible, so it will need an intri

Re: [whatwg] Scripted querying of capabilities

That would be nice to have. Unfortunately DirectShow and Quicktime do not seem to expose the ability to enumerate supported codecs, so it might be hard to implement for some browsers. As things stand, you can use elements to offer different formats, and you can try to play a stream and use script

[whatwg] Setting the "title" attribute

http://www.w3.org/html/wg/html5/#dom-tree > >1. If the title element is > null, then a new >title element must be created >and appended to the head > element

Re: [whatwg] Setting the "title" attribute

On Thu, Aug 7, 2008 at 10:43 PM, Jonas Sicking <[EMAIL PROTECTED]> wrote: > Actually, if we make the changes discussed to the mutation events spec, we > can consider setting the title a compound operation. This means that > mutation events won't fire until the above algorithm is fully done, so any

Re: [whatwg] Scripted querying of capabilities

On Thu, Aug 7, 2008 at 6:53 PM, Tim Starling <[EMAIL PROTECTED]>wrote: > DirectShow and QuickTime can add those interfaces at a later date. When > the backends develop this capability, there should be a standard way to > go the next step and expose it to JavaScript. Otherwise every > implementor w

Re: [whatwg] Active workers when user leaves the page

On Sat, Aug 9, 2008 at 7:01 AM, Jonas Sicking <[EMAIL PROTECTED]> wrote: > I do want to be agressive with killing workers when the user leaves a page > since that makes for better user experience. However I'm also worried about > stopping scripts halfway through breaking things and leaving the sit

Re: [whatwg] WebWorkers vs. Threads

On Thu, Aug 14, 2008 at 10:06 PM, Shannon <[EMAIL PROTECTED]> wrote: > On second thoughts I withdraw these claims. I don't have the statistics to > know one way or the other why "portable threads" are more prevalent than > "share nothing" ones. There may be many reasons but latencies probably isn'

Re: [whatwg] WebWorkers vs. Threads

On Fri, Aug 15, 2008 at 7:54 AM, Maksim Orlovich <[EMAIL PROTECTED]> wrote: > It's actually a lot worse in this case, since the ECMAScript runtime must > be able to enforce the sandbox properly even in face of incorrectly > threaded programs. > In particular, if two threads are accessing propertie

[whatwg] whitespace compression in document.title

IE7, FF3 and Opera 9.51 compress whitespace when getting document.title. \t and \n (at least) are converted to spaces, runs of consecutive spaces are compressed to a single space, and leading and trailing spaces are stripped. Safari 3.1 follows the spec and does none of this. We've got a report th

Re: [whatwg] whitespace compression in document.title

On Mon, Aug 18, 2008 at 2:19 PM, Ian Hickson <[EMAIL PROTECTED]> wrote: > On Mon, 18 Aug 2008, Robert O'Callahan wrote: > > > > IE7, FF3 and Opera 9.51 compress whitespace when getting document.title. > > \t and \n (at least) are converted to spaces, runs of conse

Re: [whatwg] overflow of seamless iframes

On Fri, Aug 1, 2008 at 9:11 AM, Ian Hickson <[EMAIL PROTECTED]> wrote: > My original idea (apparently not well conveyed in the spec) is that it > doesn't actually affect the rendering model at all -- it's still an > , it just doesn't have a border, and the CSS style sheets cascade > into it and pr

Re: [whatwg] overflow of seamless iframes

On Mon, Aug 18, 2008 at 4:40 PM, Ian Hickson <[EMAIL PROTECTED]> wrote: > On Mon, 18 Aug 2008, Robert O'Callahan wrote: > > > Note that the default width and height are adjusted for seamless > > > iframes to match the width that the element would have if it was

Re: [whatwg] overflow of seamless iframes

On Mon, Aug 18, 2008 at 6:45 PM, Ian Hickson <[EMAIL PROTECTED]> wrote: > On Mon, 18 Aug 2008, Robert O'Callahan wrote: > > On Mon, Aug 18, 2008 at 4:40 PM, Ian Hickson <[EMAIL PROTECTED]> wrote: > > > On Mon, 18 Aug 2008, Robert O'Callahan wrote: > >

[whatwg] Using as a source for canvas.drawImage

Thanks to Anne for pointing this out... We've implemented using elements as an image source in canvas.drawImage: https://bugzilla.mozilla.org/show_bug.cgi?id=448674 The extension is very obvious. Unlike animated images, which always draw the first or poster frame, we draw the current frame of the

Re: [whatwg] Using as a source for canvas.drawImage

On Tue, Aug 19, 2008 at 11:24 AM, Oliver Hunt <[EMAIL PROTECTED]> wrote: > Cool -- I wonder though if it would be better if it were placed in a > different method, drawFrame or something (very much an up in the air sort of > question) > drawImage is already overloaded, so why not carry on with th

Re: [whatwg] overflow of seamless iframes

On Tue, Aug 19, 2008 at 12:21 PM, Ian Hickson <[EMAIL PROTECTED]> wrote: > On Mon, 18 Aug 2008, Robert O'Callahan wrote: > > > > Suppose the iframe's document is > > > > What's the height of the bounding box? 400px or 500px? > > 500px. >

Re: [whatwg] overflow of seamless iframes

On Tue, Aug 19, 2008 at 1:05 PM, Robert O'Callahan <[EMAIL PROTECTED]>wrote: > On Tue, Aug 19, 2008 at 12:21 PM, Ian Hickson <[EMAIL PROTECTED]> wrote: > >> On Mon, 18 Aug 2008, Robert O'Callahan wrote: >> > >> > Suppose the iframe's doc

Re: [whatwg] Scripted querying of capabilities

On Wed, Aug 20, 2008 at 9:53 PM, Henri Sivonen <[EMAIL PROTECTED]> wrote: > Do you mean trying to download each video, giving it to GStreaming and > seeing if an error code comes back? > That might be what we have to do, yes. But at least that can be done asynchronously. You couldn't implement a

Re: [whatwg] Scripted query proposal

On Fri, Aug 22, 2008 at 1:56 PM, Tim Starling <[EMAIL PROTECTED]>wrote: > interface HTMLMediaElement { >... >boolean supportsType(in DOMString type); >... > } > > The supportsType() method must return false if the user agent is sure it > cannot support the given type, and true if the u

Re: [whatwg] Scripted query proposal

On Fri, Aug 22, 2008 at 2:57 PM, Eric Carlson <[EMAIL PROTECTED]>wrote: > It is possible to build a list of all types supported by QuickTime > dynamically. WebKit does this, so Safari knows about both the built in types > and those added by third party importers. > You mean this http://trac.webki

Re: [whatwg] Scripted query proposal

On Sat, Aug 23, 2008 at 1:46 AM, Eric Carlson <[EMAIL PROTECTED]>wrote: > > On Aug 21, 2008, at 8:56 PM, Robert O'Callahan wrote: > > Does that actually enumerate all supported codecs? Looking at the Webkit > code and the Quicktime docs, it looks like it's just enu

Re: [whatwg] Scripted query proposal

On Sat, Aug 23, 2008 at 11:21 AM, Eric Carlson <[EMAIL PROTECTED]>wrote: > > A three state return is an interesting idea, but wouldn't you then be > required to return "maybe" for MIME types that can describe multiple > formats? For example, "video/mpeg" can be used to describe a video > element

Re: [whatwg] Scripted query proposal

On Sat, Aug 23, 2008 at 2:17 PM, Tim Starling <[EMAIL PROTECTED]>wrote: > With this proposal, I'm trying to find a compromise between the opinions > put forward on this list. Personally I'd be happy either way, as long as > the interface gets added in some form. > > The yes = maybe definition pre-

Re: [whatwg] A slightly different use-case for shared workers

On Thu, Aug 28, 2008 at 9:59 AM, Aaron Boodman <[EMAIL PROTECTED]> wrote: > I encounter sites frequently that want to "pop out" part of their > application free of the page, into a smaller window. For example, > Pandora radio (http://pandora.com) does this. The player starts out > embedded in the

Re: [whatwg] A slightly different use-case for shared workers

On Thu, Aug 28, 2008 at 12:30 PM, Aaron Boodman <[EMAIL PROTECTED]> wrote: > Hm, that is a good point. I didn't consider the the audio object would > keep playing smoothly when moved between documents. That seems > unlikely to be reliable across implementations, but I'll keep my > fingers crossed

  1   2   3   4   5   6   7   8   >