<nikos> Morning AmeliaBR. Just about to start - will get shane to setup hangouts again in a sec

<heycam> https://svgwg.org/svg2-draft/styling.html#PresentationAttributes

<shane> AmeliaBR: https://staging.talkgadget.google.com/hangouts/_/google.com/svgwg

<scribe> scribenick: birtles

<scribe> scribe: birtles

Resolving on presentation attribute strategy

heycam: some f2f ago, I took an action to present options about what to do about presentation attributes
... I'd like to discuss if we need to change our approach
... I added a big table to the styling chapter

<heycam> https://svgwg.org/svg2-draft/styling.html#PresentationAttributes

heycam: about which properties have presentation attributes and on which elements they're supported
... it's basically the set of SVG 1.1 properties plus about 3 new ones
... paint-order, vertical-align, whitespace
... they're the new ones I think
... plus the other ones we've promoted to properties
... it's a pretty ad-hoc set of properties
... but I don't want to require that every property that implementations support have a corresponding presentation attributes
... since many of those properties won't have any effect
... so I wonder if we can say that all properties that have some sort of effect in SVG have presentation attributes
... is that a good idea?
... and if it is, how would we state that

shane: what do you mean about "have some sort of effect"?

heycam: yeah, that makes it difficult to define the set
... an example might be something like text properties
... that are orthogonal to anything we define in SVG but still have an effect
... so people don't have to think that font-style is a presentation attributes but font-variants-ligatures is not...
... we don't need to say anything about font-variants... in SVG, it should just work

Tav: I think that idea is actually pretty good
... from our perspective, anything that is a property is automatically a presentation attributes
... we support anything that changes the rendering as a presentation attribute

AmeliaBR: the main concern I have is making if forwards-compatible
... we could say that anything that could apply to an SVG element could be specified as a presentation attribute
... then if it doesn't have an effect it doesn't have an effect
... but the complication there is name conflicts
... we could never add an SVG attribute that might overlap with any existing or future CSS property

shane: is the situation with presentation attributes, the value of the pres attribute is fed through the CSS cascade
... could we just add an automatic pathway for every attribute SVG defined and feed it into the cascade

(some confusion)

correction: every attribute that is *not* defined by SVG as an attribute would be fed into the cascade

<Zakim> shepazu, you wanted to ask about xlink:href and to

shepazu: I think this is pragmatic, but there is the complication that it pollutes the infoset
... we'd have to find some way of framing this so that we're not defining them but they're part of the schema

heycam: we have some prose that covers whether the document is valid or not

AmeliaBR: regarding whether only properties that have an effect are allowed or all properties are allowed
... that could be an implementation detail
... what about inheritance and foreignObject
... if you set some sort of CSS layout property on an SVG element as a presentation attribute
... then you have a descendent foreignObject the cascade has to work in a predictable way
... I understand you might want to expose some properties as presentation attributes
... projecting all of CSS into SVG will create a very difficult maintenance problem
... for variations of...
... discoverability and detectability will be a problem in the case where you have, e.g. @supports
... you don't have that discoverability on the SVG layer
... saying that we will future-proof SVG by saying that all properties from now on, if applicable, will affect SVG
... but in general it applies to all elements
... and this works for HTML because it doesn't have these attributes
... so we have a fairly clean separation of the two module
... here the line is not so clear
... the bijection of these two sets is not clean
... you have properties in CSS that don't apply to SVG, and attribute in SVG that don't apply to CSS

heycam: underlying what you were saying, is "presentation attributes aren't a great tool, and you can't @supports etc."
... if people agree on that then we should be encouraging people to always use style attributes and style stylesheets

Rossen: precisely
... if you are going to take a dependency on CSS then take a dependency on CSS
... in that case I would argue we are going to reduce the set of attributes as much as possible
... anything magical is a path to disaster

shepazu: I find Rossen's argument persuasive
... I don't agree with the part about reducing the number of attributes
... looking at this from a different lens
... if there are people who are used to using attributes, is this a best practice
... I think it makes things a bit simpler if don't add presentation attributes

