Re: [whatwg] Codecs for audio and video
On Wed, Jul 1, 2009 at 2:35 PM, Maciej Stachowiakm...@apple.com 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 high up-front costs so they need volume to be cost effective. It's a chicken and egg problem then. Once there is volume in Theora (speak: uptake), the vendors will adapt their hardware to support it. But we will not adopt Theora because we require hardware support. I think requiring hardware support is therefore an unfair requirement - when H.264 was being standardised, no hardware support (i.e. ASICs) were available either. As far as I know, there are currently no commercially available ASICs for Ogg Theora video decoding. (Searching Google for Theora ASIC finds some claims that technical aspects of the Theora codec would make it hard to implement in ASIC form and/or difficult to run on popular DSPs, but I do not have the technical expertise to evaluate the merit of these claims.) .. Silvia implied that mass-market products just have general-purpose hardware that could easily be used to decode a variety of codecs rather than true hardware support for specific codecs, and to the best of my knowledge, that is not the case. I have no deep knowledge in this space, but have spoken to people who have and was quoting their basic statement. Even if there is no vendor right now who produces an ASIC for Theora, the components of the Theora codec are not fundamentally different to the components of other DCT based codecs. Therefore, AISCs that were built for other DCT based codecs may well be adaptable by the ASIC vendor to support Theora. Even if this would need to be done by the chip vendor - it's not a fundamental obstacle. I think the real issue around the hardware support requirement is *not* whether there are existing ASICs for Theora and whether they are commercially available and used. These can be developed where necessary - and indeed such new challenges are a good thing for the market. Instead, the real issue is what you mentioned above: the statement that technical aspects of the Theora codec make it hard to implement in ASIC form and/or difficult to run on popular DSPs. If this was the case, it would indeed pose a strong obstacle to the use of Theora. However, unless I see a detailed technical description on why it is impossible or very hard/difficult to implement ASICs for Theora, I believe this is just another urban myth. I'd be very happy for anyone knowledgeable to prove or bust this myth and clarify the situation. Regards, Silvia.
Re: [whatwg] Codecs for audio and video
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 battery life on the hardware we are shipping. I don't believe I ever said it won't work or made any claim along those lines. All I said was that some products use dedicated hardware for H.264, and no such hardware is available for Theora. There was an implication that this claim was a smokescreen because really it was all just programmable hardware; that is not the case. The battery life question is a serious and important one, but its categorically different one than can it work at all. (In particular because many people wouldn't consider the battery life implications of a rarely used fallback format to be especially relevant to their own development). If Theora is only going to be a rarely used fallback format, then it doesn't seem like a great candidate to mandate in external specs. Indeed, others have argued that inclusion in the HTML5 spec would drive far greater popularity. If it's going to be widely used, it needs power-efficient implementations on mobile. Battery life is a very important consideration to mobile devices. To give an example of a concrete data point, the iPhone 3G S can deliver 10 hours of video playback on a full charge. It's not very persuasive to say that availability of hardware implementations is unimportant because, even though battery life will be considerably worse, video will still more or less function. On Jun 30, 2009, at 11:03 PM, Silvia Pfeiffer wrote: It's a chicken and egg problem then. Once there is volume in Theora (speak: uptake), the vendors will adapt their hardware to support it. But we will not adopt Theora because we require hardware support. I think requiring hardware support is therefore an unfair requirement - when H.264 was being standardised, no hardware support (i.e. ASICs) were available either. 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. In addition, H.264 was included in standards such as Blu-Ray, HD-DVD and 3GPP. This created built-in demand for hardware implementations. I believe hardware implementations were available before H.264 saw significant deployment for Web content. 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 reasonable to assume that hardware implementations will just appear. Regards, Maciej
Re: [whatwg] Codecs for audio and video
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 consider if using less-rigid DSPs (or even the already available DSP extensions of widespread mobile processors) gives good enough results for Theora. Given there's less to compute one may very well live with a lower energy efficiency per operation. Maik
Re: [whatwg] Codecs for audio and video
2009/6/30 Robert O'Callahan rob...@ocallahan.org: 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) the reason for the claim is then firmly proven not to be factually based. - d.
Re: [whatwg] Codecs for audio and video
[Maciej, sorry for sending this to you twice] 2009/7/1 Maciej Stachowiak m...@apple.com: 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 reasonable to assume that hardware implementations will just appear. Even without any apparent industry coordination around Vorbis, many portable music players (not the ones produced by Apple, admittedly) can play Ogg audio files. Note that many of them do *not* say this on the tin: e.g. my cheap noname MP4 player is advertised as being able to play only MP3 and WMA audio and AMV video files, but it also supports Ogg/Vorbis just fine. When Vorbis files reached a small critical mass a few years ago many hardware manufacturers without much fanfare started supporting it. Having a free implementation with a very liberal licence may have helped. This player is also a good example of how some DSPs can be used for different tasks: its DSP is exactly the same that has been used only for MP3 decoding in earlier players, but in these new models it decodes the video part of AMV (a modified MJPEG). Obviously I'm not suggesting that this particular model can also decode Theora (the main CPU is an 8-bit Z80 at 60 MHz max). Anyway I think that the spec can be made more informative for web authors by pointing out (in a non-normative section) the fact that there's one and only one format that can be played by all browser that support the video element: Ogg/Theora+Vorbis. Safari can play Theora if the Xiph Quicktime component is installed, while Firefox cannot play H.264. -- Lino Mastrodomenico
Re: [whatwg] Codecs for audio and video
On Tue, 30 Jun 2009 21:39:05 +0200, Peter Kasting pkast...@google.com 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 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 of the specification. I.e. giving a single vendor veto power over the documentation of the Web Platform. Not good at all in my opinion. -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] Codecs for audio and video
On Wed, Jul 1, 2009 at 4:41 AM, Anne van Kesteren ann...@opera.com wrote: On Tue, 30 Jun 2009 21:39:05 +0200, Peter Kasting pkast...@google.com 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 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 of the specification. I.e. giving a single vendor veto power over the documentation of the Web Platform. Not good at all in my opinion. -- Anne van Kesteren http://annevankesteren.nl/ We had a vendor majority, right? Of the four major vendors of browsers participating (Mozilla, Google, Opera, Apple), three have committed to including the codecs in one form or another for usage with the video and audio tags (Mozilla, Opera, Google). I agree it would have been better would a full consensus, but the fact is that all of these companies look towards their goals. Mozilla wants to move towards its vision of the Open Web (which I personally agree with), Opera has said some time back they plan to support it, Google is fence-sitting by including ffmpeg due to their ideal of being universal (and doing a good job of it too), and Apple's vision of an Apple-centric world means they use the MPEG4 stuff, because it fits more with their current offerings of iPod, iPhone, Macs, and the Apple TV without exerting more effort to comply. We would never get everyone to agree. However, Apple didn't shut the Theora stuff out entirely. They left it open through QuickTime, which is fine. If we went through and put the Theora and Vorbis recommendation through, and the browsers implement it, then pressure would eventually make Apple somehow concede and do something about the situation. At the very least, add the XiphQT codec pack to the listing of codecs when QuickTime errors out and opens Safari to a list of codecs. If we push through it with the codecs, I don't think there will be too much of a problem at all.
Re: [whatwg] Codecs for audio and video
On Wed, Jul 1, 2009 at 8:54 AM, Gregory Maxwellgmaxw...@gmail.com 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 to hear people crying). The technical existence of a generic DSP does not a useful implementation make. So, can you please give me the url for a useful DSP codec I can install on my n810 (it runs Maemo 4.1 Diablo, and no, asking me to install your own custom platform just to play video isn't OK) ? Hypothetically, just getting the stuff the vendor offers working in a shape which is shippable is depressingly hard. I really hate the double and triple standards espoused here. For lack of a better reference, however i trust that you're capable of finding hundreds (as a google search [battery life claims] did for me), http://www.techradar.com/news/computing-components/lawsuits-planned-over-laptop-battery-life-claims-612614 and adding the word 'cell' leads to: http://reviews.cnet.com/cell-phone-battery-life-charts I have nothing to do with the 5800 and don't have any idea what it is, but it was on the first page of results, so: http://www.wirelessinfo.com/content/Nokia-5800-Cell-Phone-Review/Battery-Life.htm Summarily, it said that getting 75% of the claimed battery life was respectable (not stellar). I think it's safe to say that consumers really do care about battery life (and at least with laptops are starting to complain violently). 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. Let's consider a different position. If you heard that a hardware vendor had a product which could decode a video format called QuperVide and they provided an opensource implementation, but they had a patent on another (better) technique for decoding QuperVide which they used in their ASIC. Would you support them in their bid to mandate QuperVide as a Required codec for a Standard (e.g. HTML5:Video)? I'd hope that most people would say that it's unfair to mandate such a standard which gave the QuperVide vendor a sales advantage in its market (hardware ASICs). Would you say: oh, that's ok, we can standardize on this, and then 5 years from now we'll have an open source hardware implementation that's as good? You could do that, but for the intervening years anyone who sells hardware and wants to support QuperVide will have three choices: 1. Pay QuperVide's fees for its ASICs and get tolerable battery life. 2. Pay for an extra DSP or a faster CPU+BUS and pay a penalty in terms of battery life. 3. Pay engineers to try to develop a competing hardware ASIC which doesn't run afoul of QuperVide's vendor's patent for its hardware ASIC. 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. And yes, you've already hunted Nokia, a couple of times, but I can't remember when in the sequence it was. I guess that it's sort of open season for corporation hunting and maybe Nokia is currently slightly out of season. Actually, it sounds like Congress has opened up a session there, so maybe you're just politely waiting in line. Mozilla has sketches for adding pluggable support for its video module too, but seems to be reticent about working on it as doing that would distract from their open web position. Sadly, Apple gets no points for being Pluggable on Desktop (QT has an open API). If I were to complain about Mozilla not being open, they'd claim oh, we're open source, anyone can contribute. That isn't true btw, if I were to write a pluggable module for video, their benevolent dictator has every right to veto it. And sure, I can maintain my fork, but just like Linus with Linux, they have every right to change their APIs regularly to make my life hell. Note: Microsoft, like Apple has Pluggable APIs, and again, like Apple, people don't care, and just say ooh, they're a bad company, they won't play with us. Microsoft, like Opera, like Apple, like every other company in the world is busy working on things. Often quitely (and yes, Mozilla does things quietly too). Opera has a policy (like Apple, like Microsoft, like Nokia, ...) of not announcing things until they announce them. Microsoft presumably has a roadmap and freeze features out at a certain point in time, most companies do. Sometimes groups have to rewrite or reorganize large portions of their code, and can't fix certain things until then. Gecko, View Manager, Table Rewrites, HTML5 parser, lots of these things happen with Mozilla. Heck, the ACID tests traditionally are such that the first release of mozilla after the release of an ACID test can't possibly pass the ACID test, because of the schedule. And while people
Re: [whatwg] Codecs for audio and video
On Wed, Jul 1, 2009 at 1:58 PM, King InuYashangomp...@gmail.com 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 audio and video
2009/7/1 Maik Merten maikmer...@googlemail.com 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 consider if using less-rigid DSPs (or even the already available DSP extensions of widespread mobile processors) gives good enough results for Theora. Given there's less to compute one may very well live with a lower energy efficiency per operation. For information only (I haven't investigated these in any depth), note the references to Theora in the following pages: http://wiki.openmoko.org/wiki/Snapshot_review#Media_Player http://wiki.openmoko.org/wiki/Wish_List_-_Hardware:FPGA#AT91CAP9S500A_.28ARM9_.2B_FPGA-port.29
Re: [whatwg] Codecs for audio and video
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 that ITU-T includes relevant stakeholders, implying that it includes *all* relevant stakeholders is a joke. End-users are relevant stakeholders in standards development, and ITU-T excludes participation from end-users. -- Jeff McAdams je...@iglou.com
Re: [whatwg] Codecs for audio and video
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 to open themselves up these criticisms. These corporations have to take the good with the bad. If they chose to operate with greater transparency, then they would almost certainly come into less criticism. I have exactly zero sympathy for Apple, MS, and Google, for the criticisms they have received. They choose to operate in secrecy, then they choose to be the target of these criticisms. Suck it up. -- Jeff McAdams je...@iglou.com
Re: [whatwg] Codecs for audio and video
2009/7/1 timeless timel...@gmail.com: 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 development and debugging of a Theora hardware decoder (http://www.students.ic.unicamp.br/~ra031198/theora_hardware/), while the final design will be burned to an ASIC if/when there's commercial demand for it. Sadly, Apple gets no points for being Pluggable on Desktop (QT has an open API). If I were to complain about Mozilla not being open, they'd claim oh, we're open source, anyone can contribute. That isn't true btw, if I were to write a pluggable module for video, their benevolent dictator has every right to veto it. I fear that wide support for pluggable codecs for the video element may end up putting end users in a codec hell. If there's only one or at most two supported video formats/codecs, then it's obviously responsibility of the websites to correctly encode their videos. But if Firefox starts supporting any codec that happens to be installed on the system, many small and medium websites will probably start using videos in a lot of different formats (that works on the computer of the web developer) and the burden of finding and installing the correct codecs for each site will shift on the end user. Not good for interoperability, non-x86 platforms, and a good opportunity for spreading malware using trojan codecs. So please browser vendors, don't do this. The only exception is Safari, since it wouldn't otherwise support Theora. -- Lino Mastrodomenico
[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 not the HTML specification (of course). For example, it is not possible to get a full stop using the keypad, as required by step 12, as the keypad has a comma instead. I suggest that a comma should be treated as a decimal point by step 12. I also suggest that true MINUS SIGN should be treated the same as HYPHEN MINUS by step 8. This applies to the rules for parsing integers [2.4.4.2] also, and the use case is pasting existing content. Otherwise, existing content containing negative numbers would have to be worse than it could be in order that it could be pasted into HTML forms. Of course, these extensions should apply to input elements [4.10.4.1.13] only. Since they are pure extensions, they should not introduce any incompatibilities with what is already deployed. Cheers, Chris
Re: [whatwg] Codecs for audio and video
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
Re: [whatwg] Codecs for audio and video
On Wed, Jul 1, 2009 at 4:12 PM, Kristof Zelechovskigiecr...@stegny.2a.pl 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 by the host. historically people who want to write codec support want to do it in DSP land on devices, and in DSP land on devices you can kill devices very dead (among other interesting thing). Sandboxing that way is basically impossible. Now if you rule out DSP, you still have all the other problems (general proliferation of codecs, finding them, keeping them sandboxed, bandwidth to network/video). I'm not saying I don't look forward to this, they're just notes.
Re: [whatwg] ambiguity in header definition
On Mon, 29 Jun 2009 14:54:48 +0100, Thomas Broyer t.bro...@gmail.com 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 blah blah The fact that it is phrased as typically contains ... but can also contain makes it clear (for me) that it might contain a section's heading but this is not enforced (otherwise, it wouldn't say typically) my beef is with the words can also contain, which suggest that it can contain other stuff in addition to h1..h6, hgroup (which it can) but it's ambiguous as to whether it must contain h1..h6, hgroup as a minimum. (We're getting asked this a lot in html5doctor) -- Hang loose and stay groovy, Bruce Lawson Web Evangelist www.opera.com (work) www.brucelawson.co.uk (personal)
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 back to the server. But surely a UA can pick any UI they want for this -- including a text box where the user types a comma, and a decimal point displays as a comma? Smylers
Re: [whatwg] the cite element
On Tue, Jun 30, 2009 at 11:19 PM, Ian Hicksoni...@hixie.ch 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 cite is exclusively for titles, it shouldn't be called cite. In addition to the semantic difference between a title and a citation, limiting cite to titles potentially raises confusion between this element and the cite attribute (for blockquote and q), as the latter is limited to URLs. Yes, elements and attributes are different things. But in one context the concept cite is limited only to titles (and forbids URLs); in another context cite is limited only to URLs (and forbids titles). While it makes some sense, I suppose, to limit the cite attribute to URLs, it makes absolutely no sense to limit the cite element only to titles. If it's so pressing for there to be an element allowed in the body to mark up titles, why not create a new element for that purpose or allow for a cite-specific attribute to note that designation? I understand HTML5's attempts to provide semantic value to such elements as i, b, and small. To at the same time remove semantic value at the same time is completely asinine. Note that HTML5 now has a more detailed way of marking up citations, using the Bibtex vocabulary. I think this removes the need for using the cite element in the manner you describe. Since this is supposed to be the case, why shouldn't HTML5 just ditch cite altogether? (Aside from backward compatibility, which is beside the point of the question.) Erik Vorhes
Re: [whatwg] AppCache and javascript url question?
On Tue, Jun 30, 2009 at 9:29 PM, Ian Hickson i...@hixie.ch 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?
html manifest='myManifestFile'
body
script language=JavaScript
function frameContents1()
{
var doc = frame1.document;
doc.open();
doc.write('img src=image.png');
doc.close();
return;
}
function frameContents2()
{
return hello;
}
/script
iframe name=frame1 src=javascript:parent.frameContents1()
iframe name=frame2 src=javascript:parent.frameContents2()
/body
/html
If there's no manifest=, there's no application cache selected, as far
as I can tell.
Thats what it looks like to me too in the current draft. Wondering if thats
the right behavior though?
Generally when loading a frame, the appcache from which the doc resource was
loaded gets selected (augmented by an explicit manifest attribute that can
make something 'foreign').
In this case, the src is a script embedded in a page that is appcached, so
in a transitory sense the doc resource was loaded from an appcache, but that
cache does not get selected.
Feels like maybe image.png should load from myManifestFile in the sample?
Re: [whatwg] Codecs for audio and video
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 giecr...@stegny.2a.plwrote: 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 -- - Adam Shannon ( http://ashannon.us )
Re: [whatwg] Codecs for audio and video
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 audio and video
On Wed, Jul 1, 2009 at 2:41 AM, Anne van Kesteren ann...@opera.com wrote: On Tue, 30 Jun 2009 21:39:05 +0200, Peter Kasting pkast...@google.com 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 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 of the specification. I.e. giving a single vendor veto power over the documentation of the Web Platform. Not good at all in my opinion. I am merely echoing Hixie; from his original email in this thread: At the end of the day, the browser vendors have a very effective absolute veto on anything in the browser specs, You mean they have the power to derail a spec? They have the power to not implement the spec, turning the spec from a useful description of implementations into a work of fiction. That's something I would have considered before the advent of Mozilla Firefox. Mozilla also has the power of veto here. For example, if we required that the browsers implement H.264, and Mozilla did not, then the spec would be just as equally fictional as it would be if today we required Theora. My sole goal was to try and point out that the situation with codecs is not equivalent to past cases where vendors merely _hadn't implemented_ part of the spec; in this case vendors have _actively refused_ to implement support for various codecs (Apple with Theora and Mozilla(/Opera?) with H.264). PK
Re: [whatwg] Codecs for audio and video
2009/7/1 Jeff McAdams 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 (most?) corporations choose to operate under a heavy veil of secrecy (*particularly* Apple). That choice is also a choice to open themselves up these criticisms. These corporations have to take the good with the bad. If they chose to operate with greater transparency, then they would almost certainly come into less criticism. I have exactly zero sympathy for Apple, MS, and Google, for the criticisms they have received. They choose to operate in secrecy, then they choose to be the target of these criticisms. I'm not asking for sympathy, but I also don't think the characterization of Google as operating in secrecy is fair. There's a large number of people from the Google Chrome team participating on WHATWG and trying to contribute openly to these discussions. We're operating as an open source project, and trying to be as open as possible. At the same time, Google is a company whose purpose (as is any company) is to make money. YouTube is a separate team and not an open source project, I don't think it's reasonable to expect 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. Suck it up. -- Jeff McAdams je...@iglou.com
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 understand it, the CITE element can contain an anchor around the title, so you can have a URI as well. In particular, it could be an ISBN URN, although the browsers would have to support the ISBN namespace instead of saying Bad URL or something. HTH, Chris
Re: [whatwg] Codecs for audio and video
2009/7/1 Ian Fette (イアンフェッティ) ife...@google.com: 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 Google to address their statements of reasons being demonstrated false, however. They have notably failed to do so. Is Chris DiBona still reading? Oh sorry, I was completely wrong or you're wrong and here's why would go a long way to restore any trust in Google on this matter. - d.
Re: [whatwg] Codecs for audio and video
On Wed, 01 Jul 2009 18:29:17 +0200, Peter Kasting pkast...@google.com wrote: On Wed, Jul 1, 2009 at 2:41 AM, Anne van Kesteren ann...@opera.com wrote: On Tue, 30 Jun 2009 21:39:05 +0200, Peter Kasting pkast...@google.com 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 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 of the specification. I.e. giving a single vendor veto power over the documentation of the Web Platform. Not good at all in my opinion. I am merely echoing Hixie; from his original email in this thread: At the end of the day, the browser vendors have a very effective absolute veto on anything in the browser specs, You mean they have the power to derail a spec? They have the power to not implement the spec, turning the spec from a useful description of implementations into a work of fiction. That's something I would have considered before the advent of Mozilla Firefox. Mozilla also has the power of veto here. For example, if we required that the browsers implement H.264, and Mozilla did not, then the spec would be just as equally fictional as it would be if today we required Theora. My sole goal was to try and point out that the situation with codecs is not equivalent to past cases where vendors merely _hadn't implemented_ part of the spec; in this case vendors have _actively refused_ to implement support for various codecs (Apple with Theora and Mozilla(/Opera?) with H.264). PK That is correct, we consider H.264 to be incompatible with the open web platform due to its patent licensing. For the time being we will support Ogg Vorbis/Theora, which is the best option patent-wise and neck-in-neck with the competition in the quality-per-bit section (especially with recent encoder improvements). We would love to see it as the baseline for HTML5, but in the absense of that hope that the web community will push it hard enough so that it becomes the de-facto standard. -- Philip Jägenstedt Core Developer Opera Software
Re: [whatwg] the cite element
On Wed, Jul 1, 2009 at 11:49 AM, Kristof Zelechovskigiecr...@stegny.2a.pl 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 implementation of the cite element, then: CITE: Contains a citation or reference to other sources. (See http://www.w3.org/TR/html401/struct/text.html#h-9.2.1.) Moreover, in its sample usage, the HTML 4.01 spec uses cite for more than titles. While the HTML 4.01 specification is hardly perfect, I don't see the value in limiting the semantic potential of the cite element in HTML5. Erik Vorhes
Re: [whatwg] Codecs for audio and video
Ian Fette (イアンフェッティ) wrote: 2009/7/1 Jeff McAdams je...@iglou.com 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 (most?) corporations choose to operate under a heavy veil of secrecy (*particularly* Apple). That choice is also a choice to open themselves up these criticisms. These corporations have to take the good with the bad. If they chose to operate with greater transparency, then they would almost certainly come into less criticism. I have exactly zero sympathy for Apple, MS, and Google, for the criticisms they have received. They choose to operate in secrecy, then they choose to be the target of these criticisms. I'm not asking for sympathy, but I also don't think the characterization of Google as operating in secrecy is fair. There's a large number of people from the Google Chrome team participating on WHATWG and trying to contribute openly to these discussions. We're operating as an open source project, and trying to be as open as possible. At the same time, Google is a company whose purpose (as is any company) is to make money. YouTube is a separate team and not an open source project, I don't think it's reasonable to expect 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 don't disagree with you on any of that, really. I said you (Google, and others) have made a choice, corporately, on how open and transparent to be. Certainly Google is less secretive than many other corporations as a whole, and seemingly the Chrome team is considerably more open than most of the rest of Google, even. Nonetheless, as a whole, Google is a corporation and they have made a business decision to remain secretive on at least certain things. I do think that's a reasonable decision to make, and I might very well make the same decision in your shoes. My point was only to say that part and parcel of that decision is actions that tend to lead to criticisms of the company as a whole that Mozilla gets less of because they are more open. I won't exactly hold Mozilla up as a paragon of openness and transparency, but they are better than Google, just as Google is better than MS, and I would even argue that MS is better than Apple. I understand that you have said what you can say, and that's fantastic, and truthfully, I don't really expect more. That doesn't, however, mean that I'm going to cease criticisms of the stated positions As to the comparison between the Chrome and Youtube groups. I wish that the Youtube portion of the company were more engaged here as they clearly are a relevant party to the discussion. Again, I understand that as a business decision they may choose not to, but my understanding of that doesn't mean I'm not going to criticize them on it. -- Jeff McAdams je...@iglou.com
Re: [whatwg] the cite element
On Wed, Jul 1, 2009 at 6:04 PM, Erik Vorhese...@textivism.com wrote: On Wed, Jul 1, 2009 at 11:49 AM, Kristof Zelechovskigiecr...@stegny.2a.pl 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 implementation of the cite element, then: CITE: Contains a citation or reference to other sources. (See http://www.w3.org/TR/html401/struct/text.html#h-9.2.1.) Moreover, in its sample usage, the HTML 4.01 spec uses cite for more than titles. In practical usage it seems to be used for more than titles: http://philip.html5.org/data/cite.txt. (But I haven't tried working out what else it is used for, or how commonly it's used for titles.) -- Philip Taylor exc...@gmail.com
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] http://philip.html5.org/data/cite.txt.
Re: [whatwg] Codecs for audio and video
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 available recent public comparisons as definitive proof that Theora is (or is not!) comparable to H.264 is inappropriate (and goes further than the Theora developers have). Codec comparison is tricky and broad, and a definitive comparison (which I have not performed) would require a large variety of types/quality of input, compressed with many different option choices, and compared on both subjective and objective criteria. It also would include coverage of issues like how much buffer is needed to ensure continuous play, whether the quality can be dynamically degraded, storage space and CPU usage required on th encoding side, device support (current and projected), etc. Or, to simplify, you're oversimplifying in your declarations that one codec is as good as another. PK On Jul 1, 2009 9:55 AM, David Gerard dger...@gmail.com wrote: 2009/7/1 Ian Fette (イアンフェッティ) ife...@google.com: all of Google to suddenly release all of its information that has legitimate business reasons f... I think it is reasonable to expect Google to address their statements of reasons being demonstrated false, however. They have notably failed to do so. Is Chris DiBona still reading? Oh sorry, I was completely wrong or you're wrong and here's why would go a long way to restore any trust in Google on this matter. - d.
Re: [whatwg] Codecs for audio and video
On Wed, 01 Jul 2009 18:29:17 +0200, Peter Kasting pkast...@google.com wrote: On Wed, Jul 1, 2009 at 2:41 AM, Anne van Kesteren ann...@opera.com 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 of the specification. I.e. giving a single vendor veto power over the documentation of the Web Platform. Not good at all in my opinion. I am merely echoing Hixie; from his original email in this thread: At the end of the day, the browser vendors have a very effective absolute veto on anything in the browser specs, You mean they have the power to derail a spec? They have the power to not implement the spec, turning the spec from a useful description of implementations into a work of fiction. That's something I would have considered before the advent of Mozilla Firefox. Mozilla also has the power of veto here. For example, if we required that the browsers implement H.264, and Mozilla did not, then the spec would be just as equally fictional as it would be if today we required Theora. I disagree with the characterization Ian makes here as I believe being royalty free is very important for the formats we actively deploy to the Web and as such H.264 is not an option. My sole goal was to try and point out that the situation with codecs is not equivalent to past cases where vendors merely _hadn't implemented_ part of the spec; in this case vendors have _actively refused_ to implement support for various codecs (Apple with Theora and Mozilla(/Opera?) with H.264). Somehow I doubt that if e.g. Opera vetoed the video element it would actually be removed from the specification. And if it that were the case I would consider it to be very bad as I mentioned in my initial email in this thread. -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] Codecs for audio and video
On Wed, Jul 1, 2009 at 12:14 PM, Anne van Kesterenann...@opera.com wrote: On Wed, 01 Jul 2009 18:29:17 +0200, Peter Kasting pkast...@google.com wrote: On Wed, Jul 1, 2009 at 2:41 AM, Anne van Kesteren ann...@opera.com 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 of the specification. I.e. giving a single vendor veto power over the documentation of the Web Platform. Not good at all in my opinion. I am merely echoing Hixie; from his original email in this thread: At the end of the day, the browser vendors have a very effective absolute veto on anything in the browser specs, You mean they have the power to derail a spec? They have the power to not implement the spec, turning the spec from a useful description of implementations into a work of fiction. That's something I would have considered before the advent of Mozilla Firefox. Mozilla also has the power of veto here. For example, if we required that the browsers implement H.264, and Mozilla did not, then the spec would be just as equally fictional as it would be if today we required Theora. I disagree with the characterization Ian makes here as I believe being royalty free is very important for the formats we actively deploy to the Web and as such H.264 is not an option. Agreed. (Has anyone seriously proposed H.264 as a standard for the web?) The only arguments against Theora has been: * Too poor quality to be workable. * Risk of hidden/unknown patents. * Doesn't have hardware decoders. 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 enough seems based on poor or outdated information at this point. The second bullet I don't buy. First of all because that argument applies to absolutely everything we do. While video is particularly bad, there is simply always a risk of unknown software patents. Second, two big browser companies, with a third on the way, have at this point deemed it safe enough to risk implementing, so presumably they have done some amount of research into existing public patents. And that's on top of any company that has shipped Theora support in other contexts than browsers. Submarine patents are of course still a problem, but no more so for video than for other technologies as far as I can tell. The third applies to basically anything other than a very short list of codecs. As far as I know none of which are interesting for one reason or another. If that is a requirement then we might pack up and give up on making video a integral part of the open web. If a codec is going to have a chance to become popular enough to make hardware vendors get behind it, we need to take a first step. Hardware vendors are not going to. / Jonas
Re: [whatwg] Codecs for audio and video
On Wed, Jul 1, 2009 at 4:06 PM, Jonas Sickingjo...@sicking.cc 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 enough seems based on poor or outdated information at this point. I'm commenting here because I don't my own posts to be a source of misinformation. Depending on how and what you compare it's more than a few percent. It turns out that H.264 as used in many places on web is within spitting distance of the newer theora encoder due to encode side and decode side computational complexity and compatibility concerns and the selection of encoder software. For these same reasons there are many 'older' formats still in wide use which Theora clearly outperforms. The reality of what people are using puts the lie to broad claims that Theora is generally unusable because it under-performs the best available H.264 encoders in the lab. Different uses and organizations will have different requirements. Which is a good reason why HTML5 never required solutions to support only one codec. I do not doubt that there are uses which Theora is clearly inferior, because of the mixture of tolerance for licensing, computational load, intolerance for bitrate, requirements to operate at bits-per-pixel levels below the range that theora operates well at, etc. but it is an enormous jump to go from there are some uses to apply the claim to the general case, or to go from it's needs some more bitrate to achieve equivalent subjective quality to remarks that the bitrate inflation would endanger the Internet. It was this kind of over generalization that my commentary on Theora quality was targeting. (And it should be absolutely unsurprising that at the limit Theora does a somewhat worse off than H.264 in terms of quality/bits— it's an older less CPU hungry design which is, from 50,000 ft, almost a strict subset of H.264) At the same time, we have clearly defined cases where H.264/AAC is absolutely unacceptable. Not merely inferior, but completely unworkable due to the licensing issues. Different uses and organizations will have different requirements. Different codecs will be superior depending on your requirements. Which is a good reason why HTML5 never required solutions to support only one codec. But what I think is key is that the inclusion of Theora as a baseline should do nothing to inhibit the parties which are already invested in H.264, or whom have particular requirements which make it especially attractive, from continuing to offer and use it. The advantage of a baseline isn't necessarily that it's the best at anything in particular, but that it's workable and mostly universal. If when talking about a baseline you find yourself debating details over efficiency vs the state of the art you've completely missed the point. This is a field which is still undergoing rapid development. Even if codec-science were to see no improvements we will still see the state of the art advance tremendously in the next years simply due to increasing tolerance for CPU hungry techniques invented many years ago but still under-used. Anything we use today is going to look pretty weak compared to the options available 10 years from now. It's important for a codec to be efficient, but the purpose of the baseline is to be compatible. As such the relevant arguments should be largely limited to workability, of which efficiency is only one part. 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 over-the-web use because of the bitrate: we're talking about on the order of 10x the required bitrate over Theora before considering the audio (which would also be 10x the bitrate of Vorbis). At lest for general public web use I think the hard workability threshold could be fairly set as can a typical consumer broadband connection stream a 'web resolution' (i.e. somewhat sub-standard definition) in real time with decent quality. Even though thats a fairly vague criteria it seems clear that Ogg/Theora is well inside this limit while MJPEG is well outside it. Obviously different parties will have different demands. As far as I'm concerned spec might as well recommend a lossless codec as MJPEG— at least lossless has advantages for the set of applications which are completely insensitive to bitrate.
Re: [whatwg] Codecs for audio and video
On Tue, Jun 30, 2009 at 4:50 PM, Ian Hickson i...@hixie.ch 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. Obviously this is desirable, but why is it *necessary* for a baseline codec? Why would a vendor refuse to support a format because of high power consumption? It seems to me that using up power can't be worse than refusing to play the content at all. Does Apple block iPhone apps because they max out the CPU while they're running? It seems to me that this requirement forces HTML5 to merely document the codec preferences of device vendors. I think HTML5 could be proactive without being obnoxious, by recommending that Theora be supported wherever possible. That would encourage the consumption and production of Theora content, which would increase pressure on device vendors to support it well, which would increase the chances us all getting a codec with good universal support. Rob -- He was pierced for our transgressions, he was crushed for our iniquities; the punishment that brought us peace was upon him, and by his wounds we are healed. We all, like sheep, have gone astray, each of us has turned to his own way; and the LORD has laid on him the iniquity of us all. [Isaiah 53:5-6]
Re: [whatwg] Codecs for audio and video
--- On Wed, 7/1/09, Gregory Maxwell gmaxw...@gmail.com 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 over-the-web use because of the bitrate: we're talking about on the order of 10x the required bitrate over Theora before considering the audio (which would also be 10x the bitrate of Vorbis). Mozilla already supports Motion JPEG for the image tag (but not for video tag so far as I know). Basically, right now if you want a video file that will play on Quicktime, Media Player and Gstreamer's good set of plugins, the best option is Motion JPEG. I have mailed CDs with MJPEG video and PCM audio, and you can fit ~15 minutes of this in ~TV quality. For ~TV quality video and audio (240 x 320 pixels 30 fps) we are talking something like (If you have better numbers, point them out to me): 5 MBit/s MJPEG video with PCM audio 1-2 MBit/s MPEG-1 0.5 MBit/s Ogg Vorbis My suggestion (and I am not particularly serious) was: [(H.264 OR Theora) AND Motion JPEG] If you care about bandwidth more than licensing fees, you provide both H.264 and Theora. If you care more about licensing costs, you can provide Theora and Motion JPEG. I don't think that enshrining this in the spec is a very good idea however since it is a somewhat poor compromise. I can envision a future where a year from now Apple still has not added Theora support, but Mozilla has added gstreamer support, and suddenly Motion JPEG is the 'best' baseline codec, and the defacto video support is [(H.264 OR Theora) AND Motion JPEG] As far as I'm concerned spec might as well recommend a lossless codec as MJPEG— at least lossless has advantages for the set of applications which are completely insensitive to bitrate. What lossless codecs might be available without patent problems?
Re: [whatwg] code attributes
On Tue, 9 Jun 2009, Jonas Sicking wrote: On Thu, Jun 4, 2009 at 6:24 PM, Ian Hicksoni...@hixie.ch 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, what was the conclusion? I didn't find anything in the list archives. On Tue, 28 Apr 2009, Michael A. Puls II wrote: For example: code class=language-python/code This has been discussed before, but the basic answer is use the class attribute, at least for now. I would recommend, if this is a common-enough problem, that a group of people get together and define a common set of class attribute values for the code element, in the style of a Microformat. That way, we can build a common vocabulary that can then be made more formal in the next version of HTML. Is there a reason you encourage class values rather than microdata here? As I understood it, one of the things microdata was trying to avoid was using the class attribute since there was concern that it would collide with user values. I suppose you could use microdata if you wanted to, but it's not clear to me what the benefit would be. The goal here is typically to allow an element to be annotated (class attribute), not to allow a set of name-value pairs to be included alongside the markup (microdata). To do this right in microdata, you'd have to do something like: pre item=com.example.codecode itemprop=com.example.text meta itemprop=com.example.lang content=python ... my code ... /code/pre ...to end up with an item that has a com.example.text property with the code in question and a com.example.lang property with the language, whereas with a class attribute you just need to do something like: precode class=com.example.python ... my code ... /code/pre ...and define that the com.example.python class automatically implies that the content of the element in the code in question. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
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 i...@hixie.ch wrote: I don't think hgroup will be used often enough to justify calling it just h. Ok, but what about subheader? (subtitle, tagline?) The purpose of hgroup is to imply that hx is a subtitle. That's quite an indirection. An explicit element would be easier to understand: h1Dr. Strangelove/h1 subheaderOr: How I Learned to Stop Worrying and Love the Bombsubheader Also it could accept only phrasing content, so it would be easier for validators to catch when authors confuse it with header. It doesn't require changes to styling of hx, and can be given appropriate size with h1 + subheader CSS selector. That would have been another option (it wouldn't handle multiple-level subheadings well, but that's not a big deal), but I'm not really convinced it's enough of an improvement to change the way the spec is written. It also has poorer graceful degradation behaviour, IMHO. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
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 online-dictionary dict.leo.org: they made a JavaScript-function, that you can type the word to translate without the text-box marked an the characters get in there. So, you don't have to mark the right textbox before you type, but you can type, no matter to look, if the box is marked. I think it would be a very nice feature for HTML5-forms if this would work without Scripting... E.g. an option for text-fields, that everythins typed on this site is typed into this field (even if it is not highlighted). This isn't really done on enough sites to warrant built-in support, I don't think. 2. In search-boxes Javascript often is used for send every written character to the server and the server return search-suggestions as-you-type. If this is possible without Scripting only with HTML/CSS this would be very cool. This was possible in a previous incarnation of HTML5, but we removed support because it wasn't an especially popular feature, and it turns out to have some pretty subtle complications. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
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 i...@hixie.ch 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 between a figure that has no caption and an aside? Both seem to be connected in some way with the main content around it, but can be considered separate/ may be moved. [...] So If I have a magazine-style pullquote, is that a figure or an aside (or neither)? I have attempted to address this, but actually it turns out HTML5 already has examples of how to do pull quotes in the aside section. I didn't express myself clearly enough. This isn't a problem per se - it's the symptom of a problem. I note that there is an example of how to do pullquotes, but I can't deduce the logic that makes it obvious why one should use an aside rather than figure; the definition of each seems to allow either to be used thus. aside is defined as follows: # The aside element represents a section of a page that consists of # content that is tangentially related to the content around the aside # element, and which could be considered separate from that content. Such # sections are often represented as sidebars in printed typography. # # The element can also be used for typographical effects like pull quotes. figure is defined as follows: # The figure element represents some flow content, optionally with a # caption, that is self-contained and is typically referenced as a single # unit from the main flow of the document. # # The element can thus be used to annotate illustrations, diagrams, # photos, code listings, etc, that are referred to from the main content # of the document, but that could, without affecting the flow of the # document, be moved away from that primary content, e.g. to the side of # the page, to dedicated pages, or to an appendix. I don't really know how to make it clearer. At the end of the day it doesn't really matter if figure is used for pull quotes (it's not really that inappropriate, and if it were the only thing aside were to be used for, I'd have suggested dropping aside and leaving pull quotes to figure anyway). Pull quotes are kind of a middle ground which (notwithstanding the explicit statement in the spec saying that aside is more appropriate for pull quotes) could probably be argued either way. For example, in the middle of a fictional interview about markup, I might want to pull out a quote and citation: Do I write aside blockquoteAfter a sip of sweet sherry, I turn into Mr Last Week/blockquote citeIan Hickson/cite /aside Or figure blockquoteAfter a sip of sweet sherry, I turn into Mr Last Week/blockquote legendIan Hickson/legend /figure The former shows correct usage of aside vs figure, though the cite element usage is incorrect; the name should not be marked up. Again, I see no spec-derived reason why it should be aside rather than figure, other than it happens to be given an example of one rather than the other. Well it says The element can also be used for typographical effects like pull quotes, which is the main reason. :-) However, at the end of the day, the second markup snippet there isn't especially wrong either, it's just not the preferred way (which was more or less arbitrarily chosen in this case). (Given that marking up a name as a citation is common practice, and validator cannot distinguish between a name and a title of a work, should we widen the definition of cite to match the English language defintion 1. to quote or refer to (a passage, book, or author) ? A different discussion, apologies) cite in HTML5 is defined to mean title of work based on current usage, rather than having anything to do with actual citations. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
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. I expect we will add support for these based on demand, the same way we added time in the first place. Using dedicated elements for each data type seems like it will eventually bloat the language. Only if people don't show restraint in extending the language. For example what use would a color element or a number element do? It would allow conformance checkers to do type checking for the most commonly used types, and might allow (for number, anyway) localised formatting. If instead mashine readable values could be added using a generic method, such as a 'itemvalue' or 'propvalue' attribute, each microdata format can define how to interpret the values, be they numbers, dates, body parts, or chemical formulas. You can do that now with meta itemprop=... content= I even wonder it would allow replacing the time element with a standardized microformat, such as: Christmas is going down on span item=w3c.time itemvalue=12-25-2009The 25th day of Decemberspan! I don't really understand how that would be better than dedicated elements. The idea would be to reduce the size of the language. I.e. if a feature isn't heavily used, it might be better expressed as a microdata format. Well, you can do it today as: Christmas is going down on meta itemprop=w3c.time content=12-25-2009The 25th day of December! ...which (assuming that in your example you meant itemprop and not item, and assuming that you didn't mean the contents of the span to have any effect on the microdata processing model) would result in exactly the same name/value pair being generated into the relevant item. On the other hand, if you really meant item=, which I guess you might have meant... you could do that today as: Christmas is going down on span item=w3c.timemeta itemprop=value content=12-25-2009The 25th day of December/span! ...or some such (it doesn't matter what the textual contents of the span are in this example). However, this is going to result in much more painful structures, and you'd still need to link the item with a parent item (assuming there is one), as in: div item=com.example.somethingorother Christmas is going down on span itemprop=com.example.startdate item=w3c.timemeta itemprop=value content=12-25-2009The 25th day of December/span! /div ...which is really getting complicated compared to just: div item=com.example.somethingorother Christmas is going down on meta itemprop=w3c.time content=12-25-2009The 25th day of December! /div ...or (preferred today): div item=com.example.somethingorother Christmas is going down on time itemprop=w3c.time datetime=12-25-2009The 25th day of December/time! /div For example, why didn't you add elements for bibtex or vCard, but instead used microdata? New elements didn't really fit the use cases as well. Another reason is as a test of the microdata feature itself. Microdata is a sort of extension mechanism to HTML 5. In software development, it is common to test your extension system by developing parts of the product using the extension system. This way you can both keep the core code small, and you get a good test bed for your extension system. Indeed. You have already done this with the predefined vocabularies Right. and apparently the lack of ability to define a mashine readable value separate from the human readable one was not a problem. However it would seem that the same does not hold true for time. Right, that's why I adapted time into the microdata model. * Support for tabular data. This would be nice if we can find a way to do it that doesn't put undue burdens on simple implementations. (e.g. I would imagine that while a microdata implementation today can be a few hundred lines total, adding support for the table model could easily double that.) Quite possibly. In both these cases I'm perfectly happy to wait with adding more features to microdata for now and see if what we have is successful, before we start over engineering it to cover every imaginable case. Agreed. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
