On 07/21/2010 10:24 AM, Chris Double wrote:
Or the developers of said browser could obey the mime type that the
server sent, not have to write or maintain error prone content
sniffing code that could behave differently across browsers (Chrome
content sniffs this as Ogg but you dont!!, etc),
On 07/13/2010 07:49 PM, Ian Hickson wrote:
We
need a specification that defines how the helper servers and browsers are
to interact, and how, once they have a control channel set up, how they
are to set up further channels such as a way to be ready to receive UDP
packets for a video
On 07/05/2010 04:46 PM, Shane Fagan wrote:
For windows maybe there should be a .exe/.msi with the entire package of
VP8+Theora+Vorbis or just VP8+Vorbis to make it easier to install
There is:
http://downloads.xiph.org/releases/oggdsf/opencodecs_0.84.17315.exe
On 06/25/2010 11:50 AM, Boris Zbarsky wrote:
It seems like what you want here is for browsers to parse as they do
now, but a particular subset of browser-accepted syntax to be enshrined
so that when defining your restrictions over content you control you can
just say follow the spec instead of
On 06/24/2010 03:43 AM, Anne van Kesteren wrote:
Why would it simplify parsing?
It greatly simplifies parsing when you just want to extract entire tags,
without immediately parsing the attributes.
It's rather nice to allow it for the
iframe srcdoc feature.
The srcdoc already needs to be
On 06/24/2010 05:22 AM, Brett Zamir wrote:
I do not see any reference to this in the XHTML 1.0 specification (nor
XHTML 1.1), and in XML, section 2.4, it states only that it must be
escaped if part of the sequence ]] in content, which I guess means
only element content. E4X also does not
The HTML5 spec appears to allow inside an attribute value. For
example, the following page (note the body tag) passes the experimental
HTML5 validator at w3c.org:
!DOCTYPE HTMLhtmlheadtitle/title/head
body class=32
/body/html
I think should be disallowed inside attribute values. It is
Ian Hickson wrote:
On Thu, 23 Jul 2009, Justin Lebar wrote:
That being said, inline spec comments sound interesting.
I'm not quite sure what the UI would look like, but if anyone has any
ideas, feel free to e-mail me directly and we can figure something
out. (This would be exceedingly
Ian Hickson wrote:
On Fri, 24 Jul 2009, Benjamin M. Schwartz wrote:
That sounds to me like a good reason to declare a freeze at last call,
and release an immutable beta 1 on which comments can be made. Then
close the comment period on beta 1, and (potentially) release a beta 2,
etc
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
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
Kristof Zelechovski wrote:
The first video source that can be played wins. You cannot provide
alternative versions for different languages or resolutions in one VIDEO
element.
If the browser decides that a video is too high resolution and cannot be
played on this system, then why can't it
jjcogliati-wha...@yahoo.com wrote:
Okay. Thanks.
Maybe to make this more clear section 4.8.7.1 should add a sentence somewhere
like:
Authors may provide multiple source elements to provide different codecs for
different user agents.
Not just different codecs. Different bitrates,
Ian Fette (イアンフェッティ) wrote:
We have chosen to support H.264 + AAC as well as
Ogg (Theora + Vorbis) for video in Google Chrome
H.264 is heavily patented, and H.264 implementors typically acquire patent
licenses from MPEG LA. However, as noted in [1], Chrome's use of ffmpeg
for codec support
Ian Fette (イアンフェッティ) wrote:
We are using H.264 in Google Chrome, not in Chromium. We do not have the
ffmpeg / h.264 related code in chromium (only the header files for ffmpeg),
ffmpeg and h.264 related stuff is a complete external dependency loaded at
run time. Chromium is the open source
As I have mentioned earlier, there are some devices that will be unable to
render video faithfully inline, due to the limitations of hardware video
accelerators. However, it occurs to me that there are two essentially
different uses for video
1. Important content for the webpage. An example
Simon Pieters wrote:
Is there a problem with always falling back to the poster image and just
play the video (full-screen or on-top) when the user indicates he wants
to see the video?
If every menu button has a video tag associated with it to show a little
3D animation, then (a) how do you
Simon Pieters wrote:
If there is a controls attribute or if scripting is disabled, show
controls, else use author-provided scripted button (if any) to play the
video.
Consider a webpage in which a side-effect of clicking on some scripted
button is to trigger a small animation (using video)
Simon Pieters wrote:
On Mon, 18 May 2009 18:59:01 +0200, Benjamin M. Schwartz
bmsch...@fas.harvard.edu wrote:
Simon Pieters wrote:
If there is a controls attribute or if scripting is disabled, show
controls, else use author-provided scripted button (if any) to play the
video.
Consider
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Dear What,
Short: video won't work on slow devices. Help!
Long:
The video tag has great potential to be useful on low-powered computers
and computing devices, where current internet video streaming solutions
(such as Adobe's Flash) are too
20 matches
Mail list logo
