<scribe> Scribe: nikos

<scribe> scribenick: nikos

Unknown elements behaving as g

nikos: There was a github isse about tidying this text up
... Dirk pointed out that we may have removed this feature
... I looked into the history
... the latest resolution I could find was 2013 where we resolved to remove the feature

https://github.com/w3c/svgwg/issues/122

scribe: Erik remembers discussion after that where we decided to keep the feature
... I don't mind putting it back in, won't be too much editing work
... also think it wouldn't be too bad to just spec current browser behaviour
... in terms of getting SVG 2 to CR
... then look at web components and custom elements and what to do with unknown elements later

Tav: why do we want unknown elements to act as g?

AmeliaBR: the way unknown markup is treated in html is that it's just transparent
... and you continue with child content
... in svg the only element that behaves like that is g
... it's useful because you can be a little more forward focused, if there's additional new markup that the current ua doesn't recognise
... it can find the parts it does recognise
... and generally try to make more robust features that could potentially be extended to custom elements

Tav: if I have an unkonwn element with a transform
... it would act like g with a transform?

AmeliaBR: yes
... and global attributes and styles could be applied
... I know we discussed this recently because we were discussing implementation details

Tav: has anyone implement this?

nikos: I've tested Chrome, Safari, and FireFox and they don't render and use the SVGElement interface

Tav: From our point of view, if you have unknown elements, I don't think we would want to deal with them
... we would have to parse it - say it's not a g but acts like a g
... we would have to make sure we output as it originally was

nikos: what were the obvious problems with the html parser?

AmeliaBR: don't think they're unsurmountable, but if it gets to an element that isn't svg it'll insert a close tag

shepazu: My suggestion is if it's a roughly equal amount of work either way, is to add it to the spec, mark it at risk
... the impact is pretty low one way or the other
... I feel like if we add it to the spec and it gets dropped, it's not a tragedy
... gives us a chance to get feedback from other people
... turns out if it doesn't get implemented then we drop it

nikos: I'm happy with that

Tav: I'm indifferent, don't think we'd implement in the near future

nikos: ChrisL had raised concerns that if someone implemented an extension but put their custom elements in the svg namespace, then content could break

AmeliaBR: like replicate for instance
... might not hurt in that case, but there's cases where we could break content

shepazu: think that's pretty theoretical

AmeliaBR: yeah, we don't have huge frameworks like html

nikos: Ok, lets add it back in, do the small edits that are needed and see what happens to it in CR

AmeliaBR: Don't see it as a feature that's at risk, but the error handling behaviour is different

RESOLUTION: SVG 2 will treat unknown elements as g for the purposes of rendering, and they will use the SVGUnknownElement interface

Tav: make sure to mark it at risk

https://rawgit.com/nikosandronikos/svg2-cr-issues/master/svg2-cr-issues.html

<scribe> ACTION: Nikos to look at github issue #103 on Monday [recorded in http://www.w3.org/2016/06/09-svg-minutes.html#action01]

<trackbot> Created ACTION-3846 - Look at github issue #103 on monday [on Nikos Andronikos - due 2016-06-16].

Clarification on complex text shaping

https://github.com/w3c/svgwg/issues/65

Tav: This is basically about what breaks ligatures

AmeliaBR: there was discussion on www-style about this
... they had some related questions
... about line breaks and forced line breaks

Tav: my view is that we pass a block of text to css to layout, and we need to follow css rules for breaking ligatures at that point
... then we come back and do dx, dy, and rotate, and I don't think we should break ligatures at that point
... if you do want to break ligatures, we have font-variant-ligatures that can be used to break ligatures explicitly

nikos: I'm not an expert in that area, but sounds reasonable to me
... is there anyone specific you'd like input from?

Tav: there was some discussion when one font has ligatures and one doesn't, if you substitute and get ligatures there might be problems

AmeliaBR: sensible point is to allow them and author can turn them off if appropriate
... we can't judge what looks good so it has to be down to an author on that

RESOLUTION: We will keep SVG 1.1 behaviour wrt to ligatures allowed on text on a path

Tav: rotate will apply to the glyph, not to individual characters

AmeliaBR: no matter how large and awkward that is
... we can treat this as authoring advice

Tav: I'll add a note explaining how to turn them off
... Also about lengthAdjust=spacing
... if you put a non zero space it breaks ligatures

AmeliaBR: that's a css rule

Tav: what about textLength ?
... e.g. textLength="..." lengthAdjust="spacing

AmeliaBR: I would suggest to leave it simple

RESOLUTION: lengthAdjust=spacing will not break ligatures. Ligatures must be explicitly broken.

AmeliaBR: sometimes textLength will have negligible affect, but breaking ligatures will have a much larger effect on the text length

<AmeliaBR> https://github.com/w3c/svgwg/issues/102

Cleaning up title and desc

AmeliaBR: jarek created issue that elements are a bit arbitrary about whetehr they allow title and desc
... it's part of a larger issue of inconsistency in the spec
... want to see if people agree that we allow it pretty much everywhere
... even for pattern and stuff that is not accessible to a screen reader
... there is a theoretical accessible use where you can use non rendered elements as part of a description of a shape
... I've got an example of that
... or it can be general metadata
... I don't see a logical reason to prohibit that
... current status in SVG 1.1 is somewhat random

nikos: I'm ok with that, obviously switch can't have it. Anything else?

AmeliaBR: that's the only one I have an issue with
... html elements borrowed from html namespace wouldn't have them

RESOLUTION: title and desc can be a child of any svg namespaced element except switch

https://rawgit.com/nikosandronikos/svg2-cr-issues/master/svg2-cr-issues.html

This is scribe.perl Revision: 1.144  of Date: 2015/11/17 08:39:34  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/piont/point/
Found Scribe: nikos
Inferring ScribeNick: nikos
Found ScribeNick: nikos
Present: nikos Tav AmeliaBR shepazu stakagi
Agenda: https://lists.w3.org/Archives/Public/www-svg/2016Jun/0009.html
Found Date: 09 Jun 2016
Guessing minutes URL: http://www.w3.org/2016/06/09-svg-minutes.html
People with action items: nikos