<scribe> ScribeNick: AmeliaBR
krit: We have daylight savings time changes in the next two weeks. Times get out of sync next week.
<myles> biweekly calls sound good
krit: We've also had a lot of calls lately cancelled because of lack of agenda items. Maybe switch to calls every two weeks?
<myles> until we hear that someone has been hired, we should proceed as if we have no hire.
AmeliaBR: That sounds good. Can always switch back if we get busier.
Tav: Might get busy if someone new gets hired to do spec work. But we biweekly sounds good for now.
<myles> so we'll be skipping next week's call?
AmeliaBR: Proposal is skip next week, then biweekly from Nov 4, 4pm Boston time
krit: For now. I'll also send out a survey for asking about other conference times. We had 2 people respond to say they'd like to participate, but can't at this time.
github: https://github.com/w3c/svgwg/issues/706
Myles: We (Apple/WebKit) did some investigation. Agree with the OP (Robert Longson/Firefox) that we'd prefer to keep the SVG/complicated types separate from the simpler DOM types
krit: And there's support in the
issue from Chromium devs, too.
... The DOM Geometry spec was designed to harmonize the
existing SVG types with a broader use case, so this would
revert that.
myles: But the reality is that we have, de facto, 2 different behaviors: live elements vs non-live. Encoding that difference formally in the type system makes it easier for authors to understand what's happening. Vs if we have one type that is sometimes live & sometimes not, it's harder to predict performance characteristics.
Amelia: I agree that there is benefit of having clear type definitions. Especially re read-only types, it's currently very confusing.
krit: For the read-only types, if we remove the alias, do we still have a need for the read-only versions?
Amelia: I don't think it affects it. The SVG DOM doesn't use the read only DOM types, because read only constraints are two levels up in the nested objects.
krit: Question is, what is the use case for the read-only types if they're not connected to live reflection.
Amelia: I don't know. Performance, maybe?
krit: I don't think there's an
implementation impact.
... In addition to the base types, we also now have all these
*Init types. What to do about them?
Amelia: They should be kept.
& they will cover most of the harmonization, anyway. All
parameters take the init types, so both the SVG* and DOM*
versions will work, passing as parameter's to each others
methods.
... Other thing to consider. We've got methods & stuff that
we don't want to spec twice. So we should probably extract
things out to a mixin. E.g., a Point mixin that is implemented
by both DOMPoint and SVGPoint.
krit: That's reasonable. But I want to avoid too much change to the Geometry spec. Currently the change is mostly at the SVG level. SVG defines the aliases.
Amelia: What status is Geometry Interfaces?
krit: CR. But it's more than just process, it's also having to do the work.
myles: I also think that mixin model is the way to go.
krit: That would need approval
from CSS WG, for changes to Geometry.
... We could agree to change the SVG spec to use the SVG* names
in all the IDL. But currently, that wouldn't have an effect.
They're defined as aliases.
Amelia: SVG spec would need to define the SVG* interfaces, but they should use mixins defined in Geometry.
krit: Proposed resolution #1:
revert decision to make SVG* geommetry interfaces aliases of
the DOM* geometry interfaces
... Proposed resolution 2: Change the SVG spec to use the SVG*
interfaces instead of DOM*
Amelia: Except for where we've already switched to using DOM*Init types
krit: That should be a separate resolution.
Amelia: Then 4th res would be: Ask CSS WG to approve separating out most of the geometry interfaces into mixins we can reference.
krit: and to accept reversal of aliasing.
Amelia: That's also defined in DOM Geometry?
krit: yes.
... I don't object to prop res 1 & 2, but I want to record
that this is because of implementor priorities & could
change in future. I'm also not voting in favour.
Amelia: So you're abstaining?
krit: yes.
RESOLUTION: Revert decision to make SVG* geommetry interfaces aliases of the DOM* geometry interfaces (pending CSS WG approval)
RESOLUTION: Change the SVG spec to use the SVG* geometry interfaces instead of DOM* interfaces
RESOLUTION: Keep the usage of DOM*Init types in the SVG spec
RESOLUTION: Ask CSS WG to approve separating out most of the geometry interfaces into mixins we can reference in SVG interface definitions.
github: https://github.com/w3c/svgwg/issues/467
krit: We've discussed this previously. Not sure what is new. Amelia added it.
Amelia: Not sure myself. This is a needs edits issue. There was a new duplicate posted, but that doesn't change much. There was another new issue, that's maybe worth discussing.
github: none
github: https://github.com/w3c/svgwg/issues/741
Amelia: This is in respect to
window event handlers. In HTML, you can set these with
attributes on the body & they're reflected up. In the SVG
definitions.xml, we've got a defined class of these attributes
but don't actually use it anywhere.
... There's also confusions because a lot of these events have
changed since SVG 1.
... As far as I could tell, no one supports the attributes, but
I haven't tested all the details.
krit: So we need more tests?
Amelia: Yes. Though maybe not
ready for formal WPT tests yet. Need to figure out what the
spec should be based on what works.
... My preference is to match implementations & match HTML
as much as those intersect. Not a strong argument for
`onunload` and `onload` attributes and such.
... Next actions? Should we try to ping more implementers?
krit: That sounds like a good idea. I won't have time to look at it.
github: https://github.com/w3c/svgwg/issues/745
Amelia: We previously agree to
allow miter-clip values between 0 and 1 because most browsers
did already & it didn't affect rendering. But with some of
the new clip styles, it would cause an effect.
... my preference is to define it so that values < 1 never
have an effect: you never have a clip less than the bevel.
Tav: I agree & I can do the
edits.
... But these are slightly different statements. Do we want to
always use a value of 1? because that is sometimes more than
the bevel for a miter-clip.
Amelia: I guess there are two
options. Treat 1 as the minimum used value, versus treat the
bevel rendering area as the minimum join area.
... the pictures Tav posted earlier today show some of these
cases.
... which is your preference?
Tav: For smooth animations, you would need to allow less than 1, but still always keep the bevel area.
Amelia: Sounds good to me, unless
we have objections from implementers.
... proposed res: The "line join shape" is never less than the
shape defined for a bevel join, regardless of the
stroke-miterlimit value.
RESOLUTION: The "line join shape" is never less than the shape defined for a bevel join, regardless of the stroke-miterlimit value.
krit: No call next week. Call in two weeks at this time.
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) Default Present: krit, AmeliaBR, stakagi, Tavmjong, myles Present: krit AmeliaBR stakagi Tavmjong myles Regrets: Myles Sairus Found ScribeNick: AmeliaBR Inferring Scribes: AmeliaBR Found Date: 21 Oct 2019 People with action items: 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]