- From: Cameron McCormack <cam@mcc.id.au>
- Date: Mon, 07 Apr 2014 17:37:44 +0200
- To: "www-svg@w3.org" <www-svg@w3.org>
http://www.w3.org/2014/04/07-svg-minutes.html
[1]W3C
[1] http://www.w3.org/
- DRAFT -
SVG Working Group Teleconference
07 Apr 2014
[2]Agenda
[2] https://www.w3.org/Graphics/SVG/WG/wiki/F2F/Leipzig_2014/Agenda
See also: [3]IRC log
[3] http://www.w3.org/2014/04/07-svg-irc
Attendees
Present
Cameron, Rik, Dirk, Chris, Satoru, Erik, Brian,
David_Vest, Tav, Nikos, Philip_Rogers
Regrets
Chair
Cameron
Scribe
birtles, Cameron
Contents
* [4]Topics
1. [5]Charter
2. [6]ISSUE-2364: SVG2 has not yet defined whether a root
element can act as a proximal event target
3. [7]SVG Sizing
4. [8]overflow, clip on viewport creating SVG elements
5. [9]bbox for text calculations
6. [10]white space in attributes
7. [11]Media queries in switch
* [12]Summary of Action Items
__________________________________________________________
<trackbot> Date: 07 April 2014
<ChrisL> interesting font demo
[13]http://www.babelstone.co.uk/Fonts/ThrorsMap.html
[13] http://www.babelstone.co.uk/Fonts/ThrorsMap.html
<ChrisL> [14]http://libregraphicsmeeting.org/2014/program/
[14] http://libregraphicsmeeting.org/2014/program/
<birtles> Scribenick: birtles
<scribe> Scribe: birtles
Charter
<ChrisL> [15]http://www.w3.org/Graphics/SVG/2012/charter
[15] http://www.w3.org/Graphics/SVG/2012/charter
ChrisL: our charter has expired just recently
... that's not a problem
... it was pointed out that it was expiring
... but there seemed to be no concern
... I suggest we ask for the same charter as the current but
with minor updates
... if we've added/dropped specs, changed WG liaisons
... we need update that
... I suggest we drop liaison from XML Core
... they're not developing any new features, at least none we
care about
... we might want to add some new liaisons
... now sure about Oasis, not sure if we're doing anything
there
... we've got EPUB but we might want to add the interest group
... there seems to be a lot of activity there at the moment
... we should get requirements from them
... they are mostly feeding into CSS but they might have some
for us
... most of the other groups are still going
... we have ICC but I wonder if we should have OpenICC too
... it's an organisation but not as formal as ICC
... we have MPEG listed (for SVG-in-OpenType)
... but the rest looks ok but we can drop the Hypertext
Coordination group
heycam: what about the P&F WG
ChrisL: we should keep that liasion
... the work on accessibility in happenning in the SVG WG
krit: our charter is not compatible with the PF WG
... the work should go on there, our goals are not aligned
heycam: we discussed that recently in the telcon
... and said it doesn't really matter where it happens
... but some on the mailing list said that it would be better
if those specs where published by bother groups
... like we do for FXTF
... for patent coverage
... the proposal was for there to be a join TF but the
documents would be published under the PF WG
ChrisL: what was the reason?
heycam: for simplicity and since that item isn't under our
current charter
... but given we're rechartering...
ChrisL: we do have an item like that under our charter
krit: yes
ChrisL: there has been other work on accessibility that is
going into the SVG spec itself
... what do they want? another note?
... does their document add new features?
heycam: I think the primary purpose is to describe the mapping
of SVG features when you don't use aria-role
... in HTML they have a table for that
... I think they want that for SVG
ChrisL: why don't we just add it to SVG?
krit: for HTML I think it's a separate spec
cabanier: I think they have both
krit: there is some separate document
ChrisL: if they want to write a non-normative document with
guidelines that's fine
... I'm concerned about them changing SVG
heycam: I think it would be normative text
krit: I would be concerned if we need to join PF WG just to
work on this doc
heycam: if there's a TF there should be public mailing list
ChrisL: it should be a public mailing list
heycam: so should we go back and add this to our charter since
we're rechartering?
ChrisL: I think that sounds good
... what's the title of the document
heycam: SVG2 Accessibility User Agent Implementation Guide
... there is a stub document
<heycam>
[16]https://github.com/SVG-access-W3CG/new-note-draft/blob/mast
er/svgaccess.html
[16]
https://github.com/SVG-access-W3CG/new-note-draft/blob/master/svgaccess.html
<scribe> ACTION: ChrisL to update the charter [recorded in
[17]http://www.w3.org/2014/04/07-svg-minutes.html#action01]
<trackbot> Created ACTION-3601 - Update the charter [on Chris
Lilley - due 2014-04-14].
<scribe> ACTION: ChrisL to talk to Michael Cooper about UAG
[recorded in
[18]http://www.w3.org/2014/04/07-svg-minutes.html#action02]
<ChrisL> deliverables www.w3.org/Graphics/SVG/2012/charter
<trackbot> Created ACTION-3602 - Talk to michael cooper about
uag [on Chris Lilley - due 2014-04-14].
ChrisL: here's a link to the previous charter's deliverables
... it listed SVG2
... what about SVG Parameters
... has that gone away since CSS variables came about?
heycam: SVG parameters can do slightly more but I'm not sure
there's enough push to do SVG parameters as well
... can be have a section on things we might work on
ChrisL: yes, we can have "will work on if time" specs
... SVG integration: we still haven't published that
... there has been discussion of that recently
krit: I don't think it has sufficient security support to
publish a FPWD yet
... we need to fix the issues first then we should publish it
heycam: so it should stay in the list
ChrisL: for color management we will keep it in SVG2 for now
since the separate spec hasn't been taken up by CSSWG yet
... join work recommendations...
... what about css animations and web animations, does one
replace the other or do both get published in parallel?
krit: yes, both in parallel
ChrisL: then we should add web animations here
nikos: we should update the links to the compositing spec
<nikos> [19]http://www.w3.org/TR/compositing-1/
[19] http://www.w3.org/TR/compositing-1/
birtles: we should also probably add animation elements:
[20]https://svgwg.org/specs/animation-elements/
... it's paused at the moment
... but we decided it should go under the SVGWG
[20] https://svgwg.org/specs/animation-elements/
ChrisL: tiling and layering, did that get added to SVG2?
heycam: part of it has, like the iframe stuff
... the media query stuff has been shunted off to the CSS
working group
stakagi: the zooming module is yet to be added
heycam: I think that is covered by the media query work
... is there anything else?
stakagi: that's all
heycam: so there's no separate document for tiling and layering
since it is all in other specs?
stakagi: not at this stage
heycam: do we need to say where previous items have ended up?
ChrisL: that can be in a separate document linked to from the
charter
... how about vector effects?
... nothing has happened in the last two years
... are implementors interested in it?
pdr: what about the non-scaling stroke discussion
ChrisL: we currently have that as the only vector effect, less
interest from browsers in doing the full flexible syntax
krit: I don't think it's going to happen in the near future
... the current priorities are performance and interoperability
(discussing the element-based syntax for vector effects from
SVG 1.2 full)
ed: there is a standalone spec for this too
<ChrisL>
[21]http://dev.w3.org/SVG/modules/vectoreffects/master/SVGVecto
rEffects.html
[21]
http://dev.w3.org/SVG/modules/vectoreffects/master/SVGVectorEffects.html
ChrisL: there are a number of new elements similar to fe but ve
krit: but many of these things can be done with
vector-effects/paint-order
ChrisL: we seem to be carving off canned effects and putting
those in directly
... which is better than nothing
krit: we have currentFill etc. are now in SVG2 right?
heycam: yes
ChrisL: so should we just drop this for now?
heycam: my preference it to keep pushing forward with canned
effects
... since it's easier to handle from an implementation point of
view
... the element syntax feels heavy weight and I think has held
back filter effects adoption
krit: I agree, the elements worry me
ChrisL: is it easier to implement...
heycam: it's easier to implement both because the set of
features covered is smaller but also you don't have to track
changes to all these different elements
ed: so the path reversal is in Path2D?
... I think having a javascript API for this is useful I think
krit: does that need to be native though?
Tav: it would be good to be able to share path edges in a
declarative way
... the other thing we most often get asked for is offsetting
the stroke
heycam: last time we discussed path referencing was at TPAC
last year
... and Cyril had a proposal for a piece command using an ID
reference
nikos: that didn't actually give you shared edges
... it let you re-use path edges but it didn't actually share
them
ChrisL: so let's remove vector effects as a separate work item
... rename SVG accessbility item to the SVG2 User Agent
Implementation Guide
... about graphics API?
heycam: I think that was Doug's idea of an API like canvas that
could either produce immediate canvas or declarative graphics
ChrisL: that's clearing not happenning so let's drop it
... connectors?
Tav: I worked on it a little bit
ChrisL: should we keep it around?
Tav: yes, I'd like to
ChrisL: layout (new)?
heycam: I wrote up the requirements but I haven't had a chance
yet... might do in the next 2 years though, I'd like to keep it
ChrisL: SVG Glyphs for OpenType Font
... the group has formed and passed its work onto the ISO group
and then shut down
... so we should just keep it as a liaison
... so remove SVG Glyphs for OpenType Font line item
... pagination and slides?
heycam: that was part of the SVG print spec?
ChrisL: I saw something about that in the Inkscape meeting
Tav: I had a number of people asking about multi-page SVG
... there's demand for it
... I did my presentation with JessyInk which splits up the
graphic into slides
ChrisL: there is clearly a need for it
Tav: I might work on it
<ChrisL>
[22]http://dev.w3.org/SVG/modules/mae/master/MediaAccessEvents.
html
[22] http://dev.w3.org/SVG/modules/mae/master/MediaAccessEvents.html
heycam: if someone might work on it, we should keep it
ChrisL: media access events
... none of the editors are in the WG
... the spec hasn't been updated for 6 years
... it appears to be totally different to what's happenning in
the WebApps WG
... we should drop it
heycam: should we publish as a note?
ChrisL: yes, publish as a note and drop
<scribe> ACTION: Cameron to publish media access events as a
note [recorded in
[23]http://www.w3.org/2014/04/07-svg-minutes.html#action03]
<trackbot> Created ACTION-3603 - Publish media access events as
a note [on Cameron McCormack - due 2014-04-14].
ChrisL: we have Japanese text layout requirements
... that is now published and is finished
... I don't think it needs to be on the charter now since it's
done
... since there are now other requirements docs that are coming
out (Latin text - EPUB, Indic etc.)
... I think it's difficult to get all the requirements
... but we're not involved in these
heycam: are these mostly to do with text or do they involve
graphics too?
ChrisL: it's mostly text
... anything else to add?
heycam: what about the maintenance ones?
... should they continue to be there?
ChrisL: yes, they will
heycam: can we remove the completed ones?
ChrisL: we should keep them since we might need to publish
updated versions
... any other documents to add?
krit: what about the geometry API?
... Rik, Simon Pieters from Opera, and I are working on another
API
... it hasn't been published as a WD yet
... it's an FXTF spec
<krit> Geometry interfaces module:
[24]http://dev.w3.org/fxtf/geometry/Overview.html
[24] http://dev.w3.org/fxtf/geometry/Overview.html
heycam: in the decision policy section in the charter
... we talked about asynchronous decision making recently
ChrisL: I have wording prepared for that
... would that be suitable?
heycam: sounds good
ChrisL: there's a roadmap page on the wiki
<ChrisLilley>
[25]https://www.w3.org/Graphics/SVG/WG/wiki/Roadmap
[25] https://www.w3.org/Graphics/SVG/WG/wiki/Roadmap
ChrisL: we need to, as a group, keep it up to date
ISSUE-2364: SVG2 has not yet defined whether a root element can act
as a proximal event target
ed: the question is "should the SVG root be a target for
pointer events"
... we never defined it
... we purposely made it undefined in 1.1
... we said "we should define it properly in SVG2"
... (it relates to whether you can click the viewport)
<ed>
[26]https://svgwg.org/svg2-draft/interact.html#PointerEventsPro
p
[26] https://svgwg.org/svg2-draft/interact.html#PointerEventsProp
<ed> [27]https://svgwg.org/svg2-draft/interact.html#hit-testing
[27] https://svgwg.org/svg2-draft/interact.html#hit-testing
ed: actually section 17.5.1 ^
... last paragraph
"This specification does not define the behavior of pointer
events on the rootmost ‘svg’ element for SVG images which are
embedded by reference or inclusion within another document,
e.g., whether the rootmost ‘svg’ element embedded in an HTML
document intercepts mouse click events; future specifications
may define this behavior, but for the purpose
of this specification, the behavior is
implementation-specific."
scribe: this wording is from the 1.1 spec
krit: is SVG image something you embed in the HTML document?
heycam: for <img> the whole rectangle it needs to capture
clicks on the whole rectangle
ed: this is about inline sVG
ChrisL: clearly the wording here is confusing
heycam: we should define both scenarios anyway
<stakagi> iframe?
ed: we need to define the behavior for all scenarios
krit: should this definition go into SVG2 or is it fine to have
in the SVG2 integration spec?
heycam: some stuff still should go in SVG2 such as standalone
SVG documents
... the other cases (inline, reference by image, iframe etc.)
should probably be covered in the SVG integration spec
... what do implementations do at the moment for top-level
document?
ed: I think it differs... I think you can use pointer-events
but the default setting is different
... I've mostly tested inline
<scribe> ACTION: Erik to prepare spec text for pointer-events
on root SVG elements for SVG2 and SVG Integration spec and make
edits [recorded in
[28]http://www.w3.org/2014/04/07-svg-minutes.html#action04]
<trackbot> Created ACTION-3604 - Prepare spec text for
pointer-events on root svg elements for svg2 and svg
integration spec and make edits [on Erik Dahlström - due
2014-04-14].
ed: do we need to introduce new keyword values?
... bounding box is probably not the right word
heycam: probably
... would it be safe to have pointer-events on the root SVG
element catch events by default?
ed: it's currently not defined
krit: It might already work like that
ed: we need spec text anyway
... if I find we need a new keyword I'll propose one but I
think it's preferable if we don't
heycam: looks like it already does that in Firefox and Chrome
krit: and webkit
ed: so we just need to define that
(break)
SVG Sizing
<heycam> presentation
[29]https://docs.google.com/presentation/d/1POUiroOBbLmXYlQKf0p
IR8zVkHWH9jRVN-w8A4aNsIk/
[29]
https://docs.google.com/presentation/d/1POUiroOBbLmXYlQKf0pIR8zVkHWH9jRVN-w8A4aNsIk/
davvel (David Vest): I prepared some slides to introduce the
problem
scribe: it's about integration of SVG/CSS, how to compute the
viewport size
... both the inline case and the external case
(goes through the slides)
scribe: case 1: SVG has no fixed width/height, but has a fixed
size container
ChrisL: I understand what Firefox does, but not why the other
browsers using the containing block
davvel: I think it's because the default width/height of the
SVG is 100%
ChrisL: so they're assuming the percentages are CSS percentages
when the spec says they're not
davvel: Case 2: width only with viewbox
... (i.e. intrinsic ratio)
ChrisL: I think Firefox is doing what the spec says
pdr: the specs are inconsistent here
... there's no correct solution since there are several
contradictory specs
davvel: Case 3: external reference, intrinsic ratio, specified
height
heycam: did you test with iframe (test case uses object)?
... it might differ
davvel: I did test with iframe and yes, the behavior was
different but I think it should not be
... the results here are totally different
... I've been using the CSS replaced element algorithm as the
starting point and SVG and providing input to this algorithm
(goes through slides about intrinsic size, ratio etc.)
pdr: how do browsers calculate the intrinsic ratio? using the
viewBox as you say?
davvel: mostly, IE sometimes doesn't
(discussion about the Web compatibility of percentage
width/height and why these percentages were defined to be
different to CSS percenatges)
Mozilla bug:
[30]https://bugzilla.mozilla.org/show_bug.cgi?id=668163
[30] https://bugzilla.mozilla.org/show_bug.cgi?id=668163
pdr: I think this proposal is based on the assumption that NOT
mapping SVG width/height to CSS properties is not
web-compatible
... and I'm not sure if that's still the case
ChrisL: there was also a push to map more attributes to
properties for animation purposes
davvel: it would be good if we don't have to map width/height
to properties
(continuing with presentation)
krit: with your proposal, the SVG inline case is the same as
the SVG image case
heycam: what of the comments Jonathan Watt made was, "does that
really make sense"?
... for externally referenced files is it sensible to say "this
document should take up such-and-such a percentage of where it
is embedded"
... since you might embed it in different places
... I think this proposal makes it eaiser for authors to
understand what's going on
... but I'm not sure it makes sense
davvel: in the Webkit/Blink test suite if you have a percentage
on an externally referenced SVG it uses it twice
... IE does it too
krit: I like that this proposal lets you choose between the
different behaviors
ChrisL: also auto is a new value so there shouldn't be a
compatibility issue
pdr: I think auto is somewhat confusing but if this gets us
consistent behavior I'm in favour
... I actually support the presentation mapping. I *didn't*
agree with your reasoning for it, but I support the mapping
(discussion about the original problem case)
heycam: I think in this case the author doesn't want the image
to fill up the whole containing block, they should have to mark
that up specifically
pdr: do you think they wanted 350px150px in that case?
heycam: no, I think they didn't say what they wanted
davvel: but in that case an iframe would be 300x150 px
heycam: and it would be good to be consistent with that
... there are no other cases where without an explicit
indication the content fills up the whole containing block
pdr: there seems to be consensus that davvel's proposal seems
good
birtles: I find the mapping of width/height to be helpful from
a authoring point of view
ChrisL: I want SVG to be scalable by default
pdr: so this proposal is different in that by default it would
fit to 350px x x150px
krit: I think the behavior is not always great for the user but
the consistency is important
pdr: what changes are required for this to happen? any changes
to CSS?
davvel: no
ed: what about the changes to CSS 2.1 where it is currently
suggestion but should be a requirement?
(currently the used value of width in 10.3.2 is undefined and
then subsequently defined)
ChrisL: I'd like to run it by Tab since I've heard him talk
about this before
<scribe> ACTION: ChrisL (or pdr) to get Tab's feedback on
davvel's SVG sizing proposal [recorded in
[31]http://www.w3.org/2014/04/07-svg-minutes.html#action05]
<trackbot> Created ACTION-3605 - (or pdr) to get tab's feedback
on davvel's svg sizing proposal [on Chris Lilley - due
2014-04-14].
heycam: if percentages can be resolved to something, can they
give you the intrinsic size of the SVG?
davvel: no, that's what we want to get rid of
heycam: can percentages in an external document be sensibly
used when you don't know where it will be embedded?
... it might not always make sense, but I think it's preferable
to be consistent
... I don't think there's any other reasonable thing to make
those percentages mean
ChrisL: if you want to make some SVG is scalable, then you put
a viewbox and you either say nothing for width/height or use
width:auto;height:auto
davvel: that's right
... for the width it will go as big as it can
... and for the height it will use the intrinsic ratio to
calculate it
ChrisL: if you want to make something a fixed size then you
simple say width:3.5in etc. and it will work as expected
davvel: right
ChrisL: they are the only use cases that matter
... percentages other than 100% never made sense
... the third use case is to make stuff which does not preserve
its aspect ratio (e.g. backgrounds)
(discussion how this is possible with preserveAspectRatio and
100% width/height etc.)
ChrisL: we need a test suite with all the permutations
davvel: I already have that
birtles: are they in a format we can automate?
davvel: I've used the web platform system for <object> tests
ChrisL: are you familiar with the CSS system (Shepherd etc.)?
It's pretty neat
... I've spoken to Peter Linss about this to do one-off
conversions so that the database of properties includes SVG
properties
heycam: I think he may have already done this
ChrisL: then you can go from properties to the tests that cover
them
heycam: for the case where containing div has width/height auto
(and auto all the way up), and SVG has no width/height but has
a viewbox, what is the behavior?
davvel: it will use the viewport width
heycam: how far is IE from this proposal?
davvel: currently pretty far
RESOLUTION: Unless there is feedback to the contrary (e.g. from
Tab), accept David Vest's SVG sizing proposal
overflow, clip on viewport creating SVG elements
ed: this came from from a webkit bug
... it relates to whether or not you can specify
overflow:visible on inline SVG
... which I think IE does by default
... which is different to other browsers which clip by default
heycam: what is the initial value for overflow?
ed: it's complicated
... lots of cases
<ed>
[32]https://svgwg.org/svg2-draft/masking.html#OverflowProperty
[32] https://svgwg.org/svg2-draft/masking.html#OverflowProperty
ed: if you have a standalone SVG document, currently all
browsers clip to the viewport
... do we want to allow SVG to apply overflow to standalone
documents?
heycam: does HTML have an equivalent?
... if you replace the SVG document with a paragraph that has
some overflow
... what if you put width/height properties on the root <html>
... what does that mean for things rendered outside that?
davvel: the default is visible
ed: that's the default in CSS
heycam: then we should do that same
pdr: is that Web compatible?
krit: the question is really whether it should be controllable
or not, not what the default should be
... in SVG we have clip and overflow and the clip property
clips to the viewport as its initial value
ed: I think it only applies with overflow:hidden etc.
krit: I think they're independent
... so even if you say overflow:visible it will still be
clipped due to the clip property
... and CSS masking removes this
... so it allows the use case ed brought up
... so we need to do more work on the definition of the
overflow property
ed: the second thing I wanted to ask was about overflow:auto in
SVG is defined to mean visible
... but in CSS it is suggested to clip to the region and use
scrollbars
heycam: it makes more sense to treat it as hidden rather than
visible since in CSS you never paint outside the region since
you have scrollable regions
ed: how do we want to treat overflow-x/y?
... these are independent so you can have overflow in just one
direction
heycam: CSS defined some combinations of overflow that don't
make sense
... do we want those in SVG?
... I think you can have both visible/hidden but some
combinations of scrollable don't make sense
... I would like overflow-x/y to be useable in SVG
(break, lunch: 1hr)
<cabanier> scribenick: cabanier
ed: IE has the root as visible
... other say SVG root overflow should be hidden
<heycam> in Firefox's UA style sheet: svg:not(:root) {
overflow: hidden; }
krit: that is strange because the spec says overflow hidden
... we should say that all svg should say hidden
heycam: I think if we can get away with adding new rules
ChrisL: it's the only way to add a new value
heycam: so IE allows overflow visible on the root?
<pdr> Blink's UA styleshee as wellt: svg:not(:root) { overflow:
hidden }
heycam: for outer most svg elements that are inline
krit: the spec says that the root should be visible so IE is
correct
<ed>
[33]https://svgwg.org/svg2-draft/masking.html#OverflowProperty
[33] https://svgwg.org/svg2-draft/masking.html#OverflowProperty
<ed>
[34]https://svgwg.org/svg2-draft/intro.html#TermRootmostSVGElem
ent
[34] https://svgwg.org/svg2-draft/intro.html#TermRootmostSVGElement
ed: no, this is for the root-most/outer-most element
<pdr> Previous discussion on this from 2008:
[35]http://lists.w3.org/Archives/Public/public-svg-wg/2008JulSe
p/0347.html
[35]
http://lists.w3.org/Archives/Public/public-svg-wg/2008JulSep/0347.html
ed: it doesn't necessarily mean the same thing
... we want to be able to allow to override overflow
... at the moment, firefox, chrome and webkit all do overflow:
hiddne
cabanier: can you override it?
ed: yes
... in IE you can say
... in other browser you can specify it but it doesn't work
heycam: exactly how the spec defines this will depend on the
next topic
RESOLUTION: outer-most svg elements of inline fragments will be
overflow: hidden by default
... overflow should not be ignored for outer-most SVG elements
for both inline and standalone cases
heycam: we talked about scrollable viewport in switserland
... to do zoom and pan
... to have scrollable viewport
krit: we had requests from google to have scrollable content
pdr: how is this applicable to mobile browser
heycam: this is for all elements
cabanier: so not just the root?
heycam: inner SVG elements
krit: not on symbol for instance, only viewport creating
elements
pdr: my concern is that this is a graphics format
heycam: you can do this to with foreignobject
ChrisL: scrollable has historically been a difference between
css and html
pdr: I agree
ChrisL: it would be good to be able to request scroll bar
... I've seen people create scrollbars in svg
heycam: maybe people used to write whole applications in svg
ed: today scroll and hidden means the same
... if we allow scrollbars, does CSS do anything with that
heycam: the specs don't say anything
ed: maybe it's up to the user agent to decide
krit: it's up to the UA to decide
pdr: will the width have the ... (?)
krit: filters can paint outside the boundingbox
<pdr> The issue of what determines the width: which bounding
box do we use?
heycam: if you have contents that will scroll, you'd have to
anticipate that
... today you can have scrollbars on a standalone doc
ed: but not inside the document
davve: there is something with background
heycam: is anyone thinking it's bad idea to have scrollable
viewport
ed: would it ever be a pannable viewport, or would it be the
default
heycam: css needs a way for viewports to scroll beyond their
viewport region
... that might be a way to do arbitrary panning
... panning could use viewport scrolling, but not just yet
ed: can we put that off?
heycam: that's ok for me
RESOLUTION: svg:svg elements should allow overflow: scroll to
create scrollbars
krit: where does the origin of this viewbox come from
pdr: I don't think there's a way to set it to negative
heycam: if you have a viewbox [10 10 20 20]
krit: maybe we don't want scrolling but panning
cabanier: how about the size of the scrollable area
krit: yes, that needs to be decided
pdr: what is the bounding box of this thing?
... html has the inner and outer box
... or something to that effect
heycam: we still need to define what those CSS properties such
as offset width means for SVG
krit: maybe take viewport?
heycam: maybe we don't need to delve into the details
... how about for outermost inline SVG elements?
ed: every browser clips today
heycam: maybe overflow isn't the right thing to cause this
clipping to happen
... maybe there should be no way to affect the rendering
ed: do we want allow that to happen?
heycam: if scrollbars can appear (?)
ed: is there ever a use case to not have scroll bar
heycam: would you ever want the content outside of a short SVG
to be painted?
ChrisL: maybe if you have a symbol?
Tavmjong: we talked about this in a telecon
... andreasa asked for that
ChrisL: scroll bars in symbols would be bad
heycam: we need to have some wording there
ed: today we imply that there should be scroll bars for
standalone svg elements
heycam: we still need some wording for short svg's to be
clipped
RESOLUTION: overflow property on root svg elements still
controls if there should be scrollbars but there should be a
clipping rectangle that
... is the size of the svg element's viewport
ed: the current spec says that within SVG content the value
'auto' means visible
... should we change that
heycam: it might be if we can come up with a solution
... for instance if the appearance of scrollbars makes things
narrower
... noone's using auto today so it would be safe to use it
ed: do we want to keep the spec or should we change it?
heycam: if we allow for scrollable viewports it makes sense to
change it
... for viewport establishing elements where scroll bars don't
make sense, overflow:auto would be visible
... for svg:svg, auto will mean scrollbars will appear if the
overflow region is bigger than the viewport
pdr: why are marker and pattern different?
... we are adding special cases for certain elements
heycam: one reason is that these elements are not rendered
directly
krit: it makes it more compex for instance on patterns. because
you have to calculate how you tile them
heycam: how about mask?
pdr: yes, that wouldn't make much sense
krit: how about 'element()' in firefox, would it copy the
scroll bars?
heycam: I believe so yes
... we need to add a bunch of spec text to make sure that a
pattern with overflow:hidden does the right thing
... I worry about getting the coordinate system right
pdr: maybe it's best to get some implementor feedback
heycam: you can have an issue in the spec and wait for that
<scribe> ACTION: ed to figure out the overflow behavior in SVG
[recorded in
[36]http://www.w3.org/2014/04/07-svg-minutes.html#action06]
<trackbot> Created ACTION-3606 - Figure out the overflow
behavior in svg [on Erik Dahlström - due 2014-04-14].
heycam: we need to work out or put an issue in the spec whether
that patterns have scrollable viewports
bbox for text calculations
<ed>
[37]http://lists.w3.org/Archives/Public/www-svg/2014Mar/0030.ht
ml
[37] http://lists.w3.org/Archives/Public/www-svg/2014Mar/0030.html
ed: we discussed this on a call but didn't come to a conclusion
ChrisL: I had some comments
... the full glyph cell is not the ink bounding box
heycam: is it origin + ascent + descent
ChrisL: full glyph cell is adding rectangles, is to use all
... do we need bounding boxes for hit detection and text
selection? I think not
nikos_: how about negative advances?
ChrisL: the advance is separate from that
...
heycam: it sounds like we do need different bbox's because some
glyphs might go over and you don't want to select them
ChrisL: in practice people put transparent rects on top of the
text
<ed> [38]http://jsfiddle.net/L7pgW/18/
[38] http://jsfiddle.net/L7pgW/18/
ed: I made some examples
krit: the italic is the browser?
ed: yes.
<ed> [39]http://jsfiddle.net/L7pgW/22/
[39] http://jsfiddle.net/L7pgW/22/
ed: this is a case where the gradient is started where the
character starts
... filters have this issue too
heycam: we talked about these for stroke/mask bbox
... should we extend this to extent for ink coverage
tbah: what you might want it the bbox and the (?)
... (conversation about using em to size a gradient)
ed: as an author I would expect the gradient to fill the
bounding box
heycam: do we have interoperable behavior?
... for what the size of the bbox is?
ed: no
heycam: the dictionary to getbbox can included stroke and
markers but not for the ink coverage
... one option is to union the ink region and the glyph cell
... the other is just to get the tight bounding box
... it's possible to extend the dict for horizontal and
vertical
...
ed: I would like getbbox to return the ink coverage
... most of the time you want to know what is drawn
heycam: we already have that information
ed: yes, you need to know where things were
heycam: we use the lose ink bounds
... the tight glyph bounds might be more expensive
...
... we should do the union of the glyph boxes and the ink
coverage
tbah: that should catch the majority of the use cases
how about japanese text
scribe: all glyphs are the same size
<scribe> ACTION: getBBox and resource bounding box (for
gradients, mask, etc) to return the union of the glyph cells
and ink extends by default. [recorded in
[40]http://www.w3.org/2014/04/07-svg-minutes.html#action07]
<trackbot> Error finding 'getBBox'. You can review and register
nicknames at
<[41]http://www.w3.org/Graphics/SVG/WG/track/users>.
[41] http://www.w3.org/Graphics/SVG/WG/track/users%3E.
RESOLUTION: getBBox and resource bounding box (for gradients,
mask, etc) to return the union of the glyph cells and ink
extends by default.
heycam: do we allow control to get just the ink extends?
ed: can we reuse the same method?
... we have a method called getTextExtend
<ed>
[42]https://svgwg.org/svg2-draft/text.html#__svg__SVGTextConten
tElement__getExtentOfChar
[42]
https://svgwg.org/svg2-draft/text.html#__svg__SVGTextContentElement__getExtentOfChar
ed: do we need to make getBBox more complex or rely on these
methods
heycam: are you leaning towards not extending getbbox?
ed: if so, we should be able to do the same on gradients, for
instance gradientUnits="some_new_value"
...
heycam: maybe we can ignore that for now since it complicates
the API
nikos: most cases where you want the tight box, you might want
to hit test against it too
ed: I could go with a clarification
RESOLUTION: for now we won't provide APIs for a tight ink
bounding box on text for getBBox or gradient object bounding
box or hit detection
ed: are text decoration part of the bbox?
krit: CSS had discussions on this
... right now css doesn't gradients, just color
heycam: the boundingbox in that case is the element
... an underline could go outside of the element
... it makes sense to include them
krit: then there would be 2 definitions of bounding box
heycam: I don't want decoration to be painted differently
<ed> [43]https://svgwg.org/svg2-draft/text.html#TextDecoration
[43] https://svgwg.org/svg2-draft/text.html#TextDecoration
RESOLUTION: text decoration to be included in the bounding box
calculations
<krit>
[44]http://wiki.apache.org/xmlgraphics-fop/LineLayout/Alignment
Handling
[44]
http://wiki.apache.org/xmlgraphics-fop/LineLayout/AlignmentHandling
<heycam> [45]http://dev.w3.org/csswg/css-inline/
[45] http://dev.w3.org/csswg/css-inline/
(krit discussing issue with text baselines, etc)
<ed> ACTION: ed to do spec edits for bounding boxes of text
elements: give the union of full glyph cells and the painted
area, and include text decorations in the bbox (change for
getBBox too) [recorded in
[46]http://www.w3.org/2014/04/07-svg-minutes.html#action08]
<trackbot> Created ACTION-3607 - Do spec edits for bounding
boxes of text elements: give the union of full glyph cells and
the painted area, and include text decorations in the bbox
(change for getbbox too) [on Erik Dahlström - due 2014-04-14].
<ChrisL> ideographic = descender depth
<ChrisL> alphabetic = 0
<ChrisL> central = (ascender height - descender depth) / 2
<ChrisL> middle = x height / 2
<ChrisL> these seem good fallback definitions we could reuse
<scribe> ACTION: krit to talk to Alan Stearns about adding
fallback baseline calculations to the CSS line layout spec and
if they will stay in the spec [recorded in
[47]http://www.w3.org/2014/04/07-svg-minutes.html#action09]
<trackbot> Created ACTION-3608 - Talk to alan stearns about
adding fallback baseline calculations to the css line layout
spec and if they will stay in the spec [on Dirk Schulze - due
2014-04-14].
<heycam> Scribe: Cameron
<heycam> ScribeNick: heycam
white space in attributes
[48]https://www.w3.org/Graphics/SVG/WG/wiki/Proposals/Attribute
Whitespace
[48]
https://www.w3.org/Graphics/SVG/WG/wiki/Proposals/AttributeWhitespace
ed: I went through all the attribute types we use in SVG, made
a big table summarising
... I was looking for whether trailing/leading white space is
allowed and ignored
... comparing with HTML5
... it's inconsistent, but at least for some of the numerical
types it should be possible to make it consistent
... we discussed this in a telcon, and I went over it once more
to add test cases for each of the subsections
... we could go through each type by type and see the test
cases
<ed> [49]http://jsfiddle.net/wxJa9/
[49] http://jsfiddle.net/wxJa9/
ed: this is for <number>
... there aren't many of these in HTML
... the only ones I could find are on <input>
ChrisL: is HTML5 the right thing to be comparing to here?
... and not CSS properties?
heycam: these are all non-CSS property attributes we're looking
at
ed: this example is inconsistently handled across browsers
... HTML5 has different constraints for validators vs browsers
... for the content to be valid, it has to be a proper number
in the right format and without any garbage or white space
... but for display, it strips away the white space and junk
... and returned in a correct form if you ask for it in the DOM
... even in HTML5 this example doesn't work the same way across
browsers
... for integer values it's a bit more consistent
... in the first section I listed the browsers I tested
... Firefox/Chrome/Presto did not allow white space and
garbage; IE did allow white space and garbage
<ed> [50]http://jsfiddle.net/hxz46/
[50] http://jsfiddle.net/hxz46/
ed: that's the SVG test case
... here Firefox/Chrome do not allow the white space and
garbage; IE allows white space but not garbage, Presto allows
both
<ChrisL> <input type="range" step=" 500e-3nord" min="0"
max="10"/> works
pdr: in these examples this is not stripping white space in the
middle
... so only leading and trailing white space
... is that your intention?
ed: we could add tests for those
... so the first question is do we want to allow white space
and garbage
ChrisL: for garbage, that would probably have different levels
of support
ed: the HTML5 parsing algorithm does allow it
heycam: so IE is the only one following the spec
krit: for things that just take numbers, WebKit/Blink are
accepting
... that's how we do the parsing in SVG
ed: I looked at the functions in Blink, and it's passing a flag
whether to allow it
ChrisL: if HTML5 defines what to do with numeric attributes,
then following the exact same algorithm makes it convenient
... it's slightly worrying that only one browser implements
that
ed: there are only a handful of HTML attributes that take a
float
... for integers it was much more consistent
<ed> [51]http://jsfiddle.net/6BQGF/
[51] http://jsfiddle.net/6BQGF/
ChrisL: the thing that worries me is that if there's only one
browser implementing it properly, that requirement will be
dropped
ed: that is the test for integers
... white space and garbage is allowed across all browsers
... negative values for width doesn't work in some browsers,
but that's different from the white space handling
... anyway, all browsers allowed white space / garbage
pdr: HTML doesn't have lists like SVG
... is there any danger there?
ed: for SVG lists, I think generally white space is allowed
pdr: I'm wondering if we use that algorithm for a specific
number, but for a list that doesn't allow commas...?
krit: I would be in favour of allow leading / trailing white
space
... to allow garbage at the end is a bit strange
ChrisL: it means you constrain what you can later add
ed: I guess that's why there are different conformance classes
in HTML?
krit: do we want to allow browsers to be less restrictive
... we don't need to enforce it...
Tav: I'd like to avoid the situation where it renders well in
the browser but then imported in Inkscape it doesn't work
ed: I think the main thing I found was that there are some
minor inconstencies whether leading white space is allowed in
SVG
... so it seemed like a good thing to check everything
pdr: for the trailing garbage, I disagree
... why follow something different from HTML?
ChrisL: what if we have an attribute like x="4e10" and we start
off as an integer, what if we want to extend that later?
... to accept scinot?
ed: note that you still get the "4"
pdr: I see
... when the HTML folks made this decision, how did they handle
this future constraint?
ChrisL: maybe since it's only a handful of elements it wasn't a
problem
heycam: what is the benefit here?
... simplifies implementations slightly
... what about for authors?
ed: had a bug reported where white space was allowed in firefox
but not in chrome
... can't remember which attribute it was
pdr: I think it makes sense to align
cabanier: if you only want one algorithm, then you're going to
need to accept trailing garbage then
ChrisL: to be clear, the two objections aren't "no I'll tie
myself to the mast" objections, they're just worries
... worry about it being dropped from HTML, and future
constraining extensions
... but if the group agrees they want to do that I'm fine with
it
ed: next is length values
... IE allowed white space, no garbage; others don't allow
anything
... for enumerated values, everyone agrees no white space or
garbage
heycam: I feel like length parsing is more like CSS parsing
... so white space seems good to allow
... what about CSS comments?
ed: so for number and integer, stripping leading/trailing white
space and trailing garbage, being consistent with HTML5, is my
first proposal
krit: who doesn't allow garbage in SVG integer attributes?
<ed> [52]http://jsfiddle.net/Gaw2P/
[52] http://jsfiddle.net/Gaw2P/
ed: compare to the bottom right subtest
... which is numOctaves="1"
krit: in Safari we don't render the 5th one
... what does that indicate?
ed: it doesn't use any fallback value
heycam: I think if we have some implementations that accept the
white space and garbage and others not, then we'll eventually
all converge to that behaviour
... so may as well jump to that state now
krit: I'm OK with accepting leading/trailing white space
pdr: go for browser compatibility instead of parser
compatibility?
krit: well, the browser uses a parser...
pdr: spec parsers
ed: I think it's mostly consistent in disallowing the garbage
... in transform lists for example
krit: for numbers I would be skeptical because of that
exponential number example
... for integers we only have a few attributes
... so is it worth it?
ed: there are other cases where white space is allowed when the
spec says no
krit: I am supporting the white space
ed: to be clear, I don't want to allow white space everywhere
... for enumerated values, like accumulate="none | sum"
... I guess we could allow white space
Tav: but HTML does not
<ed> [53]http://jsfiddle.net/eT7jz/
[53] http://jsfiddle.net/eT7jz/
ed: all browsers agree there not to allow white space
krit: safari allows the white space there
pdr: I wouldn't have expected that to be different from chrome
krit: but the HTML spec doesn't want white space
... I think it's strange, but acceptable, to not allow white
space in enumerated attributes
ed: we imported a few attributes from HTML5, the boolean values
for controls="", default="", etc. on <video> and <audio>
... we currently don't have anything like that
... in SVG
... so it makes sense to follow SVG there
krit: filter effects too
ed: they don't allow white space or values other than the
attribute name itself
krit: I think it's strange it doesn't allow true/false
ed: for url values, all values allow leading/trailing white
space, which is stripped
... the spec currently says it's not allowed
... so I think we should allow it there
... xlink:href=""
... we now have <video src=""> too
pdr: what about a data URL that's not base64 encoded
... with trailing white space. that's an actual difference.
ed: I think white space is stripped there
RESOLUTION: URL attributes will be parsed like in HTML, by
stripping leading/trailing white space.
pdr: I think not allowing garbage is ok for length etc.
... what about for attributes that we later promote to
properties?
krit: you would start to allow white space
ed: but that's ok, it's more relaxed
RESOLUTION: We will allow leading/trailing white space on
integer,number,length,angle but not trailing garbage.
ed: the rest of the data types, leave them as they are
<scribe> ACTION: Erik to update attribute parsing according to
these resolutions. [recorded in
[54]http://www.w3.org/2014/04/07-svg-minutes.html#action10]
<trackbot> Created ACTION-3609 - Update attribute parsing
according to these resolutions. [on Erik Dahlström - due
2014-04-14].
Media queries in switch
ChrisL: was the previous discussion in favour of this?
heycam: yes I think so
<ChrisL> good
[heycam explains what media="" would allow]
pdr: why not fix media queries in CSS to allow this kind of
switching?
ChrisL: selector syntax is not really designed for doing switch
cases like this
... we already have these test attributes, that we inherited
from SMIL
... seems a natural extension to those
... this gives them a simple way to combine media queries with
<switch>
davve: the <switch> element has really low usage
... is there a use case we want to cover by this?
krit: you could do the same with classes...
pdr: this is somewhat torturing the <switch> statement's
intentions
krit: I don't want to encourage people to use <switch>, really
pdr: the example that estelle is showing is a proposal that is
copying a <picture> element example, but doing it in SVG
... isn't this duplicating?
... that doesn't seem like a good idea
heycam: if this is the same thing as the <picture> element can
do maybe we should just have that
<pdr>
[55]http://coding.smashingmagazine.com/2013/06/02/clown-car-tec
hnique-solving-for-adaptive-images-in-responsive-web-design/
[55]
http://coding.smashingmagazine.com/2013/06/02/clown-car-technique-solving-for-adaptive-images-in-responsive-web-design/
<ChrisL>
[56]http://www.w3.org/Graphics/SVG/Test/20110816/harness/htmlOb
ject/struct-cond-01-t.html
[56]
http://www.w3.org/Graphics/SVG/Test/20110816/harness/htmlObject/struct-cond-01-t.html
heycam: one difference is that the <picture><source> elements
have to refer to external resources
pdr: they could be data: URL encoded
birtles: we were discussing having media="" on <iframe> too
... not sure if it's possible to get into cyclic dependencies
with <switch> and media=""
pdr: in this blog post they have SVG-as-image referencing
external background-images, and I don't think that would work
in implementations
... I think this blog post is saying why have <picture> when
SVG can do this already, but I think <picture> is going to
happen
... so if we have <picture> in SVG in the future, I don't think
we should extend <switch>
also
[57]http://coding.smashingmagazine.com/2014/03/05/rethinking-re
sponsive-svg/
[57]
http://coding.smashingmagazine.com/2014/03/05/rethinking-responsive-svg/
heycam: so I guess there are a few ways to handle this use case
(a) extend <switch> with media=""
(b) write style sheets with media queries, as you can do
currently, but with a bit of duplication within them
(c) extend @media in CSS to allow switching, to avoid the
duplication
(d) extend <picture> to allow subtrees, so you don't need to
use external references
ed: there is <style media=""> too
[some discussion about avoiding fetching resources in
non-condition-matching branches]
<ChrisL> f) keep inviting new responsive elements and then
rejecting them until the heat death of the universe
<stakagi> resource piorities?
<birtles>
[58]https://dvcs.w3.org/hg/webperf/raw-file/tip/specs/ResourceP
riorities/Overview.html
[58]
https://dvcs.w3.org/hg/webperf/raw-file/tip/specs/ResourcePriorities/Overview.html
heycam: if preventing loading external resources is something
important for the use case, then (b) and (c) aren't appropriate
here
... (a) or (d) are
<scribe> ACTION: Cameron to reply to www-svg mail to say what
can be done with existing @media queries and if <picture>
exists in SVG [recorded in
[59]http://www.w3.org/2014/04/07-svg-minutes.html#action11]
<trackbot> Created ACTION-3610 - Reply to www-svg mail to say
what can be done with existing @media queries and if <picture>
exists in svg [on Cameron McCormack - due 2014-04-14].
<scribe> Chair: Cameron
Summary of Action Items
[NEW] ACTION: Cameron to publish media access events as a note
[recorded in
[60]http://www.w3.org/2014/04/07-svg-minutes.html#action03]
[NEW] ACTION: Cameron to reply to www-svg mail to say what can
be done with existing @media queries and if <picture> exists in
SVG [recorded in
[61]http://www.w3.org/2014/04/07-svg-minutes.html#action11]
[NEW] ACTION: ChrisL (or pdr) to get Tab's feedback on davvel's
SVG sizing proposal [recorded in
[62]http://www.w3.org/2014/04/07-svg-minutes.html#action05]
[NEW] ACTION: ChrisL to talk to Michael Cooper about UAG
[recorded in
[63]http://www.w3.org/2014/04/07-svg-minutes.html#action02]
[NEW] ACTION: ChrisL to update the charter [recorded in
[64]http://www.w3.org/2014/04/07-svg-minutes.html#action01]
[NEW] ACTION: ed to do spec edits for bounding boxes of text
elements: give the union of full glyph cells and the painted
area, and include text decorations in the bbox (change for
getBBox too) [recorded in
[65]http://www.w3.org/2014/04/07-svg-minutes.html#action08]
[NEW] ACTION: ed to figure out the overflow behavior in SVG
[recorded in
[66]http://www.w3.org/2014/04/07-svg-minutes.html#action06]
[NEW] ACTION: Erik to prepare spec text for pointer-events on
root SVG elements for SVG2 and SVG Integration spec and make
edits [recorded in
[67]http://www.w3.org/2014/04/07-svg-minutes.html#action04]
[NEW] ACTION: Erik to update attribute parsing according to
these resolutions. [recorded in
[68]http://www.w3.org/2014/04/07-svg-minutes.html#action10]
[NEW] ACTION: getBBox and resource bounding box (for gradients,
mask, etc) to return the union of the glyph cells and ink
extends by default. [recorded in
[69]http://www.w3.org/2014/04/07-svg-minutes.html#action07]
[NEW] ACTION: krit to talk to Alan Stearns about adding
fallback baseline calculations to the CSS line layout spec and
if they will stay in the spec [recorded in
[70]http://www.w3.org/2014/04/07-svg-minutes.html#action09]
[End of minutes]
__________________________________________________________
Received on Monday, 7 April 2014 15:38:29 UTC