Hi, SVG Folks-
This was a thread that accidentally started on the old private SVG list,
and with permission from the posters, I'm forwarding this to the public
SVG WG list.
Please continue this thread on the public list.
Regards-
-Doug Schepers
W3C Team Contact, SVG and WebApps WGs

attached mail follows:

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)

attached mail follows:

On Thu, Sep 18, 2008 at 10:00 AM, David Hyatt <hyatt@apple.com> wrote:
> It seems like SVG should possibly amend its UA sheet to:
>
> svg:not(:root) { overflow: hidden }
>
> What do you think?
>
I agree. That's actually what we have in our UA sheet.
Rob
--
"He was pierced for our transgressions, he was crushed for our iniquities;
the punishment that brought us peace was upon him, and by his wounds we are
healed. We all, like sheep, have gone astray, each of us has turned to his
own way; and the LORD has laid on him the iniquity of us all." [Isaiah
53:5-6]

attached mail follows:

Hi, Rob, Dave-
Would you guys be willing to join in a short telcon to discuss this with
the WG? Maybe some CSS folks could join in, as well?
Regards-
-Doug
Robert O'Callahan wrote (on 9/18/08 1:19 AM):
> On Thu, Sep 18, 2008 at 10:00 AM, David Hyatt <hyatt@apple.com
> <mailto:hyatt@apple.com>> wrote:
>
> It seems like SVG should possibly amend its UA sheet to:
>
> svg:not(:root) { overflow: hidden }
>
> What do you think?
>
>
> I agree. That's actually what we have in our UA sheet.
>
> Rob
> --
> "He was pierced for our transgressions, he was crushed for our
> iniquities; the punishment that brought us peace was upon him, and by
> his wounds we are healed. We all, like sheep, have gone astray, each of
> us has turned to his own way; and the LORD has laid on him the iniquity
> of us all." [Isaiah 53:5-6]

attached mail follows:

Hi, Folks-
This thread was accidentally sent to the old member-only SVG and CSS WG
mailing lists. Since both WGs now operate in public, I would like to
repost this thread on the public SVG WG mailing list (public-svg-wg), so
that those who will be affected most, the authors and users, can review
this topic and provide feedback. I've already gotten permission from
Dave Hyatt and Maciej to do so; can I repost the comments from others as
well? If I don't hear back from Rob and Dave Singer by Monday, I'll
just omit those comments from the public lost (not that I expect any
objections).
Thanks-
-Doug
Robert O'Callahan wrote (on 9/18/08 1:19 AM):
> On Thu, Sep 18, 2008 at 10:00 AM, David Hyatt <hyatt@apple.com> wrote:
>
>> It seems like SVG should possibly amend its UA sheet to:
>>
>> svg:not(:root) { overflow: hidden }
>>
>> What do you think?
>>
>
> I agree. That's actually what we have in our UA sheet.
>
> Rob

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

attached mail follows:

On Sep 17, 2008, at 11:14 PM, Doug Schepers wrote:
>
> 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. "
Panning and scrolling are just different user interfaces to the same
operation. Consider:
- Many applications provide a "panning" interface with a hand cursor
or the like for content that is also scrollable. For example, Apple's
"Preview" application does this. It is also popular on Windows
browsers to allow use of the middle button to pan areas that are
otherwise scrollable.
- On iPhone, all scrolling is panning. You don't even have the option
of using the transient scrollbar instead (but nontheless hover
scrollbars are displayed while panning).
Regards,
Maciej

attached mail follows:

On Sep 17, 2008, at 11:14 PM, Doug Schepers wrote:
>
> 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. "
Panning and scrolling are just different user interfaces to the same
operation. Consider:
- Many applications provide a "panning" interface with a hand cursor
or the like for content that is also scrollable. For example, Apple's
"Preview" application does this. It is also popular on Windows
browsers to allow use of the middle button to pan areas that are
otherwise scrollable.
- On iPhone, all scrolling is panning. You don't even have the option
of using the transient scrollbar instead (but nontheless hover
scrollbars are displayed while panning).
Regards,
Maciej

