W3C home > Mailing lists > Public > www-svg@w3.org > October 2005

Re: SVG12: nav-* properties

From: Dean Jackson <dino@w3.org>
Date: Tue, 1 Nov 2005 00:59:53 +1100
Message-Id: <6AE7017F-5553-46A5-8059-53C53AF77616@w3.org>
Cc: www-svg@w3.org
To: Bjoern Hoehrmann <derhoermi@gmx.net>

On 24/05/2005, at 9:48 AM, Bjoern Hoehrmann wrote:

> * Dean Jackson wrote:
>> Personally, I'm ok with either solution. However, we need
>> 8-way navigation, not 4-way as CSS3-UI provides. Assuming that
>> CSS WG would accept an enhancement to this feature then I
>> think nav-* is acceptable. What do you think?
> I think that related technologies should either use the same  
> facilities
> for the same functionality or that there should be consensus about  
> using
> different facilities and well-defined conflict resolution mechanisms.
> I see 8-way navigation is a concern here. There are more differences
> though, a CSS-based solution does not require that interaction is  
> hard-
> coded into the content markup, it seems thus likely that a CSS-based
> solution will make it easier to add interaction to content  
> generated by
> sXBL components. Another difference is that nav-* allows for setting
> the target frame for the navigation. And 8-way navigation can of  
> course
> also be achieved via scripting.
> Just to say, I am not convinced that markup or CSS properties for 8- 
> way
> navigation are an absolute requirement here, and that adopting the CSS
> solution provides advantages even if it does not offer 8-way  
> navigation.
> Enhancing css3-ui to provide the desired functionality is an option
> though.
> As Jon notes, XHTML 2.0 has yet a third mechanism, so do XForms and
> other formats. I don't want to end up with a X+Y+Z format with three
> different markup and scripting means to deal with navigation and three
> different ways how CSS interacts with them.

Hopefully you'll be glad to hear that we accepted your comment and
have updated the spec to use nav-* properties, consistent with
CSS3 Basic User Interface. The exception is nav-index, for which
we use nav-next and nav-prev after feedback from the WAI Working

[Just to be clear, your original request was to describe the
uDOM moveFocus method in terms of features in the spec. We've
done that as well. It was your follow-on comments where you
raised the objection to focus* because it is not consistent with

Please let us know within two weeks if you are not satisfied.

Received on Monday, 31 October 2005 14:00:10 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 8 March 2017 09:47:05 UTC