shane: I think Rossen is right that we should be doubling down on using CSS for SVG
... not because it's more technically right etc.

Rossen: we have quite a bit of history here that we can look back on
... we didn't try to bind the type systems together
... if this is a module where we want to take a dependency, then we should take the dependency

<heycam> birtles: one question is are you then suggesting that authors type <rect style="width: 100px; height: 100px">

<heycam> ... I think the cat's out of the bag

<heycam> ... we have attributes already for things like width

<heycam> ... we decided to make them into properties

<heycam> ... and now it sounds like people should only use properties. I'm just speaking from the perspective of an SVG author

<heycam> ... if you're telling me now I need to put everything in a style="" attribute, that's not fun

<heycam> Rossen: we did that with HTML, it worked out well

<heycam> ... as soon you step into HTML, you don't have attributes

<heycam> ... if you want to integrate closer to HTML/CSS, let's do it

<heycam> ... if you want to keep away, then we have to keep away and continue down the path of attributes

<heycam> shane: it's also not true that geometry is not fundamental to CSS

<heycam> Tav: but it's styling

<heycam> shane: people say that, but you need it to get something onto the screen

<heycam> ... I think we have to get over presentation/content separation

<heycam> birtles: maybe we don't need to go into the philosophy of HTML and SVG too much

<heycam> ... I'm just saying there will be some difficulty in selling this to authors I think

<heycam> ... just from an author's point of view, it looks like a backwards step in terms of ergonomics

<heycam> shepazu: I don't think we need to make the decision now, abotu whether we're going to deprecate all of the attributes

<heycam> Rossen: i'm not asking for that

<heycam> Rossen: that reasonates with me really well

<heycam> shepazu: href for example

<heycam> ... second, I want to respond to something that Cameron said

<heycam> ... I don't think it's the most common practice these days to make things as attributes

<heycam> ... I think with scripting libraries they increasingly rely on CSS, so I don't think this will be confusing to them

<scribe> scribenick: birtles

AmeliaBR: I agree we shouldn't deprecate the presentation attributes in the near future
... regarding the original issue when it comes to formatting text and fonts we have limited subset
... can we clarify in that chapter: "here's the list of properties that can be used a presentation attributes"
... and within that context of styling text to say that using CSS is preferable
... and to say that there are other properties that can't be used as presentation attributes

heycam: I think that would make sense since there tend to be a lot of text properties that get added
... there is a set of presentation attributes in the style chapter already
... so that table of presentation attributes which has the existing presentation attributes plus the 3 new ones
... should we talk about those 3 new ones
... should we rip them out?

Rossen: yes

heycam: ok I'll see if I can unship them

Rossen: I'll help you out with authoring this chapter

Status update

<nikos> https://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Chapter_Assessment

nikos: 6 chapters still marked as "in progress"
... first is document structure

ed: no update, I haven't had time to update it
... it's fairly ready to go, just minor changes
... readiness 4

(no issues to discuss, just editorial)

Rossen: next is styling

heycam: I haven't updated the wiki, but now that we've discussed the presentation attribute, it's readiness 5
... just a few more tweaks

nikos: next is coordinate system, lots of changes here
... changes might not be finished by the end of the weekend but we know what we need to do
... should be done by the end of next week

Tav: for text, probably needs about a month to make the changes

Rossen: we can help

AmeliaBR: there are some issues with underspecified behavior of textPath
... I will try to coordinate as closely as possible

heycam: the main thing that Tav was waiting was the text-layout algorithm
... I wrote up most of that in a wiki page which hopefully Tav can translate into spec text

nikos: can that work be split up?

Tav: not really

heycam: that algorithm bit is pretty independent from the rest of the chapter
... so once my notes are ready someone else could do that

AmeliaBR: the only problem is trying to avoid having separate parallel definitions

Rossen: is that the main blocker for that chapter

Tav: I was also blocked by some of the issues we discussed at the FXTF two days ago
... but now I know I can rip some of the sections out

Rossen: I was just wondering how we can help

