- From: Robert Burns <rob@robburns.com>
- Date: Thu, 5 Jul 2007 05:10:31 -0500
- To: Anne van Kesteren <annevk@opera.com>
- Cc: "HTML WG" <public-html@w3.org>
On Jul 5, 2007, at 5:01 AM, Anne van Kesteren wrote: > On Thu, 05 Jul 2007 11:44:58 +0200, Robert Burns <rob@robburns.com> > wrote: >> On Jul 5, 2007, at 4:36 AM, Anne van Kesteren wrote: >>> On Thu, 05 Jul 2007 11:29:23 +0200, Robert Burns >>> <rob@robburns.com> wrote: >>>> I added the <img>fallback</img> for xml serialization solution >>>> to the Longdescription page. If anyone can think of any other >>>> pros and cons, please add them. >>>> >>>> <http://esw.w3.org/topic/HTML/LongdescRetention#preview> >>> >>> It creates more divergence between the HTML and XHTML >>> serialization. Authors are already confused by subtle API and CSS >>> differences. Making drastic changes like this is not likely to be >>> appreciated. There also seems to be very little benefit given >>> that the HTML serialization is used most often. If anything, we >>> should optimize for that serialization. >> >> I meant to add them to the wiki. I already put that con on the >> wiki. If you'd like to reword it you're welcome to do so. > > You put it down for "pro". I did? "Cons: forks fallback solution for different serializations" How is that putting it down for pro. > Saying that authors are already familiar with <img>. I'm saying > they'll just be confused given the amount of XHTML treated as text/ > html already and authors complaining in bug databases about <span / > > or <textarea /> not working as described by XML... Yes, I understand that's why I added the con. Should I add it a second time? I've said this again and again this will take a long- term solution approach. In that time-frame authors may not even know what a text/html compatible serialization is? They won't be confused because there might come a time when no one uses that serialization anymore. >>> I have a very hard time understanding what problem you're trying >>> to solve by the way. There is a requirement listed at the top of >>> the page, but to me that seems addressed by <img alt>. >> >> I think you've asked this several times and I've answered it >> several times, but I'm happy to answer it again. > > The wiki page should explain it. I thought it did. You're welcome to edit the wiki page. Right now I think all of the pages are a bit of a mess, but I'm sure we'll get them in order over the next few weeks. > > >> Because <Img> has to be empty, authors cannot provide semantically >> rich or media rich fallback content for images in a simple and >> straight-forward manner (as they can for <object>, <video>, >> <audio>, <iframe>, <object>, and <canvas>). <img alt> cannot do >> that at all. It's really only listed there as a token solution. > > Is there any evidence that suggests that authors will start > providing more meaningfull fallback when they can have more than > just text? For instance, what do authors currently do for <object> > when they use it for Flash or video or some such? I'm not a palm reader. I don't know the future. Is there any evidence that the world wide web will exist next year? I know I couldn't prove it will. However, it should be a goal of ours to provide a language that services the needs of authors. Why are you so resistant to providing these facilities? I guess if you could say a little something about that, I could respond and we would have a dialog. At this point I can't even imagine what could motivate your resistance. >> [...] And as many have said before, this is certainly more of a >> problem to solve than the problems that inspired <video> and <audio>. > > Saying it many times does not make it true. No. I wasn't trying to make it true. That its true I think is obvious. I was simply trying to reiterate so you wouldn't forget about it. Take care, Rob
Received on Thursday, 5 July 2007 10:10:51 UTC