- From: Nigel McFarlane <nrm@kingtide.com.au>
- Date: Sat, 06 Nov 2004 02:56:39 +1100
- CC: www-svg@w3.org
> I'm really confused now. For the last few days you've been > suggesting that you wanted more accessible markup, more > semantic markup and a better separation of content from > presentation. Now, you suggest people use <canvas>! I think Ian's the clearest when he talks about the value inherent in CSS features. Questions of accessibility, UA extensions like <canvas>, and XForms all represent functional richnesses that are performance aspects (meant in no technical sense) of an overall presentation strategy. Whatever that strategy is, it has to cater for those aspects, but those aspects aren't at the core of the enabling presentational technology. Even CSS is, after all, an abstract model, not a braille printer. Rather than pick nits over <canvas> or other tags, it would be better if the "yea" sayers would defend SVG by explaining how it *can* support accessibility, UA content extensions, and XForms, and how much CSS it has to lean on to do so. How much can it do? It is not right to mandate accessibility utterly. Neither is it right to say that SVG can abandon accessibility. Accessibility always applies as a performance test of good design and good intentions. Can SVG perform accessibly without leaning on CSS? --oOo-- Secondly, dynamic arguments are distracting from the core presentation issue. If you can't prove in the static case that SVG performs well in feature areas such as accessibility, forms, and layout without more CSS integration, then you'll never prove it in the dynamic case. That include arguments over sockets and drawing surfaces. Sockets have nothing to do with core presentational problems. They are at most an implementation strategy for generic dynamism that some presentation systems must support. Everyone knows that the matter of info feeds (push or pull) to presentation systems is a matter of high-level comms architecture, not GUIs. Info feeds creating dynamic HTML are no different in principle to info feeds creating dynamic SVG. For example: Event list management is a well-establish dynamic use of textual block-oriented content based on info feeds. You don't see event list management and sockets creeping into the XHTML specs. Why then put it into SVG, especially with recent IETF RFC standards on event flow technology now available? Stick to the static case for clarity. - Nigel. -- --------------------------------------------------------------------- Nigel McFarlane nrm@kingtide.com.au Services: Analysis, Programming, Writing, Education Expertise: Software, Telecommunications, Internet, Physics "Rapid Application Development with Mozilla" / www.nigelmcfarlane.com
Received on Friday, 5 November 2004 15:53:06 UTC