On Wed, Jul 1, 2009 at 2:35 PM, Maciej Stachowiak wrote:
>
> However, it's quite clear from even a cursory investigation that H.264 ASICs
> are available from multiple vendors. This would not be the case if they
> weren't shipping in high volume products. As I'm sure you know, ASICs have
> fairly h
On Wed, Jul 1, 2009 at 12:35 AM, Maciej Stachowiak 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 for
themselves
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. This
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 t
On Jun 30, 2009, at 9:13 PM, Gregory Maxwell wrote:
On Tue, Jun 30, 2009 at 10:41 PM, Maciej Stachowiak
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
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?
>
>
>
>
> function frameContents1()
> {
> var doc = frame1.document;
> doc.open();
> doc
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 cas
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 numer
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
On Tue, Jun 30, 2009 at 10:41 PM, Maciej Stachowiak 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
> programmable DS
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 u
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 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 i
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 Tue, 30 Jun 2009 06:50:31 +0200, Ian Hickson wrote:
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 not having any powe
On Tue, Jun 30, 2009 at 3:15 PM, Peter Kasting 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 "just put it in
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
2009/6/30 Sam Kuper :
> [2] In July 2005, Chris Wilson, the Internet Explorer Platform [...]
That should have been:
[2] http://en.wikipedia.org/wiki/Acid2#Microsoft.27s_response
2009/6/30 Peter Kasting :
> * 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 standards unde
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 vio
* 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
On Wed, Jul 1, 2009 at 7:15 AM, 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
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".
PK
On Jun 30, 2009 12:31 PM, "Jeff McAdams" wrote:
Peter Kasting wrote: > > As a co
2009/6/30 Peter Kasting
> On Jun 30, 2009 2:17 AM, "Sam Kuper" wrote:
> > > 2009/6/30 Silvia Pfeiffer
> > > > On Tue, Jun 30, 2009 at 2:50 PM, Ian Hickson wrote: > >
> > > > I considered requiring Og...
> >
> > Right. Waiting for all vendors to support the specified codec would be like
> > wai
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 h
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 have agreement-on-principl
On Tue, Jun 30, 2009 at 12:50 AM, 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
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
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...
Browser-b
On Tue, Jun 30, 2009 at 12:08 PM, Dr. Markus Walther wrote:
> 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 ?
>>
>> Having removed everything else in these sections, I figured t
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 ?
>
> Having removed everything else in these sections, I figured there wasn't
> that much value in requiring PCM-in-Wave support
On Tue, Jun 30, 2009 at 10:43 AM, Gregory Maxwell 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
underway, and s
On Tue, Jun 30, 2009 at 5:31 AM, Mikko
Rantalainen 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 so with greater peak compu
On Tue, Jun 30, 2009 at 12:50 AM, Ian Hickson 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 is unlike
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 nod
--- On Tue, 6/30/09, Mikko Rantalainen wrote:
> (2) Specify {Theora or H.264} as the baseline. That way all
> vendors that
> have displayed any interest for could
> implement the spec.
> Authors would be required to provide the video in both
> formats to be
> sure that any spec compliant user
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
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
An
Ian Hickson wrote:
> on the situation regarding codecs for and 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 would
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.
2009/6/30 Silvia Pfeiffer
> On Tue, Jun 30, 2009 at 2:50 PM, 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 wi
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 Hickson wrote:
> I c
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
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
44 matches
Mail list logo
