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

Re: [1.2T-LC] Text selection - but what about Find Text ? (ISSUE-2065)

From: Jeff Schiller <codedread@gmail.com>
Date: Thu, 9 Oct 2008 11:55:43 -0500
Message-ID: <da131fde0810090955s59ca8a4at584f3111c9f5acfd@mail.gmail.com>
To: "Doug Schepers" <schepers@w3.org>
Cc: www-svg <www-svg@w3.org>


Thanks for the clarification.  This makes sense.  I would still
suggest a rewording to :

"and are recommended to adjust the viewport as if there had been a
fragment identifier link traversal to the element containing the text

or something to that effect.

(I guess that 'set the viewport to the bounding box of the element
containing the text string' is not exactly correct in light of the
behavior described in the frag-id portion of the spec that you've
clarified to me)


On 10/9/08, Doug Schepers <schepers@w3.org> wrote:
> Hi, Jeff-
>  Jeff Schiller wrote (on 10/9/08 12:20 PM):
> >
>  > "SVG viewers which allow sequential searches for text strings must pan
>  > and zoom the viewport, as appropriate, in order to show the text
>  > string in context, and are recommended to set the viewport to the
>  > bounding box of the element containing the text string, as if it were
>  > a traversal to a fragment identifier."
>  >
>  > I'm not sure if I agree with the last part of this.  Would it be
>  > sufficient instead to state:
>  >
>  > "and are recommended to adjust the viewport such that the bounding box
>  > of the element containing the text string is fully within the
>  > viewport"
>  >
>  > Searching through text is often a contextual activity - the user quite
>  > often wants to see the parts of the document that surround the text
>  > string being searched for (I suppose the user could zoom out at that
>  > point, but that seems unnecessary).
>  >
>  > In other words, as a user, I would prefer panning but leave the zooming to me.
> Yes, I agree with you, and this was part of the point in pointing to the
>  frag-id behavior [1], which states:
>  [[
>  If the element's decorated bounding box is too large to fit within the
>  current viewport, and the 'zoomAndPan'  attribute of the rootmost 'svg'
>  element is not set to 'disable', then the viewport shall not only
>  reposition but also have the current scale expanded to accommodate the
>  entire width and height of the element's decorated bounding box. By
>  contrast, if the bounding box of the target element is smaller than the
>  viewport, the viewport shall remain at the preestablished values (i.e.,
>  it will not automatically zoom in on the element).
>  ]]
>  In other words, if the text is too large to fit within the viewport,
>  zoom out.  Otherwise, just pan.  Note that the text-search behavior
>  would apply to the bbox of the whole text element, not just the
>  particular substring; thus, if there were a textual element with a lot
>  of content, the UA is recommended to zoom out to show the whole
>  sentence/paragraph/tspan.  That way, the substring would be seen in
>  (text) context.  If the text bbox is too large, this might mean that the
>  substring is zoomed out too far to read, in which case the user should
>  zoom in manually... but this is the point of the tip that authors should
>  create content accordingly (that is, make it such that searches would
>  reveal just the right amount of content, such as breaking long passages
>  up into multiple textAreas).
>  Does this seem intuitive to you, now that I've gone into more detail?
>  Should I be more explicit in the spec?
>  > Otherwise, it looks good to me.
> Cool, thanks.
>  [1]
>  http://www.w3.org/TR/SVGMobile12/linking.html#FragmentIdentifierTraversal
>  Regards-
>  -Doug Schepers
>  W3C Team Contact, SVG and WebApps WGs
Received on Thursday, 9 October 2008 16:56:19 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:54:20 UTC