How should viewTarget work?

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).

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


For the second edition of SVG 1.1, the reference to automatic highlighting
was removed, since it hadn't been implemented by anyone.  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.  However, it doesn't specifically say so, and no
one seems to have implemented it that way.

Most browsers *do* apply the :target pseudoclass to the view element
itself, so you can apply custom styling with the appropriate document
structure and CSS sibling selectors, but it is messy and inconvenient, and
it isn't even currently reliable cross-browser.

See the attached test file.  The shape links to the view.  The view shrinks
the shape somewhat to make room for a stroke.  If the :target class on the
view is recognized, the stroke is red.  If the :target class on the shape
(the element specified by viewTarget) is recognized, the stroke is green.
 (That doesn't happen on any browsers I've tested).

Firefox doesn't apply the view:target style rules at all, while IE is
really wonky. It will apply the styles, but not the view parameters, if you
load the file with the target fragment in the original URL (in other words,
the red stroke gets cut off at the edges).  If you follow an internal link,
however, you get the change of view but not the styles.  If you follow the
internal link again (click on the shape a second time), *then* you get the
styles.  Chrome/Opera apply the view:target rules and the view as
expected.  I haven't tested Safari, but I expect it would be similar.


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?

   - if yes:
      - This needs to be clearly stated in the spec.  Support for :target
      should also be normative.
      - Implementers will need to confirm that their CSS implementations
      can handle the fact that :target will now match multiple
elements at once.
      - Secondary question: would the `:target` pseudoclass still apply to
      the view 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).
   - if no:
      - The section "highlighting views" needs to be changed to distinguish
      between view:target effects and shape:target effects (which can still be
      used by linking directly to the shape, but the view will be based on the
      nearest ancestor SVG of that shape).
      - Firefox and IE still need to clean up their implementations so that
      view:target CSS styles get applied correctly.

Whatever is decided, it should also apply to element IDs mentioned in the
viewTarget parameter within an #svgView() fragment.  This would then
provide a way for authors to *both* target a specific element for CSS
:target styles *and* apply a custom view.

As a side note, getting a clear and consistent behavior for viewTarget
could be very useful when trying to improve SVG accessibility.  Currently,
views are somewhat awkward from an accessibility perspective, since they
change the visible content to emphasize a certain part of the graphic, but
there is no direct connection in the XML DOM between the target element
(the view) and the emphasized content, except via the viewTarget attribute.


We don't currently have any specific instructions related to <view> in the
SVG accessibility API mapping draft.  However, we *could* introduce an
implicit ARIA relationship for viewTarget (probably `aria-flowto`).  That
way, after following a link to a view, accessibility technologies would
then present the appropriate content next in the reading order.  However,
that sort of implicit relationship wouldn't have much of an impact unless
authors actually use `viewTarget`.  And right now, there's no reason to use
`viewTarget` because it has no effect!

--AmeliaBR