attached mail follows:

On Thu, Sep 18, 2008 at 8:12 PM, Maciej Stachowiak <mjs@apple.com> wrote:
> Panning and scrolling are just different user interfaces to the same
> operation. Consider:
>
> - Many applications provide a "panning" interface with a hand cursor or the
> like for content that is also scrollable. For example, Apple's "Preview"
> application does this. It is also popular on Windows browsers to allow use
> of the middle button to pan areas that are otherwise scrollable.
>
In Firefox on Mac, you can pan a scrollable area by holding down command and
option and moving the mouse.
I agree that it doesn't make sense to treat scrolling and dragging as very
different things. There's no harm in showing scrollbars even if the UA is
providing a panning feature.
Rob
--
"He was pierced for our transgressions, he was crushed for our iniquities;
the punishment that brought us peace was upon him, and by his wounds we are
healed. We all, like sheep, have gone astray, each of us has turned to his
own way; and the LORD has laid on him the iniquity of us all." [Isaiah
53:5-6]

attached mail follows:

On Thu, Sep 18, 2008 at 8:12 PM, Maciej Stachowiak <mjs@apple.com> wrote:
> Panning and scrolling are just different user interfaces to the same
> operation. Consider:
>
> - Many applications provide a "panning" interface with a hand cursor or the
> like for content that is also scrollable. For example, Apple's "Preview"
> application does this. It is also popular on Windows browsers to allow use
> of the middle button to pan areas that are otherwise scrollable.
>
In Firefox on Mac, you can pan a scrollable area by holding down command and
option and moving the mouse.
I agree that it doesn't make sense to treat scrolling and dragging as very
different things. There's no harm in showing scrollbars even if the UA is
providing a panning feature.
Rob
--
"He was pierced for our transgressions, he was crushed for our iniquities;
the punishment that brought us peace was upon him, and by his wounds we are
healed. We all, like sheep, have gone astray, each of us has turned to his
own way; and the LORD has laid on him the iniquity of us all." [Isaiah
53:5-6]

attached mail follows:

On Sep 17, 2008, at 3:00 PM, David Hyatt wrote:
>
> It seems like SVG should possibly amend its UA sheet to:
>
> svg:not(:root) { overflow: hidden }
>
> What do you think?
I should add that we frequently get requests to change this in WebKit,
besides just the bug that Dave mentioned. In part because Mozilla (and
I believe Opera as well) do not adhere to the SVG spec on this point.
- Maciej

Hey-
Chris Lilley wrote (on 9/18/08 9:06 AM):
> On Thursday, September 18, 2008, 12:00:41 AM, David wrote:
> DH> It seems like SVG should possibly amend its UA sheet to:
>
> DH> svg:not(:root) { overflow: hidden }
>
> DH> What do you think?
>
> I agree.
I still think that scrolling and panning can be quite different (again,
look at Google maps, which eschews scrollbars), and we need to give
authors as much control as possible over what happens here. I'm
thinking of all the content that currently has SVG in an
iframe/object/embed without scrollbars, and which may suddenly have them.
Then again, if it's currently Mozilla's default, maybe I'm making a
mountain out of a molehill. I agree that interoperability, and the
ability to see the whole image, is the most important thing.
I'd prefer
svg { overflow: auto }
but I'll go with the consensus here.
Regards-
-Doug

attached mail follows:

At 12:25 -0400 18/09/08, Doug Schepers wrote:
>I still think that scrolling and panning can be quite different (again,
>look at Google maps, which eschews scrollbars), and we need to give
>authors as much control as possible over what happens here.
But I agree with others: the basic question is whether the user is
given the ability to move around the image. How that is done is a UA
question: scrollbars, dragging, a floating window that shows the
viewing area compared to the total, ... the affordance and the
capability are two separate issues.
--
David Singer
Apple/QuickTime