RE: proposal for this link/tspan discussion

We're already encouraging our content developers to shy away from use of
<a>, but we:
a) have a totally different reason
b) have a totally different resolution and
c) have had to introduce additions to SVG to accomplish it.

The reason we don't like <a> is that on devices that don't have pointing
devices (i.e. phones, Blackberry, -- and even Palm because it doesn't have
"mouseover", in other words everything but PocketPC :-)) it is difficult to
indicate that there is a "clickable" link.  We overcome this by having the
user "tab" from one clickable link to another using the up/down buttons on
the phone or the scroll wheel).  We provide a fake animated cursor over the
object being highlighted -- but we don't like that, and I doubt most content
developers do.

So we encourage people to use the begin="foo.focusin", begin="foo.focusout"
and begin="foo.activate" semantics to provide custom animations for all
their clickable links.  Works great.  Gives complete control to the content
developer.  There's only one problem:  there is no animation that means
"load a new document".

So we fake that out by adding our own custom markup element:  <loadScene>
which has an xlink:href attribute for the scene to load and has the begin
attribute borrowed from <animate>.  This works out even better, because it
allows people to load new content not just based on user clicks, but also
based on time, end of other animations, on focus-in events -- basically any
event.  If we added some concept of inline loading, this a neat way to
accomplish streamed content, albeit under the control of the content
developer.

So my less radical suggestion is to deprecate <a>, introduce a new element
like our "<loadScene>" and encourage people to use SVG events.

BTW, we still support <a>, but if the user defines a focus-in or focus-out
behaviour for the children of the <a> element, we don't create our fake
cursor.

-----Original Message-----
From: Dean Jackson [mailto:dean@w3.org]
Sent: August 19, 2002 9:23 PM
To: www-svg@w3.org
Subject: proposal for this link/tspan discussion



Isn't it great to see a whole thread develop (ie. start,
move into the discussion phase, then the argument phase,
then the "what was it that we were talking about" phase)
during a single night's sleep (for me).

Here is something I've been thinking of recently (does not 
represent the SVG WG):

Remove <a> from SVG.

As has been discussed in the thread, <a> causes all sorts
of content model problems. Maybe someone has enumerated them
and checked to see what schema languages will be able to
solve the problems? Maybe there is only one content model
problem (PCDATA vs content similar to <g>)? I don't know.

Why can't every element be a link? We allow an xlink:href
on every element (I think this was one of the goals of xlink).

There are some elements (eg. <linearGradient>, <pattern>,
<filter>, <tref>, <image> etc) that define xlink:href to mean
something other than a traditional link (more like, go get the
referenced content and do something with it). I'd like to see
those attributes replaced with "ref".

Of course, this breaks nearly everything as we know it, and is
too huge a change for a minor version of SVG. However, I think
XHTML 2.0 are showing us a potential path, and I like 
some aspects of the direction in which they are headed.

No need for preliminary discussion phase on this one. You
can move straight to the "name calling" phase.

Dean (noting that Chris is on vacation, so is unable to tell
me why I'm wrong for at least a week)

Received on Tuesday, 20 August 2002 11:08:45 UTC