On 3/29/07, Laurens Holst [EMAIL PROTECTED] wrote:
The URL parameter (as also seen in e.g. Quicktime and Flash) is imho a
dirty hack to work around implementations not providing plugins with a
streaming file reader object. At least, that is the only explanation I
can come up with. There is a
Henri Sivonen wrote:
I've asked about this before but I still don't understand it: Why
doesn't Gecko completely ignore the classid?
Apart from the fact that this would technically be a spec violation, it actually
breaks some pages (because the ActiveX and NPAPI versions of some plug-ins
Laurens Holst wrote:
As said, I tried a few things with embedding an image, video and SVG
with the object tag:
...
First of all, one annoying thing is that you have to provide sizes,
otherwise the object will not be visible.
At least in Mozilla, this is false for images. It should become
Laurens Holst wrote:
One of the main reasons that object is still broken on the web and why
embed needs to be used is Mozilla; their plugin finder doesn’t work
with object.
I'm sorry, but that's false. See my other post (under Re: video element
feedback) and
On Mon, 26 Mar 2007 13:59:14 +0200, Benoit Piette [EMAIL PROTECTED] wrote:
In the same train of thought, a document tag might be useful. I always
found anoying that for many embeded documents (word or pdf) you would have a
second user interface that have similar functionnality to the web
At 22:17 + UTC, on 2007-03-25, Kornel Lesinski wrote:
On Sun, 25 Mar 2007 20:28:38 -, Elliotte Harold
[EMAIL PROTECTED] wrote:
[...]allowing authors the ability to override the browsers controls [...]
Seems to me the user shoudl be in control here [...]
[...] Authors use
From HTML 4.01:
type = content-type [CI]
This attribute specifies the content type for the data specified by data.
This attribute is
optional but recommended when data is specified since it allows the user agent
to avoid loading
information for unsupported content types. If the value of
Chris Adams wrote:
Actually that sounds like a splendid idea to me.
although I am not sure about using the form tag. what about something like?
video src='some_file.ogg'
button type='rewind' /
button type='playpause' /
button type='stop' /
button type='fastforward' /
/video
Why
The browser could control this, yes; however I believe that the browser
should really be as transparent as possible
as to not be a limiting factor in development.
there can always be browser defaults that take over, but by allowing authors
the ability to override the browsers controls
will allow
Chris Adams wrote:
there can always be browser defaults that take over, but by allowing
authors the ability to override the browsers controls
will allow for the flexibility of
a) allowing for disabled controls (perhaps disabling fast-forward for
training videos)
Seems to me the user shoudl
On Sun, 25 Mar 2007 20:28:38 -, Elliotte Harold
[EMAIL PROTECTED] wrote:
there can always be browser defaults that take over, but by allowing
authors the ability to override the browsers controls
will allow for the flexibility of
a) allowing for disabled controls (perhaps disabling
On Mar 18, 2007, at 4:21 PM, Matthew Ratzloff wrote:
Slightly more complex use case:
object classid=clsid:02BF25D5-8C17-4B23-BC80-D3488ABDDC6B
codebase=http://www.apple.com/qtactivex/qtplugin.cab;
width=200
height=16
param name=src value=my-audio.mp3 /
param
On Fri, Mar 23, 2007 at 04:33:39PM -0700, Eric Carlson wrote:
Yes, the UA needs the offset/chunking table in order to calculate
a file offset for a time, but this is efficient in the case of
container formats in which the table is stored together with other
information that's needed
On Sat, Mar 24, 2007 at 01:57:45AM -0700, Kevin Marks wrote:
How does one seek a Vorbis file with video in and recover framing?
It looks like you skip to an arbitrary point and scan for 'OggS' then
do a 64kB CRC to make sure this isn't a fluke. Then you have some
packets that correspond to
Geoffrey Sneddon schrieb:
That sort of info is held within the container, so everything within Ogg
(so both Theora and Dirac) will suffer from it. H.264 being part of the
MPEG-4 standard follows what Kevin Marks said:
On 24 Mar 2007, at 08:57, Kevin Marks wrote:
2. define a chunk/offset
In this case, there is a big difference between streamed data, which
can be played from various positions, and non-streamed data which
requires a complete download, or at least the start of the file.
Perhaps there should be some reflection of this in the tag?
On 23 Mar 2007, at 03:15,
On 3/23/07, Sander Tekelenburg [EMAIL PROTECTED] wrote:
I don't know of a video container format that allows named anchors to be
specified, though.
QuickTime let's authors define points in a .mov container as chapters,
which, in the cotext of the Web, could function as named anchors I'd
Håkon Wium Lie schrieb:
Does Dirac aim at becoming a member in the Ogg family, or are you
primarily working towards a standalone format?
Dirac is container neutral to my knowledge. The implementation targeted
at end-users is embedding it in Ogg, though, so it can e.g. use the free
Ogg audio
On Fri, 23 Mar 2007 10:24:30 -, Silvia Pfeiffer
[EMAIL PROTECTED] wrote:
Let's say there's http://example.com/example.html page which contains
embedded video:
...video src=video.ogg...
I'd like to be able to construct URL like:
http://example.com/[EMAIL PROTECTED]:35
that would cause UA
The difference between streaming and non-streaming is artificial and
not technically necessary - except for life content, where you cannot
jump into the future.
Silvia.
On 3/23/07, Gareth Hay [EMAIL PROTECTED] wrote:
In this case, there is a big difference between streamed data, which
can be
How about the following idea:
Example.html contains:
video id=myvideo_1 src=video.ogg
to provide the full video
video id=myvideo_2 src=video.ogg?t=0:12:35
to provide the video from offset 12:35
video id=myvideo_3 src=video.ogg?t=0:12:35/0:20:40
to provide the video segment between offset
On Mar 23, 2007, at 1:27 PM, Silvia Pfeiffer wrote:
On 3/23/07, Nicholas Shanks [EMAIL PROTECTED] wrote:
Can't we have all of:
1) A way for authors to match up timecodes with fragment identifiers
in the fallback content
2) A way for UAs to skip to that time code if a fragment identifier
is
On Fri, 23 Mar 2007 20:57:24 -, Silvia Pfeiffer
[EMAIL PROTECTED] wrote:
video id=myvideo_3 src=video.ogg?t=0:12:35/0:20:40
to provide the video segment between offset 12:35 and 20:40
video id=myvideo_4 src=video.ogg?id=section4
to provide the video from named offset section4
These
On Mar 23, 2007, at 3:49 PM, Silvia Pfeiffer wrote:
Hi Eric,
On 3/24/07, Eric Carlson [EMAIL PROTECTED] wrote:
Even without a server component, #2 and #3 do not require the UA to
download the full file if it can use byte range requests for random
access
and the file format has time to
As a newcomer to this group, please forgive my ignorance of discussions
that, undoubtedly, have already taken place, but as I have been reading
these threads on video and timed media and object, a couple of questions
have come to mind:
1. why not just include SMIL as a part of HTML, much in
Hi
Having been pointed at this discussion by Christian, I thought I'd let
you know a bit more about where Dirac is as a royalty-free open source
codec. We're certainly very keen for Dirac to be considered as one of
the supported video formats.
Dirac has been in development for 4 years. In
This is maybe off-topic to some degree.
What are the DRM constraints of this format?
I only ask as your organisation is embarking on an MS-DRM fueled
online media project, and I am curious as to the position of this codec.
thanks
On 22 Mar 2007, at 12:28, Thomas Davies wrote:
Hi
Having
: [whatwg] video element proposal
This is maybe off-topic to some degree.
What are the DRM constraints of this format?
I only ask as your organisation is embarking on an MS-DRM fueled
online media project, and I am curious as to the position of this codec
On Thu, 22 Mar 2007 14:57:08 +0100, ddailey [EMAIL PROTECTED]
wrote:
1. why not just include SMIL as a part of HTML, much in the same way
that it is integrated with SVG? It is an existing W3C reco.
Reasons for not using t:video were that it was 1) complicated and 2)
not used.
Thanks
ddailey wrote:
On Thu, 22 Mar 2007 13:03:24, Anne van Kesteren wrote
1. why not just include SMIL as a part of HTML, much in the same way
that it is integrated with SVG? It is an existing W3C reco.
Reasons for not using t:video were that it was 1) complicated and 2)
not used.
Thanks
Martin Atkins wrote:
ddailey wrote:
On Thu, 22 Mar 2007 13:03:24, Anne van Kesteren wrote
1. why not just include SMIL as a part of HTML, much in the same way
that it is integrated with SVG? It is an existing W3C reco.
Reasons for not using t:video were that it was 1) complicated and
2)
Sorry to jump into this conversation at such a late point, but I only
just joined the mailing list.
About 8 years ago, we had the idea of using fragment offsets to start
playing from offsets of media files. However, in discussions with the
URI standardisation team at W3C it turned out that
On 22 Mar 2007, at 20:53, Silvia Pfeiffer wrote:
Sorry to jump into this conversation at such a late point, but I only
just joined the mailing list.
About 8 years ago, we had the idea of using fragment offsets to start
playing from offsets of media files. However, in discussions with the
URI
On Thu, 22 Mar 2007 20:53:48 -, Silvia Pfeiffer
[EMAIL PROTECTED] wrote:
About 8 years ago, we had the idea of using fragment offsets to start
playing from offsets of media files. However, in discussions with the
URI standardisation team at W3C it turned out that fragment offsets
are only
Kornel Lesinski:
http://example.com/[EMAIL PROTECTED]:35
that would cause UA to start playing the embedded video.ogg from
12:35.
That would limit documents to one |video| (or |audio|) element.
[My apologies for initially responding off-list. That was unintentional. I'm
posting an updated version.]
At 20:04 + UTC, on 2007-03-21, Martin Atkins wrote:
Sander Tekelenburg wrote:
[...] URL:http://domain.example/movie.ogg#21:08, to mean fetch the
movie and start playing it at 21
At 19:46 + UTC, on 2007-03-22, Nicholas Shanks wrote:
On 22 Mar 2007, at 19:23, Sander Tekelenburg wrote:
[...]
We're not talking about IDs, just fragment identifiers. My point
was that
with video, you could use fragment identifiers *without* the need
for the author to provide IDs.
I
On 23 Mar 2007, at 01:30, Sander Tekelenburg wrote:
(Note that a mechanism to allow authors to define anchors in videos
is not a
solution, because it's then still the author who is in control.
What I'm
suggesting is about giving the user control.)
Can't we have all of:
1) A way for
At 07:53 +1100 UTC, on 2007-03-23, Silvia Pfeiffer wrote:
[...]
About 8 years ago, we had the idea of using fragment offsets to start
playing from offsets of media files. However, in discussions with the
URI standardisation team at W3C it turned out that fragment offsets
are only being seen
On 23/03/07, Sander Tekelenburg [EMAIL PROTECTED] wrote:
While that might be useful, it's not at all obvious to me that it is a
*requirement*. What is so wrong with fetching the entire file, and start
playing it at the point referenced by the fragment identifier? That's how
fragment identifiers
Also sprach Laurens Holst:
object is *very badly* implemented. It has been a decade since object
was first created and browsers STILL don't do it right in all cases (or
even in most cases, frankly). Adding more complexity to such a disaster
zone is bad design.
If the existing
This is a bit of a sideways step here, but why not make tags reflect
MIME type,
e.g.
image image/*
video video/*
application application/*
audio audio/*
That way we have a clear identification of what is going to be in the
tag, API's can be
On 3/20/07, Christoph Päper [EMAIL PROTECTED] wrote:
Maybe it is a stupid idea, but is something like the following
imaginable to make a XHTML5 browser display inline video with a basic
UI without the need for scripting?
form method=MEDIA
video src=pretty.ogg/
button type=play/
On 3/20/07, Robert Brodrecht [EMAIL PROTECTED] wrote:
Simon Pieters said:
Oh. I thought video fallback would work pretty much like object
fallback, but I see that's not the case. When I think about it it makes
sense; video is pretty much like iframe, it never falls back in UAs
that
Ian Hickson [EMAIL PROTECTED] wrote:
However, I think if object is so widely derided by everyone, than I
think it needs to be depreciated sooner rather than later.
I have seriously considered doing this. Unfortunately I don't think we can
actually do it given the large amount of legacy
At 09:25 + UTC, on 2007-03-20, Ian Hickson wrote:
[...]
ON NATIVE UI:
[...] I completely agree that on the long term this is something we need to
offer. However, we musn't bite off more than we can chew. There are
several sets of use cases, some of which require browser-provided UI, and
At 23:02 +0100 UTC, on 2007-03-20, Håkon Wium Lie wrote:
Also sprach Martin Atkins:
If video is going to be considered a first-class citizen, I argue that
this needs to be possible for video as well:
video src=pretty.ogg.../video
Right. I think I agree with you. Perhaps we can
On 21 Mar 2007, at 12:43, Sander Tekelenburg wrote:
Something else concerning first-class Netizenry: I'd like to see
the spec to
require UAs support implicit anchors, so that one can link to a
specific
startpoint: URL:http://domain.example/movie.ogg#21:08, to mean
fetch the
movie and start
Gareth Hay wrote:
This is a bit of a sideways step here, but why not make tags reflect
MIME type,
e.g.
imageimage/*
videovideo/*
application application/*
audioaudio/*
That way we have a clear identification of what is going to be in the
tag, API's can be
On Wed, 21 Mar 2007 18:31:29 -, Nicholas Shanks
[EMAIL PROTECTED] wrote:
Well besides the fact that fragment ids cannot start with a number
nor contain a colon
I've checked syntax for fragment identifiers in URIs (RFC 2396) and
haven't found such limitation. If such fragments cannot
Are we speaking MIME type or tag here?
Looking at the list of issued MIME types, it seems pdf and ogg can
fall under this category.
Under these conditions, I would imagine that application would be a
download, where the author wants you to get the content, as opposed
to stream it or view
Once upon a time Spartanicus shaped the electrons to say...
But if I'm wrong and this fight hasn't yet been lost, I'd like to add my
voice to not relying on JS for anything essential at least from a
specification angle.
Strongly agreed. I know more than a few people who are (still)
rabidly
Also sprach Robert Brodrecht:
Quality, size, etc. have all been goals of the Theora project, so it's
not really fair to say that they haven't been considered. There is no
technical reason why Theora shouldn't be specified as a baseline format.
I think you took that out of context.
Vladimir Vukicevic wrote:
If providing content in non-Theora formats is important, the client
should list the supported video formats in the Accept header, and the
server can send
back the right thing.
[snip]
Though as has been pointed out by someone else earlier in the thread,
the MIME
Thanks for all the feedback on video. There were several topics
discussed. I'll cover the three most important ones first.
ON THE CODEC:
A number of people put forth many arguments for and against all kinds of
codecs. However, very little of the feedback introduced any information
that
I do fully understand the points you make below, but I am not sure I
fully subscribe to the logic.
embed is in HTML5 specifically for plugins.
However, for embed, object, iframe, and video, the spec
doesn't
require that UAs implement the features using plugins or using native
code. For
Ian Hickson wrote:
On Sun, 18 Mar 2007, Anne van Kesteren wrote:
I just played some more with our internal implementation (Opera's) and
noticed that our pause() really is like togglePause() in the HTML5
Having pause() always pause is better because it means that you're not
likely to end up
Lachlan Hunt wrote:
Ian Hickson wrote:
I only included togglePause() because Flash supports it and some
people asked for it; I'm not convinced we should keep it.
I'm in favour of dropping it.
+1.
Jeff Cutsinger
On 3/20/07, Ian Hickson [EMAIL PROTECTED] wrote:
On Sat, 17 Mar 2007, Shadow2531 wrote:
Video content must be rendered inside the element's playback area such
that the video content is shown centered in the playback area at the
largest possible size that fits completely within it, with the
On Tue, 20 Mar 2007 16:18:16 +0100, Shadow2531 [EMAIL PROTECTED]
wrote:
However, if JS is needed for the video element to function at all,
then
the video element needs to fall back if JS is turned off.
Interesting point.
Yes, since JS is required, if JS is off, the browser should
On 3/20/07, Simon Pieters [EMAIL PROTECTED] wrote:
On Tue, 20 Mar 2007 16:18:16 +0100, Shadow2531 [EMAIL PROTECTED]
wrote:
However, if JS is needed for the video element to function at all,
then
the video element needs to fall back if JS is turned off.
Interesting point.
Yes, since JS
Ian Hickson wrote:
A large portion of the feedback concerned the way that the current spec
doesn't have any features for native browser-provided UI.
I completely agree that on the long term this is something we need to
offer. However, we musn't bite off more than we can chew. There are
On Tue, 20 Mar 2007, Gareth Hay wrote:
I do fully understand the points you make below, but I am not sure I fully
subscribe to the logic.
embed is in HTML5 specifically for plugins.
However, for embed, object, iframe, and video, the spec
doesn't require that UAs implement the
Ian Hickson wrote:
I don't think such metadata attributes would help. They would just be
ignored by most authors and incorrectly set by many others.
I absolutely agree, but this is opt-in metadata so the first flaw
(ignored by most authors) is by design. Such authors are precisely the
sort of
Ian Hickson wrote:
However, I think if object is so widely derided by everyone, than I
think it needs to be depreciated sooner rather than later.
I have seriously considered doing this. Unfortunately I don't think we can
actually do it given the large amount of legacy content, e.g.
Also sprach Martin Atkins:
If video is going to be considered a first-class citizen, I argue that
this needs to be possible for video as well:
video src=pretty.ogg.../video
Right. I think I agree with you. Perhaps we can encourage implementors
to add a simplistic UI in case none has
Simon Pieters said:
Oh. I thought video fallback would work pretty much like object
fallback, but I see that's not the case. When I think about it it makes
sense; video is pretty much like iframe, it never falls back in UAs
that support it.
Oh, damn it. I thought it'd work like object,
Håkon Wium Lie:
Also sprach Martin Atkins:
If video is going to be considered a first-class citizen, I argue
that
this needs to be possible for video as well:
video src=pretty.ogg.../video
Right. I think I agree with you. Perhaps we can encourage implementors
to add a simplistic UI in
I'm curious why people feel that adding another element is the way to
go. Why do people not want to use img? Afraid of object
extension craziness?
I'd like to see us have the ability to do video in both img and in
CSS places (background: url(foo.mpg) -- we're supposed to be
separating
Actually that sounds like a splendid idea to me.
although I am not sure about using the form tag. what about something like?
video src='some_file.ogg'
button type='rewind' /
button type='playpause' /
button type='stop' /
button type='fastforward' /
/video
On 3/20/07, Christoph Päper [EMAIL
Christoph Päper said:
Maybe it is a stupid idea, but is something like the following
imaginable to make a XHTML5 browser display inline video with a basic
UI without the need for scripting?
form method=MEDIA
video src=pretty.ogg/
button type=play/
/form
I was somewhat
On 20 Mar 2007, at 21:50, Benjamin Hawkes-Lewis wrote:
Ian Hickson wrote:
However, I think if object is so widely derided by everyone,
than I
think it needs to be depreciated sooner rather than later.
I have seriously considered doing this. Unfortunately I don't
think we can
actually
Once upon a time Maik Merten shaped the electrons to say...
Well, I guess everybody here will hate me for proposing it... and I
think it's ugly... but well...
video
Perhaps a verbose description of what can be seen here?
novideo
D'oh, your browser is outdated... let's embed an object here
On 21/03/07, Robert Brodrecht [EMAIL PROTECTED] wrote:
Christoph Päper said:
Maybe it is a stupid idea, but is something like the following
imaginable to make a XHTML5 browser display inline video with a basic
UI without the need for scripting?
form method=MEDIA
video
On Sun, 18 Mar 2007 22:09:02 +0100, Magnus Kristiansen
[EMAIL PROTECTED] wrote:
I would suggest the opposite. For basic actions like play and pause,
play() and pause() are the most natural options. I question whether we
need a command to toggle between play/pause at all. Any UI which uses a
Gareth Hay wrote:
Sure. What happens if you're taking old videos of a page because
you moved them to a site like YouTube? How would you tell them apart
from other content in the page that might require object, like SVG
graphics and such?
I think this kind of reasoning leads us logically to
Also sprach Robert Brodrecht:
I don't see how you're going to avoid that with
video unless you intend to make it a non-pluggable system, which does
not seem like a good idea.
I think that was the idea. I don't need plugins for certain media files,
e.g., GIF, JPEG, and PNG (and
Håkon Wium Lie schrieb:
What WHATWG has been shooting for, is one common codec. At this point,
WHATWG folks want Theora.
Yes, it's a likable format. If anyone has better ideas, this is the
time to step forward.
There's Dirac in development right now. That's a next generation wavelet
Also sprach Robert Brodrecht:
As I said before, I think we have a lot better chance at getting a common,
cross-browser, cross-platform format with MPEG 4. The reason WHAT WG
proposed Theora is *because* it is FOSS, not for quality, size, ease of
implementation, or anything else (as far
Håkon Wium Lie wrote:
Also sprach Robert Brodrecht:
As I said before, I think we have a lot better chance at getting a common,
cross-browser, cross-platform format with MPEG 4. The reason WHAT WG
proposed Theora is *because* it is FOSS, not for quality, size, ease of
implementation, or
Håkon Wium Lie schrieb:
In the context of codecs, the term performance is most often used to
describe compression ratios (at given levels of quality). There is
another factor related to performace which is also relevant when
picking the best codec for the web: how much processing power does a
On Fri, 16 Mar 2007 17:57:01 +0100, Nicholas Shanks
[EMAIL PROTECTED] wrote:
All said, it would be very useful if the startpos param could be
returned to the server when starting the download, or when scrubbing
forward into parts of the video that haven't yet downloaded. as that
would help
Recently, there has been some debate about whether the browser should
present its own standard UI for playback control or let the authors design
their own UI (branded and consistent with the site design).
Browser-provided UI has the advantage of having the same UI across all
pages, which
On Sun, 18 Mar 2007 19:14:14 +0100, Alexey Feldgendler
[EMAIL PROTECTED] wrote:
A compromise solution that I propose is to include a standard set of
browser-provided controls, displayed by default and styleable through
CSS pseudo-elements and pseudo-classes:
[...]
I think this is far too
On Sun, 18 Mar 2007 19:18:00 +0100, Anne van Kesteren [EMAIL PROTECTED]
wrote:
A compromise solution that I propose is to include a standard set of
browser-provided controls, displayed by default and styleable through
CSS pseudo-elements and pseudo-classes:
I think this is far too
On Sun, 18 Mar 2007 18:52:35 -, Alexey Feldgendler
[EMAIL PROTECTED] wrote:
How about controls overlaid on top of video, which are visible only when
mouse hovers it? Something like fullscreen controls in QuickTime Pro or
iTunes 7.
To ensure that video is always usable:
* UI would be
Hi,
I just played some more with our internal implementation (Opera's) and
noticed that our pause() really is like togglePause() in the HTML5
proposal. Looking at the specification I don't see much need for pause()
there. Perhaps togglePause() should just become pause() and pause() be
Alexey Feldgendler wrote:
On Sun, 18 Mar 2007 22:09:02 +0100, Magnus Kristiansen
[EMAIL PROTECTED] wrote:
I just played some more with our internal implementation (Opera's)
and noticed that our pause() really is like togglePause() in the
HTML5 proposal. Looking at the specification I don't
Hi Matthew,
Very cool set of test cases.
Would it be cool to make them as individual files and send them as
attachments.
On the same line, this is a testing for object, W3C QA and WASP
organised two years ago. Most recent information is missing. So if
you have a browser please add it.
Le 16 mars 2007 à 20:23, Matthew Raymond a écrit :
Laurens Holst wrote:
| object data=TheEarth.mpeg type=video/ogg-theora/object
In fact
by http://www.w3.org/TR/html401/struct/objects.html#adef-type-OBJECT
type is optional, it is exactly the same
object data=TheEarth.mpeg/object
Bjoern Hoehrmann [EMAIL PROTECTED] wrote:
It is hard to find tools that take care of transcoding, they are
difficult to use (lack of advise on which settings to use, crude command
line interfaces, ...)
Most such applications start as console applications, that changes as
soon as more mainstream
On 3/16/07, Dean Edridge [EMAIL PROTECTED] wrote:
I think the idea of having an attribute for the aspect ratio of a video
is a great idea, especially given the fact that web sites today should
be as fluid / liquid as possible since there is a need to cater for a
range of different screen sizes.
Anne van Kesteren wrote:
We're not enforcing this upon the world ;-)
Speaking about enforcing. When this element gets implemented there are a
few things I would demand from my browser:
1. That videos should never start to play without my consent. No more
bgsound-hellish experiences.
On Sat, 17 Mar 2007 11:56:53 +0100, Shadow2531 [EMAIL PROTECTED]
wrote:
For example, every video page on a site might have a 400 x 400 video
element (to fit with the layout for example), but the video that plays
in it will range in size and aspect ratio.
A way to solve that so the layout of
On 3/17/07, Anne van Kesteren [EMAIL PROTECTED] wrote:
On Sat, 17 Mar 2007 11:56:53 +0100, Shadow2531 [EMAIL PROTECTED]
wrote:
For example, every video page on a site might have a 400 x 400 video
element (to fit with the layout for example), but the video that plays
in it will range in size
Bjoern Hoehrmann schrieb:
Flash supports two codecs, the more recent one is VP6, a successor of
VP3; VP3 in turn is what Ogg Theora is based on. I would be surprised
to learn that On2 gave the superior codec away for free while it sells
the inferior one.
On2 VP6 is performing better than On2
Laurens Holst wrote:
So make the object mime type optional, only indicative. It will receive
it from the server anyway.
The problem with dropping the MIME type is that files on the Internet
don't require extensions. They already have MIME types. Therefore, as a
web author looking at someone
I don't see the problem with this.
Object is a tag to represent just about anything, even text/html
renders in an object.
Can you identify a use case where you *need* to know before you get a
content-type header?
Gaz
On 17 Mar 2007, at 15:17, Matthew Raymond wrote:
Laurens Holst wrote:
On Fri, 16 Mar 2007 23:49:04 -, Bjoern Hoehrmann [EMAIL PROTECTED]
wrote:
++-+-+---+
| SMIL | SVG | IE | WHATWG |
Gareth Hay wrote:
I don't see the problem with this.
Object is a tag to represent just about anything, even text/html
renders in an object.
Can you identify a use case where you *need* to know before you get a
content-type header?
Sure. What happens if you're taking old videos of a
701 - 800 of 894 matches
Mail list logo