Tav: it's possible someone else could do the algorithm
... the rest I probably need to do and it takes time since I need to check stuff against the SVG 1.1 spec

AmeliaBR: I'll take a look at textPath

(Rossen and Tav will discuss the exclusions section)

heycam: the paint chapter is readiness 5 as of this morning

(applause)

Tav: I need to address the fallback for the arcs linejoin, however
... I need to find out what the preferred fallback is

AmeliaBR: re the paint chapter, what's the plan of integrating this with the proposal of fantasai
... where specifying the shorthand which will, in future, we subdivided into longhands

heycam: we can ignore that for now

BogdanBrinza: interactivity chapter: there a lot of changes we can do now

shepazu: whatever we do with focus, we should make sure we run it by the SVG accessibility community

AmeliaBR: there are issues with respect to what counts as a rendered element

shepazu: I think it would be a useful exercise to see... which things get put into the accessibility tree is different to HTML

BogdanBrinza: I think this should not be defined in this chapter but in the accessibility mapping
... the focus is there but I expect it should be the same as HTML

AmeliaBR: there are issues such as putting a tabindex on a gradient element and that shouldn't have any effect
... so, as shepazu said, we should go through the HTML chapter and look for exceptions
... it should be basically HTML plus exceptions

shepazu: I suggest we have a dedicated telcon for this

BogdanBrinza: fair but I don't think it belongs in this chapter

heycam: in the interactivity chapter, what needs to be talked about is how the tabindex attribute is defined to work
... from my looking at it, it should work in the same way as the HTML definition
... shepazu's question about what should be focussable is a good question
... I'm not sure where that's defined
... but regarding just tabindex, it seems to me the HTML definition is sufficient

Rossen: is there anything that talks about the embedded case?
... is tabindex re-ordered?
... I have an <svg> with tabindex 5 and inside there, there is further tabindex

heycam: for inline <svg>?
... if so, I would expect it to use the same ordering as the rest of the document
... it's the same single document

shepazu: I'm not just talking about people who use AT, but also anyone who uses a keyboard
... I agree with heycam's suggestion that tabindex that follows the HTML definition
... I don't know about building components
... SVG has a lot of nesting
... you have a dashboard, if it has the focus, you may or may not want to drill down into it
... how does HTML handle that?

Rossen: you talking about app layer constraints which doesn't belong in the platform
... platform is about exposing enough constructs that you can realise those things in the app layer
... authors who are accessibility-responsible can annotate their content so that it navigable
... SVG data visualizations are heavily nested, you're asking how you can support focusability and navigability

shepazu: not just SVG but HTML too
... doing it with javascript doesn't seem acceptable

Rossen: that's how people do it

shepazu: not every data visualization should need to be scripted in order to be navigable

Rossen: it doesn't need to be scripted but it need to be annotated with ARIA roles etc.

shepazu: I think we're talking past each other and should take this offline
... aria assumes people are using AT and I'm concerned about people who aren't using AT
... but that's not going into SVG2 and not what we're discussing today
... we're talking about the specific case of tabindex
... and can we simply tear that section out and refer to HTML?
... I think we need to do a careful review of the section we're referring to and check it makes sense in the context of SVG
... and check if we need to add any exceptions to the text we're referring

heycam: we can do that during editing time this afternoon
... I've done a quick check but we can check again this afternoon

shepazu: just concerned that many of the accessibility experts (like Rich Schwerdtfeger) are not here

Rossen: I agree and we care about accessibility and are not taking it lightly

shepazu: we need to make sure Rich is looped-in

<AmeliaBR> Here's the thread I started with the SVG Accessibility Task Force regarding this section: https://lists.w3.org/Archives/Public/public-svg-a11y/2016Jan/0021.html

<scribe> ACTION: BogdanBrinza to do thorough check on focus and tabIndex in HTML and circle back with ARIA group on the results [recorded in http://www.w3.org/2016/02/04-svg-irc]

heycam: we haven't talked about appendices
... they were deferred while we were waiting for other changes
... since those changes are mostly done we can probably update them now
... that's on me