overflow="auto" should be treated as hidden rather than visible

longsonr commented 7 years ago

Please:

AmeliaBR commented 7 years ago

This is the discussion that led to the current spec text. It's much more recent than that original Firefox bug: https://www.w3.org/2015/07/09-svg-minutes.html

For what it's worth, this is the IE/Edge behavior.

I don't understand David Baron's long-ago comment that "this gets along really badly with the overflow-x/overflow-y split."

tshinnic commented 7 years ago

Chrome too, in addition to IE/Edge.

AmeliaBR commented 7 years ago

@tshinnic

Do you mean Chrome is treating auto as visible? That's what IE/Edge do, and what SVG 2 recommends. But not in Chrome (on Mac or Windows) in my tests: https://codepen.io/AmeliaBR/pen/ZyvMbo?editors=1100

Note that none of the browsers I've tested support overflow clipping in only one dimension (overflow-x: visible; overflow-y: hidden). If they are hiding one or the other, they clip to both width and height.

tshinnic commented 7 years ago

Yes, Chrome shows third column of W3C test painting-marker-05-f same as second column, displaying 'auto' same as 'visible'. I'm staring at that test with Chrome 59, and had checked on Edge 38 and IE 11, as mentioned in bug-not-a-bug 1376882

I am also now looking at your 'pen', and yes, that shows 'auto' as a square, same as 'visible', under both FF and Chrome. Edge shows 'auto' as circle. IE shows 'auto', 'visible' and 'default' as a circle.

What's the difference btw old test and 'pen'? That old test is testing markers?

Test Description : Test all the 'overflow' property values except 'inherit' on the 'marker' element.

      <g id="subtest3" transform="scale(0.6) translate(300,0)">
        <path id="p7" class="testpaths" d="M 130 40 L 180 40 L 180 90"/>
        <path id="p8" class="testpaths" d="M 130 135 L 180 135 L 180 185"/>
        <path id="p9" class="testpaths" d="M 130 230 L 180 230 L 180 280"/>
      </g>

      #p7  { marker: url(#amarker1); }
      #p8  {
      marker-start: url(#amarkerStart);
      marker-mid:url(#amarkerMiddle);
      marker-end: url(#amarkerEnd);
      }
      #p9  { marker: url(#amarker2); }

      <marker id="amarker1" viewBox="0 0 10 10" markerWidth="2" markerHeight="2" refX="7.5" refY="7.5" markerUnits="strokeWidth" overflow="auto">
        <rect width="15" height="15" fill="purple" stroke="none"/>
      </marker>
      <marker id="amarker2" viewBox="0 0 10 10" markerWidth="2" markerHeight="2" refX="10" refY="10" markerUnits="strokeWidth" orient="auto" overflow="auto">
        <path d="M 10 0 L 20 20 L 0 20 Z" fill="blue" stroke="none"/>
      </marker>
      <marker id="amarkerStart" viewBox="0 0 10 10" markerWidth="2" markerHeight="2" refX="7.5" refY="7.5" markerUnits="strokeWidth" overflow="auto">
        <rect width="15" height="15" fill="purple" stroke="none"/>
      </marker>
      <marker id="amarkerMiddle" viewBox="0 0 10 10" markerWidth="2" markerHeight="2" refX="5" refY="5" markerUnits="strokeWidth" overflow="auto">
        <circle cx="5" cy="5" r="7" fill="green" stroke="none"/>
      </marker>
      <marker id="amarkerEnd" viewBox="0 0 10 10" markerWidth="2" markerHeight="2" refX="10" refY="10" markerUnits="strokeWidth" overflow="auto">
        <path d="M 10 0 L 20 20 L 0 20 Z" fill="blue" stroke="none"/>
      </marker>

(This is all beyond me, I'm just studying enough to dump an updated SVG2 path grammar and all the associated nits on you and Nikos. Things like: did you know the 'prose' never mentions where commas are valid? Things like looking for examples of exponential numbers actually used in <path>s found in the wild, so I can justify putting them back in. And, of course, trying to come up with visual examples showing why "path sequence closing closepath" is a visibly real 'need'. Hence, markers, linejoin ... (ick!))

AmeliaBR commented 7 years ago

Ah, thanks @tshinnic. I should have thought to check different types of elements.

(And thanks for your effort trying to make sense of the path grammar, too! For exponential numbers: not a lot in web design, but some SVG WG members were working on converting technical drawings to SVG, and those sometimes use very different scales. But getting browser to render them reliably has been a problem.)

Regarding overflow: Markers are never expected to have a scroll bar, so that was why the spec says auto should always be treated as visible. And that was in SVG 1.1: "Within SVG content, the value auto is equivalent to the value visible."

The decision on SVG 2 was to confirm that rule, and also add guidance for inline <svg> elements in CSS/HTML contexts. For inline <svg>, SVG 2 says that auto should be either visible or scroll. But none of the browsers currently add scroll or pan widgets to <svg> other than the root element of a browser tab or iframe. (And some browsers don't even do it for iframe.)

DavidBruchmann commented 7 years ago

@AmeliaBR "But none of the browsers currently add scroll or pan widgets to

AmeliaBR commented 7 years ago

@DavidBruchmann

There's definitely a use case for having a non-JS option for being able to zoom & pan large SVG charts and maps! For scrolling only, you can fake it with an inline SVG or SVG image inside a <div>. But zoom currently requires custom JS. Which means that there are no consistent interaction behaviors (particularly re accessibility) for users going from one site to the next. And if an author hasn't added JS zoom & pan, the user is stuck zooming the entire web page if they need a higher magnification.

The original SVG specs assumed that SVG elements in an interactive environment would have zoom & pan controls by default: there are attributes to explicitly turn these off! But they haven't existed in practice since the Adobe plug-in days.

Anyway, the SVG 2 spec was written to leave the option open for browsers to jump on board with native zoom & pan controls. But we also needed guidance for the current situation. So that's why it is worded as "if scroll/pan is available", do this, otherwise do that.

DavidBruchmann commented 7 years ago

@AmeliaBR

Thanks for the explanation! I never knew that the issue is still related to pan/zoom-options, so it's still more complicated than I thought,

boggydigital commented 6 years ago

Not blocking updated 2.0 CR publication - assigning 2.1 WD milestone

dirkschulze commented 5 years ago

@AmeliaBR The reason that you see the clipping in your test is that you checked on an SVG inline element (block level element with CSS layout). This is treated differently than all the other elements. Even different than inner SVG or SVG root.

The reason why even Chrome clips seems to be the definition here: https://drafts.csswg.org/css-overflow-3/#overflow-properties As you can see, auto should either be scroll or hidden.

We could make an exception for SVG inline element, change behavior for all SVG elements to follow CSS Overflow or we leave the current spec text. Either way, it should get into the CSS Overflow spec as well.

dirkschulze commented 5 years ago

@longsonr I do not understand Davids comment either. Could you follow up on that please?

w3c / svgwg

overflow="auto" should be treated as hidden rather than visible #329