See also: IRC log
<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
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
<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].
<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].
<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
<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
This is scribe.perl Revision: 1.140 of Date: 2014-11-06 18:16:30 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/for browsers to still recognize it/for browsers to still recognize it and treating it as "_self"/ Succeeded: s/outermost transform on/on the root element, outermost to/ FAILED: s/should apply ..../to all the elements mentioned in the viewTarget attribute / Succeeded: s/<view/ed: <view/ Found ScribeNick: ed Inferring Scribes: ed Default Present: Thomas_Smailus, [IPcaller], heycam, ed, AmeliaBR, stakagi, Doug_Schepers, nikos, Doug, Rich_Schwerdtfeger Present: Thomas_Smailus [IPcaller] heycam ed AmeliaBR stakagi Doug_Schepers nikos Doug Rich_Schwerdtfeger Regrets: Chris Brian Agenda: https://lists.w3.org/Archives/Public/www-svg/2015Feb/0049.html Found Date: 26 Feb 2015 Guessing minutes URL: http://www.w3.org/2015/02/26-svg-minutes.html People with action items: amelia ameliabr cameron[End of scribe.perl diagnostic output]