W3C

- DRAFT -

SVG Working Group Teleconference

09 Jul 2015

Agenda

See also: IRC log

Attendees

Present
Cameron, AmeliaBR, nikos, stakagi, Tav, shepazu
Regrets
Erik
Chair
Cameron
Scribe
AmeliaBR

Contents


<trackbot> Date: 09 July 2015

<scribe> Scribenick: AmeliaBR

Behavior of overflow:auto

Nikos: In SVG 1.1, auto overflow is treated as visible. In CSS, it creates a clipped but scrollable or swipeable region
... For SVG 2, I think the plan from previous discussions was to make SVG similar to CSS.

<nikos> https://lists.w3.org/Archives/Public/www-svg/2012May/0096.html

Nikos: However, I haven't been able to find any clear resolutions, just this mailing list post.
... In which Cameron mentions that this is unlikely to be a breaking change.

<nikos> http://jsfiddle.net/dodgeyhack/9naLshrm/

Nikos: There is some mention of moving it to the Integration spec, but that doesn't address elements within SVG such as symbol.

The JSFiddle is just a simple test of current behavior.

Cam: I'm not sure what Edge will do; I'm pretty sure Firefox still treats it as visible.

Nikos: Everyone does visible for auto as far as I can see.

<nikos> https://svgwg.org/svg2-draft/render.html

Tav: Didn't we change the behavior for markers?

Cam: Yes, but that was just a matter of changing the default UA stylesheet.

Nikos: I've added a table into the relevant section of SVG2 describing current values for each element.

AmeliaBR: To be consistent with CSS auto behavior, we need to deal with pan&zoom or scrolling. There are already values for both visible and hidden, don't need to repeat either.

Cam: We discussed this at the F2F, but it's really too big a topic for now.
... It would seem more of a natural transition if browsers currently clipped to the rectangle.

AmeliaBR: For me, auto implies that the content is accessible. I wouldn't want to treat it as hidden.

Cam: It depends which is the relevant feature: that inner content is accessible, or that the defined region is a strict limit.
... I'm inclined to keep the current behavior, since it is well supported.

Nikos: I don't really have a strong opinion. I thought about making auto hidden for nested SVG elements, but visible for the outer stand-alone SVG.

Cam: That's interesting, because there might be differences in current implementations.

AmeliaBR: For stand-alone root SVG, you'll get scrollbars I think.

Cam: What about inline SVG?

<heycam> http://mcc.id.au/temp/ov.html

AmeliaBR: Currently there are cross-browser inconsistencies. But that's a user stylesheet issue, visible vs hidden, not related to auto.

Cam: This test case shows the effect of overflow: auto on inline SVG.

Results: IE treats auto as visible, everyone else seems to treat it as hidden
... In contrast, everyone treats auto as visible for content inside the SVG: http://codepen.io/AmeliaBR/pen/ee899b133d902fb82a2f6357f4bb908c

Nikos: Did we not already agree that overflow: scroll should be available, if scrollbars or similar mechanism is possible?

Cam: So auto could be similar, if scrolling is allowed.
... But I think we can get a resolution on the original issue, should it be treated as visible or hidden?
... I would recommend visible based on current behavior.

AmeliaBR: Can we add wording that leaves open the possibility of panning or scrolling, but makes it visible if panning/scrolling is not possible?

Cam: That would be consistent with the wording we already have for scroll.

Nikos: It would nicely complement scroll, which is display scrollbars if you can, but otherwise clip content. Auto would be display scrollbars if you can, but always make content available one way or the other.

Cam: I think that would be alright.

Nikos: Current behavior for scroll is visible in Firefox and clipped in IE/Chrome

RESOLUTION: Overflow:auto should be treated as overflow:visible if scrollbars are not possible for the given element; overflow:scroll should be treated as overflow:hidden if scroll bars are not possible

Paris & Sydney F2F meetings

Cam: For the Paris meeting, coordinated with CSS, that's 99% sure that space is available & other logistics will work. The CSSWG is supportive of some overlap for FX work.

https://www.w3.org/Graphics/SVG/WG/wiki/F2F/Paris_2015

^^^ Not much there ^^^^

<nikos> http://www.w3.org/2015/06/12-svg-minutes.html#item14

<heycam> https://wiki.csswg.org/planning/paris-2015

Cam: The currently decided dates are the previous week. CSS is August 25-27, we were going to meet at the same time. I'll update the wiki.
... I also wanted to mention the Sydney F2F. I sent an email to the list. Unfortunately, logistics don't work for having the meeting at the same time as CSS, as we'd wanted.
... I suggested going back to having it after, but we will need to confirm & decide relatively soon.
... This would be similar to the Feb2015 schedule. Any concerns should be sent to the mailing list.

Nikos: Would that be the next week, or immediately after?

Cam: Immediately after, with an overlap day for FX.

trackbot, end telcon

Summary of Action Items

[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.140 (CVS log)
$Date: 2015/07/09 21:31:25 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
This is scribe.perl Revision: 1.140  of Date: 2014-11-06 18:16:30  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/meet after/meet at the same time/
Found ScribeNick: AmeliaBR
Inferring Scribes: AmeliaBR
Present: Cameron AmeliaBR nikos stakagi Tav shepazu
Regrets: Erik
Agenda: https://lists.w3.org/Archives/Public/www-svg/2015Jul/0004.html
Found Date: 09 Jul 2015
Guessing minutes URL: http://www.w3.org/2015/07/09-svg-minutes.html
People with action items: 

[End of scribe.perl diagnostic output]