See also: IRC log
<trackbot> Date: 07 April 2014
<ChrisL> interesting font demo http://www.babelstone.co.uk/Fonts/ThrorsMap.html
<ChrisL> http://libregraphicsmeeting.org/2014/program/
<birtles> Scribenick: birtles
<scribe> Scribe: birtles
<ChrisL> 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> https://github.com/SVG-access-W3CG/new-note-draft/blob/master/svgaccess.html
<scribe> ACTION: ChrisL to update the charter [recorded in 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 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> http://www.w3.org/TR/compositing-1/
birtles: we should also probably
add animation elements: https://svgwg.org/specs/animation-elements/
... it's paused at the moment
... but we decided it should go under the SVGWG
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> 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> 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 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: 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> https://www.w3.org/Graphics/SVG/WG/wiki/Roadmap
ChrisL: we need to, as a group, keep it up to date
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> https://svgwg.org/svg2-draft/interact.html#PointerEventsProp
<ed> 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 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)
<heycam> presentation 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: 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 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
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> 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> https://svgwg.org/svg2-draft/masking.html#OverflowProperty
<ed> 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: 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 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
<ed> 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> http://jsfiddle.net/L7pgW/18/
ed: I made some examples
krit: the italic is the browser?
ed: yes.
<ed> 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 http://www.w3.org/2014/04/07-svg-minutes.html#action07]
<trackbot> Error finding 'getBBox'. You can review and register nicknames at <http://www.w3.org/Graphics/SVG/WG/track/users>.
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> 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> https://svgwg.org/svg2-draft/text.html#TextDecoration
RESOLUTION: text decoration to be included in the bounding box calculations
<krit> http://wiki.apache.org/xmlgraphics-fop/LineLayout/AlignmentHandling
<heycam> 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 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 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
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> 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> 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> 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> 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> 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 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].
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
<ChrisL> 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 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> 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 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
This is scribe.perl Revision: 1.138 of Date: 2013-04-25 13:59:11 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/not sure about/what about/ Succeeded: s/someone from Opera/Simon Pieters from Opera/ Succeeded: s/sometimes doesn't always/sometimes doesn't/ Succeeded: s/350px150px/300x150 px/ Succeeded: s/is that/in that/ Succeeded: s/resolution// Succeeded: s/ye/yes/ Succeeded: s/which might be more expensive/the tight glyph bounds might be more expensive/ Succeeded: s/and/or/ Found ScribeNick: birtles Found Scribe: birtles Inferring ScribeNick: birtles Found ScribeNick: cabanier Found Scribe: Cameron Found ScribeNick: heycam Scribes: birtles, Cameron ScribeNicks: birtles, cabanier, heycam Present: Cameron Rik Dirk Chris Satoru Erik Brian David_Vest Tav Nikos Philip_Rogers Agenda: https://www.w3.org/Graphics/SVG/WG/wiki/F2F/Leipzig_2014/Agenda Found Date: 07 Apr 2014 Guessing minutes URL: http://www.w3.org/2014/04/07-svg-minutes.html People with action items: bounding box cameron chrisl ed erik etc for getbbox gradients krit mask or pdr resource[End of scribe.perl diagnostic output]