22:29:25 <RRSAgent> RRSAgent has joined #svg
22:29:25 <RRSAgent> logging to http://www.w3.org/2016/02/04-svg-irc
22:29:27 <trackbot> RRSAgent, make logs public
22:29:29 <trackbot> Zakim, this will be GA_SVGWG
22:29:29 <Zakim> I do not see a conference matching that name scheduled within the next hour, trackbot
22:29:30 <trackbot> Meeting: SVG Working Group Teleconference
22:29:30 <trackbot> Date: 04 February 2016
22:30:03 <nikos> Agenda: https://www.w3.org/Graphics/SVG/WG/wiki/F2F/Sydney_2016/Agenda
22:30:33 <nikos> Chair: Nikos
22:31:03 <stakagi> stakagi has joined #svg
22:35:41 <AmeliaBR> AmeliaBR has joined #svg
22:37:58 <nikos> Morning AmeliaBR. Just about to start - will get shane to setup hangouts again in a sec
22:38:41 <heycam> https://svgwg.org/svg2-draft/styling.html#PresentationAttributes
22:41:46 <shane> AmeliaBR: https://staging.talkgadget.google.com/hangouts/_/google.com/svgwg
22:45:09 <birtles> scribenick: birtles
22:45:12 <birtles> scribe: birtles
22:45:15 <birtles> topic:  Resolving on presentation attribute strategy
22:46:01 <birtles> heycam: some f2f ago, I took an action to present options about what to do about presentation attributes
22:46:10 <birtles> ... I'd like to discuss if we need to change our approach
22:46:18 <birtles> ... I added a big table to the styling chapter
22:46:18 <heycam> https://svgwg.org/svg2-draft/styling.html#PresentationAttributes
22:46:34 <birtles> ... about which properties have presentation attributes and on which elements they're supported
22:46:47 <birtles> ... it's basically the set of SVG 1.1 properties plus about 3 new ones
22:46:53 <birtles> ... paint-order, vertical-align, whitespace
22:46:57 <birtles> ... they're the new ones I think
22:47:03 <birtles> ... plus the other ones we've promoted to properties
22:47:09 <birtles> ... it's a pretty ad-hoc set of properties
22:47:21 <shepazu> shepazu has joined #svg
22:47:26 <birtles> ... I'm worried that it's not a great approach for authors since I don't want them to have to think about which properties have presentation attributes
22:47:42 <birtles> ... but I don't want to require that every property that implementations support have a corresponding presentation attributes
22:47:53 <birtles> ... since many of those properties won't have any effect
22:48:07 <birtles> ... so I wonder if we can say that all properties that have some sort of effect in SVG have presentation attributes
22:48:10 <birtles> ... is that a good idea?
22:48:16 <birtles> ... and if it is, how would we state that
22:48:27 <birtles> shane: what do you mean about "have some sort of effect"?
22:48:37 <birtles> heycam: yeah, that makes it difficult to define the set
22:48:46 <birtles> ... an example might be something like text properties
22:49:00 <birtles> ... that are orthogonal to anything we define in SVG but still have an effect
22:49:17 <birtles> ... so people don't have to think that font-style is a presentation attributes but font-variants-ligatures is not...
22:49:30 <birtles> ... we don't need to say anything about font-variants... in SVG, it should just work
22:49:42 <birtles> Tav: I think that idea is actually pretty good
22:49:53 <birtles> ... from our perspective, anything that is a property is automatically a presentation attributes
22:50:15 <birtles> ... we support anything that changes the rendering as a presentation attribute
22:50:57 <birtles> AmeliaBR: the main concern I have is making if forwards-compatible
22:51:16 <birtles> ... we could use the fact that CSS properties are supposed to include a line in their blue box in the spec re: what sort of elements they apply to
22:51:32 <birtles> ... we could say that anything that could apply to an SVG element could be specified as a presentation attribute
22:51:55 <birtles> ... however if we want to make it totally open-ended, we could just say any valid CSS property can be specified as a presentation attribute
22:52:02 <birtles> ... then if it doesn't have an effect it doesn't have an effect
22:52:09 <birtles> ... but the complication there is name conflicts
22:52:26 <birtles> ... we could never add an SVG attribute that might overlap with any existing or future CSS property
22:52:44 <birtles> shane: is the situation with presentation attributes, the value of the pres attribute is fed through the CSS cascade
22:53:45 <birtles> ... could we just add an automatic pathway for every attribute SVG defined and feed it into the cascade
22:54:04 <birtles> (some confusion)
22:56:07 <birtles> correction: every attribute that is *not* defined by SVG as an attribute would be fed into the cascade
22:57:19 <shepazu> q+
22:57:51 <nikos> ack shepazu
22:57:51 <Zakim> shepazu, you wanted to ask about xlink:href and to
22:57:56 <birtles> shepazu: I think this is pragmatic, but there is the complication that it pollutes the infoset
22:58:24 <birtles> ... we'd have to find some way of framing this so that we're not defining them but they're part of the schema
22:58:42 <birtles> heycam: we have some prose that covers whether the document is valid or not
22:59:07 <birtles> AmeliaBR: regarding whether only properties that have an effect are allowed or all properties are allowed
22:59:14 <birtles> ... that could be an implementation detail
22:59:38 <birtles> ... what about inheritance and foreignObject
22:59:55 <birtles> ... if you set some sort of CSS layout property on an SVG element as a presentation attribute
23:00:11 <birtles> ... then you have a descendent foreignObject the cascade has to work in a predictable way
23:00:27 <birtles> Rossen: it sounds like you want to create very tight coupling between two layers of the system that don't need to be tightly coupled
23:00:35 <birtles> ... I understand you might want to expose some properties as presentation attributes
23:00:47 <birtles> ... projecting all of CSS into SVG will create a very difficult maintenance problem
23:00:52 <shepazu> q+
23:00:53 <birtles> ... for variations of...
23:01:08 <birtles> ... discoverability and detectability will be a problem in the case where you have, e.g. @supports
23:01:16 <birtles> ... you don't have that discoverability on the SVG layer
23:01:37 <birtles> ... saying that we will future-proof SVG by saying that all properties from now on, if applicable, will affect SVG
23:01:58 <birtles> ... in CSS and HTML, to constrast with, CSS goes to quite an extent to say that in some cases there are elements that this should not apply to
23:02:09 <birtles> ... but in general it applies to all elements
23:02:21 <birtles> ... and this works for HTML because it doesn't have these attributes
23:02:30 <birtles> ... so we have a fairly clean separation of the two module
23:02:34 <birtles> ... here the line is not so clear
23:02:40 <birtles> ... the bijection of these two sets is not clean
23:02:56 <birtles> ... you have properties in CSS that don't apply to SVG, and attribute in SVG that don't apply to CSS
23:03:40 <birtles> heycam: underlying what you were saying, is "presentation attributes aren't a great tool, and you can't @supports etc."
23:03:53 <birtles> ... if people agree on that then we should be encouraging people to always use style attributes and style stylesheets
23:03:58 <birtles> Rossen: precisely
23:04:11 <birtles> ... if you are going to take a dependency on CSS then take a dependency on CSS
23:04:34 <birtles> ... in that case I would argue we are going to reduce the set of attributes as much as possible
23:04:54 <birtles> ... anything magical is a path to disaster
23:05:00 <shane> q+
23:05:02 <birtles> shepazu: I find Rossen's argument persuasive
23:05:17 <birtles> ... I don't agree with the part about reducing the number of attributes
23:05:43 <birtles> ... I can see some things that are presentational that we can deprecate but I think there are content authors that are depending on them
23:05:49 <birtles> ... looking at this from a different lens
23:06:16 <birtles> ... if there are people who are used to using attributes, is this a best practice
23:06:17 <birtles> q+
23:06:32 <nikos> ack shepazu
23:06:46 <birtles> ... I think it makes things a bit simpler if don't add presentation attributes
23:06:52 <nikos> ack shane
23:07:11 <birtles> shane: I think Rossen is right that we should be doubling down on using CSS for SVG
23:07:41 <birtles> ... I think a strong reason why this is the right thing to do is simply because that's the direction that the rest of the Web is going
23:07:48 <birtles> ... not because it's more technically right etc.
23:08:04 <birtles> Rossen: we have quite a bit of history here that we can look back on
23:08:17 <shepazu> q+
23:08:56 <birtles> ... we have had native extension points in C++ and it wasn't until .NET became popular that we had to work out how to make them work better together
23:09:17 <birtles> ... we didn't try to bind the type systems together
23:09:28 <birtles> ... if this is a module where we want to take a dependency, then we should take the dependency
23:10:24 <heycam> birtles: one question is are you then suggesting that authors type <rect style="width: 100px; height: 100px">
23:10:28 <heycam> ... I think the cat's out of the bag
23:10:33 <heycam> ... we have attributes already for things like width
23:10:37 <heycam> ... we decided to make them into properties
23:10:50 <heycam> ... and now it sounds like people should only use properties. I'm just speaking from the perspective of an SVG author
23:10:54 <shane> q+
23:11:01 <heycam> ... if you're telling me now I need to put everything in a style="" attribute, that's not fun
23:11:06 <nikos> ack birtles
23:11:08 <heycam> Rossen: we did that with HTML, it worked out well
23:11:15 <shane> q-
23:11:39 <heycam> birtles: ok. I think it's a bit different -- or at least a very big paradigm shift for authors. geometry is kind of peripheral to HTML, whereas it's fundamental to SVG.
23:11:56 <heycam> Rossen: maybe. one thing to consider. there's been a lot of chatter about "how we can bring SVG more natively into HTML, using geometry, elements, etc."
23:12:03 <heycam> ... as soon you step into HTML, you don't have attributes
23:12:06 <shepazu> q+
23:12:10 <heycam> ... if you want to integrate closer to HTML/CSS, let's do it
23:12:21 <heycam> ... if you want to keep away, then we have to keep away and continue down the path of attributes
23:12:36 <heycam> shane: it's also not true that geometry is not fundamental to CSS
23:12:43 <heycam> Tav: but it's styling
23:12:52 <heycam> shane: people say that, but you need it to get something onto the screen
23:12:58 <heycam> ... I think we have to get over presentation/content separation
23:13:09 <heycam> birtles: maybe we don't need to go into the philosophy of HTML and SVG too much
23:13:18 <heycam> ... I'm just saying there will be some difficulty in selling this to authors I think
23:13:26 <shepazu> q+
23:13:30 <heycam> ... just from an author's point of view, it looks like a backwards step in terms of ergonomics
23:13:45 <heycam> shepazu: I don't think we need to make the decision now, abotu whether we're going to deprecate all of the attributes
23:13:47 <heycam> Rossen: i'm not asking for that
23:14:19 <heycam> shepazu: I think a clear, middle ground is to keep the presentation attributes we've already had. and just make it so that future things that are stylistic are expressed as properties and not as presentation attributes.
23:14:37 <heycam> ... so adding features to the language, we do not "backport" them into presentation attributes, and we see how the language evolves
23:14:43 <heycam> Rossen: that reasonates with me really well
23:14:54 <nikos> ack shane
23:14:57 <nikos> ack shepazu
23:14:59 <AmeliaBR> q+
23:15:01 <heycam> ... one way to ease into this would be to think very hard and long before we add any new presentation attributes, or attributes that can't be expressed by CSS
23:15:21 <heycam> ... and in the cases where there's divergence between the two models, so you have SVG attributes that have absolutely no meaning in CSS, then keep it as an attribute
23:15:24 <heycam> shepazu: href for example
23:15:40 <heycam> ... second, I want to respond to something that Cameron said
23:15:50 <heycam> ... I don't think it's the most common practice these days to make things as attributes
23:16:02 <heycam> ... I think with scripting libraries they increasingly rely on CSS, so I don't think this will be confusing to them
23:16:20 <heycam> ... especially in the case where we can start to express almost everything in SVG as a property, i think the trend will be properties and then they'll not need to distinguish between them
23:16:35 <heycam> ... so the trend, over the next 10/15 years in SVG, is that we do shift everything to CSS, but at that point it will be natural to authors
23:16:48 <birtles> scribenick: birtles
23:17:00 <birtles> AmeliaBR: I agree we shouldn't deprecate the presentation attributes in the near future
23:17:19 <birtles> ... regarding the original issue when it comes to formatting text and fonts we have limited subset
23:17:43 <birtles> ... from SVG 1.1 because they were in CSS 2.1, and there are properties for which we don't have presentation attributes and that's confusing for authors
23:18:02 <birtles> ... can we clarify in that chapter: "here's the list of properties that can be used a presentation attributes"
23:18:16 <birtles> ... and within that context of styling text to say that using CSS is preferable
23:18:32 <birtles> ... and to say that there are other properties that can't be used as presentation attributes
23:18:46 <birtles> heycam: I think that would make sense since there tend to be a lot of text properties that get added
23:19:08 <birtles> ... there is a set of presentation attributes in the style chapter already
23:19:58 <birtles> ... so that table of presentation attributes which has the existing presentation attributes plus the 3 new ones
23:20:12 <birtles> ... should we talk about those 3 new ones
23:20:19 <birtles> ... should we rip them out?
23:20:21 <birtles> Rossen: yes
23:20:33 <birtles> heycam: ok I'll see if I can unship them
23:20:41 <birtles> Rossen: I'll help you out with authoring this chapter
23:21:56 <birtles> RESOLUTION: Keep the SVG 1.1 presentation attributes, add authoring guidelines to the spec (styling chapter) to say to use properties where possible
23:25:52 <birtles> topic: Status update
23:26:01 <nikos> https://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Chapter_Assessment
23:26:34 <birtles> nikos: 6 chapters still marked as "in progress"
23:26:53 <birtles> ... first is document structure
23:27:04 <birtles> ed: no update, I haven't had time to update it
23:27:17 <birtles> ... it's fairly ready to go, just minor changes
23:27:23 <birtles> ... readiness 4
23:27:29 <birtles> (no issues to discuss, just editorial)
23:27:49 <birtles> Rossen: next is styling
23:28:06 <birtles> heycam: I haven't updated the wiki, but now that we've discussed the presentation attribute, it's readiness 5
23:28:09 <birtles> ... just a few more tweaks
23:28:18 <birtles> nikos: next is coordinate system, lots of changes here
23:28:47 <birtles> ... changes might not be finished by the end of the weekend but we know what we need to do
23:28:52 <birtles> ... should be done by the end of next week
23:29:13 <birtles> Tav: for text, probably needs about a month to make the changes
23:29:16 <birtles> Rossen: we can help
23:29:27 <birtles> AmeliaBR: there are some issues with underspecified behavior of textPath
23:29:39 <birtles> ... I will try to coordinate as closely as possible
23:29:51 <birtles> heycam: the main thing that Tav was waiting was the text-layout algorithm
23:30:02 <birtles> ... I wrote up most of that in a wiki page which hopefully Tav can translate into spec text
23:30:21 <birtles> ... I will fill out the rest of that algorithm today or tomorrow so you should have all the information to turn it into spec text
23:30:34 <birtles> nikos: can that work be split up?
23:30:40 <birtles> Tav: not really
23:30:49 <birtles> heycam: that algorithm bit is pretty independent from the rest of the chapter
23:30:57 <birtles> ... so once my notes are ready someone else could do that
23:31:16 <birtles> AmeliaBR: the only problem is trying to avoid having separate parallel definitions
23:31:54 <birtles> Rossen: is that the main blocker for that chapter
23:32:31 <birtles> ... since that chapter seems to be making the least progress, perhaps because it's the most difficult or because it was blocked by the stuff heycam talked about
23:32:44 <birtles> Tav: I was also blocked by some of the issues we discussed at the FXTF two days ago
23:32:52 <birtles> ... but now I know I can rip some of the sections out
23:32:59 <birtles> Rossen: I was just wondering how we can help
23:33:07 <birtles> Tav: it's possible someone else could do the algorithm
23:33:25 <birtles> ... the rest I probably need to do and it takes time since I need to check stuff against the SVG 1.1 spec
23:34:35 <birtles> AmeliaBR: I'll take a look at textPath
23:34:55 <birtles> (Rossen and Tav will discuss the exclusions section)
23:35:19 <birtles> heycam: the paint chapter is readiness 5 as of this morning
23:35:24 <birtles> (applause)
23:35:38 <birtles> Tav: I need to address the fallback for the arcs linejoin, however
23:35:52 <birtles> ... I need to find out what the preferred fallback is
23:36:11 <birtles> AmeliaBR: re the paint chapter, what's the plan of integrating this with the proposal of fantasai
23:36:27 <birtles> ... where specifying the shorthand which will, in future, we subdivided into longhands
23:36:41 <birtles> heycam: we can ignore that for now
23:37:10 <birtles> BogdanBrinza: interactivity chapter: there a lot of changes we can do now
23:37:37 <birtles> shepazu: whatever we do with focus, we should make sure we run it by the SVG accessibility community
23:37:47 <birtles> AmeliaBR: there are issues with respect to what counts as a rendered element
23:38:40 <birtles> shepazu: I think it would be a useful exercise to see... which things get put into the accessibility tree is different to HTML
23:39:12 <birtles> BogdanBrinza: I think this should not be defined in this chapter but in the accessibility mapping
23:39:27 <birtles> ... the focus is there but I expect it should be the same as HTML
23:40:08 <birtles> AmeliaBR: there are issues such as putting a tabindex on a gradient element and that shouldn't have any effect
23:40:33 <birtles> ... so, as shepazu said, we should go through the HTML chapter and look for exceptions
23:40:38 <birtles> ... it should be basically HTML plus exceptions
23:40:50 <birtles> shepazu: I suggest we have a dedicated telcon for this
23:41:00 <birtles> BogdanBrinza: fair but I don't think it belongs in this chapter
23:44:43 <birtles> (discussion about when we should discuss this, clarification about what needs to be clarified, and general discussion about accessibility)
23:45:32 <birtles> heycam: in the interactivity chapter, what needs to be talked about is how the tabindex attribute is defined to work
23:45:46 <birtles> ... from my looking at it, it should work in the same way as the HTML definition
23:45:59 <birtles> ... shepazu's question about what should be focussable is a good question
23:46:04 <birtles> ... I'm not sure where that's defined
23:46:20 <birtles> ... but regarding just tabindex, it seems to me the HTML definition is sufficient
23:46:30 <birtles> Rossen: is there anything that talks about the embedded case?
23:46:41 <birtles> ... is tabindex re-ordered?
23:47:12 <birtles> ... I have an <svg> with tabindex 5 and inside there, there is further tabindex
23:47:17 <birtles> heycam: for inline <svg>?
23:47:35 <birtles> ... if so, I would expect it to use the same ordering as the rest of the document
23:47:40 <birtles> ... it's the same single document
23:48:19 <AmeliaBR> q+
23:48:35 <birtles> shepazu: I'm not just talking about people who use AT, but also anyone who uses a keyboard
23:49:03 <birtles> ... I agree with heycam's suggestion that tabindex that follows the HTML definition
23:49:14 <birtles> ... I don't know about building components
23:49:18 <birtles> ... SVG has a lot of nesting
23:49:38 <birtles> ... you have a dashboard, if it has the focus, you may or may not want to drill down into it
23:49:43 <birtles> ... how does HTML handle that?
23:50:03 <birtles> Rossen: you talking about app layer constraints which doesn't belong in the platform
23:50:21 <birtles> ... platform is about exposing enough constructs that you can realise those things in the app layer
23:51:15 <birtles> ... authors who are accessibility-responsible can annotate their content so that it navigable
23:52:00 <birtles> ... SVG data visualizations are heavily nested, you're asking how you can support focusability and navigability
23:52:10 <birtles> shepazu: not just SVG but HTML too
23:52:35 <birtles> ... doing it with javascript doesn't seem acceptable
23:52:40 <birtles> Rossen: that's how people do it
23:52:54 <birtles> shepazu: not every data visualization should need to be scripted in order to be navigable
23:53:10 <birtles> Rossen: it doesn't need to be scripted but it need to be annotated with ARIA roles etc.
23:53:26 <birtles> shepazu: I think we're talking past each other and should take this offline
23:53:48 <birtles> ... aria assumes people are using AT and I'm concerned about people who aren't using AT
23:54:12 <birtles> AmeliaBR: this an interesting topic, I agree with shepazu that it would be good to have a declarative way to do better keyboard navigation
23:54:30 <birtles> ... but that's not going into SVG2 and not what we're discussing today
23:54:39 <birtles> ... we're talking about the specific case of tabindex
23:54:53 <birtles> ... and can we simply tear that section out and refer to HTML?
23:55:15 <birtles> ... 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
23:55:29 <birtles> ... and check if we need to add any exceptions to the text we're referring
23:55:38 <birtles> heycam: we can do that during editing time this afternoon
23:55:45 <birtles> ... I've done a quick check but we can check again this afternoon
23:56:19 <birtles> shepazu: just concerned that many of the accessibility experts are not here
23:56:33 <birtles> Rossen: I agree and we care about accessibility and are not taking it lightly
23:56:45 <shepazu> s/ accessibility experts/ accessibility experts (like Rich Schwerdtfeger)/
23:57:20 <birtles> heycam: Rich was the one who added the original tabindex wording to the spec which was basically just a copy-paste from the HTML spec
23:57:29 <birtles> shepazu: we need to make sure Rich is looped-in
23:58:16 <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
23:58:52 <birtles> ACTION: BogdanBrinza to do thorough check on focus and tabIndex in HTML and circle back with ARIA group on the results
23:58:53 <trackbot> Created ACTION-3835 - Do thorough check on focus and tabindex in html and circle back with aria group on the results [on Bogdan Brinza - due 2016-02-11].
23:59:25 <birtles> heycam: we haven't talked about appendices
23:59:34 <birtles> ... they were deferred while we were waiting for other changes
23:59:44 <birtles> ... since those changes are mostly done we can probably update them now
23:59:49 <birtles> ... that's on me