Maciej Stachowiak wrote:
I think audio can use almost the exact same APIs for most things as
video. This has the nice side benefit that new Audio() can just make
an audio element and provide all the relevant useful API.
To me, the distinction between the audio element and the Audio object
Maciej Stachowiak wrote:
- Even if all browsers end up supporting Ogg Theora/Vorbis, these are
not the best-compression codecs available. So a large-scale video
content provider that wants to save on bandwidth may wish to provide
H.264/AAC content to those browsers that can handle it, even
On Mar 22, 2007, at 1:29 AM, Martin Atkins wrote:
However, as others have pointed out, MIME types only represent the
container format and not the codecs inside, so content negotiation
would need to be extended to somehow allow audio and video codecs
to be presented in addition to
On Mar 22, 2007, at 2:09 AM, Dave Raggett wrote:
From an accessibility perspective the proposal lacks support for
captioning. There should be a mechanism for enabling/disabling
captions to avoid disadvantaging people who have difficulties with
hearing the audio. It should further be
Simon Pieters wrote:
Browsers are allowed to provide full screen, however there's no API for
it. Entering fullscreen should only be under the control of the user,
otherwise the author could hijack the user's screen and no way to get
out of it (e.g. as soon as the user tries to exit fullscreen,
Robert Sayre wrote:
It seems a few people believe this list is an appropriate venue for
discussion of legal issues like trademarks and patents. Well, I don't
know of any lawyers that participate here, but perhaps a more focused
list could attract some legal expertise. Here's whatwg-legal:
Maciej Stachowiak schrieb:
- As mentioned above, some devices may have a much harder time
implementing Ogg than other codecs. Although a SHOULD-level requirement
would excuse them, I'm not sure it's appropriate to have it if it might
be invoked often.
Ogg Theora decoding has been demonstrated
On Thu, 22 Mar 2007 01:08:26 +0100, Maciej Stachowiak [EMAIL PROTECTED]
wrote:
- We have included a mechanism for static fallback based on container
type and codec, so that it's possible to choose the best video format
for a client even if user agent codec support varies.
The covered
Ian Hickson wrote:
Biting off more
than we can chew is a common mistake in Web specification development.
lynx -dump -nolist http://www.whatwg.org/specs/web-apps/current-work/ |
wc --words
143147
lynx -dump -nolist http://www.whatwg.org/specs/web-forms/current-work/ |
wc --words
40523
On Wed, 21 Mar 2007 17:23:21 +0100, Christian Schmidt [EMAIL PROTECTED] wrote:
It would be useful to be able to mark certain submit buttons as
non-validating.
input type=submit validate=no /
How would this be achieved using script?
One way is to use a button with the following onclick
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
Robert O'Callahan / Maciej Stachowiak wrote:
- Placing requirements on format support would be unprecedented for
HTML specifications, which generally leave this up to the UA, with de
facto baseline support being decided by the market.
It's not unprecedented in W3C; the SVG 1.2 WD
If 21.3 can be handled - get big_264.mp4
else
if 20.9 can be handled - get medium.mp4
else
get small.png
additionally get small2.png
or to put it another way
What if I can't do 21.3, but can do 20.9, do I show the 21.3.
fallback or not?
You show
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
Dirac is _just_ a video codec - there are no DRM components in the
system.
regards
Thomas
From: Gareth Hay [mailto:[EMAIL PROTECTED]
Sent: 22 March 2007 12:51
To: Thomas Davies
Cc: whatwg@lists.whatwg.org
Subject:
Simon Pieters wrote:
On Wed, 21 Mar 2007 20:11:57 +0100, Mihai Sucan [EMAIL PROTECTED]
wrote:
Shouldn't the video API include a way to toggle full screen on/off?
Browsers are allowed to provide full screen, however there's no API for
it. Entering fullscreen should only be under the control
Gervase Markham wrote:
Simon Pieters wrote:
Browsers are allowed to provide full screen, however there's no API
for it. Entering fullscreen should only be under the control of the
user, otherwise the author could hijack the user's screen and no way
to get out of it (e.g. as soon as the user
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:
Perhaps you and I have different ideas about what is meant by full
screen, but why would a page need to hide anything when the video is
full screen? The page itself won't be visible, because the video will be
taking up the entire screen!
My thought was that it would be
You are confusing Internet Explorer with a web browser.
By that I mean that you obviously use IE and aren't considering other
UA's, including mobile devices.
Certainly Firefox and Safari on the Mac I am currently using don't
support this 'feature'.
Gaz
On 22 Mar 2007, at 14:16, Gervase
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)
On 22/03/07, Gareth Hay [EMAIL PROTECTED] wrote:
You are confusing Internet Explorer with a web browser.
By that I mean that you obviously use IE and aren't considering other
UA's, including mobile devices.
Funny that you would say that about somebody with a @mozilla.org address...
I'm sure
Is it a pre-requisite of the list to leave humour at the door?
Anyway, was my point incorrect, a sub-set of browser support that
facility
On 22 Mar 2007, at 14:29, Anne van Kesteren wrote:
On Thu, 22 Mar 2007 15:24:39 +0100, Gareth Hay [EMAIL PROTECTED]
wrote:
You are confusing
Gareth Hay wrote:
On 22 Mar 2007, at 14:16, Gervase Markham wrote:
My thought was that it would be the same function as the current full
screen that the browser has. I.e. the page says For full-screen,
press F11. The user presses F11 and the browser makes the window
full-screen...
You are
On 22 Mar 2007, at 00:08, Maciej Stachowiak proposed:
CSS Timed Media Module
HTML Timed Media Elements
• On volume:
The volume property is currently inconsistent in the string names
defined:
http://webkit.org/specs/Timed_Media_CSS.html#propdef-volume
Value: reads silent | soft | medium |
liorean wrote:
I'm sure Gervase just doesn't use a Mac, so he hasn't felt how lacking
the support for full screen mode is in Mac browsers.
It's true that I don't use a Mac.
However, I think it's a reasonable position that the idea of going to
full screen is a user agent thing (no matter what
By that I mean that you obviously use IE and aren't considering
other UA's, including mobile devices.
What are you talking about? Several browsers provide full screen
capabilities, including at least Firefox (Win) and Opera (Win and
Mac). And last time I used a mobile device, it took
On Thu, 22 Mar 2007 15:51:31 +0100, Gareth Hay [EMAIL PROTECTED] wrote:
P990i, by default is portrait display, switching to landscape does
provide a 'fullscreen' mode, but hey, don't let a valid point get in the
way of the argument!
I really don't understand this attitude, it was a very
Arve Bersvendsen wrote:
Note that 'fullscreen' and 'fullscreen' are two different things:
1. A fullscreen mode on desktop should typically be a paged media,
applying any 'projection' style sheets to the page
2. The fullscreen mode on Sony Ericsson P990i, M600i and a number of
other UIQ
On 22 Mar 2007, at 14:16, Gervase Markham wrote:
Martin Atkins wrote:
Perhaps you and I have different ideas about what is meant by
full screen, but why would a page need to hide anything when the
video is full screen? The page itself won't be visible, because
the video will be taking up
Gareth Hay wrote:
I really don't understand this attitude, it was a very clear point,
pressing F11 in a *large* number of browsers does not provide a
'fullscreen' mode. I mean, how many mobile devices even have an F11?
Er, F11 was an example (that's what it is in Firefox).
I could have said
On 3/22/07, Gervase Markham [EMAIL PROTECTED] wrote:
Would it not have made more sense to at least have asked the WHAT-WG
No.
--
Robert Sayre
Nicholas Shanks wrote:
What is chrome ?
I mean, I know what it really is, but that seems to have nothing to do
with computers or web browsers (except for the chromium-coloured iPod
phone).
Sorry. It means things like toolbars, menu bars, status bars and other
non-content-area UI.
Gerv
As my last word on this pointless bit of the thread, I'm going to
spell it out
Your thread:
Martin Atkins wrote:
Perhaps you and I have different ideas about what is meant by
full screen, but why would a page need to hide anything when the
video is full screen? The page itself won't
Gareth Hay wrote:
I think it should be like this, as you are telling the video element
to go fullscreen and *not* the page.
That's my opinion.
I guess that's the heart of it. My view is the opposite. I don't think
video should be special in this regard.
If you want to see an embedded image
On 3/22/07, Gervase Markham [EMAIL PROTECTED] wrote:
However, I think it's a reasonable position that the idea of going to
full screen is a user agent thing (no matter what type of UA it is,
even mobile) but that content should be able to respond appropriately
when users make that change. If
Gervase Markham wrote:
My assertion is that the idea of going to full screen (i.e. removing
all chrome and allowing the content to take up as much space as
possible) is a fairly common browser thing. Of course, those with a
wider experience of browser implementations than I may well tell me
On 22 Mar 2007, at 16:11, Robert Sayre wrote:
On 3/22/07, Gervase Markham [EMAIL PROTECTED] wrote:
Would it not have made more sense to at least have asked the WHAT-WG
No.
I think you're wrong and clearly I'm not alone. In fact I think legal
matters *should* be discussed here and
On 22/03/07, Martin Atkins [EMAIL PROTECTED] wrote:
Incidentally, although I'm in favour of the full-screen feature under
discussion being for full-screen *video*, not full-screen pages, I'm not
arguing that this should be mandated by the spec. This is something that
browsers could choose to
On Mar 13, 2007, at 22:29, Asbjørn Ulsberg wrote:
On Tue, 13 Mar 2007 21:07:20 +0100, Simon Pieters
[EMAIL PROTECTED] wrote:
Many pages use tables where only the first column are header
cells, e.g.:
table
trthFoo tdBar
trthFoo tdBar
trthFoo tdBar
/table
With the
On 3/22/07, Nicholas Shanks [EMAIL PROTECTED] wrote:
To me full screen mode for video would not alter the browser window
size, instead it would cover the screen in a new window and draw just
the video into that. The browser window would be left untouched below
(though the video may no longer be
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 Oct 30, 2006, at 22:33, Ian Hickson wrote:
On Sun, 29 Oct 2006, Henri Sivonen wrote:
FWIW, I think samp and kbd don't deserve to be in HTML and I
am not
convinced that the use cases for var could not be satisfied by i.
I'm lukewarm on all three, but the cost to keeping these is probably
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
Henri Sivonen:
On Oct 30, 2006, at 22:33, Ian Hickson wrote:
The CSS community has requested a date or time
element because they want to restyle dates and times according to
locale.
Then the recent request to www-style for styling numbers would be
justified as well. An element for times
Continuing today's flood of emails from me to this list, here's another.
Note: I never bothered to read this thread the first time, but since
Henri has brought to the top of my email client again, I started from
the beginning.
I want to comment on the eight bullets given at:
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
On Mar 22, 2007, at 5:08 PM, Nicholas Shanks wrote:
• Bullet 7: I think people marking up computer code in HTML are
completely wasting their time. Most sample code I have seen doesn't
bother. e.g. some random OpenGL sample code:
http://developer.apple.com/samplecode/Red_Rocket/listing4.html
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
On Mar 22, 2007, at 2:16 AM, Håkon Wium Lie wrote:
I think having a single baseline codec will make video immensely
more
attractive to authors than it otherwise would be. I also believe
from the
point of view of Mozilla (or any other open source project) Theora
is vastly
more attractive
On 3/22/07, Maciej Stachowiak [EMAIL PROTECTED] wrote:
To the extent we have a media platform we want to promote, it is
MPEG-4, a format and codec family that is an ISO standard.
Not a particularly high bar for a Web standard.
This
format family is available in many hardware and software
On Fri, 23 Mar 2007, Robert Sayre wrote:
MPEG-4 is proprietary, because it is covered by patents.
I hate to be the one to break this to you, but CSS is covered by patents,
HTML is covered by patents, the DOM is covered by patents, JavaScript is
covered by patents, and so forth. Proprietary
On Fri, 23 Mar 2007, Robert Sayre wrote:
On 3/23/07, Ian Hickson [EMAIL PROTECTED] wrote:
I hate to be the one to break this to you, but CSS is covered by
patents,
I hate to be the one to break this to you, but you don't [know] anything
about patents. Many engineers have trouble
On 3/23/07, Ian Hickson [EMAIL PROTECTED] wrote:
On Fri, 23 Mar 2007, Robert Sayre wrote:
On 3/23/07, Ian Hickson [EMAIL PROTECTED] wrote:
The technologies I listed _are_ covered by patents, yet they are not
proprietary. This seems like a relevant counterexample to your
argument.
If I
On Mar 22, 2007, at 3:33 AM, Christian F.K. Schaller wrote:
A fallback without a mandated 'minimum' codec is next to worthless.
Standards
with similar goals of interoperability, like DLNA, have ended up
choosing some
mandated codecs (which are all 'older' codecs) and some optional
higher
62 matches
Mail list logo
