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
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
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
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
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:
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
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
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,
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;
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
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.
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
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
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
!--
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
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
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
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
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,
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
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
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
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.
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
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.
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
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
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?
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
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
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
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
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
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
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
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
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
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,
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
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
40 matches
Mail list logo
