Forwarded message 6
Hi, Dave-
I agree this issue needs reexamining in light of the body of content. I
warn you before you read my ramblings that I don't reach a conclusion...
I'm just presenting the variables as I see them.
I believe the lack of scrollbars is by design. As I understand it, the
intent was that SVG viewers would be more panning-based, rather than
scrolling-based. This was a common mechanism at the time, with Flash,
and it's even more common now with all the mapping webapps, like
GoogleMaps.
(I've heard the argument from some UI folks that users don't understand
zooming and panning... that the average user can't distinguish different
image types, and that the UI for vectors should be the same as that for
rasters, but I haven't seen evidence of that. GoogleMaps' and Flash's
popularity would seem to be evidence to the contrary, as is the fact
that raster images are not normally as interactive as SVG can be, except
when they are used for buttons and such.)
Scrolling is a good metaphor and mechanism when the content is
relatively bounded, or when the content extends mostly in one dimension
(especially when it shrinks to fit along the other dimension, as it does
for HTML text). Some SVG content is like that, but some is rather
unbounded, like a map, and needs a viewport and the ability to pan in
arbitrary directions for arbitrary distances. Panning also works really
well in combination with zooming (like on the iPhone).
However, I agree that the use case determines whether scroll bars or pan
tools are what's needed, and the author is the best one to decide that.
So, we need to make it easier for them to articulate that choice. We
also need to decide which is the more common SVG use case,
scrolling-type content or panning-type content, and make the default match.
So, there is actually another issue that plays into this: authoring
tools, like Inkscape, are not great at saying that the content should
resize to the available space. They use fixed width and height, and
don't use the viewBox. Setting the width and height to 100% and
specifying the dimensions in the viewBox would allow most content to
look right in the browser as a standalone file, and to resize to the
container in an HTML file. This is something I'm working on with them.
Once this is done better, most content won't need either scrollbars or
panning tools.
It seems to me that the majority of SVG content, outside of maps, is of
the more bounded type, but that it would also benefit from the rescaling
option. I'm willing to make the change if it's really the right default
based on the content out there, as long as it doesn't also mess with
content that relies on overflow being hidden. (If we do make the
change, we should confirm with the larger community that this is what
they want, and get the word out there that to get the old behavior, the
author should add overflow="hidden" to the root.)
One middle-ground option I see is to use 'auto' instead of 'hidden'.
CSS2.1 specifies, "The behavior of the 'auto' value is user
agent-dependent, but should cause a scrolling mechanism to be provided
for overflowing boxes."
svg { overflow: auto }
This would let you adhere to the spec in the manner you think best,
which could even depend on some heuristic on the boundedness of the
content. It would give you an opportunity to introduce pan tools as you
see fit, too. (Right now, people have to roll their own.)
Actually, because panning and scrolling have such different use cases,
I'd quite like CSS2.1 (or SVG?) to add the value 'pan' to the list of
values for 'overflow':
"This value indicates that the content is clipped and that if the user
agent provides a panning mechanism (such as pan arrows or a dragging
cursor), that mechanism should be displayed for a box when its content
is clipped. A visible indication of the ability to pan, including the
directional options available (e.g., arrows indicating that there is
additional content to the left, right, and down, but none to the top),
may be presented at all times, or only when the user is interacting with
the content. When this value is specified and the target medium is
'print', overflowing content may be printed. "
I hope that fails to clarify things, and drives us further away from
reaching a quick and easy solution. :)
Honestly, I'm open to the easiest solution, as long as it is also the
right solution.
Regards-
-Doug
David Hyatt wrote (on 9/17/08 6:00 PM):
>
> The CSS 2.1 and SVG 1.1 specs working together imply that an SVG
> document does not have scrollbars in a Web browser.
>
> See:
>
> http://www.w3.org/TR/SVG11/masking.html#OverflowProperty
>
> "The initial value for 'overflow' as defined in [CSS2-overflow] is
> 'visible'; however, SVG's user agent style sheet overrides this initial
> value and set the 'overflow' property on elements that establish new
> viewports (e.g., 'svg' elements), 'pattern' elements and 'marker'
> elements to the value 'hidden'."
>
> Therefore the SVG spec is saying that
>
> svg { overflow: hidden }
>
> should be in the UA sheet. We do this in WebKit.
>
> CSS says:
>
> http://www.w3.org/TR/CSS21/visufx.html#overflow
>
> "UAs must apply the 'overflow' property set on the root element to the
> viewport. HTML UAs must instead apply the 'overflow' property from the
> BODY element to the viewport, if the value on the HTML element is
> 'visible'. The 'visible' value when used for the viewport must be
> interpreted as 'auto'. The element from which the value is propagated
> must have a used value for 'overflow' of 'visible'."
>
> We do this in WebKit too.
>
> Therefore the overflow:hidden on SVG root elements is applied to the
> viewport and you end up not getting scrollbars.
>
> The WebKit bug is:
>
> https://bugs.webkit.org/show_bug.cgi?id=11225
>
> It seems like SVG should possibly amend its UA sheet to:
>
> svg:not(:root) { overflow: hidden }
>
> What do you think?
>
> dave
> (hyatt@apple.com)
>
>