- From: John Hayman <JHayman@rim.net>
- Date: Tue, 20 Aug 2002 11:08:43 -0400
- To: "'www-svg@w3.org'" <www-svg@w3.org>
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