<krit> ScribeNick: AmeliaBR
github: https://github.com/w3c/svgwg/pull/374
krit: There's an open pull
request from Eric, but it's been there for some time.
... We discussed & made requests for changes, but Eric
hasn't been able to do this.
Amelia: Someone else needs to do the edits. We have agreement on what to say.
krit: Should we be marking it as at-risk? Do we have implementations?
tav: Inkscape now supports it for rendering.
Amelia: And our agreements should match the Chrome implementaiton, so that's 2.
krit: Who wants to take over?
Amelia: I can.
Chris: I think there are only minor conflicts.
Amelia: But also need to check that our resolutions are integrated.
krit: Anything else to discuss?
Amelia: No. I'll try to do the work this week.
github: https://github.com/w3c/svgwg/issues/196
chris: domenic already said (in
an HTML PR) what needs to be done. We can copy the HTML
edits.
... I think we should get something in the spec & then ask
them to review.
krit: I think the changes are (1)
include the new mixin, and (2) reference the right
section.
... anyone willing to do the edits?
chris: I could take a try, but not super familiar with the topic.
Amelia: OK. You can always bring
the issue back up if anything is unclear.
... Do we need a resolution?
krit: Wait until we have a proposed text.
chris: The bits about currentScript, is that implemented or defined anywhere?
Amelia: I think it's defined in HTML, just need to acknowledge that that can be an SVG script.
github: https://github.com/w3c/svgwg/issues/467
Amelia: Complaint is that the wording is too vague, re event handler attributes. Ms2ger's suggestion, which I support, is to reference the DOM/IDL event handlers, which are an explicit list defined by mixins.
krit: Is this editorial, or a change?
Amelia: Should be editorial,
matching implementations.
... Don't know if we need a resolution. But probably also want
to clear out some other text that may conflict with HTML.
krit: If I do the edits, can you review?
Amelia: sure.
github: https://github.com/w3c/svgwg/issues/699
<krit> ScribeNick: krit
AmeliaBR: this issue was brought
up be ppl working on a standard within IEC for describing power
station interfaces. Representation should be described with the
help of SVG. And the group would integreraet this into their
standard without the full complexity of SVG. However, the group
does want to have text which is not part of SVG Native for
instance. SVG tiny doesn't fulfil the requirements
either.
... So the request is to have a way to specify a subset by
referencing sections they need.
... They also ask for an SVG schema that they can include by
reference.
... IMO it is a nice comparison to SVG Native. We also want to
define a subset of SVG full. As we go on with SVG Native we
should think about subsetting SVG full in a more general term.
A process that other ppl can follow
... We would also need to define how that can be conformant
checked with test suites.
sairus: At the OT meeting last week we talked about features that are not even covered by SVG Full like CMYK support. Could SVG Native be the minimum subset for any specification in the future?
chris: Like the idea but the spec currently has not text support which might make it to minimal.
AmeliaBR: Yeah, some ppl need the full functionality of shapes with all its complexity but not interested in colors.
chris: CSS Colors 4 covers CMYK. Happy to talk to you about integration in SVG Native.
sairus: thanks. So is SVG Full too complex in general?
AmeliaBR: There are differences
between authoring tool and rendering applications like web
browsers.
... So we would need to define a conformant viewer and the
other side around.
sairus: IMO OT handles it very well with its tables. Implementations just support some table but not the others. Defining tables in OT is organically.
AmeliaBR: OT has the table structure that allows list out the tables which an implementation supports or does not support. SVG has elements, attributes and style properties which all interact.
sairus: OT has kind of similar issues and it can get complex too. But we handle it organically in the OT world but not in a standardised way.
AmeliaBR: this is kind of how it worked in SVG by saying which parts are not supported. Comes up to quite some details that need to take into account and makes it hard to describe the subset. Especially to avoid any conflicts.
myles: CSS has the design where
futures are detectable with fallbacks. Each implementation can
support a different set of properties and websites can provide
fallback for some browsers and use another for yet another set
of browsers. Maybe we should have a similar model in SVG?
... Let software detect what is supported and use
mechanisms.
AmeliaBR: SVG did have a supported testing feature which was poorly defined and implemented so we dropped it. Sadly w/o any replacement.
<AmeliaBR> SVG 1/1.1 Feature strings: https://www.w3.org/TR/SVG11/feature.html
myles: In CSS you can define a property twice. If one doesn't work take the other one. Can we do something similar with attributes?
chris: not really, no
... CSS has a document order. In XML each attribute can just be
used one and in practice they are in order.
AmeliaBR: There was the idea to
use switch element. Test one thing and switch between one
element or the other.
... 2 questions: a) can we define a nice subset with easy way
to define which should be supported. b) is it possible to write
fallbacks and detections to handle multiple environments.
... myles on the first question: Have you looked at SVG Native
and how this cold be done there? Have you looked into other
ways but using the diff as it is done currently? Like using a
table with supported values and fallbacks?
myles: I was planning doing that and asked the WG. The advice that I got was to keep it as a comparison with the original document.
AmeliaBR: but in the sense that
you do not duplicate content. Doesn't mean that it needs to be
done chapter by chapter. Try to find a link from SVG
Tiny.
... SVG Tiny had an appendix with just a table of elements and
what is supported.
myles: I think a table in the
spec sounds fine and I would be happy to do that.
... I think the point here is to find guidlines how different
parts interact with it.
AmeliaBR: That would be the first
part. 2nd would be defining how conformance tests work with
it.
... We also need to look at extensions in the case of IEC with
custom elements and attributes in custom namespaces.
myles: I don't have good ideas how to define or follow good practices.
krit: could AmeliaBR and myles brain storm and see if and how this could be done?
AmeliaBR: myles: I think we can do that.
myles: planning to do another pass soon to add all the resolutions we did in the group yet.
AmeliaBR: and by doing it we
should look at all the complications.
... the other aspect would be how to work with the conformance
side of things.
... How do we deal with browser and non-web environments?
Figure our which tests are relevant of this?
myles: are those part of the platform tests for SVG Native? It is not targeting the web.
AmeliaBR: No, but if we take SVG Native as a foundation we should think about it .
krit: maybe we can take it one step after the other and look at conformance 2nd.
myles: I think we should have a list of tests for web platform and non-web tests.
AmeliaBR: definitely one way to
go. Concern is that we do not have a suite for SVG2 yet
... So we would need to look at all new tests to see in which
buckets they could go
myles: some amount of gardening is required. Either authors or reviewers/spec editors. Not sure which one is better than the other.
AmeliaBR: So course of action on this issue is to keep everyone updated and use SVG Native as a "test case" of a defined SVG subset.
RESOLUTION: Myles and Amelia brain storm on subsetting specs based on SVG Native and get back to the group
GitHub: How should currentColor be handled?
chris: my proposal would be to allow currentColor but do not require the color property.
myles: matches what I imagined.
AmeliaBR: it would be consistent with variables.
krit: should not? Must not? (support color)
AmeliaBR: myles: Conformant doc must not support color and a UA should not support color
<AmeliaBR> https://docs.microsoft.com/en-us/typography/opentype/spec/svg#colors
AmeliaBR: There was a question about color supported in OT SVG fonts. Any input if there is content affected by the new decision?
<AmeliaBR> github: https://github.com/w3c/svgwg/issues/678
krit: Authoring tools likely don't support color but manual created SVG documents might. Testing/tracking required on the platform layer to be sure.
AmeliaBR: Seems like it is not explicitly forbidden in the OT spec.
sairus: It is an implication.
myles: Apple's implementation does not support the color property.
krit: If there is one major platform that does not support color than my concern is less relevant.
AmeliaBR: maybe it should at
least be added to the avoided list on the OT spec.
... sairus, could you follow up?
sairus: will do.
RESOLUTION: Conformant SVG Native documents must not set the color property and a UA should not support the color property.
myles: Our implementation actually DOES support color. Was minuted wrong. We just don't have fonts in our repository that do use the color property.
sairus: it is recommended that color attribute or property should not appear in an SVG Native document?
chris: that is right
proposed res: currentcolor for SVG Native is set by the initial value of the color property of the environment.
RESOLUTION: currentcolor for SVG Native is set by the initial value of the color property of the environment.
<AmeliaBR> github-bot, end topic
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/UI/UA/ Succeeded: s/currentcolor/color attribute or property/ Default Present: krit, chris, sairus, stakagi, Tavmjong, AmeliaBR, myles Present: krit chris sairus stakagi Tavmjong AmeliaBR myles Found ScribeNick: AmeliaBR Found ScribeNick: krit Inferring Scribes: AmeliaBR, krit Scribes: AmeliaBR, krit ScribeNicks: AmeliaBR, krit Found Date: 17 Jun 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]