- From: Robert Burns <rob@robburns.com>
- Date: Thu, 5 Jul 2007 10:20:56 -0500
- To: James Graham <jg307@cam.ac.uk>
- Cc: Anne van Kesteren <annevk@opera.com>, HTML WG <public-html@w3.org>
On Jul 5, 2007, at 10:17 AM, James Graham wrote: > > Robert Burns wrote: >>> a) That there is a real use case that demands rich fallback for >>> images. Possibly anyone with this use case today would be using >>> longdesc to provide the rich content so demonstrating the correct >>> use of longdesc with rich contents would be helpful. >>> Alternatively a series of examples in which the user experience >>> is significantly degraded where rich fallback is not available >>> are likely to be persuasive. >> Why would correct use of the longdesc help my case. > > Because it would demonstrate that, despite the complexity, authors > had sufficient need for rich fallback that using longdesc to > provide it was worthwhile. > > If you can't demonstrate that authors are using the existing > mechanisms that are in place, you have the somewhat harder task of > demonstrating that they would use rich fallback if only it were > epsilon easier, where epsilon is the difference in difficulty > between the simplest existing mechanism and your proposal. > > >>> b) That there is a viable migration path from here to there. For >>> example, people are trying to find migration paths based on >>> <picture> elements + conditional comments. They all look pretty >>> painful to me. If there is no sensible migration path for authors >>> that can deal with a mixture of supporting and non-supporting UAs >>> the element will never be used so there's no point in speccing it. >> I do not think those migration paths look very painful. >> Regardless, if we're serious about interoperability,, we need to >> address the issue of canonical empty elements in text/html that >> are no longer necessarily canonically empty in xml (in other words >> we can say they're empty, but if we want to facilitate authoring >> errors, then we need to accommodate the possibility that authors >> will place content within the start and end of an image element; >> what might they mean if they do that). > > I agree that we should cover that issue in the spec. > >> I would like to do as you suggest. I will start immediately. >> Could you point me to the document for the <video>, <audio> and >> <canvas> elements that does the same tasks. > > I'm not sure what you mean "document" here. I had in mind an email > or a wiki page. Therefore I suggest you look for discussions about > audio, video and canvas in the WHATWG mailing list archives where > the fallback issue was discussed. Note that the situation for these > elements is rather different for that which you are proposing since > they introduce entirely new features rather than reworking an > existing feature. > >> No, it is not clear that these is skepticism about what I am >> proposing. There is quite a bit of support for what I am proposing >> (providing parallel rich fallback content for still images). There >> is also a few who are responding with quite a bit of irrational >> resistance to what I am proposing: particularly in this latest >> suggestion, where I'm not actually proposing we change anything >> fundamental, but instead provide interoperability and author >> guidance for something that is already happening (non-inter- >> operably) in UAs. > > Calling people who disagree with you "irrational" doesn't seem > constructive; to me it suggests that you are not taking the time to > understand what they are saying. No, I understand what you're saying and its irrational.
Received on Thursday, 5 July 2007 15:21:09 UTC