- From: <bugzilla@jessica.w3.org>
- Date: Wed, 03 Apr 2013 11:07:08 +0000
- To: public-html-bugzilla@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=21501 --- Comment #5 from Charles McCathieNevile <chaals@yandex-team.ru> --- I think a lot of what you are describing is best practice (although in some situations things that aren't best practice might nevertheless be legitimate - e.g. a short description might be fine in a text/plain data: url, but describing a complex infographic might well require a table or two of data, and enough structure to navigate around). I am against filling the spec with stuff that is purely meant to answer the longdesc lottery article. For most users, that will be unnecessary extra content. Another best practice would be to check that the language of the longdesc matches the language of the source document. And another would be to check if it negotiates to match the users preferred language even if the page itself doesn't (this is one of the cool things you can do with external longdesc links). But I am not interested in putting all that into the spec... I'm coming to the idea that it would be useful to write a specific best practices document. Note that there are validators that linkcheck - I just don't know of any free products that do that. Looking at the list: We answer 1 and 2 (so did HTML 4) 3, 4 and 5 have legitimate use cases so should only throw warnings anyway. Describing the kind of warning and the use cases is definitely better in a Best Practices document IMHO. 6 is a non-problem. There is a clear difference between having a link somewhere on a page, and having an explicitly associated link, in terms of allowing user agents (which include things like search engines) to unambiguously associate the description with the image. -- You are receiving this mail because: You are the QA Contact for the bug.
Received on Wednesday, 3 April 2013 11:07:11 UTC