- From: Nikos Andronikos <Nikos.Andronikos@cisra.canon.com.au>
- Date: Thu, 8 Oct 2015 22:06:29 +0000
- To: www-svg <www-svg@w3.org>
Minutes from today’s call are at:
http://www.w3.org/2015/10/08-svg-minutes.html
Or below as text:
-----------------------------------------------------------------------------------
SVG Working Group Teleconference
08 Oct 2015
[2]Agenda
[2] https://lists.w3.org/Archives/Public/www-svg/2015Oct/0025.html
See also: [3]IRC log
[3] http://www.w3.org/2015/10/08-svg-irc
Attendees
Present
Cameron, ed, tav, amelia, nikos, fantasai, stakagi,
shepazu
Regrets
Chair
Cameron
Scribe
Nikos
Contents
* [4]Topics
1. [5]writing modes
2. [6]Path stroking for paths that end with tight curves
3. [7]Declarative animation and conformance
4. [8]back to writing modes
5. [9]Anchor tag nesting and HTML harmonization
* [10]Summary of Action Items
__________________________________________________________
<trackbot> Date: 08 October 2015
<fantasai> passcode?
<scribe> Scribe: Nikos
<scribe> scribenick: nikos
writing modes
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> [11]https://svgwg.org/svg2-draft/types.html#syntax
[11] 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
[12]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
Path stroking for paths that end with tight curves
<AmeliaBR> Yes, it's in HTML 5 here, so no change required in
CSS Writing Modes:
[13]http://www.w3.org/TR/html5/rendering.html#bidi-rendering
[13] 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> [14]http://tavmjong.free.fr/SVG/STROKING/
[14] 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>
[15]https://svgwg.org/svg2-draft/painting.html#StrokeShape
[15] 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
[16]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].
Declarative animation and conformance
ed: this was raised as an issue on github
<ed> [17]https://github.com/w3c/svgwg/issues/23
[17] 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
[18]http://www.w3.org/TR/SVG11/conform.html#ConformingSVGViewer
s
[18] 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:
[19]https://svgwg.org/svg2-draft/conform.html#ConformingSVGView
ers
[19] 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
[20]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.
back to writing modes
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
Anchor tag nesting and HTML harmonization
<ed> [21]https://github.com/w3c/svgwg/issues/26
[21] 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:
[22]https://html.spec.whatwg.org/multipage/semantics.html#the-a
-element "Content model: Transparent, but there must be no
interactive content descendant."
[22] https://html.spec.whatwg.org/multipage/semantics.html#the-a-element
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
[23]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:
[24]http://www.w3.org/TR/html5/text-level-semantics.html#the-a-
element
[24] 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
[25]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>
[26]https://svgwg.org/svg2-draft/linking.html#InterfaceSVGAElem
ent
[26] https://svgwg.org/svg2-draft/linking.html#InterfaceSVGAElement
heycam: yes
... I'm surprised target is an animated string
Summary of Action Items
[NEW] ACTION: Amelia to investigate behaviour of nested links
in SVG and HTML [recorded in
[27]http://www.w3.org/2015/10/08-svg-minutes.html#action04]
[NEW] ACTION: amelia to look at adding extra html attributes
onto svg a element [recorded in
[28]http://www.w3.org/2015/10/08-svg-minutes.html#action05]
[NEW] ACTION: Cameron to come up with a list of properties to
explicitly allow unitless values in [recorded in
[29]http://www.w3.org/2015/10/08-svg-minutes.html#action01]
[NEW] ACTION: heycam to add an issue to conformance appendix
noting that it needs review/rewriting [recorded in
[30]http://www.w3.org/2015/10/08-svg-minutes.html#action03]
[NEW] ACTION: Nikos to look into implementation of path
stroking in various libraries with view to what recommendations
svg 2 spec should make [recorded in
[31]http://www.w3.org/2015/10/08-svg-minutes.html#action02]
[End of minutes]
The information contained in this email message and any attachments may be confidential and may also be the subject to legal professional privilege. If you are not the intended recipient, any use, interference with, disclosure or copying of this material is unauthorised and prohibited. If you have received this email in error, please immediately advise the sender by return email and delete the information from your system.
Received on Thursday, 8 October 2015 22:07:04 UTC