W3C home > Mailing lists > Public > www-svg@w3.org > February 2015

Re: How should viewTarget work?

From: Chris Lilley <chris@w3.org>
Date: Wed, 18 Feb 2015 12:43:45 +0100
Message-ID: <145876559.20150218124345@w3.org>
To: Amelia Bellamy-Royds <amelia.bellamy.royds@gmail.com>
CC: www-svg <www-svg@w3.org>
Hello Amelia,

Tuesday, February 17, 2015, 9:25:55 PM, you wrote:

> The <view> element takes the `viewTarget` attribute, whose value is
> a list of IDs (XML names) from the current document (presumably, the
> elements that will be the focus/key feature of that view).

Right.

> In SVG 1.0, the description of the attribute was "Indicates the
> target object associated with the view.         If provided, then
> the target element(s) will be highlighted."
> http://www.w3.org/TR/SVG10/linking.html#ViewElement

Yes, by analogy with similar functionality in other formats such as
CGM.


> For the second edition of SVG 1.1, the reference to automatic
> highlighting was removed, since it hadn't been implemented by
> anyone. 

There is no general method to make arbitrary graphics highlighted which
works for all content. (In CGM, which is frequently used for black and
white line drawings, a red highlight was popular).

>  Instead, a section on using the CSS :target pseudoclass was added instead.
> http://www.w3.org/TR/SVG11/linking.html#ViewElementViewTargetAttribute

> The relevant notes for the decision to make that change are organized as ACTION-2947.
> https://www.w3.org/Graphics/SVG/WG/track/actions/2947 


> The text as it stands *seems* to imply that when you link to a view
> element, the :target pseudoclass will apply to all the elements
> listed in the viewTarget attribute. 

Yes, like with HTML. Of course, you need to add a style rule that
selects on :target, to actually see anything.

In other words, the responsibility for choosing a visually distinctive
way to highlight something was moved from the viewer code, which has no
clue, to the content author, who is expected to choose something
suitable.

>  However, it doesn't specifically say so,

Hmm, fair point. For generally linking to a fragment, it is defined -
the defining document there would be CSS Selectors, specifically
section 6.6.2
http://www.w3.org/TR/selectors/#target-pseudo

and indeed in 1.1 we made direct linking to fragments actually do
something (previously it was kind of useless).

But view elements are a type of indirection (the fragment links to a
named view, which then says what to bring into view.

We should fix this by explicitly defining that :target applies to the
elements wholly contained within the specified view.


> So the question: 
> Should the `:target` CSS pseudoclass apply to all elements
> mentioned in the viewTarget attribute of a view that is itself the target of an IRI fragment?

yes

> if yes:

> This needs to be clearly stated in the spec.  Support for :target
> should also be normative.
yup

> Implementers will need to confirm that
> their CSS implementations can handle the fact that :target will now
> match multiple elements at once.
good point - best to check with css wg folks on that. Although in
general multiple elements can belong tothe same class so they should
also be able to belong to the same pseudoclass.

They might want us to define a different pseudoclass though. Best to
discuss.

>  Secondary question: would the
> `:target` pseudoclass still apply to the view element itself? 

By default it would (as you found) but I think that while fully
defining that element behaviour we should exclude it from being
directly applied to the element itself.

>  I
> would think so, but then FF and IE need to figure out why this isn't
> currently working.

> Secondary question: could this work with inline
> SVG or only stand-alone?  Currently, view targets don't have an
> effect on the display of inline SVG, but the normal :target
> pseudoclass does (when targetting a shape or group).

should work with inline as well.


-- 
Best regards,
 Chris Lilley, Technical Director, W3C Interaction Domain
Received on Wednesday, 18 February 2015 11:43:48 UTC

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