chari: krit
Link to the agenda: https://lists.w3.org/Archives/Public/www-svg/2019Nov/0009.html
trackbot, who is present?
<trackbot> Sorry, krit, I don't understand 'trackbot, who is present?'. Please refer to <http://www.w3.org/2005/06/tracker/irc> for help.
<Tav_> present
<scribe> ScribeNick: krit
GitHub https://github.com/w3c/svgwg/issues/745
GitHub: https://github.com/w3c/svgwg/issues/745
Tav_: There is one additional
comment to the last discussion.
... Cuts on corners. You have a bevel (you want to fall back
to)
... It could be that you cut back further than the bevel and we
shouldn't
AmeliaBR: Which is consistent
with our previous resolution
... A consequence is that the shape might be more complicated
than expected.
Tav_: I don't thin it would be more complicated... it is a corner case
<AmeliaBR> from October 21, we resolved: The "line join shape" is never less than the shape defined for a bevel join, regardless of the stroke-miterlimit value.
Tav_: I am working on a text change. But build scripts seem to require pythin2
AmeliaBR: So your recommandation
is no change to the previous resolution
... ... if problems come up during implementing we will discuss
them?
Tav_: You should not push a
corner further back than the bevel would be the proposal.
... I think we should add this as addition
... more a clarification
AmeliaBR: so the cut off line
should always be a straight line for arcs. And we need to make
sure that it is never less than a bevel.
... And you are willing to do the edits?
Tav_: yes
propose RESOLUTION: Clipped line for arc-miters is always a straight line and adjusted to the previous resolution to always be in the bevel area.
RESOLUTION: Clipped line for arc-miters is always a straight line and adjusted to the previous resolution to always include at least the bevel area.
GitHub: https://github.com/w3c/svgwg/issues/717
krit: original proposal was coming from Cyrus
AmeliaBR: Discard was added in
SVG 2. It is no longer but still in the Animation spec and
referenced form SVG2
... Reason was to manage complicated animations without
scripting
... There is an implementation in Blink that no-one knew.
... pdr posted that the use-counter is close to zero
Tav_: I do not like the use counter argument.
AmeliaBR: yeah. And in this case
there just was one implementation. So it only shows that there
is no legacy reason to keep it.
... we could leave it in the spec as a nice-to-have but do not
discourage Blink to remove
krit: I think we should not encourage to remove a feature but still keep it in the spec. Either come to an agreement that there is not enough interest and remove or ask Blink to keep it.
AmeliaBR: I don't think there is
a conflict here
... This is a draft spec. There are a lot of draft specs out
there where the spec is not ready for implementation but don't
remove it from the spec yet.
... the spec is still in a draft state.
krit: Is there a FPWD yet?
AmeliaBR: We resolved but it didn't happen yet
krit: In this case I don't see a reason to remove it but we should still review its usefulness based on the comments.
AmeliaBR: The need comes down to what the future of the animation elements is at all. Will it stay legacy? Will we add improvements?
krit: Do members feel it is relevant still and should stay in general?
nzimmermann: From the WebKit
implementation I doubt it is complex to implement. Managing the
state by web dev is more complex.
... Don't understand the argument of complexity from Blink. We
need more input why it is difficult for them.
... Did not hear about the element before this call so I might
miss something as well.
RESOLUTION: Keep discard in the SVG Animation draft proposal. Ask Blink for more specific input about implementation complexity
GitHub: https://github.com/w3c/svgwg/issues/508
AmeliaBR: This is about HTML
consitency. HTML element allows hidden attributes on any
element that Is usually mapped to disaplay: none. It is
encouraged in HTML as a way to keep semantics in the markup
instead of the stylesheet.
... In SVG we have presentation attributes to do this already.
We didn't have a need for this attribute. But there might be
confusion if we do not support it and people use it on SVG
elements. Especially within CSS layout embedded in
webpages/
krit: proposal is to add hidden attributes to all SVG elements? Or a list of elements?
AmeliaBR: If we add them then to
all elements.
... also for implementation complexity. My main concern is
about wording and how it maps to display none or visibility
properties. Or cascading attributes if you have this attribute
and the regular presentation attributes.
... Attributes have no particular order so we need to define
the priority.
<AmeliaBR> HTML spec for hidden attribute: https://html.spec.whatwg.org/multipage/interaction.html#the-hidden-attribute
nzimmermann: There is a note in
the HTML spec that display: block will cancel the effect of the
hidden attribute. So it has precedence over the hidden
attributes.
... So I don't think there is no issue with precedence with
display or visibility.
AmeliaBR: We still need to specify how attributes affect each other in SVG because that is not defined in HTML. But I agree with your logic to overwrite hidden attributes.
nzimmermann: For authors it would make sense to have an explicit definition how attributes affect each other.
AmeliaBR: If we want to define the attributes in form of cascading it would override definition of presentation attributes. We can maybe ask for feedback from implementers what is easier to implement. And have a clear note in the spec how they relate
nzimmermann: your concern was that attribute might override UA stylesheets?
AmeliaBR: The opposite.
<AmeliaBR> `svg|[hidden] {display: none}`
AmeliaBR: The presentation attributes would be overridden
nzimmermann: you are right.
krit: what specific feedback we need from implementers?
AmeliaBR: this was specifically about cascade issues. We just need to make sure it is clearly defined.
krit: disagreement with being
consistent with HTML and add hidden attributes??
... I need to look at it deeper. But it sounds like it is not
just semantics but effects the styling
AmeliaBR: Implementation is not
that complicated.
... The semantic impact in fact of a11y is just coming out of
the stylesheet. If I make something hidden it gets detected by
accessibility software as well.
... I'd like to hear implementers commitment before adding it
to SVG 2 but have no concerns with adding them in general.
nzimmermann: no disagreement
Tav_: no disagreement
proposed RESOLUTION: Add a global hidden attribute to SVG with the same semantics as HTML that is expected to be implemented using UA stylesheets.
RESOLUTION: Add a global hidden attribute to SVG with the same semantics as HTML that is expected to be implemented using UA stylesheets. Iff there is implementation commitment
AmeliaBR: Who would be doing the
work?
... Will ask Zoe
AmeliaBR: This came out of
conversations on the mailing list. People were looking at the
published version of SVG2 w/o all fixes we put in
... We had many edits to SVG2 in the meantime. (Last CR more
than a year ago)
... We should update to make sure the changes are
reflected
... If people are actively working on fixes should we wait for
them?
... Or should we publish what we got?
krit: I'd prefer to publish sooner and publish another CR in 4-5 months as needed
AmeliaBR: Same preference. Many edits I want to do but time might not allow to get them in for the next cR.
RESOLUTION: Update CR for SVG 2 ASAP based on W3C staff feedback
https://github.com/w3c/svgwg/issues/750
AmeliaBR: The names of the tokens
in the path grammar between SVG1 and SVG2. It looks like one of
the values in the arc syntax was accidentally not
changed.
... Apparently some values must be positive at the moment.
krit: I think I did the last changes. Might be an oversight
AmeliaBR: SVG 1 used
nonnegative-number and we keep that. The third argument changed
the definition name which got confused and results into a
difference to SVG 1.1
... should allow negative value as 3rd argument.
... Boris has a longer set of recommendation how to clean-up
the grammar.
... Quick resolution is to confirm that the normative change
was accidentally.
... We may need to look into how fixing it in the GitHub PR
krit: Do we have tests to confirm?
AmeliaBR: I did a quick test
<AmeliaBR> https://codepen.io/AmeliaBR/pen/e5414de0f7e7ac89acab8f736765427d
AmeliaBR: seems like we do not have detailed WPT tests for path syntax.
<AmeliaBR> https://wpt.fyi/results/svg/path?label=master&label=experimental&aligned
RESOLUTION: WG confirms that the change of behavior to elliptic arc have been accidentally
krit: AmeliaBR do you follow up with Boris?
AmeliaBR: sure. I will do that.
trackbot, end telcon
This is scribe.perl Revision: 1.154 of Date: 2018/09/25 16:35:56 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: Irssi_ISO8601_Log_Text_Format (score 1.00) Succeeded: s/There is/So it only shows that there is/ Succeeded: s/ and no interest to implement otherwise// Succeeded: s/manage complicated animations with scipting/manage complicated animations without scripting/ Default Present: krit, nzimmermann, AmeliaBR, stakagi, Tav_ Present: krit nzimmermann AmeliaBR stakagi Tav_ Found ScribeNick: krit Inferring Scribes: krit Found Date: 20 Nov 2019 People with action items: WARNING: Input appears to use implicit continuation lines. You may need the "-implicitContinuations" option. WARNING: IRC log location not specified! (You can ignore this warning if you do not want the generated minutes to contain a link to the original IRC log.)[End of scribe.perl diagnostic output]