SVG Working Group Teleconference -- 26 Feb 2015

<trackbot> Date: 26 February 2015

<Tav> I'm going to be late... I will respond to Tab about text width and height via email. I don't think we should revert.

<scribe> scribeNick: ed

SVG 2 WD publication date

AmeliaBR: heycam, were there any particular updates you wanted to get in before the publication?

heycam: yes, splitting out some things into new specs... to ensure publication is synchronized
... I propose we aim for March 12 for the publication

AmeliaBR: sounds sensible
... anything else that we're waiting for?

heycam: nothing in particular, but we assigned many actions at the f2f

deprecating target=replace

<heycam> http://www.w3.org/mid/CAFDDJ7xYOq-pTdVWpyU86X1z6kRVog=zs+Rg-GHRD_kx46QHWQ@mail.gmail.com

AmeliaBR: this list of items came up because some things didn't make sense
... the last update of svg 1.1
... it introduced link targets
... have a special keyword "replace"
... it's svg specific
... no equivalent in html
... for when svg is embedded in <object>
... the distinction is no longer relevant
... most browsers treated it as the name for a new tab
... proposal: deprecate this and recommend authors to not use it
... and for browsers to still recognize it and treating it as "_self"

<shepazu> +1

AmeliaBR: think it's fairly straightforward

<heycam> ack

shepazu: don't think there are any complications we need to worry about, support AmeliaBR's proposal

heycam: I'm in favor of deprecating
... but i'm wondering if it's sufficiently unused so that we can remove it entirely
... if there's only one browsers supporting this case then authors can't rely on it anyway
... given the opportinity to remove it I'd like to take it

shepazu: so, "to hell with the people that use this keyword"?

heycam: pretty much, but don't think it's much used at all

shepazu: do you mean depreacte or remove in the spec?

heycam: I'd like to remove from spec directly

shepazu: by not saying anything it leads to confusion
... would prefer a section in the spec that lists all deprecated and obsoleted features
... would provide clarity for anyone wondering

<Tav> +1 for a section listing deprecated/obsoleted stuff

TS: agree

heycam: one difference to html5 obsoleted features are that those are usually in use
... this feature here otoh only has two search results on the web
... so might argue for taking a different approach

shepazu: I'm looking for less author perspective and more implementor perspective
... I looked at svg tiny 1.2, and I don't think we should be recommend it any more
... we should recind it, it confuses people
... a major complication is that 1.2T was standardised and ratified by JIS
... so we should explain why we did that
... don't want to put a note in the spec where it used to be, because that's a distraction
... better with a chapter/appendix with removed and deprecated things

nikos: doesn't the changes section cover this already?

shepazu: sure

AmeliaBR: I like the idea of having a formal place for removed features
... don't agree with shepazu about not having notes where things were removed
... on heycam's question on whether we should have any fallback for this keyword, would that be complex?
... we should try to not break content if possible

heycam: for a feature like this if we list it as deprecated/removed... should a new implementation bother implementing it?
... I don't think we should encourage implementation of things we want to drop

AmeliaBR: ok, so we can take it out and add a comment saying why it was taken out
... in my testing only IE recognized the keyword
... so probably not much content that would break

shepazu: ok, I agree that we shouldn't recommend implementing deprecated/obsolete features

RESOLUTION: make the '_replace' keyword for @target obsolete and add a note explaning why it was removed

Smailus: there may be companies using these features, content not searchable online

shepazu: we're not changing what's valid for svg 1.1, so nothing stops an implementor from doing an svg 1.1 engine... this is for svg2 in particular

<heycam> can you be an SVG 1.1 and SVG 2 conforming implementation simultaneously?

shepazu: we don't forbid people from doing SMIL, but it's not part of svg2

heycam: ok, probably not important to discuss this right now

