<scribe> ScribeNick: krit

SVG Native

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.)