Re: [whatwg] Codecs for audio and video
In recent news, Google may be about to open source On2 codecs, perhaps creating a route out of the HTML 5 video codec deadlock: http://www.theregister.co.uk/2009/08/06/google_vp6_open_source/
Re: [whatwg] Dates BCE
2009/7/30 Elliotte Rusty Harold elh...@ibiblio.org I note in http://www.whatwg.org/specs/web-apps/current-work/#valid-date-string that Dates before the year zero can't be represented as a datetime in this version of HTML. This seems a serious omission. Why can we represent the birth of Nero but not the birth of Julius Caesar? Are there plans to rectify it? I sure hope there are! Historians and classicists are increasingly publishing to the web, and being unable to mark up years BCE in HTML 5 would hinder this. That said, marking up a year, say 1992 AD, (as opposed to a specific day within a specific month within a specific year, e.g. 3rd September 1992) also seems to be hard or impossible in HTML 5... unless I've misread the spec.
Re: [whatwg] Dates BCE
2009/7/30 Bruce Lawson bru...@opera.com On Thu, 30 Jul 2009 15:05:10 +0100, Sam Kuper sam.ku...@uclmail.net wrote: I sure hope there are! Historians and classicists are increasingly publishing to the web, and being unable to mark up years BCE in HTML 5 would hinder this. That said, marking up a year, say 1992 AD, (as opposed to a specific day within a specific month within a specific year, e.g. 3rd September 1992) also seems to be hard or impossible in HTML 5... unless I've misread the spec. Orthodoxy has it that there is no use case for marking up an ancient date or fuzzy date like June 2009 using time. I disagree, and this has been discussed many times before. Do you have any concrete use cases or examples of how marking these up using time would be necessary? Not for BCE; I'm not working on that period at the moment, but excepting that, here are a couple of good examples with ranges: http://www.darwinproject.ac.uk/darwinletters/calendar/entry-10762.html http://www.darwinproject.ac.uk/darwinletters/calendar/entry-295.html http://www.darwinproject.ac.uk/darwinletters/calendar/entry-6611f.html Now, either there should be markup available for ranges, or it should at least be possible to specify components of a date independently of each other, and to imply (at least for humans) a range spanning these different date elements as appropriate. Exactly the same sort of situation could easily arise when marking up BCE materials, although in this case one would likely have even less information (if any) about which day of the year was being used, so it would be even more crucial to be able to mark up dates in a way that just specifies the year but leaves the month and day undefined. Flexibility is crucial here and since it need not come at the expense of parseability, it should be provided for. Best, Sam
Re: [whatwg] Dates BCE
2009/7/30 Tab Atkins Jr. jackalm...@gmail.com On Thu, Jul 30, 2009 at 10:34 AM, Sam Kupersam.ku...@uclmail.net wrote: Not for BCE; I'm not working on that period at the moment, but excepting that, here are a couple of good examples with ranges: http://www.darwinproject.ac.uk/darwinletters/calendar/entry-10762.html http://www.darwinproject.ac.uk/darwinletters/calendar/entry-295.html http://www.darwinproject.ac.uk/darwinletters/calendar/entry-6611f.html Now, either there should be markup available for ranges, or it should at least be possible to specify components of a date independently of each other, and to imply (at least for humans) a range spanning these different date elements as appropriate. Now, here's the million-dollar question: Why do you need time or something like it for these dates? You seem to have them marked up quite fine as it is. 1) Machine readability. 2) Consistency across websites that mark up dates.
Re: [whatwg] Dates BCE
2009/7/30 Tab Atkins Jr. jackalm...@gmail.com On Thu, Jul 30, 2009 at 11:12 AM, Sam Kupersam.ku...@uclmail.net wrote: 2009/7/30 Tab Atkins Jr. jackalm...@gmail.com On Thu, Jul 30, 2009 at 10:34 AM, Sam Kupersam.ku...@uclmail.net wrote: Not for BCE; I'm not working on that period at the moment, but excepting that, here are a couple of good examples with ranges: http://www.darwinproject.ac.uk/darwinletters/calendar/entry-10762.html http://www.darwinproject.ac.uk/darwinletters/calendar/entry-295.html http://www.darwinproject.ac.uk/darwinletters/calendar/entry-6611f.html Now, either there should be markup available for ranges, or it should at least be possible to specify components of a date independently of each other, and to imply (at least for humans) a range spanning these different date elements as appropriate. Now, here's the million-dollar question: Why do you need time or something like it for these dates? You seem to have them marked up quite fine as it is. 1) Machine readability. This begs the question. Why do you need machine readability for the dates in the Darwin journals? More specifically, why do you need machine readability in a standardized fashion currently expected to be used primarily for adding dates to calendars? For projects like the Darwin Correspondence Project, machine readable HTML markup of dates might well simplify the various rather fragile and complex custom date search mechanisms these projects have historically tended to use, allowing users to access materials more easily and making APIs to such online corpora easier to create. 2) Consistency across websites that mark up dates. What form of consistency? Date format consistency? This varies by use-case, region, and language. Machine-format consistency? You then have to answer why such consistency is important - what does it let you *do*? Suppose you wanted to mash up the Darwin correspondence data with a SIMILE Timeline[1], it would help if the correspondence data was (more) machine-readable. Now suppose you also wanted to add some diary entries[1] to the same timeline, so that you could instantly visualise when letters were written vs when diary entries were written. This would be much easier if both the two websites from which you were sourcing your data used a consistent, machine-readable date format. [1]http://www.simile-widgets.org/timeline/ [2]http://darwin-online.org.uk/content/frameset?itemID=F1925viewtype=textpageseq=1
Re: [whatwg] Dates BCE
2009/7/30 David Singer sin...@apple.com: Quite. We've had this debate before and Ian decided that it might be confusing to apply a dating system to days when that dating system was not in effect on those days, I think. If by confusing you mean sufficiently confusing that it needs to be avoided, then the proleptic Gregorian calendar would not be suitable for use in HTML5. Yet it has been adopted for HTML5. So either the confusion is tolerable or the reasoning has been inconsistent. I assume the former, and actually I think that using the proleptic Gregorian calendar *decreases* confusion by creating a mutually-agreed neutral vocabulary for dates that other calendars can be translated from and to, thus reducing the total number of mappings needed between calendars if all calendars are to be mappable to each other. Against that, one has to realize that the label of the day before X is well-defined for the day before the introduction of the Gregorian calendar, and iteratively going back to year 1, year 0, year -1, and so on. And it would be nice to have a standard way of labelling dates in historical documents so that they are comparable; I am reminded of Kilngaman's book in which he has parallel chapters for China and Rome in the first century CE http://www.amazon.com/First-Century-Emporers-Gods-Everyman/dp/0785822569/ref=sr_1_1?ie=UTF8s=booksqid=1248970679sr=8-1. It would be nice if one could determine that two events in separate documents were essentially contemporary, despite being labeled in the original text in different ways. It's not simply nice, it's a necessity for accurate automated processing of historical or other non-Gregorian temporal information. However, whether the spec. formally blesses using time like this may not be very relevant, as it can be done textually with or without the blessing. By textually, do you mean manually? If so, many exciting possibilities in online historical research would be rendered quite impractical (as they are currently) simply because of the massive amount of time that would be required to manually process each date conversion. This is a *very* real problem.
Re: [whatwg] Dates BCE
2009/7/30 Tab Atkins Jr. jackalm...@gmail.com: On Thu, Jul 30, 2009 at 11:56 AM, Mike Shavermike.sha...@gmail.com wrote: Can the historical-timeline community perhaps work with a microformat for such things, so that we can standardize on the basis of experience using the technology in the field, rather than on speculative uses? I'd actually advise against trying to push this to the Microformats group. They're about marking up visible data in such a way that a machine can parse it. This discussion so far seems to be about taking a visible date (or date range, possibly fuzzy) in an arbitrary calendar, and marking it up with an invisible date in the proleptic gregorian calendar, with support for ranges and fuzziness. Spot on.
Re: [whatwg] Dates BCE
2009/7/30 Aryeh Gregor simetrical+...@gmail.com time certainly wouldn't help here -- this application doesn't need a way to say this text string denotes a particular time, but rather this event happened at this particular time. The latter presupposes the former. That's why being able to mark historical dates up with time or date or year (etc, as appropriate) would be so useful, and indeed appropriate in HTML5.
Re: [whatwg] Chipset support is a good argument
2009/7/5 Ian Hickson i...@hixie.ch On Sun, 5 Jul 2009, Eric Flores wrote: [...] On the other side, I'm firmly convinced that some vested interest could lobby and even pay the chipmakers for having them not adding support to Ogg. This is a free market, isn't it? As you say, it's a free market. If people want Theora chips, then it's likely that they will become available. For that to happen there has to be some demand for Theora support, though, which the spec's can't generate. I think that if Theora support is recommended in HTML5, this *will* generate demand, since content producers and (most) browser vendors alike will take advantage of it. Chips may well, in that scenario, become available. Sam
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
2009/6/30 Peter Kasting pkast...@google.com On Jun 30, 2009 2:17 AM, Sam Kuper sam.ku...@uclmail.net wrote: 2009/6/30 Silvia Pfeiffer silviapfeiff...@gmail.com On Tue, Jun 30, 2009 at 2:50 PM, Ian Hicksoni...@hixie.ch wrote: I considered requiring Og... Right. Waiting for all vendors to support the specified codec would be like waiting for them all to be Acid3 compliant. Better to specify how browsers should behave (especially if it's how most of them will behave), and let the stragglers pick up the slack in their own time under consumer pressure. Sam 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-principle from various vendors) and this issue, where vendors have publicly refused to implement particular cases. [...] I'd question, based on the following statements, whether your memory of Acid3 is correct: Controversially, [Acid3] includes several elements from the CSS2 recommendation that were later removed in CSS2.1 but reintroduced in W3C CSS3 working drafts that have not made it to candidate recommendations yet.[1] The following standards are tested by Acid3: [...] * SMIL 2.1 (subtests 75-76) [...][1] SMIL 2.1 became a W3C Recommendation in December 2005.[2] [1] http://en.wikipedia.org/wiki/Acid3 [2] http://en.wikipedia.org/wiki/Synchronized_Multimedia_Integration_Language#SMIL_2.1 So, there is some precedent for the W3C to publish specs/tests, expecting browser vendors to catch up with them further down the line. Sam
Re: [whatwg] Codecs for audio and video
2009/6/30 Peter Kasting pkast...@google.com: * I didn't say 5 years from Rec status No, you didn't; I was being generous. You said something much less meaningful: published with no dispute for 5 years. No dispute from whom? Browser developers and web developers disputed aspects of several of the standards under test in Acid3 during the 5 years preceding its publication. Witness the divergence between different browsers' implementations of ECMAScript and CSS; witness different approaches taken by web developers to handle them; witness disputed elements like q and cite. * Acid3 was meant to be an illustrative example of a case where the test itself was not intentionally introducing new behavior Well, it was intentionally testing whether a browser implemented specs accurately. In some cases, browsers had to have new behaviour added in order to do so. or attempting to force consensus on unwilling vendors [...] I quote Wikipedia again: Microsoft, developers of the Internet Explorer browser, said that Acid3 does not map to the goal of Internet Explorer 8 and that IE8 would improve only some of the standards being tested by Acid3.[20] IE8 scores 20/100 and has some problems with rendering the Acid3 test page.[1] Similarly with Acid2 (released April 13 2005): In July 2005, Chris Wilson, the Internet Explorer Platform Architect, stated that passing Acid2 was not a priority for Internet Explorer 7, describing the test as a wish list of features rather than a true test of standards compliance.[2] The point of specs is to define how things *should* be. They are, by nature, idealistic. Implementation may not be perfect or universal. This has to be acknowledged, but it does not justify dropping an item from the spec that several major browser vendors are willing to support and that other would probably be willing to support once fears of submarine patents have dissipated. Sam [1] http://en.wikipedia.org/wiki/Acid3 [2] In July 2005, Chris Wilson, the Internet Explorer Platform Architect, stated that passing Acid2 was not a priority for Internet Explorer 7, describing the test as a wish list of features rather than a true test of standards compliance.
Re: [whatwg] Codecs for audio and video
2009/6/30 Sam Kuper sam.ku...@uclmail.net: [2] In July 2005, Chris Wilson, the Internet Explorer Platform [...] That should have been: [2] http://en.wikipedia.org/wiki/Acid2#Microsoft.27s_response
Re: [whatwg] ---
2008/11/5 Martin McEvoy [EMAIL PROTECTED]: [...] closely followed by the Mosaic Web Browser[1] a direct descendant of Firefox Ancestor, surely?
[whatwg] Citing multiple blockquote elements in HTML5
Dear all, In the current HTML5 draft, section 4.4.6 The blockquote elementhttp://www.w3.org/html/wg/html5/#the-blockquote states, If a blockquote element is preceded or followed by a single paragraph that contains a single cite element and that is itself not preceded or followed by another blockquote element and does not itself have a q element descendant, then, the title of the work given by that cite element gives the source of the quotation contained in the blockquote element. Now, I think that being able to use a cite element to give the source of a blockquote element's contents is a useful step forward for HTML, and I approve of its being introduced in HTML5. However, I'm not sure that the criteria for determining the cite element are the best ones, as it looks to me as though they will rule out a common literary usage of block quotes: using a number of block quotes from different authors to preface a work or part of a work. Such usage is evident, for instance, in this bookhttp://darwin-online.org.uk/content/frameset?itemID=F381viewtype=imagepageseq=9 . If I understand section 4.4.6 correctly, then having: blockquoteFirst quote./blockquote pFirst quote's author: citeFirst quote's reference/cite./p blockquoteSecond quote./blockquote pSecond quote's author: citeSecond quote's reference/cite./p blockquoteThird quote./blockquote pThird quote's author: citeThird quote's reference/cite./p in an HTML5 file will mean that only the third of these cite elements will be used as the reference for its preceding blockquote, because it is the only one of the three in a single paragraph that is itself not preceded or followed by another blockquote element and does not itself have a q element descendant. This strikes me as problematic. How, in a case like this, should one mark up the block quotes and their references, without introducing extraneous elements? NB. If I'm not the first to ask this question, I'd be grateful for a link to where it has been discussed previously. As a preliminary suggestion, perhaps it would be better if the spec said, If a blockquote element is followed by a single paragraph that contains a single cite element and that is itself not preceded or followed by another blockquote element and does not itself have a q element descendant, then, the title of the work given by that cite element gives the source of the quotation contained in the blockquote element. It is, after all, normal in English and a number of other widely-used languages (though I cannot vouch for all languages - perhaps others will have some useful insights here) for the citation to be given following a block quote, where one is given. Many thanks, Sam
Re: [whatwg] Citing multiple blockquote elements in HTML5
Dear all, For some reason, the email set-up I used to send my previous message (Gmail via Chrome) inserted whitespace:pre values into each paragraph's style attribute. Depending upon your email client, this may have rendered my email difficult/unpleasant to read. My apologies for this. Quoted below is a (hopefully) plaintext copy of the body of that email. Sam 2008/9/10 Sam Kuper: Dear all, In the current HTML5 draft, section 4.4.6 The blockquote element (http://www.w3.org/html/wg/html5/#the-blockquote) states, If a blockquote element is preceded or followed by a single paragraph that contains a single cite element and that is itself not preceded or followed by another blockquote element and does not itself have a q element descendant, then, the title of the work given by that cite element gives the source of the quotation contained in the blockquote element. Now, I think that being able to use a cite element to give the source of a blockquote element's contents is a useful step forward for HTML, and I approve of its being introduced in HTML5. However, I'm not sure that the criteria for determining the cite element are the best ones, as it looks to me as though they will rule out a common literary usage of block quotes: using a number of block quotes from different authors to preface a work or part of a work. Such usage is evident, for instance, in this book (http://darwin-online.org.uk/content/frameset?itemID=F381viewtype=imagepageseq=9). If I understand section 4.4.6 correctly, then having: blockquoteFirst quote./blockquote pFirst quote's author: citeFirst quote's reference/cite./p blockquoteSecond quote./blockquote pSecond quote's author: citeSecond quote's reference/cite./p blockquoteThird quote./blockquote pThird quote's author: citeThird quote's reference/cite./p in an HTML5 file will mean that only the third of these cite elements will be used as the reference for its preceding blockquote, because it is the only one of the three in a single paragraph that is itself not preceded or followed by another blockquote element and does not itself have a q element descendant. This strikes me as problematic. How, in a case like this, should one mark up the block quotes and their references, without introducing extraneous elements? NB. If I'm not the first to ask this question, I'd be grateful for a link to where it has been discussed previously. As a preliminary suggestion, perhaps it would be better if the spec said, If a blockquote element is followed by a single paragraph that contains a single cite element and that is itself not preceded or followed by another blockquote element and does not itself have a q element descendant, then, the title of the work given by that cite element gives the source of the quotation contained in the blockquote element. It is, after all, normal in English and a number of other widely-used languages (though I cannot vouch for all languages - perhaps others will have some useful insights here) for the citation to be given following a block quote, where one is given. Many thanks, Sam
Re: [whatwg] [HTML5] Accessibility question
On 16/03/2008, Ian Hickson [EMAIL PROTECTED] wrote: Could you elaborate more on what problem you are trying to solve? I wonder if this http://www.alistapart.com/articles/fir/ is one of the problems to do with content for sighted/unsighted viewers it might be nice to have a good solution to in HTML5?
Re: [whatwg] [HTML5] Accessibility question
On 17/03/2008, Ian Hickson [EMAIL PROTECTED] wrote: That seems more like a CSS issue. I now think so too. Simon Pieters made the point that CSS3 can solve this problem.
Re: [whatwg] Proposal for a link attribute to replace a href
On 28/02/2008, Robert O'Rourke [EMAIL PROTECTED] wrote: I don't understand why buttons should not be allowed an href, obviously when the button or input is to submit a form (ie. explicitly having type=submit as an attribute) it shouldn't be allowed but I'd find it useful where I've had to style a collection of links and inputs to be similar, for example the steps for a checkout process: One has to be careful here. You're absolutely right that form submission buttons need to be treated specially, as otherwise users' web accelerator software will start checking out their shopping carts, etc. I'm concerned that in all the exuberance to make more elements links, various basic problems like this might get overlooked. Sam
Re: [whatwg] whatwg Digest, Vol 33, Issue 90 (Krzysztof ?elechowski)
Dear Chris, From the Oxford English Dictionary online (accessed today): initialism: The use of initials; a significative group of initial letters. Now spec. a group of initial letters used as an abbreviation for a name or expression, each letter or part being pronounced separately (contrasted with ACRONYM). acronym: A word formed from the initial letters of other words. Hence as v. trans., to convert into an acronym (chiefly pass. and as pa. pple.). This is concordant with my understanding is that in English at least, acronyms and initialisms are abbreviations, but not vice versa. That is, the set of English acronyms is a subset of the set of English abbreviations. Whether or not this is true of Polish, it should not be asserted of English. A multilingual standard should accommodate the existing practice and terminology of the languages to which it applies; it should not attempt to re-define those practices or terminologies. (If you are not convinced, then consider this analogy: should the HTML spec have insisted that all languages marked up in HTML be written from left to right, using characters called 'a', 'b', 'c', etc?) Sorry to make the point so strongly. All best, Sam On 12/12/2007, Krzysztof Żelechowski [EMAIL PROTECTED] wrote: You may be right but this theory seems to be very specific to the English language. For example, you silently assume that URL is an abbreviation; acronyms like ZUS or PKO are not considered to be abbreviations in Polish. The term initialism is stranger to HTML so this distinction is essential for academic linguistic papers only; Aspell does not even recognise this word. However, the distinction between an acronym and an abbreviation is clear and intuitive. Chris Dnia 12-12-2007, Śr o godzinie 22:29 +, Sam Kuper pisze: Dear Chris, Your classifications are incorrect, as is your rule of thumb. The following excerpt should clarify things: Initialism[s] originally described abbreviations formed from initials, without reference to pronunciation. ... [Some people] differentiate between the [terms 'acronym' and 'initialism'], restricting 'acronym' to pronounceable words formed from the initial letters of the constituent words, and using 'initialism' ... for abbreviations pronounced as the names of the individual letters. In the latter usage, examples of proper acronyms would be 'NATO' ... and 'radar' ..., while examples of initialisms would include 'FBI' ... and 'HTML'... There is no agreement on what to call abbreviations whose pronunciation involves the combination of letter names and words, such as 'JPEG' ... and 'MS-DOS' ... . These abbreviations are sometimes described as acronym–initialism hybrids... There is also no agreement as to what to call abbreviations that some pronounce as letters and others pronounce as a word. For example, the internet term 'URL' can be pronounced as individual letters or as a single word. (from http://en.wikipedia.org/wiki/Acronym_and_initialism) Best regards, Sam -- Forwarded message -- From: Krzysztof Żelechowski [EMAIL PROTECTED] To: Ian Hickson [EMAIL PROTECTED] Date: Wed, 12 Dec 2007 22:20:56 +0100 Subject: Re: [whatwg] whatwg Digest, Vol 33, Issue 90 Dnia 12-12-2007, Śr o godzinie 08:59 +, Ian Hickson pisze: Most people don't mark up abbreviations or acronyms at all, they only mark them up at all to give the expansions generally. And for this purpose, it doesn't really matter which is which (not to mention that different people disagree on which is which -- I say ess quere ell and ewe are ell, others say sequel and earl). SQL and URL are acronyms because they are built from initial letters. Mr., Dr., Ch. and cf. are abbreviations. i.e. and etc. are... er... abbreviations? Except for these cases, I hardly see any valid disagreement. A rule of thumb is that abbreviations are usually written with a dot. Chris
