Re: [whatwg] setting location.hash property and browser reload
Ian Hickson wrote: HTML5 requires that there not be a reload. Setting location.hash eventually (if you follow the admittedly convoluted definitions) is equivalent to running the navigation algorithm: http://www.whatwg.org/specs/web-apps/current-work/#navigate ...which, in step 4, just scrolls and aborts the algorithm without actually changing the active Document object. Hmm. That algorithm doesn't look quite right in the case when going from http://example.com/#foo to http://example.com/. That case should actually do the load instead of scrolling, last I checked, unless done as part of a history traversal. See also https://bugzilla.mozilla.org/show_bug.cgi?id=273158. Same thing for the case when going from http://example.com/ to http://example.com/ (as comment 5 in the above bug points out). If I read the current draft right, per step 4 that would be a no-op, whereas in practice I don't believe it is in browsers... -Boris
[whatwg] Selectable category tree, nested optgroups?
Hi, Imagine you have a (for example) category tree like this: * Cars * Sporty * Limo * 18 wheeler * Bloody good * Big * Places to live in * Villa * Flat * Under bridge ... and you are to select one for your article of some sort. optgroup isn't capable of doing this at the moment as it cannot be nested and you cannot select Cars category (it's its label attribute). Currently this is done by intending with spaces and, in my humble opinion, it doesn't look too accessible - I wouldn't want to crawl through it with my screenreader if it was a longer list. I'm here to ask if there is/could be a better way than intending. Thanks, Ollie.
[whatwg] Serializing HTML fragments (9.4)
According to this section 9.4, any descendant text node of a style element should be outputted literally, rather than being escaped. However, this doesn't seem to match what Opera/Chrome/FF do. Test case: html body style id=test /style script type=text/javascript var test = document.getElementById(test); var c1 = document.createElement( 'c1' ); c1.appendChild( document.createTextNode( 'somestuff' ) ); test.appendChild( c1 ); test.appendChild( document.createTextNode( 'morestuff' ) ); var html = test.innerHTML; alert(html); /script /body /html Opera and Chrome will alert c1somegt;stuff/c1morestuff (escaping the angle bracket inside the child element) and Firefox just outputs morestuff (presumably a bug). I tried a couple of the other special elements (script and xmp) and they worked the same way. I think for compatibility the spec should say If the parent of the current node is a instead of If one of the ancestors of current node is a for the Text/CDATASection handling. Cheers, kats
Re: [whatwg] Codecs for audio and video
On Wed, 08 Jul 2009 18:24:42 +0200, Charles Pritchard ch...@jumis.com wrote: On 7/8/09 2:20 AM, Philip Jagenstedt wrote: On Tue, 07 Jul 2009 22:45:41 +0200, Charles Pritchard ch...@jumis.com wrote: At some point, a Blob / Stream API could make things like this easier. If the idea is to write a Vorbis decoder in JavaScript that would be quite cool in a way, but for vendors already implementing Vorbis it wouldn't really add anything. A pure JS-implementation of any modern audio codec would probably be a ridiculous amount of code and slow, so I doubt it would be that useful in practice. Well I'd like to disagree, and reiterate my prior arguments. Vorbis decoders have been written in ActionScript and in Java. They are not ridiculous, in size, nor in CPU usage. They can play audio streams, smoothly, and the file size is completely tolerable. And the idea is codec neutrality, a Vorbis decoder is just one example. OK, I won't make any assumptions of the size/speed of such an implementation until I see one. Well, again, there exist implementations running on Sun/Oracle's Java VM and the Flash VM. These two use byte-code packaging, so the file size is under 100k, deflated ECMAScript source would also weigh under 100k. Transcoding lossy data is a sub-optimal solution. Allowing for arbitrary audio codecs is a worthwhile endeavor. ECMAScript can detect if playback is too slow. I want to point this out again. While there is some struggle to define a standard codec (so we might be spared the burden of so very many encoders), there is a very large supply of already-encoded media in the wild. I've recently worked on a project that required a difficult to obtain/install codec. Open source descriptions were available, and if it was an option, I certainly would have paid to have the codec written in ECMAScript, and delivered it with the media files. In that particular case, paying someone to write a decoder for one particular, minority codec, would have been cheaper, and more correct, than paying for the transcoding of 60 gigs of low bit-rate audio. Most media formats are lossy, making their current format, whatever the encumbrance, the best solution. Yes, re-encoding always lowers the quality, so this use case is something I would agree with. Additionally, in some cases, the programmer could work-around broken codec implementations. It's forward-looking, it allows real backward compatibility and interoperability across browsers. canvas allows for arbitrary, programmable video, audio should allow for programmable audio. Then, we can be codec neutral in our media elements. While stressing that I don't think this should go into the spec until there's a proof-of-concept implementation that does useful stuff, is the idea to set audio.src=new MySynthesizer() and play()? (MySynthesizer would need to implement some standard interface.) You also have the question of push vs pull, i.e. does the audio source request data from the synthesizer when needed or does the synthesizer need to run a loop pushing audio data? Well we really need to define what useful stuff is, you know, to set that bar. It really doesn't matter if you and agree on what it useful. If one browser implements an audio synthesis interface and it's good enough, others will follow and the spec work will begin. There are two use cases that I think are important: a codec implementation (let's use Vorbis), and an accessibility implementation, working with a canvas element. I don't know what would qualify for accessibility. A topographical map, which makes a lower or higher pitched hum, based on elevation (surrounding the pointer), is an example. On that same line of thinking, a hum of varying intensity signaling proximity to a clickable element, (we're still talking about canvas) might be useful. If there is no sound in the right-channel, there are no elements to be clicked on, to the right of the pointer. If it is a low-sound, then the element is rather far away. Site developers still need to put in the work. With a buffered audio API, they'll at least have the option to do so. Can we come to an agreement as to what would constitute a reasonable proof of concept? This is meant to allow canvas to be more accessible to the visually impaired. Obviously, audio src tags could be used in many cases with canvas, so our test-case should be one where audio src would be insufficient. Both of these use cases can be accomplished with a raw audio buffer. They do not need native channel mixing, nor toDataURL support. In the long term, I think those two options would be nice, but in the short term, would just cause delays in adoption. As Robert has said, there are much more important things to work on ( https://bugzilla.mozilla.org/show_bug.cgi?id=490705 ). I think at this point, the model should play buffered bytes as they are made available
[whatwg] DOMTokenList: mutation clarification
Hi, 1) in http://www.whatwg.org/specs/web-apps/current-work/#common-dom-interfaces When the attribute is absent, then the string represented by the object is the empty string; when the object mutates this empty string, the user agent must first add the corresponding content attribute, and then mutate that attribute instead Does it mean it should fire two DOMAttrModified events, one with the empty string addition, and the other with the attribute mutation? I think it should simply fire only one mutation event in that case as in all other cases (should be simpler and more efficient, although that case shouldn't happen very often). I don't see a good reason to fire one with the empty string. 2) (using the class attribute for the discussion) What should happen when you do a remove(foo) on an element which has no class attribute? My understanding is that it shouldn't add a class attribute with an empty string. That's because the remove() algorithm starts with an empty string and doesn't change it, so the when the object mutates this empty string, case shouldn't be true (and thus no attribute modification should happen). However Simon's testcase [1] doesn't agree with this, and adds an empty string. So maybe it's worth clarifying this situation? Sylvain [1] http://simon.html5.org/test/html/dom/reflecting/DOMTokenList/getting/009.htm
Re: [whatwg] Serializing HTML fragments (9.4)
Kartikaya Gupta wrote: Opera and Chrome will alert c1somegt;stuff/c1morestuff (escaping the angle bracket inside the child element) and Firefox just outputs morestuff (presumably a bug). It's actually rather purposeful, at least in terms of the code. It'd be pretty easy to change to returning the textContent instead (so walking into kids). See https://bugzilla.mozilla.org/show_bug.cgi?id=125746 for the history here (the code has just been carried along since). I tried a couple of the other special elements (script and xmp) and they worked the same way. I think for compatibility the spec should say If the parent of the current node is a instead of If one of the ancestors of current node is a for the Text/CDATASection handling. No opinion on this, honestly. -Boris
[whatwg] Canvas context.drawImage clarification
Hello, I'm new to the list so I hope this is the right place and format. I've been having a look at the canvas API specification and I noticed at least one ambiguity. (I'm guessing those that have been on the list for a while are laughing) The specific ambiguity I'd like to bring up has to do with the several versions of a function, context.drawImage. They take width and height values. The spec does not make it clear what is supposed to happen with negative values. My personal interpretation and preference is that negative values should (a) be legal and (b) draw backward, flipping the image. The specification currently says: The source rectangle is the rectangle whose corners are the four points (sx, sy), (sx+sw, sy), (sx+sw, sy+sh), (sx, sy+sh). ... The destination rectangle is the rectangle whose corners are the four points (dx, dy), (dx+dw, dy), (dx+dw, dy+dh), (dx, dy+dh). Well, simple math would suggest that if sx = 10, and sw = -5 then it still defines a valid rectangle. Unfortunately since the spec is ambiguous the current browsers that implement this all do it differently. Firefox and Opera draw nothing with a negative width or height. Safari and Chrome draw to the rectangle defined by negative widths and heights but do not flip the image. I'd like to make a passionate plea that the spec say implementations must support negative widths and negative heights and draw the image backward effectively flipping the result. Coming from a graphics and game development background we use the ability to flip images all the time. I know that I can achieve similar results by using a transform matrix but still it would be much easier to just make negative widths and heights specifically part of the spec. Also, I'd like to suggest that a widths and heights of 0 for source should be valid as well as rectangles outside of the source also be valid and that this part of the spec. If the source rectangle is not entirely within the source image, or if one of the sw or sh arguments is zero, the implementation must raise an INDEX_SIZE_ERR exception. be changed to reflect that. Coming from a graphics background I see no reason why if I let my user size an image in a canvas I should have to special case a width or height of zero. Just draw nothing if the width or height is zero. Similarly, if I was to provide a UI to let a user choose part of the source to copy to the dest and I let them define a rectangle on the source and drag it such that all or part of it is off the source I see no reason why I should have to do extra math in my application to make that work when simple clipping of values in drawImage would make all that extra work required by each app disappear. The next issue related to drawImage is that the spec does not specify how to filter an image when scaling it. Should it use bi-linear interpolation? Nearest Neighbor? Maybe that should stay implementation dependent? On top of that the spec does not say what happens at the edges and the different browsers are doing different things. To give you an example, if you take a 2x2 pixel image and scale it to 256x256 using drawImage. All the major browsers that currently support the canvas tag will give you an image where the center of each pixel is around center of each 128x128 corner of the 256x256 result. The area inside the area defined by those 4 points is rendered very similar on all 4 browsers. The area outside though, the edge, is rendered very differently. On Safari, Chrome and Opera the colors of the original pixels continue to be blended all the way to the edge of the 256x256 area. On Firefox though, the blending happens as though the source image was actually 4x4 pixels instead of 2x2 where the edge pixels are all set to an RGBA value of 0, 0, 0, 0. It then draws that scaled image as as though the source rectangle was sx = 1, sy = 1, sw = 2, sh = 2 so that you get a progressively more and more translucent color towards the edge of the rectangle. I don't know which is right but with low resolution source images the 2 give vastly different results. Could these ambiguities be clarified in the spec?
Re: [whatwg] the cite element
On Jun 5, 2009, at 3:53 AM, Ian Hickson wrote:
I don't really understand what problem this is solving.
HTML4 actually defined cite more like what you describe above; we
changed it to be a title of work element rather than a citation
element because that's actually how people were using it.
I don't think it makes sense to use the cite element to refer to
people,
because typographically people aren't generally marked up anyway. I
don't
really see how you'd use it to refer to untitled works.
Thus, I don't really think it makes sense to make the change you
propose.
There are plenty of times when you want to mark up someone's name. For
instance, if you're quoting someone in a testimonial, you may want the
quote to appear in normal roman text, but the person's name who you
are quoting to be in italic and right aligned:
Best value for the money!
-- J. Random User
I might format this as:
aside class=testimonial
qBest value for the money!/q
citeJ. Random User/cite
/aside
aside.testimonial cite:before { content: — }
aside.testimonial cite { display: block; font-style: italic; text-
align: right }
Here's an example of someone asking about this specific use case, of
how to mark up a testimonial and its source:
http://stackoverflow.com/questions/758785/what-is-the-best-way-to-markup-a-testimonial-in-xhtml
(note that I don't believe the uses of blockquote mentioned here,
including by me, are correct, as the citation actually refers to the
quote rather than being part of it, but I think the use of cite is
perfectly reasonable)
The Mozilla Style Guide also uses formatting for cite that I believe
would be appropriate for citing either a work or a person:
http://www.mozilla.org/contribute/writing/markup#quotations
Of course, it's generally preferable to cite a work, rather than a
person, as then the citation can be verified; if you just include a
person's name, you have to assume that they mean personal
correspondence which is unverifiable, or simply that the work is left
unspecified and someone else will have to track it down. But people do
write quotes and attribute the quotation to the person rather than the
work, and as HTML is about marking up content and not about enforcing
academic standards, I don't see why HTML5 should be adding this
unenforceable restriction that doesn't seem to add much value.
I wonder if there is value in specifying the semantics of elements
like cite in much detail, in cases where there is no way to
automatically verify those semantics and there is no use case for
machine processing of those semantics. It seems that whatever the
definition of cite is, you're going to need to use a microformat or
microdata or RDFa to actually provide semantics that are machine-
readable, so the spec should be relatively loose and leave the precise
semantics up to one of the more flexible systems for specifying
semantics.
-- Brian Campbell
Re: [whatwg] the cite element
On Thu, Jul 9, 2009 at 2:51 PM, Brian
Campbellbrian.p.campb...@dartmouth.edu wrote:
On Jun 5, 2009, at 3:53 AM, Ian Hickson wrote:
I don't really understand what problem this is solving.
HTML4 actually defined cite more like what you describe above; we
changed it to be a title of work element rather than a citation
element because that's actually how people were using it.
I don't think it makes sense to use the cite element to refer to people,
because typographically people aren't generally marked up anyway. I don't
really see how you'd use it to refer to untitled works.
Thus, I don't really think it makes sense to make the change you propose.
There are plenty of times when you want to mark up someone's name. For
instance, if you're quoting someone in a testimonial, you may want the quote
to appear in normal roman text, but the person's name who you are quoting to
be in italic and right aligned:
Best value for the money!
-- J. Random User
I might format this as:
aside class=testimonial
qBest value for the money!/q
citeJ. Random User/cite
/aside
aside.testimonial cite:before { content: — }
aside.testimonial cite { display: block; font-style: italic; text-align:
right }
Here's an example of someone asking about this specific use case, of how to
mark up a testimonial and its source:
http://stackoverflow.com/questions/758785/what-is-the-best-way-to-markup-a-testimonial-in-xhtml
(note that I don't believe the uses of blockquote mentioned here,
including by me, are correct, as the citation actually refers to the quote
rather than being part of it, but I think the use of cite is perfectly
reasonable)
The Mozilla Style Guide also uses formatting for cite that I believe would
be appropriate for citing either a work or a person:
http://www.mozilla.org/contribute/writing/markup#quotations
Of course, it's generally preferable to cite a work, rather than a person,
as then the citation can be verified; if you just include a person's name,
you have to assume that they mean personal correspondence which is
unverifiable, or simply that the work is left unspecified and someone else
will have to track it down. But people do write quotes and attribute the
quotation to the person rather than the work, and as HTML is about marking
up content and not about enforcing academic standards, I don't see why HTML5
should be adding this unenforceable restriction that doesn't seem to add
much value.
I wonder if there is value in specifying the semantics of elements like
cite in much detail, in cases where there is no way to automatically
verify those semantics and there is no use case for machine processing of
those semantics. It seems that whatever the definition of cite is, you're
going to need to use a microformat or microdata or RDFa to actually provide
semantics that are machine-readable, so the spec should be relatively loose
and leave the precise semantics up to one of the more flexible systems for
specifying semantics.
-- Brian Campbell
FWIW, in the corporate sites I control I mark up testimonial
quotations using blockquote and cite, like this:
blockquote
testimonial testimonial testimonial
citeJoe Sixpack/cite
/blockquote
This gives a good default display in the absence of CSS, and I modify
it a bit further for myself (making cite display:block and adding a
::before glyph to it).
This seemed like the most reasonable solution at the time. I settled
on this before the cite discussion on this list.
~TJ
Re: [whatwg] A Selector-based metadata proposal (was: Annotating structured data that HTML has no semantics for)
On Thu, Jul 9, 2009 at 12:06 AM, Ian Hicksoni...@hixie.ch wrote:
On Wed, 10 Jun 2009, Eduard Pascual wrote:
I think this is a level of indirection too far -- when something is a
heading, it should _be_ a heading, it shouldn't be labeled opaquely
with a transformation sheet elsewhere defining that is maps to the
heading semantic.
That doesn't make much sense. When something is a heading, it *is* a
heading. What do you mean by should be a heading?.
I mean that a conforming implementation should intrinsically know that the
content is a heading, without having to do further processing to discover
this.
For example, with this CSS and HTML:
h1 { color: blue; }
h1 Introduction /h1
...the HTML processor knows, regardless of what else is going on, that the
word Introduction is part of a heading. It only knows that the word
should be blue after applying processing rules for CSS.
Now I think I got your point. However, I don't think it is really an
issue. Let's take a variant of your example:
CSS:
h1 { font-size: large; }
CRDF:
h1 { foo|MainHeading: contents; }
HTML:
h1 Introduction /h1
If we took the HTML alone (for example, if the CSS and CRDF are in
external files and fail to download), the browser will find an H1
element and it will know that it is a first-level heading. It will
also render it large by default (maybe depending of context; a voice
browser won't render anything as large). Now, if the CSS and CRDF
get processed, the browser will *also* know that it has to render it
large (now it's not just falling back to some default, it knows that
the author wanted the heading to render as large), and that it is
whatever the foo (or the namespace mapped by the foo prefix, to be
more specific) namespace defines as a MainHeading, which will
probably be something quite similar to the browser's own concept of
first-level heading.
The point here is: the CSS is stating that the h1 should display
large; despite the browser would display it large in most cases.
Similarly, the CRDF is defining the h1 as a MainHeading, despite the
browser already knows it is a heading. Both the CSS and the CRDF
provide redundant information. Of course, someone could attempt to
describe semantics through CRDF that conflict with HTML's, but that
one could also make headings smaller, hide strongs and enlarge
smalls with CSS.
No matter what CRDF says, a compliant HTML browser will always know
that h1 is a heading (and similarly, will know what other HTML
elements mean). But if what CRDF says is consisten with what the HTML
says (the main point of metadata is stating things that are true,
false data is almost useless), then RDF tools that are completelly
unaware of HTML itself can still know that something is a heading. The
same way, when CSS is consistent with HTML's semantics (for example
making headings large, strongs bold, or ems italized), a user
viewing the page can perceive that something is a heading, important,
or emphasized, respectivelly.
I think by and large the same should hold for more elaborate semantics.
(I didn't really agree with your other responses regarding my criticisms
of your proposal either, but I don't have anything except my opinions to
go on as far as those go, so I can't argue my case usefully there.)
Most of such responses were based on what is brewing for the next
version of the document, rather than the version actually available,
so I don't think it's worth going further on those points until the
update is ready and up.
I think CRDF has a bright future in doing the kind of thing GRDDL does,
I'm not sure about what GRDDL does: I just took a look through the spec,
and it seems to me that it's just an overcomplication of what XSLT can
already do; so I'm not sure if I should take that statement as a good or
a bad thing.
A good thing.
GRDDL is a way to take an HTML page and infer RDF information from that
page despite the page, e.g. by implementing Microformats using XSLT. So
for example, GRDDL can be used to extract hCard data from an HTML page and
turn it into RDF data.
Ok. Making metadata available from documents that were not authored
with metadata in mind, and without altering the document itself (at
much adding a link to the header) is one of the use-cases CRDF aims
to handle; so it's good news to hear from someone that it's on the
right way to achieve it ^^-
It's an interesting way of converting, say, Microformats to RDF.
The ability to convert Microformats to RDF was intended (although not
fully achieved: some bad content would be treated differently between
CRDF and Microformats); and in the same way CRDF also provides the
ability to define de-centralized Microformats.org-like vocabularies (I'm
not sure if referring to these as microformats would still be
appropiate).
I think this is a particularly useful feature; I would encourage you to
continue to develop this idea as a separate language, and see if there is
a market for it.
The
[whatwg] Serving up Theora video in the real world
(this is not quite about the standard itself, but it is about how to use shiny new bits of it in real world practice) Wikimedia is preparing to use video (and quite likely HTML5 all through) for serving up Ogg Theora video in MediaWiki. Desktop is easy: * In the one released browser that supports video and Theora, Firefox 3.5, this will Just Work. * In Safari with XiphQT, we can *probably* detect Theora's MIME type as being supported and it will Just Work (more or less). * Everyone else gets the Cortado player (written in Java), with a link suggesting FF 3.5 for a better video experience. The question is what to do for platforms such as the iPhone, which doesn't even run Java. Is there any way to install an additional codec in the iPhone browser? Is it (even theoretically) possible to put a free app on the AppStore just to play Ogg Theora video for our users? (There are many AppStore apps that support Ogg Vorbis, don't know if any support Theora - so presumably AppStore stuff doesn't give Apple the feared submarine patent exposure.) Our goal is to have happy end users who don't have to think about this rubbish. - d.
Re: [whatwg] Serving up Theora video in the real world
David Gerard wrote: * In the one released browser that supports video and Theora, Firefox 3.5, this will Just Work. Two! Firefox and Chrome. --Ben signature.asc Description: OpenPGP digital signature
Re: [whatwg] Serving up Theora video in the real world
On Thu, Jul 9, 2009 at 10:04 PM, David Gerarddger...@gmail.com wrote: Really? I thought that was next Chrome, not this Chrome. It works in the developer version: http://dev.chromium.org/getting-involved/dev-channel Also in experimental Opera builds: http://labs.opera.com/news/2008/11/25/ But not in any stable browser release I'm aware of aside from Firefox 3.5, or Safari plus XiphQT.
Re: [whatwg] Serving up Theora video in the real world
David Gerard wrote: 2009/7/9 Benjamin M. Schwartz bmsch...@fas.harvard.edu: David Gerard wrote: * In the one released browser that supports video and Theora, Firefox 3.5, this will Just Work. Two! Firefox and Chrome. Really? I thought that was next Chrome, not this Chrome. It seems you're rightish. Google, as usual, is having lots of fun with their stable/beta/release distinctions. See if you can decipher http://googlechromereleases.blogspot.com/ . At any rate, video is not supported in Chrome Stable, which is currently 2.0.x. signature.asc Description: OpenPGP digital signature
Re: [whatwg] Serving up Theora video in the real world
2009/7/9 David Gerard dger...@gmail.com: * Everyone else gets the Cortado player (written in Java), with a link suggesting FF 3.5 for a better video experience. I should note, by the way, that this isn't a great option - second and subsequent videos in Cortado are just fine, but the thirty seconds waiting for Java to start up the first time you play a video *really sucks*. - d.
Re: [whatwg] Serving up Theora video in the real world
2009/7/9 Benjamin M. Schwartz bmsch...@fas.harvard.edu: It seems you're rightish. Google, as usual, is having lots of fun with their stable/beta/release distinctions. See if you can decipher http://googlechromereleases.blogspot.com/ . At any rate, video is not supported in Chrome Stable, which is currently 2.0.x. Yep. For these purposes we're only considering release stuff. Anyone got ideas on the iPhone problem? - d.
Re: [whatwg] Serving up Theora video in the real world
2009/7/9 Benjamin M. Schwartz bmsch...@fas.harvard.edu: David Gerard wrote: * In the one released browser that supports video and Theora, Firefox 3.5, this will Just Work. Two! Firefox and Chrome. Really? I thought that was next Chrome, not this Chrome. What's ETA on the next Chrome? - d.
Re: [whatwg] Serving up Theora video in the real world
On Thu, Jul 9, 2009 at 5:59 PM, David Gerarddger...@gmail.com wrote: * In Safari with XiphQT, we can *probably* detect Theora's MIME type as being supported and it will Just Work (more or less). I'm now being told that our workaround of checking for system mime types stopped working and isn't working for users with Safari 4.0.2 and fresh XiphQT installs. We've been doing querying navigator.plugins to look for 'video/ogg' since canPlayType fails for Ogg/Theora even when XiphQT is installed for current Safari (I understand that this is fixed in development builds). I'm trying to figure out where the plugin mime detection workaround stopped and why. On Thu, Jul 9, 2009 at 6:00 PM, Benjamin M. Schwartzbmsch...@fas.harvard.edu wrote: David Gerard wrote: * In the one released browser that supports video and Theora, Firefox 3.5, this will Just Work. Two! Firefox and Chrome. AFAIK Chrome support is only in the developer builds, not the full released stuff yet.
Re: [whatwg] Serving up Theora video in the real world
2009/7/9 David Gerard dger...@gmail.com 2009/7/9 Benjamin M. Schwartz bmsch...@fas.harvard.edu: It seems you're rightish. Google, as usual, is having lots of fun with their stable/beta/release distinctions. See if you can decipher http://googlechromereleases.blogspot.com/ . At any rate, video is not supported in Chrome Stable, which is currently 2.0.x. Yep. For these purposes we're only considering release stuff. As Peter said, please don't just block Chrome flat out -- if you must, just block Chrome under version 3. Note that when we push 3 to stable, everyone will be automatically updated. As for how to decipher the releases blog, at the beginning of each post we state which channels this affects (Dev/Beta/Stable). Dev is, as it sounds, the latest and most frequently released to, stable is less frequently updated. Eventually, when we're happy, we take a dev release and call it beta and then stable. Anyone got ideas on the iPhone problem? - d.
Re: [whatwg] Serving up Theora video in the real world
On Thu, Jul 9, 2009 at 3:34 PM, David Gerarddger...@gmail.com wrote: Anyone got ideas on the iPhone problem? I think this is off topic, and I am not an iPhone developer, but: Assuming the app store terms allow video players, it should be possible to distribute some sort of dedicated player application, free or otherwise. I believe the fee for a cert to sign applications is currently $100/year. However, the iPhone doesn't have a shared filesystem, or helper-applications in the normal sense, At least not as far as I can tell. The work-around I'm aware of is for site authors to check if you're running on the iPhone in javascript, and rewrite the video elements to normal anchors with a custom schema, e.g. a href=oggplayer://example.com/file.ogvClick here to watch in Ogg Player/a. Then, if the user has installed the Ogg Player app, which registers itself has handling the 'oggplayer' schama, Safari will pass the custom uri to it, and it can download/stream/whathaveyou. -r
Re: [whatwg] Serving up Theora video in the real world
2009/7/9 Ian Fette (イアンフェッティ) ife...@google.com: As Peter said, please don't just block Chrome flat out -- if you must, just block Chrome under version 3. Note that when we push 3 to stable, everyone will be automatically updated. As version 3 is easily detectable, presumably we'd just detect it. The Java interface takes 30 seconds to start, the first 10 of which your browser or computer appears to have hung. It's really horrible. Which is a pity, as Cortado is otherwise really cool. So avoiding having to drop back to that is really really good, and so giving the native Theora in video experience to Chrome 3 users is just the thing :-) So let's hope Safari with XiphQT remains detectable ... - d.
[whatwg] Canvas context.drawImage clarification
Hello, I'm new to the list so I hope this is the right place and format. I've been having a look at the canvas tag API specification and I noticed at least one ambiguity. (I'm guessing those that have been on the list for a while are laughing) The specific ambiguity I'd like to bring up has to do with the several versions of a function, context.drawImage. They take width and height values. The spec does not make it clear what is supposed to happen with negative values. My personal interpretation and preference is that negative values should (a) be legal and (b) draw backward, flipping the image. The specification currently says: The source rectangle is the rectangle whose corners are the four points (sx, sy), (sx+sw, sy), (sx+sw, sy+sh), (sx, sy+sh). ... The destination rectangle is the rectangle whose corners are the four points (dx, dy), (dx+dw, dy), (dx+dw, dy+dh), (dx, dy+dh). Well, simple math would suggest that if sx = 10, and sw = -5 then it still defines a valid rectangle. Unfortunately since the spec is ambiguous the current browsers that implement this all do it differently. Firefox and Opera draw nothing with a negative width or height. Safari and Chrome draw to the rectangle defined by negative widths and heights but do not flip the image. I'd like to make a passionate plea that the spec say implementations must support negative widths and negative heights and draw the image backward effectively flipping the result. Coming from a graphics and game development background we use the ability to flip images all the time. I know that I can achieve similar results by using a transform matrix but still it would be much easier to just make negative widths and heights specifically part of the spec. Also, I'd like to suggest that a widths and heights of 0 for source should be valid as well as rectangles outside of the source also be valid and that this part of the spec. If the source rectangle is not entirely within the source image, or if one of the sw or sh arguments is zero, the implementation must raise an INDEX_SIZE_ERR exception. be changed to reflect that. Coming from a graphics background I see no reason why if I let my user size an image in a canvas I should have to special case a width or height of zero. Just draw nothing if the width or height is zero. Similarly, if I was to provide a UI to let a user choose part of the source to copy to the dest and I let them define a rectangle on the source and drag it such that all or part of it is off the source I see no reason why I should have to do extra math in my application to make that work when simple clipping of values in drawImage would make all that extra work required by each app disappear. Another way to look at that is in OpenGL, if my texture coordinates are set less than 0 or greater than 1 the GPU does not fail. Why should drawImage act any differently? The next issue related to drawImage is that the spec does not specify how to filter an image when scaling it. Should it use bi-linear interpolation? Nearest Neighbor? Maybe that should stay implementation dependent? On top of that the spec does not say what happens at the edges and the different browsers are doing different things. To give you an example, if you take a 2x2 pixel image and scale it to 256x256 using drawImage. All the major browsers that currently support the canvas tag will give you an image where the center of each pixel is around center of each 128x128 corner of the 256x256 result. The area inside the area defined by those 4 points is rendered very similar on all 4 browsers. The area outside though, the edge, is rendered very differently. On Safari, Chrome and Opera the colors of the original pixels continue to be blended all the way to the edge of the 256x256 area. On Firefox though, the blending happens as though the source image was actually 4x4 pixels instead of 2x2 where the edge pixels are all set to an RGBA value of 0, 0, 0, 0. It then draws that scaled image as as though the source rectangle was sx = 1, sy = 1, sw = 2, sh = 2 so that you get a progressively more and more translucent color towards the edge of the rectangle. I don't know which is right but with low resolution source images the 2 give vastly different results. Could these ambiguities be clarified in the spec?
Re: [whatwg] Serving up Theora video in the real world
On Jul 9, 2009, at 3:34 PM, Peter Kasting wrote: On Thu, Jul 9, 2009 at 3:30 PM, Aryeh Gregor Simetrical +...@gmail.com wrote: On Thu, Jul 9, 2009 at 10:04 PM, David Gerarddger...@gmail.com wrote: Really? I thought that was next Chrome, not this Chrome. It works in the developer version: http://dev.chromium.org/getting-involved/dev-channel For any site author needing a UA sniffing route to determine whether a visitor's Chrome version supports video, just look for version 3.x or higher. I'd recommend using feature testing or fallback instead though, if you can make that work for your site. - Maciej
Re: [whatwg] Canvas context.drawImage clarification
I'd like to make a passionate plea that the spec say implementations must support negative widths and negative heights and draw the image backward effectively flipping the result. We'd need to be fairly sure that such a change would not break existing content -- this is a change that would result in substantially different rendering in some scenarios. Also, I'd like to suggest that a widths and heights of 0 for source should be valid as well as rectangles outside of the source also be valid and that this part of the spec. If the source rectangle is not entirely within the source image, or if one of the sw or sh arguments is zero, the implementation must raise an INDEX_SIZE_ERR exception. be changed to reflect that. The issues of when exceptions should be thrown in the canvas API have been discussed repeatedly on this list, you should search the archives and see if there are any arguments you can make that have not already been made. (I note that i am also all for exceptions not being thrown in many of these cases) The next issue related to drawImage is that the spec does not specify how to filter an image when scaling it. Should it use bi-linear interpolation? Nearest Neighbor? Maybe that should stay implementation dependent? Image scaling is implementation dependent everywhere else, why would it be spec defined in the case of canvas? --Oliver
Re: [whatwg] Serving up Theora video in the real world
On Jul 9, 2009, at 3:11 PM, Gregory Maxwell wrote: On Thu, Jul 9, 2009 at 5:59 PM, David Gerarddger...@gmail.com wrote: * In Safari with XiphQT, we can *probably* detect Theora's MIME type as being supported and it will Just Work (more or less). I'm now being told that our workaround of checking for system mime types stopped working and isn't working for users with Safari 4.0.2 and fresh XiphQT installs. We've been doing querying navigator.plugins to look for 'video/ogg' since canPlayType fails for Ogg/Theora even when XiphQT is installed for current Safari (I understand that this is fixed in development builds). I'm trying to figure out where the plugin mime detection workaround stopped and why. I don't think we did anything intentional in 4.0.2 to break detection of XiphQT. If you have a solid reproducible case, please file a bug. On the other hand, I suspect the canPlayType fix will have shipped by the time we manage to do any fixes for the navigator.plugins technique. Regards, Maciej
Re: [whatwg] Serving up Theora video in the real world
On Thu, Jul 9, 2009 at 7:14 PM, Maciej Stachowiakm...@apple.com wrote: I don't think we did anything intentional in 4.0.2 to break detection of XiphQT. If you have a solid reproducible case, please file a bug. On the other hand, I suspect the canPlayType fix will have shipped by the time we manage to do any fixes for the navigator.plugins technique. It may even be something about the XiphQT install that changed. Or, more significantly, something the XiphQT install can fix. If so we don't have the problem of where we can't tell Safari users to install XiphQT (because if they do they'll just continue to get the message). At the moment we're just going to have to tell Safari users to install Firefox 3.5 though.
Re: [whatwg] Serving up Theora video in the real world
On Thu, Jul 9, 2009 at 7:24 PM, Maciej Stachowiakm...@apple.com wrote: I thought your plan was to use Cortado for plugins that don't have video+Theora. Why would you single out Safari users for a worse experience? As david mentioned, Cortado is a worse experience. What we've been planning was that everyone without native support who appeared to be on a platform which could have native support were going to get a recommendation to upgrade/change software along with the Cortado. This would have resulted in Safari users being advised to install XiphQT, but since that doesn't appear to work anymore for the shipping software it will just get treated like Firefox 3.0 and other video-less browsers.
Re: [whatwg] Canvas context.drawImage clarification
On Jul 9, 2009, at 4:19 PM, Gregg Tavares wrote: On Thu, Jul 9, 2009 at 4:11 PM, Oliver Hunt oli...@apple.com wrote: I'd like to make a passionate plea that the spec say implementations must support negative widths and negative heights and draw the image backward effectively flipping the result. We'd need to be fairly sure that such a change would not break existing content -- this is a change that would result in substantially different rendering in some scenarios. Given that it's inconsistent in the various browsers it's hard to see how this would break something since it's broken in 2 browsers one way or the other currently. Inconsistency doesn't lead to no one depending on a behaviour, it just means sites only work in one browser. Your suggesting would result in sites being broken in all browsers -- the only options from here on out are either nothing gets drawn (as in gecko and presto), or the destination is normalised (as in webkit) Image scaling is implementation dependent everywhere else, why would it be spec defined in the case of canvas? There are 2 issues here I brought up 1) What happens at the edges. The results are VASTLY different now. Unless this works consistently it would be hard to make canvas graphics work across browsers and expect get reproducible results. The 2x2 pixel example I gave, one browser ends up scaling with translucency even though there is no translucent pixels in the source image. This is just an artifact of scaling, and you agree below that scaling is implementation dependent. 2) How it does the scaling. I agree that it being implementation dependent is probably fine. --Oliver
Re: [whatwg] page refresh and resubmitting POST state
On Thu, 11 Jun 2009, Jeremy Orlow wrote: On Sat, 23 May 2009, Mike Wilson wrote: I was thinking about the resubmit problem in a general context, specifically how browsers could make it possible for web authors to create POSTing pages that avoids giving the dreaded do you want to resubmit question at all, independent of operation. Just do a redirect like Jonas describes, instead of returning the page contents directly. You can even redirect to the same URL. This would cause additional network round-trips which is suboptimal. One alternative is to detect the case where JS is enable, and if it is, use pushState() and XHR to do the POST in the background and avoid the page load altogether. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] page refresh and resubmitting POST state
On Mon, 15 Jun 2009, Mike Wilson wrote: On Sat, 23 May 2009, Mike Wilson wrote: I was thinking about the resubmit problem in a general context, specifically how browsers could make it possible for web authors to create POSTing pages that avoids giving the dreaded do you want to resubmit question at all, independent of operation. Just do a redirect like Jonas describes, instead of returning the page contents directly. You can even redirect to the same URL. As I pointed out in a followup to Jonas's mail: http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-May/019937.html doing PRG with current technology has the drawback of losing the page state. This can be patched back again by adding query params to the URL but this isn't good for all scenarios (see below). I think generally speaking if the user experience is being tweaked to this level, then it's best to just do a JS-based Web app rather than relying on multiple page loads from the server. So instead of navigating the entire browsing context, just do an XHR POST, update the UI accordingly, and pushState() to get the new UI into the history. On Sun, 24 May 2009, Aryeh Gregor wrote: One workaround is to just stick the info in the query string of the GET. One problem with this is that it makes it easy to trick users into thinking they've just done something alarming: you can link to confirmmove.php?page1=Main_Pagepage2=Main_Page_ON_WHEELS, and the user will think they actually just moved the page (the software told them so!). Another problem is that sometimes there's way too much data to fit into a query string. For instance, in MediaWiki you can move a page with all its subpages. There might be hundreds or even thousands of these, and a success/failure message is printed for each, with the reason for failure if appropriate. This might be too long to fit in a GET. Just stick the data into the query parameters, including the user's ID, then sign the query parameters, and when serving the page, check the signature and check the user's ID matches the cookie. Adding data to the URL makes sense in some scenarios, but not in others. Often the application needs to hold on to state shared by a sequence of pages in the same browsing context, but at the same time not wanting this state to be shared with the same set of pages in another browsing context. This rules out cookie-based state as this is shared by all browsing contexts in the user agent. That's what the Web Storage sessionStorage API is for. A similar workaround would be to use cookies. This is nicer than the previous method, but has the potential to break confusingly if the user takes several similar actions at once (e.g., moving a number of pages at once in multiple tabs). Using sessionStorage can be used to work around this somewhat, at least in AJAX apps. For server-oriented webapps a solution that doesn't rely on script is preferred. This means the server should be able to transmit browsing_context-scoped state to the client and have it automatically sent back on any following request. Something like browsing_context-oriented cookies. If we want to support this, then that would be a new feature for Cookies, I guess. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Canvas context.drawImage clarification
On Thu, Jul 9, 2009 at 4:28 PM, Oliver Hunt oli...@apple.com wrote: On Jul 9, 2009, at 4:19 PM, Gregg Tavares wrote: On Thu, Jul 9, 2009 at 4:11 PM, Oliver Hunt oli...@apple.com wrote: I'd like to make a passionate plea that the spec say implementations must support negative widths and negative heights and draw the image backward effectively flipping the result. We'd need to be fairly sure that such a change would not break existing content -- this is a change that would result in substantially different rendering in some scenarios. Given that it's inconsistent in the various browsers it's hard to see how this would break something since it's broken in 2 browsers one way or the other currently. Inconsistency doesn't lead to no one depending on a behaviour, it just means sites only work in one browser. Your suggesting would result in sites being broken in all browsers -- the only options from here on out are either nothing gets drawn (as in gecko and presto), or the destination is normalised (as in webkit). Or making it consistent when the DOCTYPE is set to something. Image scaling is implementation dependent everywhere else, why would it be spec defined in the case of canvas? There are 2 issues here I brought up 1) What happens at the edges. The results are VASTLY different now. Unless this works consistently it would be hard to make canvas graphics work across browsers and expect get reproducible results. The 2x2 pixel example I gave, one browser ends up scaling with translucency even though there is no translucent pixels in the source image. This is just an artifact of scaling, and you agree below that scaling is implementation dependent. I disagree. When I scale a rectangular opaque image I expect rectangular opaque results. The Firefox implementation does not do this. If I take a 1x1 pixel image and attempt to use it to cover up something in another image by scaling it it will not cover up that other image. Only the very center pixel will be opaque, all other pixels will be some percentage translucent, showing whatever was previously drawn on the canvas. That's a much bigger issue than whether the scaled pixels are blocky or smooth. 2) How it does the scaling. I agree that it being implementation dependent is probably fine. --Oliver
Re: [whatwg] Serving up Theora video in the real world
2009/7/10 Ian Fette (イアンフェッティ) ife...@google.com
To me, this seems like a great test if canPlayType actually works in
practice. In the perfect world, it would be great to do
getElementById('video'), createElement, and
then canPlayType('video/whatever','theora').
If this simple use case doesn't work, I would ask if it's even worth
keeping canPlayType in the spec.
var v = document.getElementById(video);
if (v.canPlayType v.canPlayType(video/ogg; codecs=vorbis,theora)) {
...
} else {
...
}
should work great. Certainly does in Firefox.
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] Serving up Theora video in the real world
On Thu, Jul 9, 2009 at 10:35 PM, Robert O'Callahanrob...@ocallahan.org wrote:
2009/7/10 Ian Fette (イアンフェッティ) ife...@google.com
To me, this seems like a great test if canPlayType actually works in
practice. In the perfect world, it would be great to do
getElementById('video'), createElement, and
then canPlayType('video/whatever','theora').
If this simple use case doesn't work, I would ask if it's even worth
keeping canPlayType in the spec.
var v = document.getElementById(video);
if (v.canPlayType v.canPlayType(video/ogg; codecs=vorbis,theora)) {
...
} else {
...
}
should work great. Certainly does in Firefox.
It works. Except where it doesn't. It's the where it doesn't that
counts. At the moment Safari has issues. Out of two widely used
production browsers with HTML5 support, one is broken. Not good odds,
but I'm hopeful for the future.
There is also the potential problem of It technically supports format
X; but the browser developer never bothered testing X and its too
buggy to be usable.
My preference, however, is to start with the basic canPlayType test
and then only eliminate known problems and to make the problem
filtering as specific as possible with the assumption that future
versions will get it right.
Re: [whatwg] Serving up Theora video in the real world
On Fri, Jul 10, 2009 at 2:46 PM, Gregory Maxwell gmaxw...@gmail.com wrote:
On Thu, Jul 9, 2009 at 10:35 PM, Robert O'Callahanrob...@ocallahan.org
wrote:
var v = document.getElementById(video);
if (v.canPlayType v.canPlayType(video/ogg; codecs=vorbis,theora)) {
...
} else {
...
}
should work great. Certainly does in Firefox.
It works. Except where it doesn't. It's the where it doesn't that
counts. At the moment Safari has issues. Out of two widely used
production browsers with HTML5 support, one is broken. Not good odds,
but I'm hopeful for the future.
It's unfortunate that Safari is broken out of the gate, but realistically
hardly anyone is going to be using XiphQT right now. Hopefully Apple will
have fixed the bug before too long.
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] Serving up Theora video in the real world
On Jul 9, 2009, at 7:46 PM, Gregory Maxwell wrote:
On Thu, Jul 9, 2009 at 10:35 PM, Robert O'Callahanrob...@ocallahan.org
wrote:
2009/7/10 Ian Fette (イアンフェッティ) ife...@google.com
To me, this seems like a great test if canPlayType actually
works in
practice. In the perfect world, it would be great to do
getElementById('video'), createElement, and
then canPlayType('video/whatever','theora').
If this simple use case doesn't work, I would ask if it's even worth
keeping canPlayType in the spec.
var v = document.getElementById(video);
if (v.canPlayType v.canPlayType(video/ogg;
codecs=vorbis,theora)) {
...
} else {
...
}
should work great. Certainly does in Firefox.
It works. Except where it doesn't. It's the where it doesn't that
counts. At the moment Safari has issues. Out of two widely used
production browsers with HTML5 support, one is broken. Not good odds,
but I'm hopeful for the future.
Robert's code is a bit buggy; canPlayType returns a string, not a
boolean, so it will always appear to say yes. Corrected sample code
below. I tested, and the following is tragically broken in Safari
4.0.2 even with XiphQT installed, but works as expected in WebKit
nightlies and will very likely work in the next Safari dot release. In
Safari 4.0.2 it will always say no, even with XiphQT installed. If you
are patient, I would say just use this test and it will work as
desired Real Soon. Please note, the 4.0.2 bug is just a bug, and not a
design flaw in canPlayType.
script
var v = document.createElement(video);
if (v.canPlayType v.canPlayType(video/ogg; codecs=vorbis,theora) !
= no) {
document.write(I CAN HAS OGG);
} else {
document.write(OH NOES);
}
/script
Regards,
Maciej
Re: [whatwg] Canvas context.drawImage clarification
On Jul 9, 2009, at 9:25 PM, Oliver Hunt wrote: I disagree. When I scale a rectangular opaque image I expect rectangular opaque results. The Firefox implementation does not do this. If you believe that to be the case then you can always file a bug at bugs.webkit.org . Why would he file a bug to WebKit for a Firefox rendering issue? I would think that https://bugzilla.mozilla.org/ would get better results. -- Brian Campbell
Re: [whatwg] Serving up Theora video in the real world
On Jul 9, 2009, at 9:15 PM, Robert O'Callahan wrote: On Fri, Jul 10, 2009 at 3:04 PM, Maciej Stachowiak m...@apple.com wrote: Robert's code is a bit buggy; canPlayType returns a string, not a boolean, so it will always appear to say yes. You're being polite, my code was not a bit buggy, it was completely broken. I've actually made this mistake several times while writing tests recently, so I should have known better. I actually anticipated this problem, and argued strenuously to break canPlayType into two boolean functions, canPlayType and cannotPlayType, but I lost. Hopefully most Web authors are smarter than I am. I think at one point I suggested that canPlayType should return one of boolean false, true or maybe, so that naiive boolean tests would work. Or in any case, make the no option something that tests as boolean false. - Maciej
Re: [whatwg] Serving up Theora video in the real world
On Fri, Jul 10, 2009 at 3:04 PM, Maciej Stachowiak m...@apple.com wrote: Robert's code is a bit buggy; canPlayType returns a string, not a boolean, so it will always appear to say yes. You're being polite, my code was not a bit buggy, it was completely broken. I've actually made this mistake several times while writing tests recently, so I should have known better. I actually anticipated this problem, and argued strenuously to break canPlayType into two boolean functions, canPlayType and cannotPlayType, but I lost. Hopefully most Web authors are smarter than I am. 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] Canvas context.drawImage clarification
On Jul 9, 2009, at 9:09 PM, Brian Campbell wrote: On Jul 9, 2009, at 9:25 PM, Oliver Hunt wrote: I disagree. When I scale a rectangular opaque image I expect rectangular opaque results. The Firefox implementation does not do this. If you believe that to be the case then you can always file a bug at bugs.webkit.org . Why would he file a bug to WebKit for a Firefox rendering issue? I would think that https://bugzilla.mozilla.org/ would get better results. Whoops, i knew what i meant :D -- Brian Campbell
Re: [whatwg] Serving up Theora video in the real world
On Thu, 9 Jul 2009, Maciej Stachowiak wrote: On Jul 9, 2009, at 9:15 PM, Robert O'Callahan wrote: I actually anticipated this problem, and argued strenuously to break canPlayType into two boolean functions, canPlayType and cannotPlayType, but I lost. Hopefully most Web authors are smarter than I am. I think at one point I suggested that canPlayType should return one of boolean false, true or maybe, so that naiive boolean tests would work. Or in any case, make the no option something that tests as boolean false. I've changed the API to return instead of no. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Serving up Theora video in the real world
On Thu, Jul 9, 2009 at 9:22 PM, Maciej Stachowiakm...@apple.com wrote: I think at one point I suggested that canPlayType should return one of boolean false, true or maybe, so that naiive boolean tests would work. Or in any case, make the no option something that tests as boolean false. We seem to have wound up with a tristate where one of the states is never used, which is unfortunate. Is it too late now? To recap (off the top of my head): it's hard to say if you can play something because that requires either a validator, or actually playing it, So in addition to 'yes' and 'no', a 'maybe' was added, to say I've heard of the media type and codecs and profiles, so it's worth trying; no promises. But the whole idea of canPlayType is to be a lightweight test do decide what to try playing in advance, so browsers are unlikely to implement a check that involves actually loading and testing the resource. So in practice 'yes' would only be returned in special applications, not for general web resources. 'No' means no, 'maybe' means yes and 'yes' never gets used. It will be confusing either way, but if canPlayType were reverted to a boolean, with a note that true means 'maybe', not 'yes', there would at least be fewer programming errors. But Ian's just replied with a clever compromise. -r
Re: [whatwg] Serving up Theora video in the real world
On Fri, Jul 10, 2009 at 4:40 PM, Ralph Giles gi...@xiph.org wrote: To recap (off the top of my head): it's hard to say if you can play something because that requires either a validator, or actually playing it, So in addition to 'yes' and 'no', a 'maybe' was added, to say I've heard of the media type and codecs and profiles, so it's worth trying; no promises. The way we've implemented in Firefox, we'll return yes if you specify a codecs parameter and we support every codec in your list. So v.canPlayType(video/ogg; codecs=vorbis,theora) returns probably in Firefox 3.5. I think this is reasonable because I believe that, modulo bugs in our implementation, we support the full Theora and Vorbis specs. On the other hand, we will return maybe for v.canPlayType(video/ogg). I think this distinction will be useful. I know it's trickier for H.264 where there are many profiles, but IIRC the codecs parameter is flexible enough to encode profile levels as well. 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]
