- From: Cameron McCormack <cam@mcc.id.au>
- Date: Fri, 27 Feb 2015 08:33:54 +1100
- To: www-svg@w3.org
Minutes from the call are here:
http://www.w3.org/2015/02/26-svg-minutes.html
and below as text for bot consumption.
[1]W3C
[1] http://www.w3.org/
- DRAFT -
SVG Working Group Teleconference
26 Feb 2015
[2]Agenda
[2] https://lists.w3.org/Archives/Public/www-svg/2015Feb/0049.html
See also: [3]IRC log
[3] http://www.w3.org/2015/02/26-svg-irc
Attendees
Present
Thomas_Smailus, [IPcaller], heycam, ed, AmeliaBR,
stakagi, Doug_Schepers, nikos, Doug, Rich_Schwerdtfeger
Regrets
Chris, Brian
Chair
Cameron
Scribe
ed
Contents
* [4]Topics
1. [5]SVG 2 WD publication date
2. [6]deprecating target=replace
3. [7]#svgView(transform(...))) behavior
4. [8]should viewTarget match :target
* [9]Summary of Action Items
__________________________________________________________
<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>
[10]http://www.w3.org/mid/CAFDDJ7xYOq-pTdVWpyU86X1z6kRVog=zs+Rg
-GHRD_kx46QHWQ@mail.gmail.com
[10] 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
[11]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>
[12]https://lists.w3.org/Archives/Public/www-svg/2014Dec/0015.h
tml
[12] 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:
[13]http://www.w3.org/Graphics/SVG/Test/20110816/harness/htmlOb
ject/linking-frag-01-f.html
[13] 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
[14]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>
[15]https://lists.w3.org/Archives/Public/www-svg/2015Feb/0042.h
tml
[15] 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
[16]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>
[17]http://www.w3.org/blog/news/archives/4442?pk_campaign=feed&
pk_kwd=first-public-working-draft-svg-accessibility-api-mapping
s-1-0-svg-aam
[17] 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
Summary of Action Items
[NEW] ACTION: Amelia to make the '_replace' keyword for @target
obsolete and add a note explaning why it was removed [recorded
in [18]http://www.w3.org/2015/02/26-svg-minutes.html#action01]
[NEW] 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
[19]http://www.w3.org/2015/02/26-svg-minutes.html#action02]
[NEW] ACTION: Cameron to email www-style about :target and view
fragments [recorded in
[20]http://www.w3.org/2015/02/26-svg-minutes.html#action03]
[End of minutes]
__________________________________________________________
--
Cameron McCormack ≝ http://mcc.id.au/
Received on Thursday, 26 February 2015 21:34:22 UTC