Re: [whatwg] Annotating structured data that HTML has no semantics for

On Tue, 9 Jun 2009, Jonas Sicking wrote: > >> > >> Some of the improvement suggestions that I have heard that sounds > >> interesting, though possibly for the next version of microdata. > >> > >> * Support for specifying a machine-readable value, such as for dates, > >> colors, numbers, etc. > >

Re: [whatwg] request for clarification: aside, figure

On Tue, 9 Jun 2009, Bruce Lawson wrote: > On Tue, 09 Jun 2009 01:57:15 +0100, Ian Hickson wrote: > > On Sun, 10 May 2009, Bruce Lawson wrote: > > > > > > I don't think the spec is clear enough defining these two elements > > > from an author's perspective. [...] > > > What is the difference betw

Re: [whatwg] Two feature-suggestions for HTML5 (forms)

(Trimmed cc list to reduce cross-posting.) On Mon, 8 Jun 2009, Asser Nilsson wrote: > > There are two things in HTML5-forms that are often made with "Active" > Technology like JavaScript, that would be very cool, if HTML5 could do > these things without Scripting: > > 1. I've seen this at the

Re: [whatwg] Question on (new) header and hgroup

On Sat, 6 Jun 2009, Kornel Lesinski wrote: > On Sat, 06 Jun 2009 04:00:28 +0100, Ian Hickson wrote: > > > I don't think will be used often enough to justify calling it > > just . > > Ok, but what about ? (, ?) > > The purpose of is to imply that is a subtitle. That's quite an > indirection.

Re: [whatwg] attributes

On Tue, 9 Jun 2009, Jonas Sicking wrote: > On Thu, Jun 4, 2009 at 6:24 PM, Ian Hickson wrote: > > On Tue, 28 Apr 2009, Jacob Rask wrote: > >> > >> has there ever been any discussion on including an attribute to the > >> code element, specify the programming language in the markup? If so, > >> wha

Re: [whatwg] Codecs for and

--- On Wed, 7/1/09, Gregory Maxwell wrote: > > It was suggested here that MJPEG be added as a > baseline.  I considered > this as an option for Wikipedia video support some years > ago before we > had the Theora in Java playback working. I quickly > determined that it > was unworkable for ove

Re: [whatwg] Codecs for and

On Tue, Jun 30, 2009 at 4:50 PM, Ian Hickson wrote: > - has off-the-shelf decoder hardware chips available > I don't think this should be a requirement. As written, this requirement primarily means "need to be able to build devices today that play back with minimal power consumption". Obviousl

Re: [whatwg] Codecs for and

On Wed, Jul 1, 2009 at 4:06 PM, Jonas Sicking wrote: [snip] > I think the first bullet has been demonstrated to be false. The > relative quality between theora and h.264 is still being debated, but > the arguments are over a few percent here or there. Arguments that > theora is simply not good enou

Re: [whatwg] Codecs for and

On Wed, Jul 1, 2009 at 12:14 PM, Anne van Kesteren wrote: > On Wed, 01 Jul 2009 18:29:17 +0200, Peter Kasting > wrote: >> >> On Wed, Jul 1, 2009 at 2:41 AM, Anne van Kesteren >> wrote: >>> >>> The "vendor consensus" line of argument seems like a very dangerous >>> slippery slope. It would mean th

Re: [whatwg] Codecs for and

On Wed, 01 Jul 2009 18:29:17 +0200, Peter Kasting wrote: On Wed, Jul 1, 2009 at 2:41 AM, Anne van Kesteren wrote: The "vendor consensus" line of argument seems like a very dangerous slippery slope. It would mean that whenever a vendor refuses to implement something it has to be taken out o

Re: [whatwg] Codecs for and

I don't believe Chris was speaking in any official capacity for YT or Google any more than I am. I think it is inappropriate to conflate his opinion of the matter with Google's. I have not seen _any_ official statement from Google regarding codec quality. As an aside, I think taking the availabl

Re: [whatwg] the cite element

If "more then titles" means other uses of the CITE tag, as evidenced in [1], they do not form any pattern. They look more like random errors. If "more then titles" means "title and something else", I do not see much harm in such syntax. Chris [1] .

Re: [whatwg] the cite element

