[whatwg] Element-related feedback; attribution element
In http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2010-March/025549.html with a subject of "Element-related feedback", Ian Hixie quoted me and asked: >On Fri, 1 Jan 2010, Jim Jewett wrote: >> >> Evil Lawyer: So, when did you stop beating your wife? >> Defendant: Never! >> >> "Evil Lawyer" and "Defendant" aren't pronounced. Their meanings (and >> silence) are deduced from English conventions about punctuation. I >> would prefer a semantic tag. Hixie: > Why? What problem would a semantic tag solve? The default styling here > seems to not need any particular element; the above is perfectly > understandable as is as far as I can tell. For written output, yes, the convention works. Ideally, a screen reader should *not* read the attribution labels -- but it should use them to switch voices. >> I'm expecting [scripts] to do something like increase the font size or >> change the background for lines *I* have to memorize for *my* character >> [based on the semantic marked in the page identifying the character], or >> for cue lines that I have to recognize. > Are there any examples of this in the wild? Since this is technically > possible today, if it's a use case important enough that we should address > it, it should be easy enough to find examples of this. > I'm very reluctant to provide features for hypothetical problems that > don't stem from a real market need. (If we start solving such problems, we > would fast find ourselves on the path to feature bloat.) I haven't acted much since finding the internet. I have seen plenty of printed scripts in which this was done manually with a highlighter for rehearsals. I would expect today's equivalent to be done at time of printing, rather than by a helpful web site. So the need is there; the question is whether the need is too specialized (like the various poetry elements) ... if the only use were scripts, I would say that it was too specialized, but I would also use it for photo credits (the italicized captions), etc. Whether that then makes it too much of a catchall element -- maybe. >> > You're still not saying why you want this element. What would >> > be good for? What UI would it trigger? How would users or authors >> > benefit? (Per above, the UI would change voices in a screen reader, and could be used as a hook for user style sheets in scripts.) >> I would expect it to be used in License checkers that some organizations >> would deploy to ensure they aren't violating copyright. > Wouldn't the Work microdata vocabulary be a better solution to this > problem? Possibly. I find that more complicated, but the precision may be worth the complication. >> I would expect it to be used by some scrapers looking for stock photos. > I'm not sure what you mean. Wouldn't fingerprinting the photos be more > effective? I was thinking of scrapers acting on behalf of a consumer -- collecting a bunch of photos that you would be allowed to use. >> I would expect it to be used with custom CSS for some users, who are >> really looking for a model or photographer rather than an existing >> photograph. > I don't understand this case. Can you elaborate? Maybe an example of this > use in the wild would help. Some of the original examples from the wild were really credits -- they listed the photographer and the model. Plenty of model and photographer websites are largely devoted to finding each other; I assume that this is because photographers are looking to find (and then contact) models with a particular look, while models are looking to be photographed by photographers skilled in a certain style. Again, this seems like a fairly specialized need, but I've seen in on several sites, and it again gets met by an attribution or credits element. [On why should really be read as , but still called for historical reasons] > > > Why would it be wrong to have an element to style titles [for titles >> > of works]? >> Turning around your favorite question, what is the semantic value? > It provides a way to have appropriate default styling (italics, in the > visual medium) for a typographic feature that is widely used, while > allowing it to be easily restyled independent of other uses of italics. > This is the same benefit , , , etc, have. I think "title of work" is itself a fairly rare case. Normally, it is enough to just put it in quotes or italics. The times when you care that it is a title aren't really more common than the times that you care about attribution. -jJ
[whatwg] the cite element
Back around Oct 15, Ian summarized his objections to letting refer to the primary source of the information, rather than being an oddly named synoymy for . > On Thu, 8 Oct 2009, Jim Jewett wrote: >> > I hate to be so repetitive, but why is that beneficial? What is the >> > semantic value of this? >> You are welcome to say that argument by authority is so weak as to be >> invalid, but it still happens. >> Similarly, you are welcome to say that the academic habit of crediting >> other authors (sometimes but not always for specific publications) is >> silly, but it still happens. > What I'm saying is that doesn't help with either of the above. It's > quite possible to cite people in text/plain, without any markup. What does > _add_ that solves a real problem? ... >> -- particularly when restyled to not be visually apparent -- may >> be one of the few aspects of HTML which is more important to other >> classes of products. > Like what? Are there examples I could look at? That would be very helpful > in terms of finding purposes for other than just italics. I was thinking of business-rule-validators that ensure claims are "justified", or academic-influence measures that track citation graphs. That said, I suspect any tool that can assume cooperative authors will be custom, and could therefore be written to look for . So this use case may be about cruft rather than needs. >> > Is there as much semantic value in pointing to the primary source of a >> > statement as there is in knowing that the word "earth" refers to the >> > planet and not the dirt, for example? If so, what is that extra value? When quotes are attributed to Winston Churchill (or Oscar Wilde), that attribution is important -- generally more important than which specific speech it came from. >> >> dialogues and transcripts and credits and theatrical scripts are all >> >> arguably too fine-grained for a "citation", as opposed to a "label" >> >> or "attribution", but they are certainly real use cases where the >> >> attribution is important. >> > Why? This is not a rhetorical question, I'm trying to get to the use >> > case that means that there is an actual benefit to what you are asking >> > for. >> They are all cases where "who said it" or "who did it" is important -- >> sometimes far more important than what they actually said or did. > Sure, but doesn't help determine that. English helps determine > that. (Or whatever natural language is used.) What is doing? Evil Lawyer: So, when did you stop beating your wife? Defendant: Never! "Evil Lawyer" and "Defendant" aren't pronounced. Their meanings (and silence) are deduced from English conventions about punctuation. I would prefer a semantic tag. (I'll freely agree that isn't the perfect name, but it seems bizarre to forbid this related meaning, while allowing generic Title Of Work.) > and are both useful because of their default styling, as is > , when used for something that works with its default styling. But > that doesn't apply to people's names -- they are almost never made > italics. I actually have read scripts that used italics to indicate the speaker's name. I didn't find them the most readable of scripts, but I have seen them. >> >> I'll agree that it seems odd to have that many elements in >> >> such close proximity, but it is the closest match I can find in the >> >> spec, and it doesn't seem to be actually wrong. ?Searching for lines >> >> by a particular character is a fairly common use case. >> > Doesn't "find in page" handle that fine? >> Not in my opinion. > What are you expecting Web browsers to do that would make a better > solution? Has a browser vendor expressed an interest in some UI feature > for searching by citation name or some such? Initially, nothing except Javascript or CSS hacks. I'm expecting those to do something like increase the font size or change the background for lines *I* have to memorize for *my* character, or for cue lines that I have to recognize. >> Because we don't have an or even a element, and so >> is the closest match. > You're still not saying why you want this element. What would be > good for? What UI would it trigger? How would users or authors benefit? I wouldn't expect the main use to be in normal browsing. I would expect it to be used in License checkers that some organizations would deploy to ensure they aren't violating copyright. I would expect it to be used by some scrapers looking
Re: [whatwg] the cite element
On Mon, Oct 5, 2009 at 10:13 PM, Ian Hickson wrote: > On Tue, 22 Sep 2009, Jim Jewett wrote: >> On Tue, Sep 22, 2009 at 8:46 PM, Ian Hickson wrote: >> > On Wed, 16 Sep 2009, Erik Vorhes wrote: >> >> On Wed, Sep 16, 2009 at 4:16 AM, Ian Hickson wrote: ... >> points to a primary source of the statement, >> as opposed to an someone merely named by the >> statement. > I hate to be so repetitive, but why is that beneficial? > What is the semantic value of this? You are welcome to say that argument by authority is so weak as to be invalid, but it still happens. Similarly, you are welcome to say that the academic habit of crediting other authors (sometimes but not always for specific publications) is silly, but it still happens. > Is there as much semantic value in pointing to the primary source of a > statement as there is in knowing that the word "earth" refers to the > planet and not the dirt, for example? If so, what is that extra value? I recently saw a .sig (where, by who?) with a quotation of one character asking whether another character had said something. I could link to the archived email by title, but it has nothing to do with .sig. I could fake up a title, such as "Steven Bethard's .sig". But that can get really awkward when referring to something informal. "The Hiphopopotamus, in something that I couldn't identify even if I saw it, but which I am titling as the original source of the .sig quote". The .sig itself (if the message weren't in plaintext) could refer to an episode title, but ... that would be a little too pedantic for a .sig quote. "The Hiphopopotamus" seems a much more reasonable solution. >> dialogues and transcripts and credits and theatrical scripts are all >> arguably too fine-grained for a "citation", as opposed to a "label" or >> "attribution", but they are certainly real use cases where the >> attribution is important. > Why? This is not a rhetorical question, I'm trying to get to the use case > that means that there is an actual benefit to what you are asking for. They are all cases where "who said it" or "who did it" is important -- sometimes far more important than what they actually said or did. Reversing the characters in a dialogue can change the meaning. Changing the attribution of an statement containing "I" in a criminal trial can have important consequences. > What does do that you want? It says who to praise/blame/question for the original thought and/or expression, as opposed to the decision to repeat (and possibly ridicule) it. That may not matter much in a technical discussion, but matters in lawsuits and it matters (for different reasons) in academics. >> These three are even cases where print sources will typically shift >> font in some way between the attribution (Mephistopheles) and >> the actual statement, though not always in the same manner. Of the >> three that I found first, ... > I'm not sure what you're saying here. I was pointing out that attribution (to a person by name, not to a work by title) was important enough that print sources distinguished the way they presented the name from the way they presented the content. >> >> On October 31, 2006, Michael Fortin suggested the following pattern: >> >> Me: Can I say something? >> ... >> >> Aside from the current definition of , I think this would be a >> >> good use of the element, ... >> > I don't understand why we need an element here at all, and I don't >> > understand why we would want to reuse , of all elements, if we did >> > in fact need one. >> That "Me:" isn't pronounced; it is metadata so important that it gets >> written (in an odd style) in printed form. > I don't buy that at all. It's just one way that people write dialogs, but > as far as I can tell this is perfectly adequate: > Me: Can I say something? > ...and you need neither nor . You *never* need q -- you could just use quotation marks. And you *never* need -- you could just use the entity for a bullet. But being explicit is often judged worthwhile. >> The punctuation (followed by a new sentence, complete with initial >> capitals) is the closest a typewriter can come to markup, and scripts >> will typically make the difference more emphatic. > If it's _important_, then use . If it's just a keyword, then > is fine. If you're saying that the name is something that is in a > different voice, then either the name or the text could be in . Typically, the name would be entirely silent; in a proper audio rendition, it would be inferred from the change in voice. Alas
[whatwg] Closing tags for empty content model
> Just to reiterate, Opera<10 treats all unknown elements as container > (flow) elements. Most desktop Opera installations (only in the US?) were put there by an end user, and offer to update themselves. Is Opera < 10 likely to still be common by the time the spec actually exits last call? -jJ
[whatwg] Structured clone algorithm on LocalStorage
In http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2009-September/023192.html Robert O'Callahan wrote: > The unlocking around plugin calls is a problem, but it seems to me that any > given library function is much more likely start with a plugin-based > implementation and eventually switch to a non-plugin-based implementation > than the other way around. So there would still be a point in time when the library was using plugins on some browsers but not on others -- and you lose the cross-browser advantage that the library was supposed to give you. > Beyond plugins, I hope and expect that library functions don't suddenly add > calls to alert(), showModalDialog() or synchronous XHR. I would expect that at least some such calls are typically on error paths that don't often get taken or heavily tested. -jJ
[whatwg] progress/meter in spec
http://www.whatwg.org/specs/web-apps/current-work/ uses status.js and status.css to create a popup showing status. It shows status of the section (such as "Awaiting implementation feedback" or "Controversial Working Draft"), the number of tests, the number of demos, implementation status for each of (in practice) 5 implementations, and last-updated information. Am I correct in believing that the implementation statuses would ideally be a set of elements, even though the progress level won't be likely finish (or even change) during one reading? (And the same for overall section status?) If so, it looks like this is an example of wanting to style based on an arbitrary number of categories/thresholds (here done with classes), and also a fairly good example of the sort of styling that might be desired. (Currently done with dt/dd for the implementation status.) -jJ
[whatwg] the cite element
Smylers wrote: > I wrote: >> I think that gets at the root of the problem with cite. Most people >> don't read the spec, or even know where to find it. cite isn't common >> enough to just copy by example, and it turns out to be ambiguous as >> the name of an element or attribute. > But why would somebody be in the situation where they encounter , > want to use it, but aren't sure where? > Surely that's backwards? Why would authors be trying to use elements > for the sake of them? I can assure you that I was revising papers to get the citation format looking correct for years before I saw any actual rules. Even those professors who agreed on "use the APA format" didn't seem to interpret it the same way, and I wasn't (at the time) sure where to get a copy of those rules for myself. I instead tried to copy from examples. BigCorp business documents seem to be created the same way -- from an example, or at best a template; the "rules" or "guidelines" documents always seem to be both insufficient and wrong. > I'd expect the more usual sequence to be an author typing some text, > blissfully unaware of , then coming to the title of a book and > wanting it to be styled differently so as to convey that to users, and > looking for the element to use. In that case, I would expect them to just use and not waste time looking for anything else. Of those careful enough to look for another element, I would expect the more common use case is "I have to attribute this somehow" (More concretely, they are careful people who want to give credit, or they disagree and want to disclaim the statement, or they are afraid of plagiarism charges, or they are really arguing from authority.) And that need is there regardless of whether or not "this" happens to be a book. > If authors are spending time on using an element which has no effect on > users (and Hixie's pointed out that in many cases where is used > other than for titles of works authors use CSS to remove the default > italics, to ensure that users don't actually have the presence of the > conveyed to them) then there's no reason for HTML5 to continue to > support it. If they are merely changing the styling to some other distinctive form, there is still reason to support it. If they are truly going to the effort of adding it, then working to make it indistinguishable, that tells me the element is *very* important (if perhaps only for bureaucratic reasons), and the problem is with the default styling and UI. (And of course, if the reasons are bureaucratic, all the more reason to make a standard solution that can be easily verified or scraped into a database, instead of forcing a human proofreader to check.) -jJ
[whatwg] article/section/details naming/definition problems
On Wed, 16 Sep 2009, Erik Vorhes wrote: >> (which has already been proposed) might more logically suit the >> bill for standalone articles (in a blog or whatever) as well as >> blog/forum comments. And since it's part of the Atom spec., there's some >> precedent for defining its use. > Renaming to might make sense, I guess. It seems like > it'd get more abuse, though. It sounds quite generic. To me, the problem is that it has other meanings. I would assume it was for some sort of input. Others might assume it was for some sort "good place to start reading", sort of like a fragment ID but clearly intended for even external links. Would these be a problem in actual usage? It probably depends on how quickly the name catches on with clear examples, so ... maybe. -jJ
Re: [whatwg] the cite element
her bold or as a link, rather
than italics, but still differently).
Nor have I yet seen a script (or published play) that didn't use some
styling variation to distinguish the character names from their words.
(Usually -- but not quite always -- I see additional variations to
indicate character actions, and generic stage directions such as scene
endings.)
> On Mon, 21 Sep 2009, Erik Vorhes wrote:
>> I feel here that you're stretching the definition of "title of work"
>> beyond its usefulness. If we can use aliases within , great, but
>> that seems to make more apparent the usefulness of having be
>> for more than just "title of work."
> There's two uses that I know of: making titles of works italics by
> default, and making it easier to change that style.
The original purpose of a citation was so that readers could, if they
wished, go back to the original. That is much easier when the
original is only a click away, and so even more important.
> On Wed, 16 Sep 2009, Jim Jewett wrote:
>> ... If you have to look it up, then only careful people will
>> use it properly. (On the other hand, if there is any HTML element whose
>> users are likely to be extra careful, cite is a strong candidate.)
> I think you're right to be pessimistic, but ...
> A simple definition like "titles of works" helps.
The source of the information, such as the name of the person or the
title of the book being quoted.
>> My own interpretation of (a fraction of)
>> http://philip.html5.org/data/cite.txt did not support narrowing the
>> definition only to titles. For example
>> (1) Examples of citing a person, arguably the creator.
>> (1a) http://www.hiddenmickeys.org/Movies/MaryPoppins.html
>> The cite element is used to give credit to the person who
>> found/verified each "Hidden Mickey":
>> REPORTED: mailto:...";>Beverly O'Dell 12 MAR 98
>> UPDATE: Greg Bevier 29 JUL 98
> I don't think that's a usage anyone is actually arguing for though, is it?
Yes, I do think so. The person in the cite element is the source of
the information. This is similar to using cite for the author of a
comment at a blog.
>> (1b) http://www.webporter.com -- they give the author of the article.
>> But it looks like they (at least sometimes) include the title as
>> well, which fits under full citation.
> Right, this is the "full citation" feature. Notice their stylings, though:
> they are overriding the default font styles, and instead treating the
> whole thing as a block-level element. They would be better off using
> with a class, or having us introduce a block-level element like
> or (which we might add to ).
I agree that they would be better off with a element. I also
believe that would be better for some of the use cases that
seem to be contentious, like blog-comments-author. (1a, 1c, and 1d
would also be better off with , in my opinion.) An
element might be better still, as that would also work sensibly in
dialogues.
But is clearly the best option unless/until the more
specialized (or attrib) is added.
> This would be what would let them do, especially if we added
> for credits:
>
>
>
> Paddler: Kelly McCauley
> Photo: April McCauley, 2001
>
dc? diagram credits?
Can there be more than one dt/dd pair in a figure? How do these
associate with dc?
Can there be more than one dc for the same dd? (author and
illustrator? two co-authors?)
is a fine element, whether block or inline. seems like
another layer or two of workaround.
>> (2) Several uses -- and several *non-uses* for titles from
>> http://www.growndodo.com/wordplay/oulipo/
>>
>> The page begins with carefully attributed blockquotes. These are
>> *not* done with cite, presumably because it didn't seem flexible
>> enough. Instead, it was marked up as
>>
>> ...
>>
>> François Le Lionnais,
>> Lipo: First Manifesto
>>
>> Within the text, was used to point to source materials, but
>> there didn't seem to be anything quoted; in most cases the texts were
>> used as example objects of study; if they actually need a title
>> markup, then so does the specific Viking ship in Leif's example.
>> Sample usage: S + 7 (substrata ("novelette" +
>> 7) does appear to be a title.
>>
>> At the end of the page, there is a further readings section.
>> authortitlepublisher is used for printed
>> reference books
>> but
>> is used for equivalent references
>> on the web,
>> and cite is also used to name the professor of a course
>> 4-5 units, > href="http://www.centerforbookculture.org/dalkey/bio_gsorrentino.html";>Sorrentino
> That page seems pretty close to what HTML5 specifies now, though it's not
> fully consistent, as you say.
That almost sounds as though the real specification were:
"Book Title, even if you aren't quoting or
paraphrasing anything -- this isn't really about
citations; we just call it cite for historical reasons."
I'm trying to imagine keeping a straight face as I say that books get
special markup because their names often need to be italicized, but
this doesn't apply to ships, because, well, ships aren't written down.
And whether to The Gettysburg Address sort of depends on
how you want it styled.
-jJ
[whatwg] Note on 4.8.7 (video) and 4.8.8 (audio)
Michael(tm) Smith wrote: > What would then be the recommended way to provide fallback content > for a video like the following? > http://upload.wikimedia.org/wikipedia/commons/2/23/Ara_chloroptera.ogg > That's a 6-second video of a Red-and-green Macaw moving along a > tree branch, with the only sounds being it making a brief > vocalization, and some background sounds. It doesn't seem to lend > itself either to fallback content provided by alternative media > streams or by embedded captions or subtitles. That paragraph sounds like a reasonable alternative -- another argument for the text/html (or text/plain) source as a final alternative. On the other hand, I personally would prefer that sort of caption before deciding whether to watch in the first place, so maybe it could just be handled with an aria-describedby. -jJ
[whatwg] the cite element
In
http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2009-September/023005.html,
Ian quoted Erik Vorhes as writing:
>> Put another way, if you had no prior knowledge of the current HTML5
>> definition of (and perhaps any other specification's definition
>> of the element), what would seem to be logical and appropriate uses of
>> the element?
Ian:
> You mean based on just the element name? I wouldn't use it without reading
> the spec first. Most people seem to think it means "italics", though, for
> what that's worth.
I think that gets at the root of the problem with cite. Most people
don't read the spec, or even know where to find it. cite isn't common
enough to just copy by example, and it turns out to be ambiguous as
the name of an element or attribute.
Do you wrap the actual excerpt (the precise thing you're citing), or
the name of the source? If you wrap the name/title of the source, is
there a way to show the scope of what you're attributing?
The HTML 4 definition ("CITE: Contains a citation or a reference to
other sources.") didn't help much, but I'm not sure it can be fixed by
a spec change. If you have to look it up, then only careful people
will use it properly. (On the other hand, if there is any HTML
element whose users are likely to be extra careful, cite is a strong
candidate.)
My own interpretation of (a fraction of)
http://philip.html5.org/data/cite.txt did not support narrowing the
definition only to titles. For example
(1) Examples of citing a person, arguably the creator.
(1a) http://www.hiddenmickeys.org/Movies/MaryPoppins.html
The cite element is used to give credit to the person who
found/verified each "Hidden Mickey":
REPORTED: mailto:...";>Beverly O'Dell 12 MAR 98
UPDATE: Greg Bevier 29 JUL 98
(1b) http://www.webporter.com -- they give the author of the article.
But it looks like they (at least sometimes) include the title as
well, which fits under full citation.
(1c) http://www.thesentencegame.com/ -- a link to the snipped author.
(1d) http://drotner.com/squirtboating/ -- the phototographer and subject
Paddler: Kelly McCauley
Photo: April McCauley, 2001
These do seem useful; if you wanted more information, it might well be
"How do I contact this photographer or that model to get something
similar?"
(2) Several uses -- and several *non-uses* for titles from
http://www.growndodo.com/wordplay/oulipo/
The page begins with carefully attributed blockquotes. These are
*not* done with cite, presumably because it didn't seem flexible
enough. Instead, it was marked up as
...
François Le Lionnais,
Lipo: First Manifesto
Within the text, was used to point to source materials, but
there didn't seem to be anything qouted; in most cases the texts were
used as example objects of study; if they actually need a title
markup, then so does the specific Viking ship in Leif's example.
Sample usage: S + 7 (substrata ("novelette" +
7) does appear to be a title.
At the end of the page, there is a further readings section.
authortitlepublisher is used for printed
reference books
but
is used for equivalent references
on the web,
and cite is also used to name the professor of a course
4-5 units, http://www.centerforbookculture.org/dalkey/bio_gsorrentino.html";>Sorrentino
(3) Example of usage as per HTML5
http://www.pacifier.com/~tpope/
(4) Example of italics -- though they may be going for the
"commendation" meaning of cite:
http://www.patriagrande.net/guatemala/otto.htm
(5) Clearly just for italics -- http://www.truck-town.com/
(6) http://www.winthrop.dk/hender.html -- Using it to wrap the
portion of your own text that was "cited" as opposed to original.
That said, I can't rule out that it was just a way to get italics;
later on the page, there was cites for "shot heard round
the
world" (title of event?) and "revolutionaries" (describing the
original settlers).
-jJ
Re: [whatwg] SharedWorkers and the name parameter
On Tue, Aug 25, 2009 at 7:24 PM, Ian Hickson wrote: > Drew Wilson wrote: >> Per section 4.8.3 of the SharedWorkers spec, >> if a page loads a shared worker with a url and >> name, it is illegal for any other page under the >> same origin to load a worker with the same name > The idea here is that if you have an app that > does database manipulation, you might want to > ensure there is only ever one shared worker > doing the manipulation, so you might decide > on a shared worker name that is in charge of > that, and then you can be sure that you don't > accidentally start two workers with that name > using different copies of a script So the name is really intended as a (lightweight) URN, but it can default to the URL? -jJ
[whatwg] SharedWorkers and the name parameter
> Currently, SharedWorkers accept both a "url" parameter and a "name"
> parameter - the purpose is to let pages run multiple SharedWorkers using the
> same script resource without having to load separate resources from the
> server.
> [ request that name be scoped to the URL, rather than the entire origin,
> because not all parts of example.com can easily co-ordinate.]
Would there be a problem with using URL fragments to distinguish the workers?
Instead of:
new SharedWorker("url.js", "name");
Use
new SharedWorker("url.js#name");
and if you want a duplicate, call it
new SharedWorker("url.js#name2");
The normal semantics of fragments should prevent the repeated server fetch.
-jJ
[whatwg] Dates BCE
> Orthodoxy has it that there is no use case for marking up an ancient date > or "fuzzy date" like "June 2009" using . 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 would be necessary? Whether or not it is useful, wikipedia does it -- a fair number of 4-digit numbers are linked to a page of "things that happened this year", but those pages are far from complete -- they often don't even include the events being linked from. In theory, that could be done with a span and a class ... but the ad hoc solutions have clearly been found wanting. I would sometimes like to search on a date range, as opposed to a specific date; right now, I'm not sure how to do that cross-domain; if there were a "time" element, I would expect it to be used often enough that time searches would be more reasonable. These may all fail to the 80% rule, but ... they are of at least some utility, and I'm not sure how much harder it is to support them, given that will exist, and parsing rules already have to be aware of such dates to the extent of figuring out what to do for error-processing. -jJ
[whatwg] Codecs for and -- informative note?
Ian Hickson wrote: | does support fallback, so in practice you can just use Theora and | H.264 and cover all bases. Could you replace the codec section with at least an informative note to this effect? Something like, "As of 2009, there is no single efficient codec which works on all modern browsers. Content producers are encouraged to supply the video in both Theora and H.264 formats, as per the following example" (If there is an older royalty-free format that is universally supported, then please mention that as well, as it will still be sufficient for some types of videos, such as crude animations.) -jJ
[whatwg] longdesc [was: A new attribute for and low-power devices]
> In the ~0.1% of images where > longdesc= is used, it's misused literally over 99% of the time: > http://blog.whatwg.org/the-longdesc-lottery Responding for the archive; that blog bost keeps getting cited, but it isn't up to Mark's usual standards. longdesc is not a success story, but neither is it the miserable failure suggested by those numbers. The 99.9% unused is (or at least was) probably close to correct, and is a good thing. I just checked the front page of CNN, where there are 137 images, of which at most one would benefit from a longdesc -- and even that one is pretty questionable. The 99% misused is at best debatable. I'm pretty sure that using a longer human-readable description instead of an URL was once (admittedly long ago) recommended. It worked at least as well with the browsers I tested with at the time. Blanks should be treated the same way as blank alts -- an explicit statement that this image does not need a long description. URLs which are redundant to something else in the area are actually a good thing, since that "something" isn't standardized. (aria-described-by should offer a better solution going forward.) http://wiki.whatwg.org/wiki/Longdesc_usage makes it clear that useful (if not pedantically correct) usage is much greater than 1% of the actual usage. Not as high as it should be, certainly, but still better than, say, the percentage of tables which represent data rather than layout. -jJ
[whatwg] RDFa is to structured data, like canvas is to bitmap and SVG is to vector
> Now wait a second, you're changing the parameters of the requirements. > Before, the criteria was based on the DOM. Now you're saying that the > browsers actually have to do with something with it. [Put "almost" in front of most words in the following.] The consistent DOM criteria is necessary but not not sufficient. Browsers doing something with it is a step towards sufficient. Without DOM consistency (or at least an agreed workaround), it almost doesn't matter how great RFDa is, because it isn't compatible. Once you have that consistency, then the questions can move on to the next step. That next step boils down to "Why bother?" Needing DOM integration of the information is a reason to bother. Browsers doing something with it is a reason to bother. Those aren't the only reasons to bother, but they are likely reasons, so people have asked about them. If you have other reasons, go ahead and offer those as well. (But "existing W3C standard" probably isn't strong enough.) -jJ
