- From: Robert Burns <rob@robburns.com>
- Date: Thu, 5 Jul 2007 09:51:45 -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 9:27 AM, James Graham wrote: > > Robert Burns wrote: >> On Jul 5, 2007, at 6:39 AM, Anne van Kesteren wrote: >>>>> >>>>> Ok, I hope I explained well enough why I think this is not >>>>> obvious at all. >>>> >>>> No. That had nothing to do with <video> and <audio>. Look I have >>>> nothing against those additions to the language. But I can't >>>> even begin to come up with a use-case for <video> and <audio> >>>> that could come close in importance to the need to provide >>>> fallback for still images. And no one else has been able to >>>> describe any pressing need for those either. >>> >>> James explained the reasons for <video> and <audio> in a separate >>> thread. >> Yes he explained that video and audio need to be first class >> citizens with fully featured fallback content. And you seem to be >> saying that still images do not deserve to be first class citizens >> in HTML with fully featured fallback content. > > Images clearly are first class citizens in HTML. That they don't > support rich fallback doesn't change that. > > If you believe it is necessary to introduce a new method of marking > up images that does allow for rich fallback you need to demonstrate > that the benefits outweigh the costs. In particular, you need to > demonstrate: > > 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. My point is that longdesc is to complicated for authors to use. <object> as it stands now is also too complicated for authors to use (and I've already suggested we try to use our draft recommendation to eventually address that issue too). > 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 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 think it will serve as an excellent template for my work. With the use of that as a template, my task will be far easier than the task for making the case for why our final recommendation will include <video>, and <audio>. > It is clear that there is a certian amount of scepticism about the > need or viability of what you are proposing. The correct response > to that is not to give up in frustration as Phillip apparently did; > rather it is to provide evidence for your position. Often (and by > no means just in HTML discussions) it turns out that actual > evidence undermines all the well-constructed theoretical arguments > that preceded it. 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. Take care, Rob
Received on Thursday, 5 July 2007 14:51:58 UTC