<scribe> ScribeNick: krit
myles: SVG. Native is a subset of
currently shipping SVG.
... suitable for native apps. Overall Phil is that SVG is
similar to other image formats like PNG or JPEG but with vector
rather than raster
... For native apps, it is required to be performant, secure
and implementation
... Web browsers have a sandbox for web content.
... SVG content in a native context needs to be more secure
since there might not be a sandbox
... content in hosting app needs more strict implications and
requirements
... needs to be implementable w/o web browser based on existing
platform techniques.
... effort started in OpenType (fonts)
... this expanded to general purpose artwork and images. This
is why we bring it to W3C
... We brought up the initial draft to start the process.
... We'd like the WG to accept the proposal as a starting point
for an editors draft.
sairus: Draft looks great and is
a great starting point.
... OT SVG defines a minimum subset of SVG which is the same
subset of SVG Native. Right now it is not clear that they are
the same.
... Could we make this more clear that they are compatible
<stakagi> I think that it is worthwhile as a spec for the implementation of the SVG subset by javascript.
myles: there are at least 3
possibilities. 1. either all come together and we use one
profile to serve all 2. the opposite is that OT is distinct
from W3C spec (unprefered) 3. W3C creates a spec that is almost
the same as OT SVG and the latter can reference the former with
additions.
... The first option would be great. The 3rd option would be
the 2nd best and the lest preferred the 2nd option.
sairus: Shouldn
't OT be able to reference a spec then?
chris: Good to have a canonical spec and OT uses this spec with additions.
AmeliaBR: we might get a set of
profiles or a set of features. Others could reference features
with a bare minimum + additional features.
... That was the plan with SVG Tiny and its levels and
profiles.
myles: should ower document list
all possible use cases?
... I think it is better that the OT spec references the W3C
spec instead.
chris: I agree. And it would be
good that this referenced spec is in the W3C space.
... I don't think we can cover all use cases. The more use
cases the harder it gets to have a common subset.
sairus: When we started OT many
were concerned with the SVG complexity.
... Dean and Myles pushed later to have a profile.
... We liked this initiative. The important part is that the
core work has been done in SVG OT
... The OT lost confidence that the document in W3C space stays
current. So SVG OT defined its own set and let W3C figure out
the rest later.
... Based on this history, SVG OT might hesitate to referencing
SVG Native instead of putting everything in SVG Native
itself.
chris: we probably did not do the right job initially.
myles: another point: there are a
number of use cases. W3C should probably make this profile
independent of what OT does or says. Though we should take OT
into account of course.
... if we do a good job OT might reference the W3C spec again
in the future.
AmeliaBR: how do we define the
scope of the spec by all those different use cases?
... each use case has its own priorities what should /
shouldn
... t be included
... This spec can just be the specific use case for light
weight SVG graphics.
... And OT has a wider set of features
Tav: The introduction does seem to match what InkScape does. But then a lot of features were missing like text.
chris: It is very common to use
text in technical graphics
... removing text is the one complex thing to implement
myles: Given the relation to PNG
and JPEG: those do not have selectable text either.
... text could be converted to outlines.
... as chris says, cuts down on implementability.
sairus: every thing in SVG has a good use case. Otherwise it wouldn't have been in the spec in the first place.
dino: Adobe Illustrator always had an option to convert text to outlines. What else is missing what InkScape needs.
Tav: Markers, style element and clipping and masking.
myles: we should discuss all the
specifics after we agreed to use the draft
... out idea with the draft is if there is another way to
represent the feature it is a good candidate to get
removed.
... It makes sense to keep the expressible part as much as
possible since it must primarily be machine readable.
Tav: how do you express markers?
chris: removing markers would remove the semantics.
myles: right, that move the implementation to the exporting tool
dino: It is almost the set of
drawing commands required to render SVG documents.
... like a set of drawing commands that gives you the
interop
<stakagi> I think that it is better to make specifications based on the actual implementation that anyone can easily modify and extend.
krit: focus is on rendering and not semantics. A11ya nd semantics are less important since that happens on a higher level. SVG Native addresses the lower platform level where this is not needed.
Tav: so it is not meant to be edited.
myles: correct it is similar to
PNG... as result of an export
... do we want to continue working on this profile in this
WG?
... should we use the proposal as a starting point.
krit: heard in this discussion that it is. Any objections?
chris: I agree it is a good proposal
AmeliaBR: it is helpful to start
with it
... discussions can be based on this document.
... debate about what should go in or not go in can happen over
time.
myles: thanks for the feedback and the time to look through it.
RESOLUTION: We start SVG Native based on the proposed draft from Myles which gets a first ED
krit: any concerns about the name?
<chris> Core was a very bad name, certainly
myles: We started with SVG Core then we renamed to SVG Native. Then in the past couple weeks we got internal feedback to the name and the confusion with it. Few had a great replacement. We think that SVG Static is the best of bad options.
AmeliaBR: Static is problematic since it has a meansing in SVG's processing mode.
<AmeliaBR> https://svgwg.org/svg2-draft/conform.html#static-mode
AmeliaBR: (SVG as static image has these features... <img src...)
<stakagi> SVG Basic?[
krit: was a proposal to name it SVG Tiny 2.0 however, 1.2 still had interactions, scripting and animation in it.
sairus: core?
AmeliaBR: this term is used internally already
sairus: SVG Simple?
myles: we don't have deep thoughts about the name.
AmeliaBR: basic exists already and is a profile with more features than tiny
krit: should we name the spec later?
myles: should I switch back to native for the ED?
chris: I think so.
myles: would you please upload a Bikeshed version?
dino: smaller changes need to be done then we do it.
AmeliaBR: I'd suggest starting with the meta question: structure and relation to SVG 1.1/SVG 2.0
myles: I chose SVG 1.1 since it
is mechanical a smaller spec and OT SVG did as well
... there are features from SVG 2.0 like color space that I
want
chris: you get that by referencing CSS specs
myles: suggest to base it on SVG 2
general agreement
<chris> And I do want the extended color spaces
sairus: OT based it on SVG 1.1
chris: was a huge spec with many not implemented features. SVG 2 is now different and has a lot of corrections.
myles: I don't plan to change functionality. Benefit would be the corrections/bug fixes from SVG 2.0. No affect on supported features.
sairus: Someone who reads OT SVG might be confused since 1.1 and 2.0 are different specs.
chris: the overall structure is similar.
sairus: OT says implement 1.1 except for these features.
krit: SVG NAtive will be a subset of SVG 1.1 and SVG 2.0 but uses the corrections from SVG 2.0 that fixes a couple of features.
AmeliaBR: I see that as a problem for OT since the structure might be different.
sairus: There might be a difficulty since OT SVG implementations are done and now W3C comes with SVG 2.0
chris: when you look at SVG 2, there is not so much of a difference.
sairus: someone needs to know that.
krit: you could help the OT group to understand the differences for SVG 1.1 and SVG 2.0
sairus: I will but usually mailing lists are not the best way to solve concerns.
RESOLUTION: SVG Native will be based on SVG 2.0
sairus: what about SVG next? Will this change SVG Native?
chris: there won't be a new version. we split into modules.
AmeliaBR: we do not plan to publish another monolithic spec.
chris: we should communicate this better.
AmeliaBR: with structure I mean
that the spec is written as "this section is deleted". So an
actual diff to SVG full.
... I'd rather like the spec to be a little bit more fouced on
actual supported features instead of referencing each
section.
myles: I should clarify when something is deleted or forbidden,
AmeliaBR: SVG model does not delete... it ignores unsupported effects/features.
myles: forbidden or deleted shall mean ignored.
krit: would address my concerns
as well?
... how do you want to have the request organised?
myles: Someone needs to characterise the issues and create an issue per category.
krit: agree
AmeliaBR: definitely the way to go
rackbot, end telcon
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, Tav, AmeliaBR, stakagi, chris, sairus, dino, myles Present: krit Tav AmeliaBR stakagi chris sairus dino myles Found ScribeNick: krit Inferring Scribes: krit Found Date: 15 Apr 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]