W3C home > Mailing lists > Public > www-svg@w3.org > February 2015

minutes, 26 February 2015 SVG WG telcon

From: Cameron McCormack <cam@mcc.id.au>
Date: Fri, 27 Feb 2015 08:33:54 +1100
To: www-svg@w3.org
Message-ID: <20150226213354.GF1557@wok.mcc.id.au>
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

This archive was generated by hypermail 2.3.1 : Wednesday, 8 March 2017 09:47:39 UTC