Re: [whatwg] drawImage() - image argument description for animation
On Mon, 22 Jun 2009, OmegaJunior wrote: Currently the drawImage() function defines the following behaviour for its image argument if that happens to represent an animation: When the drawImage() method is passed, as its image argument, an HTMLImageElement representing an animated image, the poster frame of the animation, or the first frame of the animation if there is no poster frame, must be used. This seems grammatically incorrect (but isn't). However, I found it a bit convoluted, and had to read it several times before understanding what was intended. Fixed. Thanks. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] [html5] r3306 - [] (0) Define interaction with CSS case-sensitivity rules.
On Tue, 23 Jun 2009, Simon Pieters wrote: + + pClasses from the code title=attr-classclass/code attribute + of spanHTML elements/span in documents that are in spanquirks + mode/span must be treated as case-insensitive./p This is the case for SVG classes, too, but maybe it's up to the SVG spec to define that. Yeah, I'd rather not poke any more fingers into SVG than I already have... + pAttribute selectors on an span title=HTML elementsHTML + element/span in an span title=HTML documentsHTML + document/span must treat the emvalues/em of attributes with + the following names as case-insensitive:/p Why are values case-insensitive only in HTML documents? The values are case-insensitive in XHTML, too. Do we really want to have anything case-insensitive in XML docs? This list is missing charset and ismap As far as I can tell, those are not case-insensitive in Selectors in either Gecko or WebKit. and presumably the new attributes in HTML5: [...] Why would we want to add anything to this list? I'd rather keep this list as small as possible. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] [html5] Image captions in FIGUREs
Dne Tue, 14 Jul 2009 02:52:22 +0200 Aryeh Gregor simetrical+...@gmail.com napsal/-a: On Mon, Jul 13, 2009 at 8:29 PM, Aen Tanhe...@aentan.com wrote: I was specifically referring to the LEGEND element. That seems to work less. WebKit just removes it from the DOM. Are you suggesting that for compatibility, it should be named something else so that it works at least as well as the other elements? Indeed, unless browsers let us style legend any way we want (let's say like span element), people won't use it (in figures) because it wouldn't be flexible enough. Just my two hundred five billion cents, Rollie.
[whatwg] .tags on HTMLCollections
Ian just pointed out to me that his current draft requires HTMLCollections to implement a tags() method (which seems to do a filter by tagName on the contents of the collection). As far as I can tell, IE, Webkit, and Opera implement this; Gecko does not. I was wondering whether any of the Webkit or Opera folks could comment on _why_ they implement this? I haven't seen any uses of this in the wild (outside document.all.tags, but document.all doesn't behave like a normal HTMLCollection in all sorts of other ways either). I'd rather be specifying (and implementing) a smaller DOM API, if that's all that's needed for actual web compat -Boris
Re: [whatwg] Plus Signs in Signed Integers
On Mon, Jul 13, 2009 at 8:07 PM, Ian Hicksoni...@hixie.ch wrote: On Thu, 18 Jun 2009, Smylers wrote: The algorithm for parsing signed integers does not allow an optional plus sign before positive integers; that is, parsing +4 will return an error at step 8 of this algorithm: http://www.whatwg.org/html5#rules-for-parsing-integers That is inconsistent with the algorithm for non-negative integers, which tolerates (and ignores) a leading plus sign (step 6): http://www.whatwg.org/html5#rules-for-parsing-non-negative-integers I've made + be tolerated by the signed parser also. Based on what Boris said, why make this distinction? Generally +1 is not considered a valid integer by most number parsing libraries. And since gecko is planning on becoming more strict, why follow (part of) it's lead here? / Jonas
Re: [whatwg] Plus Signs in Signed Integers
On Tue, 14 Jul 2009, Jonas Sicking wrote: On Mon, Jul 13, 2009 at 8:07 PM, Ian Hicksoni...@hixie.ch wrote: On Thu, 18 Jun 2009, Smylers wrote: The algorithm for parsing signed integers does not allow an optional plus sign before positive integers; that is, parsing +4 will return an error at step 8 of this algorithm: http://www.whatwg.org/html5#rules-for-parsing-integers That is inconsistent with the algorithm for non-negative integers, which tolerates (and ignores) a leading plus sign (step 6): http://www.whatwg.org/html5#rules-for-parsing-non-negative-integers I've made + be tolerated by the signed parser also. Based on what Boris said, why make this distinction? Generally +1 is not considered a valid integer by most number parsing libraries. And since gecko is planning on becoming more strict, why follow (part of) it's lead here? I was basing the change on what IE does, not on what Gecko does. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Issues with Web Sockets API
On Mon, Jul 6, 2009 at 9:30 PM, Ian Hickson i...@hixie.ch wrote: 1) The 'readyState' attribute can never actually be used by an application and is redundant. Initially, the 'readyState' attribute is set to CONNECTING, but while the object is in this state the user is not permitted to interact with the WebSocket in any way. The only useful thing that a user could do is set event handlers and wait for the 'open' event to fire. When the WebSocket becomes connected, the readyState becomes 1 and the 'open' event is fired. Once the WebSocket is open, the spec states that whenever the connection is closed the readyState changes to CLOSED and a 'close' event is enqueued. However, users can't usefully check the readyState to see if the WebSocket is still open because there are not and cannot be any synchronization guarantees about when the WebSocket may close. A user will have to wrap all calls to postMessage() (or send() if the function is renamed) in a try/catch block in order to handle INVALID_STATE_ERRs. Once the 'close' event has been received the readyState attribute is useless since the state of the WebSocket is known and can never change. I think 'readyState' should just go away since an application will have to keep track of state updates through the fired events and use try/catch blocks around all API calls anyway. The attribute is mostly present for debugging purposes. I wouldn't expect anyone to actually use it for production work. Is there precedent for other portions of the API that are mostly for debugging purposes? (I can't think of anything off the top of my head.) Also, maybe it should be noted as such in the spec? On Fri, 26 Jun 2009, James Robinson wrote: Not changing variables out from under executing JavaScript makes a lot of sense, but if that was the case then it's not clear when the readyState could be updated. The spec states When the *Web Socket connection is closed*, the readyState attribute's value must be changed to CLOSED (2), and the user agent must queue a task to fire a simple event called close at the WebSocket object. If the browser cannot mutate the readyState until JavaScript stops running then it would either have to either enqueue a second task to change readyState at some point in the future or set the readyState right before dispatching the 'close' event. The latter would be much nicer to implement - but then it does make the readyState completely useless as it would always be exactly equivalent to the last event that was fired on a given WebSocket. I've left it as is (the attribute changes on the fly), which is possibly risky, but more consistent with how such attributes are handled in general. If it's only for debugging purposes, maybe a cleaner way to define it is to simply be the last event fired on a given WebSocket? One other random question: in the IDL for WebSockets, the three constants for ready state are all defined as shorts but the value of ready state is a long. Is this an oversight? J
Re: [whatwg] Plus Signs in Signed Integers
On Thu, Jun 18, 2009 at 9:33 AM, Smylerssmyl...@stripey.com wrote: It also doesn't seem to match browser behaviour: the ol element's start attribute is an integer, so I tried this out in various browsers: ol start=+4 liPlus four /ol All the ones I had to hand (Firefox, Opera, Konqueror, Dillo, Lynx, Links, and W3M) numbered the element with 4. [snip] To check that it is specifically the plus sign they are ignoring and not any non-digit character I also tried: ol start=H2SO4 liAcid test /ol That should cause parsing an integer to abort and so the default of start=1 to be used. Opera, Links, and W3M get that right. Konqueror, Dillo, and Lynx all also seem to manage the aborting, but use a default of zero instead. Firefox parses the 2 out of H2SO4, seemingly using the first integer it can find in the attribute, so possibly isn't special-casing +. What does IE do in these two examples? It appears webkit treats the first one as start=4 and the second as start=0. / Jonas
Re: [whatwg] .tags on HTMLCollections
On Jul 13, 2009, at 11:55 PM, Boris Zbarsky wrote: Ian just pointed out to me that his current draft requires HTMLCollections to implement a tags() method (which seems to do a filter by tagName on the contents of the collection). As far as I can tell, IE, Webkit, and Opera implement this; Gecko does not. I was wondering whether any of the Webkit or Opera folks could comment on _why_ they implement this? I haven't seen any uses of this in the wild (outside document.all.tags, but document.all doesn't behave like a normal HTMLCollection in all sorts of other ways either). I'd rather be specifying (and implementing) a smaller DOM API, if that's all that's needed for actual web compat Support for HTMLCollection.tags() in WebKit predates the fork from KHTML. So we don't know why it was originally added. Regards, Maciej
Re: [whatwg] HTML 5 video tag questions
On Mon, 13 Jul 2009 23:32:44 +0200, Tab Atkins Jr. jackalm...@gmail.com wrote: On Mon, Jul 13, 2009 at 4:01 PM, Philip Jägenstedtphil...@opera.com wrote: I thought you meant video source fallback fallback content here /source /video I would prefer if fallback content and source elements weren't mixed on the same level, but maybe that's just me. Eh, fallback content for non-video browsers is already there, so it's nothing new. (You could also just put @fallback on the second source and drop the third source entirely for the same effect.) Once the source element is iterated by the resource selection algorithm and starts loading, the fallback attribute or the whole source element might be removed. You would have to set a flag at some point to remember the fallback state and unset it... when? What is the effect of video source fallback source src=cant.play.ogg fallback here /video ? It would hit the first source, note that there's no @src, see that there is @fallback, and immediately drop to showing fallback content. Is fallback irrevocable or could the same video element go back to showing video under some circumstances? It should be revocable in the exact same circumstances that a video element might start playing from one source, and then switch to another. From my reading of the algorithm I don't think this is possible, so fallback would be irrevocable. Right, anything but irrevocable fallback would make this even stranger than object fallback. Let's not go there. Does audio also have fallback content? It uses source and the same source-selection algorithm (and the same fallback situation in the case of non-audio browsers), so yes. This is why I suggested videosource src=cant.play.oggnew-fallback-elementOoops!/new-fallback-element/video I still think the use of this is questionable though. I'm not sure why you think the usecase is questionable. It seems pretty clear - it'd be nice to have a non-script way of showing content (specifically, alternate video players) when the browser supports video but can't play any of the provided sources. Yes, handling the (minor) use case video support + no supported source + no script would be nice, but only if it doesn't make an even bigger mess of the resource selection algorithm and doesn't allow switching back and forth between video and fallback. From what I can tell of the resource selection algorithm, fallback should be irrevocable, just like a successful source load is. The resource selection algorithm appears to need fairly trivial changes to accommodate this. Step 4, when parsing @src from video, insert a new substep between substeps 2 and 3. Pull the first sentence from the current substep 3 into this new substep, and say something like If the element has a fallback attribute, abort this algorithm immediately and display the fallback content. When parsing See below for why we can't put the fallback attribute on the video element. source elements, change step 3 so that whenever any of those conditions are met, if the source has @fallback the algorithm aborts immediately and shows the fallback content, otherwise it fires the error event and jumps to the search loop step as normal. This would only cause fallback to be used when the source element is rejected up front, not if it is a candidate for the resource fetch algorithm that fails to fetch/play. So you also need to check @fallback before step 6. However, by then the source element may very well be removed from the DOM, so I you'd have to assign @fallback to a variable earlier in the algorithm and check that. This approach is implementable in my guesstimation, but I'd really want to know more about the history of object fallback issues. Should fallback content be treated as if it were display:none, or are there nastier hacks involved? Alternately, we could just put @fallback always on the video element directly, rather than on source. That would preserve the first part of what I said, but now we have a step between substeps 9 and 10 that checks for @fallback on the video. If it finds it, it immediately aborts and shows the fallback content, otherwise substep 10 proceeds normally (waiting forever). That would cause the fallback to be triggered unconditionally during parsing: video fallback source src=foo type=video/x-unsupported !-- steps 8-10 run here -- source src=bar type=video/x-supported /video There's nothing in the resource selection algorithm that's special-cased for static markup by hooking into the parser, which would be required to make it work (but then only for static markup). Putting @fallback on the video element just won't work. -- Philip Jägenstedt Core Developer Opera Software
Re: [whatwg] HTML 5 video tag questions
On Mon, 13 Jul 2009 17:23:47 -0400, Michael A. Puls II
shadow2...@gmail.com wrote:
On Mon, 13 Jul 2009 17:01:26 -0400, Philip Jägenstedt
phil...@opera.com wrote:
Does audio also have fallback content?
With audio, you can set its display to 'none' and the audio will still
play. However, if its display is set to 'none' and the element were to
fall back to a child object element that loads a plug-in, things
wouldn't work because plug-ins don't work with a display of 'none'.
You would then have to detect that audio fell back so you could set
its display to inline-block for example so the fallback plug-in would
actually load. Or, there'd have to be a new css selector to handle this
like audio::fallback_state { display: inline-block} or a parent selector
on the child object element that was only applied when audio fell back
to it. Or, the browser would have to make plug-in objects that are
descendants of an audio element work with a display of 'none'.
The same applies to video if you want to set its display to 'none' and
just hear the audio.
I realize that this is also a problem for fallback in browsers that don't
support video and audio. So, it's not specific to falling back in
browser that *do* support them.
--
Michael
Re: [whatwg] HTML 5 video tag questions
On Mon, 13 Jul 2009 23:28:41 +0200, Jonas Sicking jo...@sicking.cc wrote:
On Mon, Jul 13, 2009 at 5:01 AM, Philip Jägenstedtphil...@opera.com
wrote:
The design you describe is what object tried to do, and it proved
to be
extremely problematic in practice -- and that was without another
built-in
fallback mechanism to complicate matters.
While object has had a very poor implementation story, I don't think
this was a big reason for that.
Robert O'Callahan, Boris Zbarsky and other gecko layout folks can
answer this better, but at least in gecko I don't think this part of
object was particularly hard to implement correctly once we actually
tried.
Has any browser vendor argued against displaying the fallback due to
high implementation burden?
Implementation probably isn't the biggest burden here, specifying sane
behavior is. For example:
If fallback content is displayed after the last source element has
failed,
what should happen when a new source element is inserted? Switching
back to
video mode would make it even more special than object fallback and
if you
don't you'll just get stuck with fallback and have effectively broken
the
possibility of inserting source elements via scripts.
Something like videosource
src=cant.play.oggnew-fallback-elementOoops!/new-fallback-element/video
is what you'd need to make the resource selection algorithm deal with
fallback in a sane way when scripts are disabled, but this is too much
of a
corner case to justify the complexity in my opinion.
I think fallback contents is simply defined as the contents of the
video, minus any source elements (which wouldn't render anyway).
No need for new-fallback-element.
If I may nit-pick, the spec explicitly says this content is not fallback
content. But your suggestion is to change is, so very well...
The simplest solution would be to display the fallback when there
aren't any source (or @src) elements being either displayed or
waiting to load. I think spec-wise the simplest thing would be to
display fallback when
The networkState of the element is NETWORK_NO_SOURCE.
This way even incremental rendering of the fallback contents would
work fine. The only case that's weird is markup like:
video
lots and lots of fallback here
source src=...
/video
There is a risk that content would be displayed, and then switch to
displaying video. This doesn't seem like a big problem as it seems
more likely that people will put the source first. And if someone
doesn't the effects aren't very bad.
Alternatively we could use the following rules:
1. The networkState of the element is NETWORK_NO_SOURCE.
*and*
2. The video element is fully parsed. I.e. it has been removed from
the stack of open elements.
This would mean that incremental rendering doesn't work. This doesn't
seem any worse than what we have now when fallback is never displayed.
Though I think it'd work fine always display fallback whenever the
networkState is NETWORK_NO_SOURCE.
/ Jonas
Anything that can cause the element to switch back and forth between
displaying fallback and video is a no-go, that would cause a race
condition for if plugins/images in the fallback content. If they have
event handlers the results will get ugly fast:
video
!-- network lag --
source
!-- network lag --
source
!-- network lag --
img src=foo onload=alert('how many times will you see this message?')
/video
--
Philip Jägenstedt
Core Developer
Opera Software
Re: [whatwg] Week Strings
Ian Hickson writes: On Fri, 19 Jun 2009, Smylers wrote: For input type=week elements the spec requires: The value attribute, if specified, must have a value that is a valid week string. -- http://www.whatwg.org/html5#week-state But the spec's HTML source contains this comment immediately afterwards: !-- ok to set out-of-range value, we never know when we might have to represent bogus input -- it [...] means that there's no requirement that the value= be within the range given by min= and max=. Thanks for clarifying that. input type=week value=2010-W53 input type=week value=2010-W54 If out-of-range week values are to be permitted in input elements then a validator should permit both of them. Conversely if they aren't permitted then it should accept neither of them. Please report such bugs straight to Henri. :-) Of course -- but I wanted to check what the correct behaviour was first. Smylers
Re: [whatwg] HTML 5 video tag questions
Philip Jägenstedt wrote:
Anything that can cause the element to switch back and forth between
displaying fallback and video is a no-go, that would cause a race
condition for if plugins/images in the fallback content. If they have
event handlers the results will get ugly fast:
video
!-- network lag --
source
!-- network lag --
source
!-- network lag --
img src=foo onload=alert('how many times will you see this message?')
/video
The answer to the question in the alert is once. This is true in the
current fallback model, and would presumably be true in the new fallback
model.
For the current model, note that all the text says is should not show
this content to the user. While this is not defined anywhere, it
doesn't seem to indicate that the content's DOM should not exist, for
example. In Gecko, at least, the image in your example will be loaded
and hence its onload will fire.
-Boris
Re: [whatwg] .tags on HTMLCollections
Maciej Stachowiak wrote: Support for HTMLCollection.tags() in WebKit predates the fork from KHTML. So we don't know why it was originally added. I guess the other question is whether you feel it's worth keeping... -Boris
Re: [whatwg] .tags on HTMLCollections
On Jul 14, 2009, at 2:50 AM, Boris Zbarsky wrote: Maciej Stachowiak wrote: Support for HTMLCollection.tags() in WebKit predates the fork from KHTML. So we don't know why it was originally added. I guess the other question is whether you feel it's worth keeping... I don't know of a reason it's needed for collections other than document.all. But it also doesn't seem harmful and I can't say definitively whether it helps anything. I wouldn't object to removing it from the spec, but we probably wouldn't remove it from WebKit short of evidence that it's actually harmful. Perhaps Opera people can shed more light on the matter. Regards, Maciej
Re: [whatwg] HTML 5 video tag questions
On Tue, Jul 14, 2009 at 9:46 PM, Boris Zbarsky bzbar...@mit.edu wrote: For the current model, note that all the text says is should not show this content to the user. While this is not defined anywhere, it doesn't seem to indicate that the content's DOM should not exist, for example. In Gecko, at least, the image in your example will be loaded and hence its onload will fire. There's actually a fairly major related problem here. We hide the fallback content by treating it as display:none. Currently Gecko has a huge bug where a display:none plugin does not load/run. This works out well for the video fallback case. If we fix that bug, then unless we do some special magic, plugin-based video fallback will run and play audio while the video element plays --- very bad. People have already discovered that video src=hellokitty.ogvobject data=hellokitty.ogv/object/video plays the audio track twice in Firefox, and aren't happy about it, although it's what the spec seems to suggest. I'm not sure how to modify the spec in a sane way to fix this case, though. 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]
Re: [whatwg] HTML 5 video tag questions
On Tue, Jul 14, 2009 at 3:05 AM, Robert O'Callahanrob...@ocallahan.org wrote: On Tue, Jul 14, 2009 at 9:46 PM, Boris Zbarsky bzbar...@mit.edu wrote: For the current model, note that all the text says is should not show this content to the user. While this is not defined anywhere, it doesn't seem to indicate that the content's DOM should not exist, for example. In Gecko, at least, the image in your example will be loaded and hence its onload will fire. There's actually a fairly major related problem here. We hide the fallback content by treating it as display:none. Currently Gecko has a huge bug where a display:none plugin does not load/run. This works out well for the video fallback case. If we fix that bug, then unless we do some special magic, plugin-based video fallback will run and play audio while the video element plays --- very bad. It shouldn't be that hard to for plugins walk the parent chain to see if there are any active video elements before starting the plugin. People have already discovered that video src=hellokitty.ogvobject data=hellokitty.ogv/object/video plays the audio track twice in Firefox, and aren't happy about it, although it's what the spec seems to suggest. I'm not sure how to modify the spec in a sane way to fix this case, though. We can do what's described above for videos and audios too (i.e. walk parent chain etc). / Jonas
[whatwg] Should target '_search' be taken as part of HTML 5 spec?
Target '_search' makes a link open in a sidebar (Opera) or sidebar-like window (IE). For some offline web apps would be cool to open sidebar by just one click. In other browsers (Firefox) web content could be open in a sidebar only by creating a bookmark, marking it as to open in a sidebar, use (click) that bookmark. So, there are tendencies and voices to open web content in a sidebar in all browsers but it is not taken as a standard. I would really like this feature to be available in all browsers. Opinions? Honza Bambas
Re: [whatwg] HTML 5 video tag questions
On Tue, Jul 14, 2009 at 10:34 PM, Jonas Sicking jo...@sicking.cc wrote: We can do what's described above for videos and audios too (i.e. walk parent chain etc). We can hack something in, but what about dynamic DOM changes? IFRAME loads? etc 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]
Re: [whatwg] HTML 5 video tag questions
On Tue, Jul 14, 2009 at 10:42 PM, Robert O'Callahan rob...@ocallahan.orgwrote: On Tue, Jul 14, 2009 at 10:34 PM, Jonas Sicking jo...@sicking.cc wrote: We can do what's described above for videos and audios too (i.e. walk parent chain etc). We can hack something in, but what about dynamic DOM changes? IFRAME loads? etc More importantly for this list, what should the spec say? 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]
Re: [whatwg] [html5] r3306 - [] (0) Define interaction with CSS case-sensitivity rules.
On Tue, 14 Jul 2009 08:26:37 +0200, Ian Hickson i...@hixie.ch wrote: and presumably the new attributes in HTML5: [...] Why would we want to add anything to this list? I'd rather keep this list as small as possible. Hmm. In that case maybe we can remove it altogether? I think it was only implemented for compliance with CSS2 and HTML4 when Niels Leenheer wrote a Selectors test suite back in 2006. -- Simon Pieters Opera Software
Re: [whatwg] HTML 5 video tag questions
On Tue, 14 Jul 2009 11:46:08 +0200, Boris Zbarsky bzbar...@mit.edu wrote:
Philip Jägenstedt wrote:
Anything that can cause the element to switch back and forth between
displaying fallback and video is a no-go, that would cause a race
condition for if plugins/images in the fallback content. If they have
event handlers the results will get ugly fast:
video
!-- network lag --
source
!-- network lag --
source
!-- network lag --
img src=foo onload=alert('how many times will you see this
message?')
/video
The answer to the question in the alert is once. This is true in the
current fallback model, and would presumably be true in the new fallback
model.
For the current model, note that all the text says is should not show
this content to the user. While this is not defined anywhere, it
doesn't seem to indicate that the content's DOM should not exist, for
example. In Gecko, at least, the image in your example will be loaded
and hence its onload will fire.
True, but you could easily have other things in the fallback content (like
mouse listeners) that are suddenly being triggered even though the
fallback content isn't going to be used. No switching back and forth,
please.
I've discussed the object fallback a bit with a knowledgeable colleague
who confirmed that we've had lots of problems with it. Uncertain state of
the fallback content from a scripts point of view is one issue. What to do
with nested objects (when to load/unload them) is another.
If we allow fallback people will certainly begin using nested video,
unless we want to another hack to prevent that.
Ian: can you make nested video elements non-conforming so that
validators will flag it? This would be helpful regardless of the fallback
discussion.
--
Philip Jägenstedt
Core Developer
Opera Software
Re: [whatwg] HTML 5 video tag questions
On Tue, Jul 14, 2009 at 5:05 AM, Robert O'Callahanrob...@ocallahan.org wrote: On Tue, Jul 14, 2009 at 9:46 PM, Boris Zbarsky bzbar...@mit.edu wrote: For the current model, note that all the text says is should not show this content to the user. While this is not defined anywhere, it doesn't seem to indicate that the content's DOM should not exist, for example. In Gecko, at least, the image in your example will be loaded and hence its onload will fire. There's actually a fairly major related problem here. We hide the fallback content by treating it as display:none. Currently Gecko has a huge bug where a display:none plugin does not load/run. This works out well for the video fallback case. If we fix that bug, then unless we do some special magic, plugin-based video fallback will run and play audio while the video element plays --- very bad. People have already discovered that video src=hellokitty.ogvobject data=hellokitty.ogv/object/video plays the audio track twice in Firefox, and aren't happy about it, although it's what the spec seems to suggest. I'm not sure how to modify the spec in a sane way to fix this case, though. How do y'all currently handle noscript content in a context that allows scripts? What if there was a video or object in the noscript? ~TJ
Re: [whatwg] Codecs for video and audio
On Tue, Jul 7, 2009 at 5:09 PM, Ian Hicksoni...@hixie.ch wrote: We've narrowed codecs down to two. The spec could say that UA which supports video MUST implement at least one of Theora or H.264. All vendors can comply with that, and that's better than not specifying any codecs at all (e.g. doesn't allow browsers to support WMV only). That may be where we end up if we really can't resolve this, yes. That would be unfortunate, thouh. I don't see how that helps, if the spec is descriptive rather then prescriptive. Surely if a major browser were to pop up and say we will only support VC1 you'd be forced to change the spec to permit that? If you can't forbid people from supporting H.264 only, via spec text, I don't understand how you could forbid people from supporting WMV only via spec text. I also still don't understand how YouTube's objection is relevant to the codec decision for the standard, since the 1% browser from that company _will_ support Theora. But that would be less important to me if there were something more crisp than quality-per-bit isn't good enough, so that people could reasonably work to reach that target. Some sort of statement about what would be good enough would certainly make the objection more constructive, and to my eyes at least would make it a more principled basis for influencing the spec. Mike
[whatwg] Error handling for MIME type parsing (canPlayType)
While implementing canPlayType I've found that Firefox/Safari/Chrome (and now Opera) all have different error handling in parsing the MIME types. RFC 2045[1] gives the BNF form, but it appears that no browser gives much weight to this. Sample of quirks: (Ignore no vs here, it's not relevant) Firefox: AUDIO/X-WAV: no audio/x-wav codecs: maybe audio/x-wav; codecs=: probably audio/x-wav; codecs=,: no Safari: AUDIO/X-WAV: no audio/x-wav codecs: no audio/x-wav; codecs=: probably audio/x-wav; codecs=,: maybe Opera internal: AUDIO/X-WAV: audio/x-wav codecs: audio/x-wav; codecs=: maybe audio/x-wav; codecs=,: maybe Chrome ignores codecs, so I can't get meaningful results. I believe the correct answers are: AUDIO/X-WAV: same as for audio/x-wav (by RFC 2045, but we could ignore it because it looks ugly) audio/x-wav codecs: the same as audio/x-unknown-type (i.e. no for Firefox) audio/x-wav; codecs=: same as audio/x-wav (unless we want this to mean no codecs, in which case no would be more appropriate) audio/x-wav; codecs=,: same as audio/x-wav (i.e. ignore broken codecs parameter) Has there been any work done on defining error handling for Content-Type parsing or the like? It wouldn't be fun to get cross-browser bugs as soon as someone forgets a semicolon... -- Philip Jägenstedt Core Developer Opera Software
Re: [whatwg] HTML 5 video tag questions
On Tue, Jul 14, 2009 at 3:29 AM, Philip Jägenstedtphil...@opera.com wrote: On Mon, 13 Jul 2009 23:32:44 +0200, Tab Atkins Jr. jackalm...@gmail.com wrote: source elements, change step 3 so that whenever any of those conditions are met, if the source has @fallback the algorithm aborts immediately and shows the fallback content, otherwise it fires the error event and jumps to the search loop step as normal. This would only cause fallback to be used when the source element is rejected up front, not if it is a candidate for the resource fetch algorithm that fails to fetch/play. So you also need to check @fallback before step 6. However, by then the source element may very well be removed from the DOM, so I you'd have to assign @fallback to a variable earlier in the algorithm and check that. Ah, yes, you're right. You'd have to check for @fallback at the end of substep 2 (those subsubsteps are guaranteed atomic, so no race condition) and set a flag, then actually activate fallback if the algorithm fails at step 3 or 6. This approach is implementable in my guesstimation, but I'd really want to know more about the history of object fallback issues. Should fallback content be treated as if it were display:none, or are there nastier hacks involved? As others note in emails following yours, there are already issues with the existing defined fallback content. Once those are successfully resolved, I believe it should work fine for here as well. Successfully resolving them, though, will almost certainly require nastier hacks. Alternately, we could just put @fallback always on the video element directly, rather than on source. That would preserve the first part of what I said, but now we have a step between substeps 9 and 10 that checks for @fallback on the video. If it finds it, it immediately aborts and shows the fallback content, otherwise substep 10 proceeds normally (waiting forever). That would cause the fallback to be triggered unconditionally during parsing: video fallback source src=foo type=video/x-unsupported !-- steps 8-10 run here -- source src=bar type=video/x-supported /video There's nothing in the resource selection algorithm that's special-cased for static markup by hooking into the parser, which would be required to make it work (but then only for static markup). Putting @fallback on the video element just won't work. Sorry, I assumed that checking it at step 10 *did* effectively special-case static markup. I assume that I'm wrong because the delay could just be due to the network/parser being slow at receiving and adding the source elements that are supposed to be in the the static document? If so, then yeah, you're right. @fallback can only be placed on video @src, but not when source elements are involved. ~TJ
Re: [whatwg] HTML 5 video tag questions
On Tue, Jul 14, 2009 at 9:02 AM, Simon Pieterssim...@opera.com wrote: On Tue, 14 Jul 2009 14:51:42 +0200, Tab Atkins Jr. jackalm...@gmail.com wrote: How do y'all currently handle noscript content in a context that allows scripts? What if there was a video or object in the noscript? noscript is parsed as a CDATA element in the HTML parser when scripting is enabled. Any tags would be interpreted as text. This is not the case for object or video because it's ugly and doesn't work in XHTML. You'll notice that noscript is not allowed in XHTML5. Hrm, that's no good then. *Something* has to be done about it, though, because just display:none'ing the fallback content doesn't allow legacy video clients to be tried, which the spec explicitly mentions (and just plain makes sense anyway - without it, video adoption will be substantially slower). We need *some* way to indicate that particular elements aren't to be activated at all in certain circumstances. On a side note, does the old objectembed/ trick work only because the browsers that support that use of object don't support that use of embed, and vice versa? So even though the embed is parsed in an object-supporting browser, it doesn't activate? If so, then it seems like our problem is *too much* interop now. ^_^ ~TJ
Re: [whatwg] Browser Bundled Javascript Repository
On Jul 13, 2009, at 3: 01PM, Aryeh Gregor wrote: How about you have an extra HTTP header like X-Content-Hash? This could provide a SHA256 hash (or something else that looks safe for now, progressively upgradeable) of the content. The browser can keep its cached copies of these files indexed by hash. If it tries downloading a file, and notices that the hash is the same as a file already downloaded, it can terminate the HTTP connection and use the existing file (even if it's from a different site). It will then proceed as though it had actually downloaded the file: e.g., it will respect the Expires headers separately (two sites might serve the same file but have different expectations about how likely it is to change). I think thats brilliant. Its a cache that works across all sites. On Jul 13, 2009, at 3: 01PM, Aryeh Gregor wrote: The most obvious place to solve this seems to be HTTP, not HTML. HTTP is closer to the resource itself. If you do something with HTML, like an extra link attribute, then you're going to get authors updating the HTML but not the thing it points to or vice versa. An ETag-like solution would be implemented either in the web server or whatever script is serving the content, and those should always know whether the file has changed. (Modulo pathological behavior like something changing the file and then forging the mtime/ctime.) I agree. On Jul 13, 2009, at 4: 20PM, Aryeh Gregor wrote: Does anyone have statistics on how useful this would be in real life? I suspect only marginally. I think this is the most important aspect of this idea. We don't yet know if this is worth doing yet. It is likely only preventing the initial download of some files. However some of the initial framework sizes are getting hefty: (These were the sizes just pulled from google's hosted libraries for the latest versions) 91K dojo.xd.js 79K ext-core.js 182K jquery-ui.min.js 56K jquery.min.js 127K prototype.js 2.6K scriptaculous.js 10K swfobject.js 27K yuiloader-min.js I'm guessing that mobile browsers would benefit from not needing to download a few of those 100KB downloads and use up an HTTP Connection to do so. And speaking of mobile, there are some mobile specific web application frameworks (I'm thinking of ones for iPhone web apps) that don't have a single cache point (like google) that weigh in pretty heavily. Real statistics would make it obvious wether or not this is a good idea. But even still, I like the HTTP idea, because at that point its just a more efficient way to cache files, by content, across all the entire web, rather then site specific and by name/URL. - Joe
Re: [whatwg] Should target '_search' be taken as part of HTML 5 spec?
On Tue, Jul 14, 2009 at 3:39 AM, Honza Bambas hon...@allpeers.com wrote: Target '_search' makes a link open in a sidebar (Opera) or sidebar-like window (IE). For some offline web apps would be cool to open sidebar by just one click. In other browsers (Firefox) web content could be open in a sidebar only by creating a bookmark, marking it as to open in a sidebar, use (click) that bookmark. So, there are tendencies and voices to open web content in a sidebar in all browsers but it is not taken as a standard. I would really like this feature to be available in all browsers. Not all browsers support sidebars. Notably, Google Chrome has no such concept. I'm also not sure why search semantically means open in a sidebar. Those two aren't really related in my head. PK
Re: [whatwg] Codecs for video and audio
On Tue, Jul 14, 2009 at 11:14 AM, Mike Shaver mike.sha...@gmail.com wrote: which led me to believe that YouTube's opinion was part of the relevant-vendor positions which led to the choice to not specify a codec. If it's not relevant, then its inclusion was certainly quite confusing I am referring to emails sent after that point (sorry, don't have direct quotes handy) which, IIRC, said that the reason Theora was not named a baseline codec was Apple's decision not to support it, and that if people convinced Apple to support it, that decision would be changed. It makes sense if you think about it -- whether YouTube sends videos encoded as H.264 is irrelevant to what the _baseline_ codec for video needs to be, it is only relevant as additional info for vendors deciding whether to support H.264. PK
Re: [whatwg] Codecs for video and audio
On Tue, Jul 14, 2009 at 2:19 PM, Peter Kastingpkast...@google.com wrote: It makes sense if you think about it -- whether YouTube sends videos encoded as H.264 is irrelevant to what the _baseline_ codec for video needs to be, it is only relevant as additional info for vendors deciding whether to support H.264. Yes, I concur -- I couldn't think of any reason for that to be relevant to the discussion of baseline codecs at first, so I tried to make it fit (and asked questions about the details of it). I will patiently await the details. :-) Mike
Re: [whatwg] Should target '_search' be taken as part of HTML 5 spec?
On Tue, Jul 14, 2009 at 6:39 AM, Honza Bambashon...@allpeers.com wrote: Target '_search' makes a link open in a sidebar (Opera) or sidebar-like window (IE). Firefox used to have this behavior, but it was accidentally broken prior to 3.0 (opened a new tab instead). We then removed it in 3.0.2 because only one person had noticed the change in behavior, and it didn't seem worth the code complexity or maintenance cost. https://bugzilla.mozilla.org/show_bug.cgi?id=438526 has more details. Comment 7 in that bug implies that IE 7 only supports if you enable a non-default preference option. Gavin
Re: [whatwg] Error handling for MIME type parsing (canPlayType)
On Wed, Jul 15, 2009 at 12:56 AM, Philip Jägenstedt phil...@opera.comwrote: While implementing canPlayType I've found that Firefox/Safari/Chrome (and now Opera) all have different error handling in parsing the MIME types. RFC 2045[1] gives the BNF form, but it appears that no browser gives much weight to this. In Firefox I just reused our existing MIME type parser. I'm not sure how tightly that parser is constrained by Web compatibility quirks issues. audio/x-wav codecs: the same as audio/x-unknown-type (i.e. no for Firefox) Yes, that seems like a bug. audio/x-wav; codecs=: same as audio/x-wav (unless we want this to mean no codecs, in which case no would be more appropriate) I interpret this as no codecs. In that case, probably is correct, since we support every codec in the list. audio/x-wav; codecs=,: same as audio/x-wav (i.e. ignore broken codecs parameter) I interpret this as two codecs, both whose name is the empty string. We don't support that codec. Has there been any work done on defining error handling for Content-Type parsing or the like? That's a very good question, but I don't know the answer. 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] AppCache can't serve different contents for different users at the same URL
Most apps provide different contents for the same uncacheable main-page URL, depending on the identity of the user, which is typically stored in a cookie and read by the server. However, the HTML5 AppCache spec doesn't allow cookies to influence the choice of AppCaches or the contents of a response returned by the cache. This makes it a lot harder, but not impossible, for developers of existing apps to start using AppCache, while still supporting multiple users per browser or browser profile. Without changing the user-visible URL structure of an app, developers might support multiple users, by replacing their server-generated user-specific main page, with a generic cacheable JS app that does this: 1) Establish the user's identity using a cookie, or a database record, or a session key-value store. 2) If the user can be identified, load the user-specific resources (JS, CSS, data, etc.) from the network and/or local storage, possibly including a separate AppCache with user-specific or fingerprint-specific URLs. Otherwise, load the unknown-user version or a login page. That'd be a complete restructuring of the main page, but it's possible. I suspect that this is the model the AppCache was designed to support. A more radical change to existing apps, and app design in general, would be to include account-identifying information in the user-visible URL. The main page could redirect users to their user-specific page or the unknown-user page.
Re: [whatwg] MediaElement enhancement - preservesPitch attribute
On Tue, 23 Jun 2009, Brady Eidson wrote: From 4.8.10.9: If the playbackRate is not 1.0, the user agent may apply pitch adjustments to the audio as necessary to render it faithfully. While pitch correction is certainly desirable a lot of the time, we've found that it is also desirable to disable pitch correction on demand. Content authors might *prefer* the chipmunk effect during faster playback or the stretched low voice effect during slower playback. As such, WebKit just added a new attribute to the MediaElement called webkitPreservesPitch. For now it defaults to true, as the default playback behavior for our main ports has been to do pitch correction. But by setting it to false, author's can get the chipmunk/stretch effect when they desire. Hopefully other folks will like this idea and we could add the preservesPitch attribute to the MediaElement so we could drop the webkit prefix on this! I've noted this in the spec notes for future versions. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] oninput for contentEditable
On Tue, 23 Jun 2009, Ojan Vafai wrote: Currently, textareas and text inputs support the oninput event that fires on all user-initiated modifications to their content. We should add this event to contentEditable elements as well and add an action property the specifies what action the user took that caused the input event. I haven't yet added this. I think we should probably address the various problems with contenteditable all at once, to make sure the solution is coherent overall. I'm watching what happens with the mutation event changes and tracking proposals for various other changes to contentEditable. It may be that we need to defer these changes to after HTML5 reaches last call, though, and have them in a future version next year some time. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] UTF-16 encoding default
On Wed, 24 Jun 2009, Kartikaya Gupta wrote: There's a page (http://www.microsoft.com/windowsmobile/mobile/en-us/totalaccess/software/software/eula-sw-netflix.mspx specifically) that has a Content-Type header of text/html; charset=utf-16 and has no BOM. The references I've seen (RFC2781, as well as http://unicode.org/faq/utf_bom.html#gen7) say that this means the content should be assumed to be UTF-16BE. The page, however, is actually in UTF-16LE. All browsers seem to do some sort of unspecified magic and figure out that the page is in LE. I was wondering if that magic could be described and added to the HTML5 spec so that it covers rendering the above page as expected. According to the draft spec as it stands, I believe that page should be rendered as garbage. IE and Safari assume UTF-16LE if the content is labeled as UTF-16. Firefox checks to see if the first two bytes are null/not-null or not-null/null and acts accordingly; if they're both not null it uses BE and if they're both null it does something I don't recognise (and checks both the UTF-8 and UTF-16 character encodings in the menu...). Opera appears to assume UTF-16BE unless the second, fourth, sixth, eighth, and tenth bytes are null and the first, third, fifth, seventh, and ninth bytes are not, in which case it assumes BE. I've added a requirement in the spec that UTF-16 with no BOM be treated as LE rather than BE. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Spec annotation broken by class=impl
On Wed, 24 Jun 2009, Simon Pieters wrote:
I tried to annotate the Parsing HTML documents section but ended up
adding a box to the earlier 9.1.6 Comments section. It seems the
script gets confused by the div class=impl.
It seems the relevant function is
document.addEventListener('click', function(event) {
in status.js
Fixed.
--
Ian Hickson U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] AppCache can't serve different contents for different users at the same URL
I guess in the double-AppCache model, where there's a generic cached redirect page, one could make it so all user-specific accesses use a URL with a user-specific prefix, so it can prefix-match against an entry in the NETWORK section of the generic cached app manifest. still, given how many apps on the web identify the user using an ID in a cookie, it'd be nice if apps wanting to use AppCache didn't have to go through these gyrations. a On Tue, Jul 14, 2009 at 3:30 PM, Aaron Whyte awh...@google.com wrote: Most apps provide different contents for the same uncacheable main-page URL, depending on the identity of the user, which is typically stored in a cookie and read by the server. However, the HTML5 AppCache spec doesn't allow cookies to influence the choice of AppCaches or the contents of a response returned by the cache. This makes it a lot harder, but not impossible, for developers of existing apps to start using AppCache, while still supporting multiple users per browser or browser profile. Without changing the user-visible URL structure of an app, developers might support multiple users, by replacing their server-generated user-specific main page, with a generic cacheable JS app that does this: 1) Establish the user's identity using a cookie, or a database record, or a session key-value store. 2) If the user can be identified, load the user-specific resources (JS, CSS, data, etc.) from the network and/or local storage, possibly including a separate AppCache with user-specific or fingerprint-specific URLs. Otherwise, load the unknown-user version or a login page. That'd be a complete restructuring of the main page, but it's possible. I suspect that this is the model the AppCache was designed to support. A more radical change to existing apps, and app design in general, would be to include account-identifying information in the user-visible URL. The main page could redirect users to their user-specific page or the unknown-user page.