On Wed, Jul 1, 2009 at 6:04 PM, Erik Vorhes wrote: > On Wed, Jul 1, 2009 at 11:49 AM, Kristof > Zelechovski wrote: >> I can imagine two reasons the CITE element cannot be defined as "citing >> whom": >>  1. Existing tools may assume it contains a title. > > Existing tools (which I would assume foll

Re: [whatwg] Codecs for and

Ian Fette (イアンフェッティ) wrote: 2009/7/1 Jeff McAdams mailto:je...@iglou.com>> timeless wrote: I also don't like how people enjoy a good run of corporation hunting. First you go after Microsoft. Then you go after Google. Then you after Apple. Many (mos

Re: [whatwg] the cite element

On Wed, Jul 1, 2009 at 11:49 AM, Kristof Zelechovski wrote: > I can imagine two reasons the CITE element cannot be defined as "citing > whom": >  1. Existing tools may assume it contains a title. Existing tools (which I would assume follow the HTML 4.01 spec) would be mistaken in their implementat

Re: [whatwg] Codecs for and

On Wed, 01 Jul 2009 18:29:17 +0200, Peter Kasting wrote: On Wed, Jul 1, 2009 at 2:41 AM, Anne van Kesteren wrote: On Tue, 30 Jun 2009 21:39:05 +0200, 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

Re: [whatwg] Codecs for and

2009/7/1 Ian Fette (イアンフェッティ) : > all of Google to suddenly release all of its information that has legitimate > business reasons for staying company-internal. We've made what statements we > can make, and I don't honestly think it reasonable to expect more. I think it is reasonable to expect Go

Re: [whatwg] the cite element

I can imagine two reasons the CITE element cannot be defined as "citing whom": 1. Existing tools may assume it contains a title. 2. A title is conventionally typeset in italic because it is an expression that is a proper name although it does not really look like one, whereas the author does no

Re: [whatwg] the cite element

On Wed, 01 Jul 2009 17:36:34 +0100, Kristof Zelechovski wrote: The CITE tag does not mean "I am a citation". It is as confusing for novices as can be but the specification cannot do anything about it because it is already established. It means "Citing what?" and it does not mean "Citing

Re: [whatwg] the cite element

The CITE tag does not mean "I am a citation". It is as confusing for novices as can be but the specification cannot do anything about it because it is already established. It means "Citing what?" and it does not mean "Citing whom?". A book title is the obvious answer to this question. As I unde

Re: [whatwg] Codecs for and

2009/7/1 Jeff McAdams > timeless wrote: > >> I also don't like how people enjoy a good run of corporation hunting. >> > > First you go after Microsoft. Then you go after Google. Then you after >> Apple. >> > > Many (most?) corporations choose to operate under a heavy veil of secrecy > (*particul

Re: [whatwg] Codecs for and

On Wed, Jul 1, 2009 at 2:41 AM, Anne van Kesteren wrote: > On Tue, 30 Jun 2009 21:39:05 +0200, 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

Re: [whatwg] Codecs for and

Clearly allowing a third-party codec to reprogram a hardware DSP would be one of the silliest things to do. (If it turns out that I cannot answer to something important from now on, assume I am banned for using an offensive word.) Chris

Re: [whatwg] Codecs for and

That would have to be done by each browser not the spec. Some vendors would include their own plugins that were safe so they may not feel the need to sandbox them (even though they should). On Wed, Jul 1, 2009 at 8:12 AM, Kristof Zelechovski wrote: > Regarding the fear of Trojan codecs: it would

Re: [whatwg] AppCache and javascript url question?

On Tue, Jun 30, 2009 at 9:29 PM, Ian Hickson wrote: > 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 frameContent

Re: [whatwg] the cite element

On Tue, Jun 30, 2009 at 11:19 PM, Ian Hickson wrote: > I don't understand why it would be more useful. Having an element for the > typographic purpose of marking up titles seems more useful than an element > for the purpose of indicating what is a citation. Why is it more useful? If is exclusive

Re: [whatwg] Localised numbers

K?i?tof ?elechovski writes: > The rules for parsing floating point number values [2.4.4.5] apply to > the input element in number state as well. Do those rules actually limit UI? The say how a user agent must parse a value attribute provided in the source. And they constrain what a UA may send

Re: [whatwg] ambiguity in definition

On Mon, 29 Jun 2009 14:54:48 +0100, Thomas Broyer wrote: perhaps the language should be tightened? ie ""A header element typically contains the section's heading (an h1–h6 element or an hgroup element), but this is not mandatory and may contain content such as navigation, a search form b

Re: [whatwg] Codecs for and

On Wed, Jul 1, 2009 at 4:12 PM, Kristof Zelechovski wrote: > Regarding the fear of Trojan codecs: it would help if third-party plug-ins > for codecs could be sandboxed so that they cannot have access to anything > they do not have to access in order to do their job, and only via an API > provided b

Re: [whatwg] Codecs for and

Regarding the fear of Trojan codecs: it would help if third-party plug-ins for codecs could be sandboxed so that they cannot have access to anything they do not have to access in order to do their job, and only via an API provided by the host. IMHO, Chris

[whatwg] Localised numbers

The rules for parsing floating point number values [2.4.4.5] apply to the input element in number state as well. This is not good. People who fill forms tend to input numbers with the keypad --- that is what the keypad is for --- and the keypad keyboard layout follows the local conventions and no

Re: [whatwg] Codecs for and

2009/7/1 timeless : > I have no idea about purchasing costs (again, we work on software), > but I think people will accept that the cost for an FPGA is orders of > magnitudes higher than and not commercially viable in contrast to > ASICs. I think we can all agree that a FPGA is being used only for

Re: [whatwg] Codecs for and

timeless wrote: I also don't like how people enjoy a good run of corporation hunting. First you go after Microsoft. Then you go after Google. Then you after Apple. Many (most?) corporations choose to operate under a heavy veil of secrecy (*particularly* Apple). That choice is also a choice

Re: [whatwg] Codecs for and

Only one point to touch on here, and perhaps its a bit off-topic, and if it is, I apologize. Maciej Stachowiak wrote: I believe the wide availability of H.264 hardware is in part because H.264 was developed through an open standards process that included the relevant stakeholders. Saying th

Re: [whatwg] Codecs for and

2009/7/1 Maik Merten > Maciej Stachowiak wrote: > > So I don't > > think it's reasonable to assume that hardware implementations will just > > appear. > > The dire need of ASIC "hardwired-style" implementations for Theora > hasn't been demonstrated either. H.264 has much higher computational > com

Re: [whatwg] Codecs for and

On Wed, Jul 1, 2009 at 1:58 PM, King InuYasha wrote: > We had a vendor majority, right? Who is we, and which vendor do you represent? Please don't use royal we.

Re: [whatwg] Codecs for and

On Wed, Jul 1, 2009 at 8:54 AM, Gregory Maxwell wrote: > There are mass market products that do this. Specifically palm-pre is > OMAP3, the N810 is OMAP2. These have conventional DSPs with publicly > available toolchains. Hrm, I worked on the n810 (nowhere near DSP, thankfully, although I did get

Re: [whatwg] Codecs for and

On Wed, Jul 1, 2009 at 4:41 AM, Anne van Kesteren wrote: > On Tue, 30 Jun 2009 21:39:05 +0200, 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

Re: [whatwg] Codecs for and

On Tue, 30 Jun 2009 21:39:05 +0200, 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". The "vendor consensu

Re: [whatwg] Codecs for and

[Maciej, sorry for sending this to you twice] 2009/7/1 Maciej Stachowiak : > It's not clear if a similar virtuous cycle would repeat for other codecs. > Might happen, but it took a lot of industry coordination around H.264 to > build the ecosystem around it that exists today. So I don't think it's

Re: [whatwg] Codecs for and

2009/6/30 Robert O'Callahan : > If we are going to allow individual vendors to exert veto power, at least > lets make them accountable. Let's require them to make public statements > with justifications instead of passing secret notes to Hixie. +1 Particularly when (e.g. Google's YouTube claim)

Re: [whatwg] Codecs for and

Maciej Stachowiak wrote: > So I don't > think it's reasonable to assume that hardware implementations will just > appear. The dire need of ASIC "hardwired-style" implementations for Theora hasn't been demonstrated either. H.264 has much higher computational complexity, it may be interesting to con

Re: [whatwg] Codecs for and

On Wed, Jul 1, 2009 at 2:12 AM, Maciej Stachowiak wrote: > > I'm not sure I have much useful information to add to this discussion, but > I wanted to address a few points: > > On Jun 30, 2009, at 10:54 PM, Gregory Maxwell wrote: > > >> Then please don't characterize it as "it won't work" when the

Re: [whatwg] Codecs for and

I'm not sure I have much useful information to add to this discussion, but I wanted to address a few points: On Jun 30, 2009, at 10:54 PM, Gregory Maxwell wrote: Then please don't characterize it as "it won't work" when the situation is "it would work, but would probably have unacceptable