<myles> ScribeNick: myles
<sairus> not hearing anything, for some reason
<sairus> OK. I can't hear you... let me keep working on figuring that out
GitHub: https://github.com/w3c/svgwg/issues/706
krit: there are multiple
problems. For context, SVG 1.1 had their own geometry
information. SVGRect, SVGPoint, SVGMatrix, etc. Then we
combined them with CSS objects. There was a CSS Matrix, CSS
Rect, etc. This would be DOMPoint, DOMMatrix, etc.
... And replace all the types with the new types.
... Robert from Firefox sees issues with this approach and
requests that we change it back to SVG*** from DOM***
AmeliaBR: The issue is the implementations in Firefox and maybe other implementations, the DOM classes were done in a lightweight way that the individual values within the object are implemented as literal values in the underlying C code, so they can't be used for getters and setters that have side effects, which are necessary if you're going to do attribute reflection
<sairus_> on phone :)
AmeliaBR: as I understand it, the
concern is that if they change that implementation so that
attribute reflection would be supported, it would reduce the
overall performance of the geometry interfaces in other
contexts.
... I didn't add this to the agenda expecting a decision. We
need to get more feedback from more implementors about looking
at what is in your code, what are the blockers for combining
the two sets of interfaces, and if there is a decision that
nobody has an intention to combine these interfaces, then
what's the best way to go forward?
krit: Or, rephrasing: We have
those properties in the SVG DOM, which means that any change
that comes from anywhere are reflected everywhere.
... Usually a property that returns an object, it has no
bindings to the original value that created the API
... But, instead of a new object, it gives you an object that
references the internal value
... that's waht we call "live-ness"
<AmeliaBR> `el.viewBox.baseVal` returns an SVGRect/DOMRect which remains live-linked to the `viewBox` attribute.
AmeliaBR: The viewbox attribute
is reflected as an object. If you change that object, the
attribute updates. But, if you change the attribute somewhere
else, the object that you're holding a reference to needs to
update to. So, internal to the implementation of that object,
it needs a poitner back to the element. Instead of storing the
values in a permanent way, it needs to have getters and setters
that check the current values on the DOM element.
... The other use case for these geometry properties as
something you can do math with in a way that, you call a method
and it returns an object htat has X, Y, width, and heigh
tproperties, and you can do transforms on it
... And if you do math on it, it doesn't have a conection to
the original element.
... So, if you make it live, it gets slower
krit: myles, can you ask shallawa for advice?
myles: yes
AmeliaBR: We need feedback from implementors before we can proceed.
krit: Let's wait for the WebKit investigation
AmeliaBR: the SVG*** interfaces are the live, previously impelmented interfaces, though they also work in a detached way if you want. The DOM ones where defined to replace the SVG ones but the implementations that went ahead only focused on the detached use cases, and don't support the live use cases.
krit: All the SVG ones are live.
SVGAElement implements two conflicting interfaces
GitHub: https://github.com/w3c/svgwg/issues/312
AmeliaBR: We've discussed this
before. We know how we want the spec to work for backwards
compatibility needs, but we need a way to make it correctly
defined in WebIDL. I put it on the agenda because we got a bug
report that it was breaking some Web Platform tests that were
trying to create automatic tests based on IDL and our IDL is
broken.
... We're using an HTML mixin which defines an href property,
but we also have our own mixin that defines a different version
of the href property. The SVG <a> element uses both of
these mixins, and there's nothing in WebIDL that says which one
should have priority. For backwards compatibility, the SVG
version needs to have priority even though its less
useful.
... My suggestion is maybe we can somehow introduce a "dummy"
interface just so that we can inherit from the dummy interface
in a way that it makes it clear that the SVG href is overriding
the HTML href. It's kind of an ugly way to do it, but it's an
ugly situation. The important thing is the end result spec is
clear about what should happen.
krit: The problem is that href is defined in two interface objects, and HTMLAElement implements both.
AmeliaBR: And WebIDL doesn't
define which one wins.
... But if you both inherit and override, then WebIDL does
define which one wins.
... So if we created some sort of interface that implements
HTMLHyperlinkUtils, and inherit from that, and then override it
....? It's going to be ugly either way. The other way is to
take this up with WebIDL and get it officially specified
somewhere in IDL that if you have two mixins, there is a
priority order. This is a cleaner solution.
... It requires a dependency on another spec.
krit: Is it possible to inherit from a non-interface object?
AmeliaBR: I don't think so. That should be a mixin rather than an interface.
krit: righ.t
... Another alternative is we don't use
HTMLInterfaceHyperlinkUtils
AmeliaBR: I don't think we have any implementations. I haven't tested
krit: What if we make a resolution depending on testing? We can make a resolution now, and then re-discuss if there is an implementation of HTMLHyperlinkUtils
AmeliaBR: That probably makes
sense
... If we don't have implementations, we can drop it. Though,
one of the reasons we don't have implementations is because of
this confusion, and implementors don't know what to do.
krit: Are those requests coming from implementors?
AmeliaBR: ....
krit: We should bring this back
to another Working Group. Or WHATWG?
... Maybe someone can follow up on public-script-coord
AmeliaBR: They have a github repo, this is the best place to go.
<AmeliaBR> https://github.com/heycam/webidl/issues
krit: AmeliaBR, can you follow up
with heycam?
... AmeliaBR, and possibly bring this up on the mailing
list?
AmeliaBR: Okay I will 1) confirm
that we don't have any implementations 2) follow up with WebIDL
with two conflicting mixins.
... Then we can come back and make a decision with more
information.
GitHub: https://github.com/w3c/svgwg/issues/700
krit: Do we need to discuss any non-<use> elements?
AmeliaBR: It's not specific to <animate>, it's just about xlink:href in general
krit: Is there a difference between <use> and <animate>? Or will this apply everywhere
AmeliaBR: It will apply
everywehre
... The issue is about URL resolution. An iframe srcdoc doesn't
have its own URL. It's defined in HTML to behave as the parent
frame's URL applies to the srcdoc. But if you put inline svg
which needs hrefs to its own document, then that's the wrong
base URL.
... so #target inside the srcdoc doesn't work becuase it looks
for one in the main page instead of the local page.
... This is similar to SVG inside shadow dom. The rules there
say, first, look in the main document. Initial implementations'
SVG cross references weren't working inside the shadow dom.
There is a general acceptance now that for shadow trees,
hash-only URLs should look in the local trees first, but some
of the details there are still undecided as well.
krit: For the shadow dom discussion, rniwa and annevk had different opinions, but eventually resolved on something. Would it be possible that we ask rniwa and annevk to comment on this issue as well?
AmeliaBR: Yes.
... Getting feedback from HTML would be useful because this
whole thing comes from an HTML situation. It's important to try
to coordinate with the shadow dom behaviors. I'm not sure how
much of that has actually gotten reflected into specs.
krit: There are similarities with
shadow dom. Hopefully we can get a solution soon.
... AmeliaBR, is there something else you are looking for?
AmeliaBR: I can't remember.
... one option is to go like CSS and just say if the URL starts
with a hash, treat it specially. But if we can have more
general rules, that would be helpful anyway.
... At this point, if you can follow-up with anybody relevant,
that would be great.
GitHub: https://github.com/w3c/svgwg/issues/707
AmeliaBR: Should we add a cross
origin attribute to the use element.
... Right now, none of the browsers support <use>
references to cross-origin files. But they do support it to the
same origin.
... When SVG introduced the cross-origin attribute for
<image> and <script>, it was added to <use>
but it got pulled back because it was unclear how it would work
with shadow dom, and how that would affect cross-origin. I
think that is cleared up now. The way we agreed that
<use> should be a closed shadow dom where you can't
access the internals
krit: I don't think we have consensus on that
AmeliaBR: I thought we agreed? I can dig up the issue
<AmeliaBR> https://github.com/w3c/svgwg/issues/363
AmeliaBR: Everyone agrees.
... But! Neither of those really make a difference. All those
complications would be the same. The use case brought up in
this new issue makes a good point, that because cross-origin
<use> isn't supported, the workaround that authors have
to use is to fetch the cross-origin file with script, and then
inject the markup directly in their page, because this is
less-secure than <use> cross references, we say things
like "don't run scripts"
krit: But if there is a less-secure method, then providing a more-secure method isn't necessarily a win for the users
AmeliaBR: There are two risks. 1)
Allowing the current webpage access to the content from the
other domain, but I'm not suggesting that we should allow free
origin; it should be based on CORS
... This is security for the webpage author when you're
referencing a 3rd party domain, where the content on that 3rd
party domain might change.
... We get a little bit of extra security if the page author
opts into it. Like CSP.
... Also, it's easier for the author (less lines of code)
krit: We already define cross-origin attribute for other elements. Specification-wise, it wouldn't be a big deal to add it. Do you think implementations would implement it? Or should we move it to SVG 2.1.
AmeliaBR: I'd like to resolve that we'd like to add this, but then ask implementors whether they think it can come in the short term or whether it should be delayed
krit: Any concerns for adding the cross-origin attribute to <use>?
<silence>
RESOLUTION: Add cross-origin attribute to the <use> element in a current or future spec
RESOLUTION: Add cross-origin attribute to the <use> element in a current or future spec
krit: Since we resolved on that part, we can at least have a note with our intentions into SVG 2.
AmeliaBR: Sure. We can add a note and open issue, requesting implementor issue
krit: That's part two. For now, let's resolve on a note.
<some general discussion about the merits of a note vs normative text>
AmeliaBR: We should start the request for feedback right away, on the issue therad.
*thread
RESOLUTION: Add the cross-origin attribute to the <use> element to SVG 2, and mark it at-risk
RESOLUTION: Request implementation feedback about the cross-origin attribute to the <use> attribute
GitHub: https://github.com/w3c/svgwg/issues/689
<krit> ScribeNick: krit
sairus_: SVG OT spec does not
support pattern, marker and symbol
... but not banned either
... The use element is specifically used as an example in the
spec though
myles: We can probably agree on
patterns
... Apples implementation is the only implementation as far as
I know that supports it and we didn't find any content that
uses it. We can remove.
AmeliaBR: Depends on the use
cases for SVG Native.
... if the idea is that the files are individual icons or small
things in general then Wouldn't expect anything of that to be
in.
... otherwise I would imagine that you want to reuse shapes to
simulate shadows w/o rewriting the same shape.
... for patterns there is even more
... For patterns, every dot can add a lot of markup in
comparison of using a pattern once.
... making the SVG larger and less easy to work with it
myles: file size vs supported
features is a trade of
... There is no content that does use patterns for fonts.
... and that makes sense since the files are so small
... there is a point for supporting it on the other hand: 1)
there is no wide support for fonts and 2) there is a way to do
visually the same w/o patterns
sairus_: There were discussions to add patterns to the OT table. IT would be a competitive advantage to support it in SVG Native.
myles: will all implementations update to do it?
sairus_: Patterns doesn't seem to be a minimal subset. Though SVG Native is not really "minimal".
AmeliaBR: Myles point is that it is easier to add features later.
myles: there is a CGPattern... an API to draw patterns in CG. The pattern space is different from the document coordinate space and it is tricky to match the 2 spaces and that part is not in the API
RESOLUTION: Patterns are not part of SVG Native
AmeliaBR: markers and symbols we were leaning to not support?
myles: A tool that generates SVG
Native file would know the geometry for markers. So we can omit
it. Not much markup anyway
... And as far as I know it does not have wide support in OT
implementations
RESOLUTION: Markers are not part of SVG Native
myles: I think we have to support
use. There is much content out it that uses it.
... Apple does not support symbol.
AmeliaBR: Symbol to me is very
similar to nested SVG.
... as it affects coordinate system and internal coordinate
system. They should be treated the same. So I would say no
symbol either. But there definitely are use cases for
symbol.
myles: symbol doesn't let you do what you can't do otherwise.
AmeliaBR: It allows creating a
new SVG viewport
... that is why it is similar to nested SVG.
krit: I would be ok with removing.
AmeliaBR: use is still useful w/o symbol.
RESOLUTION: Symbol and nested SVG elements are
not part of SVG Native
... Allow use element in SVG Native
myles: gradients sharing color
stops?
... we support it in our implementations.
AmeliaBR: used a lot in Adobes
SVG export.
... Ai ends up with using lot of gradients but all sharing the
same color stops.
... shouldn't be a large implementation addition.
krit: inheritance and currentColor might be the biggest issue but that applies to everything
myles: don't think anyone
considered it
... IMO if SVG OT doesn't mention something it is supported
since it is SVG 1.1 minus stuff
AmeliaBR: It would be useful for fonts to define stops once and use it at different positions for different glyphs
myles: does Adobe's OSS implementation support it?
krit: it does.
RESOLUTION: Support href on gradients referencing gradients
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/???/coord/ Succeeded: s/support/agree on/ Succeeded: s/CTPattern/CGPattern/ Succeeded: s/CT./CG./ Succeeded: s/at different/at different positions for different/ Default Present: krit, AmeliaBR, sairus, myles, stakagi Present: krit AmeliaBR sairus myles stakagi Regrets: chris tav Found ScribeNick: myles Found ScribeNick: krit Inferring Scribes: myles, krit Scribes: myles, krit ScribeNicks: myles, krit Found Date: 15 Jul 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]