- From: Tantek Çelik <tantek@cs.stanford.edu>
- Date: Sat, 7 May 2011 09:51:57 -0700
- To: John Foliot <jfoliot@stanford.edu>
- Cc: Benjamin Hawkes-Lewis <bhawkeslewis@googlemail.com>, "Gregory J. Rosmaita" <oedipus@hicom.net>, Laura Carlson <laura.lee.carlson@gmail.com>, Charles McCathieNevile <chaals@opera.com>, HTML Accessibility Task Force <public-html-a11y@w3.org>
Hi John, Just a quick clarification on a couple of points. On Fri, May 6, 2011 at 18:36, John Foliot <jfoliot@stanford.edu> wrote: > Benjamin Hawkes-Lewis wrote: >> >> Here's Tantek's objection from the poll: >> >> "[@longdesc] is one of the worst forms of invisible metadata or "dark >> data" >> which are known to rot and become inaccurate over time (see: meta >> keywords, RDF >> in comments, sidefiles, etc.)." > > Links rot; this is a known problem. To be clear - the data/content rot I refer to is *not* the link rot problem. I'm talking about rot that occurs *in the same document*, not *across documents*. E.g. the first couple of examples given: meta keywords, RDF in comments - are both hidden metadata in a document that has been known to get out of sync with the visible (actual) content of the document to the point of those features being entirely ignored by commonly used search engines (search engines which do pay attention to links, rotten or not). In the case of "longdesc" - the content rot scenario is that a web author changes the image (src) to point to something else, but forgets to update the longdesc to point to a new description because it is hidden metadata and isn't apparent as being "wrong" when the author refreshes the page in their browser to check it. The longdesc URL itself may still be fully functional (i.e. no *link* rot may have actually occurred). The result is a new image, with a longdescription that no longer applies to it. Doesn't matter for most users, and those that attempt to access the longdesc get inaccurate information. > (Here's another for you: http://tantek.com/CSS/19980106.html - check the > link to HyperCard... BTW, Tantek is also a friend, and I don't mean to pick > on him.) Heh. No personal offense taken :) And yes, links/markup on tantek.com are fair game (understand that some old pages I may leave as is for historical purposes ;) I'm actually a bit shocked that http://hypercard.apple.com/ doesn't at least redirect to something else, like perhaps http://support.apple.com/kb/DL1230?viewlocale=en_US Perhaps Maciej can forward that onto someone. > Link rot is a fact of the web, whether or not the links are referenced via > @longdesc or via @src. Agreed. But content rot and link rot are two different things. Just wanted to clarify that. > The problem with @longdesc today is not the attribute, it's the browsers' > failure to make it discoverable to end users. John, a while ago you proposed the alternative of using rel="longdesc" and looks like there is a stub description evolving in the microformats wiki (I started it with just a link originally but it's grown since). http://microformats.org/wiki/rel-longdesc Is this still under consideration? Seems to me there's much lower barriers to specification and adoption of a rel="longdesc" (since 2003 more and more web authors are cognizant of and actually using (even *new*) rel values on links per XFN, rel=license, rel=tag and other rel microformats). And web authors have become quite skilled at using progressive disclosure of their content/links when their designs call for it. Was there already a debate somewhere between longdesc="" vs. rel="longdesc" ? Thanks, Tantek -- http://tantek.com/ - I made an HTML5 tutorial! http://tantek.com/html5
Received on Saturday, 7 May 2011 16:53:04 UTC