See also: IRC log
<trackbot> Date: 08 October 2015
<fantasai> passcode?
<scribe> Scribe: Nikos
<scribe> scribenick: nikos
fantasai: I think we came to a
bunch of conclusions at the F2F and I tried to edit them
in
... then there was an issue about whethter the old values
should compute to each other, or if they needed to be
maintained separately in the layout engine just for SVG
... seems discussion on the list is that it's ok to compute
them to new values
... so overall looks good
... Amelia may have wanted some clarifications?
AmeliaBR: just for
text-orientation. I think the way you've approached it is
great
... shorthand translates to new property
... but making sure all existing valid values are translated
properly
... as an angle value rather than a string value
... it's tricky that no units at all doesn't map to a css
angle
fantasai: there's a question of
whether that's accepted in the css syntax as well
... there was discussion about unitess values and supporting
them in css but there was push back on that
AmeliaBR: it currently works in
the limited number of browsers that support that property
... that's consistent with svg 11
... you can leave off units if it's a property that was
introduced for svg
... as this one was
... but as far as mapping, it's probably easiest to just
describe it as two different ways
... a number and an angle option
... and map them both
<heycam> https://svgwg.org/svg2-draft/types.html#syntax
heycam: at the moment we have
text in svg 2 about how to parse presentation attributes
... which effectively does a search and replace on the grammar
to insert number at a ppropriate places
... so thats what let them accept zero
... for ones that aren't svg specific (come from css) we insert
it into the grammar
fantasai: that's going to get
confusing when moving properties back and forth
... but suppose you need to do that for backwards compat. Don't
think it's a practice we should take forward
heycam: would you prefer we limit that to the set of properties that we already support - new svg properties don't get that ?
fantasai: think that would be a
good idea - we are seeing cases where we're taking properties
from svg
... and there really shouldn't be a distinction for the
author
heycam: that's reasonable - I can come up with the list of properties to allow that for
fantasai: as far as glyph
orientation vertical, the question is if we ignore other
values
... current recommendation is to ignore and treat as
unsupported
... unless you think there's content out there that relies on
the weird values
heycam: I agree - I keep hearing
dirk mention output from illustrator
... afaik it was using text-orientation: 0
... so it could do it's own glyph layout
fantasai: zero gets mapped to upright which does the same thing
<heycam> ACTION: Cameron to come up with a list of properties to explicitly allow unitless values in [recorded in http://www.w3.org/2015/10/08-svg-minutes.html#action01]
<trackbot> Created ACTION-3822 - Come up with a list of properties to explicitly allow unitless values in [on Cameron McCormack - due 2015-10-15].
AmeliaBR: only other comment I had was somewhere adding a comment about the html direction properties
fantasai: it's handled in the bidi section
AmeliaBR: I found in testing that
IE responds to those things but it doesn't set the css in a way
that will inherit into svg
... so if you say direction=rl on html or body it's not
inherited into inline svg
... the way the css direction property would
fantasai: we had an appendix that
had mapping rules for html4 but some html people asked us to
take it out
... html5 defines this already in it's rendering section
... I can add a reference to that section if there isn't one
already, but it is required by the HTML spec that you map to
the CSS properties
AmeliaBR: I haven't tested in Edge - it may be fixed there. Pretty sure everyone else inherits as expected
fantasai: I just have to make a
few clarifications regarding writing-mode - add some mappings,
but don't know if anyone actually needs that
... what do you do for radian?
... it's not a rational number so don't know how you'd do that
mapping
AmeliaBR: has to be exactly that value
fantasai: if svg wg wants me to
specify radians and gradians as well I can do that, but please
let me know what you want to do for radians
... if you don't need them we can drop that
... you'll have to tell me what range is accepted as 90
degrees, etc
AmeliaBR: yeah that was something that wasn't defined in the svg spec
Tav: it says they're restricted
to 0, 90, 270, 180
... doubt anyone would use gradians
AmeliaBR: unitless numbers are out there in the real world, radians less likely
Tav: I'd ignore radians
heycam: that'd be fine with me
shepazu: Just one point - you
were saying Amelia (meow) that IE doesn't inherit
... that's probably juts a bug
heycam: I think fantasai was
referring to ua stylesheet where it maps
... I could see there may be ua style rules that reset those
properties on svg elements
... It's unlikely the spec says that so I'd agree with Doug
that it's probably a bug
<AmeliaBR> Yes, it's in HTML 5 here, so no change required in CSS Writing Modes: http://www.w3.org/TR/html5/rendering.html#bidi-rendering
Tav: I just had a question of whether we want to define how you do stroking
heycam: we do
<Tav> http://tavmjong.free.fr/SVG/STROKING/
Tav: I looked at how stroking is
implemented while looking at the stroke alignment
property
... there's one place where theres inconsistency between FF and
other browsers and Postscript and PDF
... if you have a very tight curve at the end of the line you
sometimes see this ugly behaviour and it surprises people
<heycam> https://svgwg.org/svg2-draft/painting.html#StrokeShape
heycam: I did add a section on
what the exact shape of a stroke should be
... that describes it in the form of what set of points should
be in the stroke
... so that matches the 'move a line of stroke width around the
path' method
... I showed this to one of our graphics guys and he was a bit
unhappy because it was too precisely defined
... because we're at the mercy of underlying graphics
libraries
... theres no way we can change our implementation without
creating a whole new renderer
... and as we move to using more os and gfx card libraries that
will get even harder
... so he would have preferred some leway
... not sure how to do that - whether we allow two methods or
what
... but practically we have to allow something like that
Tav: it would be nice to have
some consistency, if you scroll down on the link and look at
the dash pattern
... you can see the dash pattern is doing more what I would
expect
shepazu: might have to consider
hardware implementations also
... we should check with khronos about what hw is likely to
do
Tav: good idea
... another consideration is the sweeping a perpendicular line
around
... doesn't work with inside/outside
... you get things outside the area you would expect them
in
... talking with the khronos guys might be a good idea
AmeliaBR: if the long term result is to get these features hw accelerated we want consistency with specs and whatever hw is calcaulating
Tav: my guess is they can probably do it either way
shepazu: I think they probably have some way they have chosen to do it
heycam: Tav do you you agree we
should change the svg 2 spec wrt covering the various
strategies
... should we make it a 'should' or what?
Tav: I'd prefer to take FFs approach but agree it may be hard if people rely on underlying libraries
nikos: what does PDF do?
Tav: matches FF
... as soon as you add a dash pattern you can see that they're
doing something different
AmeliaBR: at that point each dash
becomes it's own path
... so the rules change
heycam: you're probably seeing
Cairos behaviour if you're testing FF on linux
... you might see different behaviour on other platforms
shepazu: underlying libraries can
also change - that's not a totally inflexible requirement
... we should talk to khronos and library vendors etc and get
agreement
nikos: Cairo implements PDF model so I think it would difficult to change
AmeliaBR: well that's the one it
would be nice to fix upon
... but what are we going to do with SVG 2 for now, knowing
other engines do things differently?
heycam: agree that option is the
ideal
... I'd be happy with the spec saying here's the ideal stroke
shape but you may differ in some particular ways
Tav: one way you may be able to
make them look closer is if you connect the point where it goes
in the opposite direction to the path itself
... at the end point
<ed> would be interesting to hear what the skia people have to say about this
<scribe> ACTION: Nikos to look into implementation of path stroking in various libraries with view to what recommendations svg 2 spec should make [recorded in http://www.w3.org/2015/10/08-svg-minutes.html#action02]
<trackbot> Created ACTION-3823 - Look into implementation of path stroking in various libraries with view to what recommendations svg 2 spec should make [on Nikos Andronikos - due 2015-10-15].
ed: this was raised as an issue on github
<ed> https://github.com/w3c/svgwg/issues/23
ed: Brian responded but I'm not sure if we need to update the conformance chapter to say something about SMIL and declarative animations
AmeliaBR: it comes up in this
case where teh chapter distinguishes between static and dynamic
viewers
... in describing a dynamic viewer it mentions declarative
animation and script
... in my sense, that is written as descriptive rather than
prescriptive
... further on we have some more text about requirements
... maybe we need to clean up to say 'for example, dynamic
content could be achieved in either of these ways'
... does that make sense?
heycam: think so and I think
you're right about why it's mentioned there
... not meant to include or exclude SMIL explicitly, just that
that was the only declarative method around at the time the
spec was written
<AmeliaBR> Here's SVG 1.1 text http://www.w3.org/TR/SVG11/conform.html#ConformingSVGViewers
heycam: conformance appendix
hasn't had much attention yet
... could do with some reviews
<AmeliaBR> Latest SVG 2: https://svgwg.org/svg2-draft/conform.html#ConformingSVGViewers
heycam: maybe someone should
rewrite - probably a lot of conformance classes we don't need
are included
... if no one has an interest at the moment, we should probably
add an issue saying conformance class wording needs to be
reviewed
... as for the result of the issue, I agree and we should
comment in the github issue to that effect
AmeliaBR: I can do that if Cam will add the issue to the spec
<fantasai> summary is, add gradiens and integers to glyph-orient, otherwise spec is okay?
<fantasai> or other edits/concerns?
<scribe> ACTION: heycam to add an issue to conformance appendix noting that it needs review/rewriting [recorded in http://www.w3.org/2015/10/08-svg-minutes.html#action03]
<trackbot> Created ACTION-3824 - Add an issue to conformance appendix noting that it needs review/rewriting [on Cameron McCormack - due 2015-10-15].
<heycam> fantasai, that sounds right.
heycam: probably don't need to bother about gradiens, it's very unlikely anyone is using them
fantasai: works for me
shepazu: we can always add them later
fantasai: so conslusion is to add
integers to represent unitless values
... gradiens and radians get dropped
... clarify that they are not part of the glyph orientation
property going forwards
... clarifying the spec that values other than 0,90,180,270 are
not supported
heycam: that sounds like what we agreed on
fantasai: I'll make those edits
and take the spec back to CSS for a resolution to publish
CR
... concludes what I need from you guys wrt writing modes
<ed> https://github.com/w3c/svgwg/issues/26
ed: two questions in this
issue
... first, we disallow nesting of anchor tag in svg 2
AmeliaBR: that's something that
should have been disallowed anyway
... but it maybe wasn't clearly stated before
... right now we've got a content model that is generic and it
should not allow that
ed: i think it would be good to have a small note explaining why we did this and why it wasn't disallowed before
heycam: to be clear, this is just about author conformance requirements right?
ed: yeah - not quite sure what implementations do right now. They may differ in how they handle the case.
AmeliaBR: theoretically if they
were just a elements with anchors and not links they might not
break anything
... but otherwise things are not going to work properly, and I
think HTML explicitly disallows it
heycam: I would probably put it
down to a mistake when I was generating those blue boxes
... it's difficult to construct nested a elements because of
how the html parser work
... but you can do it in the dom
<ed> html: https://html.spec.whatwg.org/multipage/semantics.html#the-a-element "Content model: Transparent, but there must be no interactive content descendant."
heycam: hope the HTML spec says something about that, and we can do something similar
ed: we might want to clarify what
happens if you have nested links in svg 2
... which link is clicked
heycam: agree we should write
that up
... whos the owner of the linking chapter?
AmeliaBR: it's been myself and Bogdan
heycam: is it something you'd be willing to work on Amelia?
AmeliaBR: I can tidy that up.
Will do some quick tests to see what happens
... do people like Erik's idea of which link should be
active?
heycam: yes
AmeliaBR: do we have a preference ?
ed: I'd like it to be the same as HTML
<scribe> ACTION: Amelia to investigate behaviour of nested links in SVG and HTML [recorded in http://www.w3.org/2015/10/08-svg-minutes.html#action04]
<trackbot> Created ACTION-3825 - Investigate behaviour of nested links in svg and html [on Amelia Bellamy-Royds - due 2015-10-15].
ed: that covers the first question, second question is whether we should add additional attributes that HTML defines
AmeliaBR: I like that idea
heycam: doesn't sound like those three would be problematic
<AmeliaBR> For reference, here's the HTML 5 spec: http://www.w3.org/TR/html5/text-level-semantics.html#the-a-element
heycam: we've already decided to
have the same set of attributes for style and script
... so I think it makes sense to have the same set of
attributes on a
ed: agree
AmeliaBR: there's about eight
different attributes in HTML
... all of which would be applicable
heycam: would we want to add the
corresponding DOM properties?
... so duplicate what's on HTML anchor elements?
AmeliaBR: I'd opt for consistency
unless there's some issue. There may be accessibility
interfaces that use these extra attributes
... would make it much easier if SVG supports them as well
heycam: let's assume we will have
the same attributes and DOM properties then and if we find
anything that will be problematic then we can discuss
skipping
... but I think it should all be fine
AmeliaBR: right now the only special dom property we have is for target, and I'm pretty sure that's consistent with the HTML one
ed: for href we have an svg animated string as the interface
AmeliaBR: same with target, listed as animated string rather than simple string
<ed> so it's aElement.href.baseVal = "#foo"
AmeliaBR: which is inconsistent
with the html interface
... so if we bring new things in, are we consistent to the
existing svg dom or the html dom?
heycam: for non animated thing I
think we tend to do something similar to the html spec
already
... so I think in a way it would be consistent with existing
things in html if we took the idl from html
... for everything other than href
<scribe> ACTION: amelia to look at adding extra html attributes onto svg a element [recorded in http://www.w3.org/2015/10/08-svg-minutes.html#action05]
<trackbot> Created ACTION-3826 - Look at adding extra html attributes onto svg a element [on Amelia Bellamy-Royds - due 2015-10-15].
AmeliaBR: to be clear, href and target are animated string and the rest are just dom strings?
<ed> https://svgwg.org/svg2-draft/linking.html#InterfaceSVGAElement
heycam: yes
... I'm surprised target is an animated string
This is scribe.perl Revision: 1.140 of Date: 2014-11-06 18:16:30 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/gradients/gradians/ Succeeded: s/radains/radians/ Succeeded: s/and add/if Cam will add/ Succeeded: s/gradiens and radians get mapped/gradiens and radians get dropped/ Succeeded: s/strg/string/ Succeeded: s/animated strings/animated string/ Found Scribe: Nikos Inferring ScribeNick: nikos Found ScribeNick: nikos Present: Cameron ed tav amelia nikos fantasai stakagi shepazu Agenda: https://lists.w3.org/Archives/Public/www-svg/2015Oct/0025.html Found Date: 08 Oct 2015 Guessing minutes URL: http://www.w3.org/2015/10/08-svg-minutes.html People with action items: amelia cameron heycam nikos[End of scribe.perl diagnostic output]