Re: SVG 1.2 Comment: Detailed last call comments (all chapters)

> 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