On Tue, 30 Jun 2009, Matthew Gregan wrote:
Is there any reason why PCM in a Wave container has been removed from
HTML 5 as a baseline for audio?
Having removed everything else in these sections, I figured there wasn't
that much value in requiring PCM-in-Wave support. However, I will
Even if Apple decides to implement Ogg Theora, iPod users will still get
QuickTime served and get a better rendering because the common codec is the
failsafe solution and will be specified as the last one. This phenomenon is
expected to happen for any platform, not just Apple's. I cannot see how
On Tue, 30 Jun 2009, Kristof Zelechovski wrote:
I understand that the reason for rejecting MPEG-1 as a fallback mechanism is
that the servers will not serve it because of increased bandwidth usage,
right?
Right.
--
Ian Hickson U+1047E)\._.,--,'``.fL
Hi Ian,
I have just posted a detailed reply on your email to public-html
(http://lists.w3.org/Archives/Public/public-html/2009Jun/0830.html),
so let me not repeat myself, but only address the things that I
haven't already addressed there.
On Tue, Jun 30, 2009 at 2:50 PM, Ian
Thank you, Ian, for the summary.
I just wanted to say that we're not happy with the situation. We
continue to monitor it, to take what action we can, and we continue
to hope that we will, at some time, find a solution that reaches
consensus.
--
David Singer
Multimedia Standards, Apple Inc.
Ian Hickson wrote:
on the situation regarding codecs for video and audio in HTML5, I have
reluctantly come to the conclusion that there is no suitable codec that
all vendors are willing to implement and ship.
I have therefore removed the two subsections in the HTML5 spec in which
codecs
Hi,
I wonder what (and where) are the reasons to use XHTML namespace also
with HTML elements.
The behavior causes few issues like
https://bugzilla.mozilla.org/show_bug.cgi?id=501312 and
http://www.w3.org/Bugs/Public/show_bug.cgi?id=6777 and
http://www.w3.org/Bugs/Public/show_bug.cgi?id=7059
Ian Hickson wrote:
I considered requiring Ogg Theora support in the spec, since we do have
three implementations that are willing to implement it, but it wouldn't
help get us true interoperabiliy, since the people who are willing to
implement it are willing to do so regardless of the spec, and
--- On Tue, 6/30/09, Mikko Rantalainen mikko.rantalai...@peda.net wrote:
(2) Specify {Theora or H.264} as the baseline. That way all
vendors that
have displayed any interest for video could
implement the spec.
Authors would be required to provide the video in both
formats to be
sure
On Jun 30, 2009, at 15:11, Olli Pettay wrote:
I wonder what (and where) are the reasons to use XHTML namespace
also with HTML elements.
The behavior causes few issues like
https://bugzilla.mozilla.org/show_bug.cgi?id=501312 and
A variant of this corner case already existed with attribute
On Tue, Jun 30, 2009 at 12:50 AM, Ian Hicksoni...@hixie.ch wrote:
Finally, what is Google/YouTube's official position on this?
As I understand it, based on other posts to this mailing list in recent
days: Google ships both H.264 and Theora support in Chrome; YouTube only
supports H.264, and
On Tue, Jun 30, 2009 at 5:31 AM, Mikko
Rantalainenmikko.rantalai...@peda.net wrote:
[snip]
Patent licensing issues aside, H.264 would be better baseline codec than
Theora.
I don't know that I necessarily agree there.
H.264 achieves better efficiency (quality/bitrate) than Theora, but it
does
On Tue, Jun 30, 2009 at 10:43 AM, Gregory Maxwellgmaxw...@gmail.com wrote:
No one has bothered
porting Theora to the TMS320c64x DSP embedded in the OMAP3 CPU used in
this handheld device is an obviously surmountable problem.
Unless I'm mistaken about the DSP in question, that work is in fact
Ian Hickson wrote:
On Tue, 30 Jun 2009, Matthew Gregan wrote:
Is there any reason why PCM in a Wave container has been removed from
HTML 5 as a baseline for audio?
Having removed everything else in these sections, I figured there wasn't
that much value in requiring PCM-in-Wave support.
Gregory Maxwell wrote:
PCM in wav is useless for many applications: you're not going to do
streaming music with it, for example.
It would work fine for sound effects...
The world in which web browsers live is quite a bit bigger than internet
and ordinary consumer use combined...
Assuming bandwidth will increase with technological advance, it seems
unreasonable that the bandwidth issue is allowed to block fallback solutions
such as PCM within a specification that is expected to live longer than
three years from now.
IMHO,
Chris
On Tue, Jun 30, 2009 at 12:50 AM, Ian Hicksoni...@hixie.ch wrote:
I considered requiring Ogg Theora support in the spec, since we do have
three implementations that are willing to implement it, but it wouldn't
help get us true interoperabiliy, since the people who are willing to
implement it
Peter Kasting wrote:
As a contributor to multiple browsers, I think it's important to note
the distinctions between cases like Acid3 (where IIRC all tests were
supposed to test specs that had been published with no dispute for 5
years), much of HTML5 (where items not yet implemented generally
2009/6/30 Peter Kasting pkast...@google.com
On Jun 30, 2009 2:17 AM, Sam Kuper sam.ku...@uclmail.net wrote:
2009/6/30 Silvia Pfeiffer silviapfeiff...@gmail.com
On Tue, Jun 30, 2009 at 2:50 PM, Ian Hicksoni...@hixie.ch wrote:
I considered requiring Og...
Right. Waiting for all
On Wed, Jul 1, 2009 at 7:15 AM, Peter Kasting pkast...@google.com wrote:
As a contributor to multiple browsers, I think it's important to note the
distinctions between cases like Acid3 (where IIRC all tests were supposed to
test specs that had been published with no dispute for 5 years), much
* I didn't say 5 years from Rec status
* Acid3 was meant to be an illustrative example of a case where the test
itself was not intentionally introducing new behavior or attempting to force
consensus on unwilling vendors, not a perfect analogy to something
PK
On Jun 30, 2009 12:36 PM, Sam Kuper
Peter Kasting wrote:
There is no other reason to put a codec in the spec -- the primary
reason to spec a behavior (to document vendor consensus) does not
apply. Some vendors agreed, and some objected violently is not
consensus.
But Most people agreed, and one or two vendors objected
2009/6/30 Peter Kasting pkast...@google.com:
* I didn't say 5 years from Rec status
No, you didn't; I was being generous. You said something much less
meaningful: published with no dispute for 5 years. No dispute from
whom? Browser developers and web developers disputed aspects of
several of the
2009/6/30 Sam Kuper sam.ku...@uclmail.net:
[2] In July 2005, Chris Wilson, the Internet Explorer Platform [...]
That should have been:
[2] http://en.wikipedia.org/wiki/Acid2#Microsoft.27s_response
Jeff McAdams wrote:
Peter Kasting wrote:
There is no other reason to put a codec in the spec -- the primary
reason to spec a behavior (to document vendor consensus) does not
apply. Some vendors agreed, and some objected violently is not
consensus.
But Most people agreed, and one or two
On Tue, Jun 30, 2009 at 3:15 PM, Peter Kastingpkast...@google.com wrote:
This is not a case where vendor
consensus is currently possible (despite the apparently naive beliefs on the
part of some who think the vendors are merely ignorant and need education on
the benefits of codec x or y), and
On Tue, 30 Jun 2009 06:50:31 +0200, Ian Hickson i...@hixie.ch wrote:
video itself supports multiple sources, so there's no need for
JavaScript to do this. But it does mean we end up with exactly the
situation we're in now, with different implementations supporting
different codecs and the spec
On Tue, 30 Jun 2009, Olli Pettay wrote:
I wonder what (and where) are the reasons to use XHTML namespace also with
HTML elements.
The main reason was simplification.
* Consistency for scripts in HTML and XHTML. For example, a script can
now use createElementNS() in both without having
On Jun 30, 2009, at 1:59 AM, Silvia Pfeiffer wrote:
- has off-the-shelf decoder hardware chips available
decoder hardware for video means that there are software libraries
available that use specific hardware in given chips to optimise
decoding. It is not a matter of hardware vendors to
On Thu, 4 Jun 2009, Drew Wilson wrote:
I'd like to suggest that we allow sending ports that are not entangled
(i.e. ports that have been closed)
Done.
--
Ian Hickson U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/ U+263A/, _.. \ _\
On Thu, 4 Jun 2009, Kartikaya Gupta wrote:
I have a question about section 3.7.2. Under step 5, it says that it is
considered a reentrant invocation of parser if the document.write()
method was called from script executing inline. Does this include
document.write() calls invoked from user
On Tue, Jun 30, 2009 at 10:41 PM, Maciej Stachowiakm...@apple.com wrote:
I looked into this question with the help of some experts on video decoding
and embedded hardware. H.264 decoders are available in the form of ASICs,
and many high volume devices use ASICs rather than general-purpose
On Thu, 4 Jun 2009, Andrew W. Hagen wrote:
I have a copy of the Constitution of the United States on my web site.
That is a legal text. It also qualifies as legalese, a derogatory
term. If I were to change it to HTML 5, the current spec encourages me
to place the entire Constitution in
On Fri, 5 Jun 2009, Andrew W. Hagen wrote:
That was interesting about the history of the cite element.
The import of my proposed change is that it would make the cite element
much more useful than it would be than if it were limited to titles.
For example, take a page listing numerous
On Tue, 9 Jun 2009, Kristof Zelechovski wrote:
* Let a COLOR element have a value DOM property in the DOM that returns a
color.
.value already does so.
* Let a NUMBER element has a value DOM property that returns a number.
.valueAsNumber already does so.
Actually, the latter use case is
On Thu, 4 Jun 2009, Michael Nordman wrote:
What appcache (if any) should the resulting iframes be associated with? I
think per the spec, the answer is none. Is that the correct answer?
html manifest='myManifestFile'
body
script language=JavaScript
function frameContents1()
{
var
On Jun 30, 2009, at 9:13 PM, Gregory Maxwell wrote:
On Tue, Jun 30, 2009 at 10:41 PM, Maciej Stachowiakm...@apple.com
wrote:
I looked into this question with the help of some experts on video
decoding
and embedded hardware. H.264 decoders are available in the form of
ASICs,
and many high
On Fri, 5 Jun 2009, Julian Reschke wrote:
Ian Hickson wrote:
On Fri, 5 Jun 2009, Julian Reschke wrote:
Ian Hickson wrote:
Michael(tm) Smith wrote:
It seems pretty clear that there isn't anything else to refer
to for the date/time parsing rules -- but to me at least,
Ian Hickson wrote:
If this was a totally new syntax, I would agree.
But as something based on ISO8601 (and thereby also RFC 3339) it appears
to be a bad idea to make it less compatible just for that reason.
We've seriously simplified the ISO-8601 syntax in many more ways than just
this.
On Wed, Jul 1, 2009 at 12:35 AM, Maciej Stachowiakm...@apple.com wrote:
For the mobile phones where I have specific knowledge regarding their
components, I am not at liberty to disclose that information.
Unsurprising but unfortunate.
There are other people trying to feel out the implications
40 matches
Mail list logo