<scribe> ACTION: Amelia to make the '_replace' keyword for @target obsolete and add a note explaning why it was removed [recorded in http://www.w3.org/2015/02/26-svg-minutes.html#action01]

<trackbot> Created ACTION-3760 - Make the '_replace' keyword for @target obsolete and add a note explaning why it was removed [on Amelia Bellamy-Royds - due 2015-03-05].

#svgView(transform(...))) behavior

<heycam> https://lists.w3.org/Archives/Public/www-svg/2014Dec/0015.html

AmeliaBR: somethign that came up in email discussion
... where we discussed adding transform attr to <svg>
... so conclusion was that the transform applies to the parent coordinate system
... complexity with the svgView spec syntax
... said transform applies the same way as <g> elements... so that raises questions for what was meant
... the testsuite is clear that the transform applies at the child level

ED: pretty sure that test was a draft (as in: not part of the offical testsuite, and not guaranteed to be correct)

AmeliaBR: ok... right now implementations are not consistent

<AmeliaBR> This is the draft test: http://www.w3.org/Graphics/SVG/Test/20110816/harness/htmlObject/linking-frag-01-f.html

ED: I recall that we agreed on how the trasnforms shopudl apply on <svg> but I've only added issues in the spec for now
... we never discussed the svgView syntax issue though

heycam: ok, I'd imagine that users when linking to some svg... they want to override something to look at a paricular part of the svg
... say want to look at some path
... easier to reason about what transform to apply if the transform is on the very outside of the stack

AmeliaBR: I'm leaning towards making it consistent with the transform on the <svg>, easier that way

ed: I'd agree with that

heycam: what happens when you have transforms on both, combine or replace?

AmeliaBR: the way the svgView syntax works is that they replace the attribute

<TabAtkins> Oh, that's weird.

AmeliaBR: so would prefer to be consistent with that

TabAtkins: don't think it's that weird, e.g for viewBox

<TabAtkins> Yeah, replacing viewBox seems fine, but replacing transform seems odd to me. Maybe not that odd.

ed: I'd agree with tab that it's a bit strange to not stack the transforms

heycam: it'd be odd if the transform was replaced since it might affect the origianl document quite a lot

AmeliaBR: not sure how often ppl would use transformations on the root element

ed: right now don't think there's any content since transforms on <svg> roots was not permitted in svg 1.1

AmeliaBR: right, so we wouldn't break content here

heycam: ok, changing my mind to go with the append the transformation

RESOLUTION: svgView(transform()) will apply on as an additional transform outermost transform on the transform stack

<scribe> ACTION: AmeliaBR to add text to say that svgView(transform()) will apply on as an additional transform outermost transform on the transform stack [recorded in http://www.w3.org/2015/02/26-svg-minutes.html#action02]

<trackbot> Created ACTION-3761 - Add text to say that svgview(transform()) will apply on as an additional transform on the root element, outermost to the transform stack [on Amelia Bellamy-Royds - due 2015-03-05].

should viewTarget match :target

<heycam> https://lists.w3.org/Archives/Public/www-svg/2015Feb/0042.html

AmeliaBR: changes were made in 1.1
... viewTarget names which specific element is the focus of a given <view>
... original SVG 1 say it should highlight these elements
... in the update it said authors should use the :target pseudoclass
... to describe how things should be highlighted
... but this doesn't work for the view element
... so I think the target pseudoclass shoudl apply ....

shepazu: the way I understand svgView...
... ppl are trying to use it for spritesheets
... it may or may not be desireable for the :target to be highlighter in that context

<AmeliaBR> s/should apply ..../to all the elements mentioned in the viewTarget attribute /

AmeliaBR: it would be up to the author to do that

shepazu: if you can style things with :target then...
... if you want some interacation based on :hover... is having that being the :target...
... invocting the target state in css, does that have negative implications?
... if using the :target pseudoclass you can still do things with :hover

AmeliaBR: to be clear: nothing would change for the author
... you can still add a hover state
... you can use :target to add styles to your svg when someone links to your svg
... to trigger styling
... but you cannot do things when you use a <view>

shepazu: think we should ask the css wg about this
... they may not think of an svg <view> also being a target (in addition to viewTarget)

ed: <view viewTarget="foo"> is just a level of indirection, not sure it's worth it IMHO

AmeliaBR: view only applies to embedded images or objects, not in documents

shepazu: want to confirm with css people if this is a good idea

heycam: two things might be good to bring up
... 1) the thing that gets targetted is NOT the thing with the id
... 2) multiple elements matching that pseudoclass, since currerntly only one match is there
... AmeliaBR, you asked if multiple matches are easy to support
... I looked in gecko, shoudln't be that hard to support

<heycam> ACTION: Cameron to email www-style about :target and view fragments [recorded in http://www.w3.org/2015/02/26-svg-minutes.html#action03]

<trackbot> Created ACTION-3762 - Email www-style about :target and view fragments [on Cameron McCormack - due 2015-03-05].

<heycam> AmeliaBR: I had two other issues relating to view fragments

<heycam> AmeliaBR: they are maybe less interesting to discuss, so I can just draft some spec text and discuss them then

<heycam> shepazu: there's only 5 minutes, so we can wait

<shepazu> http://www.w3.org/blog/news/archives/4442?pk_campaign=feed&pk_kwd=first-public-working-draft-svg-accessibility-api-mappings-1-0-svg-aam

<heycam> shepazu: I have some news; the FPWD of the SVG Accessibility mapping has been published

<shepazu> SVG Accessibility API Mappings 1.0 (SVG-AAM) was published today

<heycam> richardschwerdtfeger++ for driving that

trackbot, end telcon

- DRAFT -

SVG Working Group Teleconference

26 Feb 2015

Attendees

Contents

SVG 2 WD publication date

deprecating target=replace

#svgView(transform(...))) behavior

should viewTarget match :target

Summary of Action Items

Scribe.perl diagnostic output