See also: IRC log
<trackbot> Date: 31 May 2012
<heycam> scribenick: krit
ed: when do we publish first draft
ed: a lot of edits are not in the
... get the tings into the spec that you assigned for
heycam: more actual spec edits
ed: I did some edits
... like text-overflow
... I went through my actions and am working on some edits, but they are not yet ready to be committed
... any updates to discuss?
cyril: can we have a link to the chapter where the edits were made?
ed: on the wiki?
cyril: yes, a link on the wiki to
the change on the spec
... it could help
Tav: it could move
cyril: e.g z-index, where is it?
Tav: I don't remeber :)
cyril: found i
Tav: might be good to have a link
krit: Question, what styling on element definition?
heycam: have not tried the lrecently one
Tav: as a proposal, a table seems
to be ok
... problems with table might be semantcis, but that is ok and can be fixed later
... SVG 1.1 has certain IDs that are used
... but there seems no trouble to switch to heycam proposal without it
heycam: yes i think that is ok
Tav: me too
heycam: you are aksing because of edits that you are doing?
krit: yes, I would like to have a style at the beginning
heycam: can be changed later easily
heycam: I finished most of marker
... I am not happy about the 2nd part of the marker spec, but it can be discussed on the list
cyril: I reviewed marker and have a list of changes, send it tomorrow to the list
Tav: everyone is interessted on it, so it might be better
cyril: I mean public list or wg list
<cyril> we should use www-svg for technical discussion
heycam: we should use www-svg
general agreement to www-svg
ed: next topic
cyril: I made tests with Alan in
... he just used desktop client, we the equipment
... it worked
... the adobe equipment could work as well
... we have to confirm that the meeting are done as discussed
cyril: I think the time slots of cameron are fine
Tav: will we be able to call
... maybe i can go to seattle with the help of inkscape
... (small chance)
cyril: I thought it would be helpful for people from europe
Tav: yeah, but am not in paris at that time
ed: I would come
cyril: who else would come to
... so far we have 3?
... Is it worth to have a meeting in paris for just three? rooms are empty anyway
... we have polycom equ. so we have everything for video conference
... fine if we are just 3?
krit: did all people already assigned so far?
cyril: 9 so far
... doug is not
krit: I'll take car of hotel opertunities for seattle
heycam: time is good. We can publish WD a couple of days later
resolve: We go with the proposed time slots, meeting split to Seattle and Paris
resolution: We go with the proposed time slots, meeting split to Seattle and Paris
krit: I just was not happy about
the red color on elements
... continue with smaller and bold text for attributes and elements
heycam: I am fine if there are
solutions that make it better
... list of quted attribute or element list might look scarry
krit: do you have an example?
heycam: try to get an example?
<heycam> https://svgwg.org/svg2-draft/shapes.html#RectElement -- click the "show" next to "presentation attributes"
krit: looks ok for me
... quotes are inside of links on attributes and elements, but outside for properties
heycam: I try to change it and look how it looks liek
Tav: heycam: but it is good as it is
<heycam> https://svgwg.org/svg2-draft/pservers.html#MeshGradients has an example of this note
krit: current style looks great, will we have the same style on WD?
heycam: yes, with exception of
... for WD, do we want to publish it without background colors?
krit: I think so, yes
ed: that is fine for me
... yellow background should be reviewable text
krit: but do we want to have backgrounds on WD at all?
heycam: might be ok to have
different styles for publishing WD
... we don't want to have annotations either
krit: property and attributes have different blueish colors
heycam: yes, planned
krit: what for presentation attributes, should they be the attribute blue, or property blue?
heycam: they should have the attribute blue
krit: at the moement spec is not talking about presentation attr, but about the property, does this change for current attributes that move to presentation attributes as well?
heycam: they might later, yes
ed: next topic
heycam: In CSS3 it will be a text
... it is not in gecko, but in opera and webkit
... is it ok to remove it yet?
... the current writing mode spec has some possibility to use the SVG orientation property
... so should this spec still have that? is it necessary?
Tav: we might be the wrong people to ask
heycam: since CSS has it, do we need it in SVG? Do we want to continue with CSS?
krit: does CSS has angles for text orientation?
heycam: might be limited
... but angle on SVG must be a multiple of 90deg
krit: upside down text is not possible for CSS
... not sure about vertical text implementations
Tav: inkscape has it
krit: webkit as well
ed: opera has some support for it
heycam: Iam aslo happy to keep it in the spec
nikos: Is it already deprecated?
heycam: I think so
... maybe not
... if people are confortale enough we can remove it.
... or first deprecating?
Tav: I don't know
nikos: we need feedback from japan first
ed: doe we have an action for someone?
<scribe> ACTION: heycam will look into how removing GlyphOrientationHorizontalProperty would influence the web [recorded in http://www.w3.org/2012/05/31-svg-minutes.html#action01]
<trackbot> Created ACTION-3299 - Will look into how removing GlyphOrientationHorizontalProperty would influence the web [on Cameron McCormack - due 2012-06-07].
heycam: only webkit implements
... it gives posibility to override kerning of font
... and turn off automatical kerning
... font-kerning can turn on and off automatic kenring\
... you could get all functionality of kerning with turn off kerning with font-kerining and letter-spacing
... do we want to remove duplicated behavior?
ed: I think so
krit: the quetion is if authors can still rely on specs, if we remove parts that are specified later.
heycam: if implementations haven't picked up things, we are in a lucky position that we still can change behavior
ed: on the other hand kerning is more doing letter-spacing, so it is not doing what it suposed to
heycam: I was able to find 5examples where kerning was used
krit: is it already deprecated?
heycam: it is not
krit: At least we can agree to deprecate it
heycam: as longer it remains on
the spec, as more likely it will be used
... my preference is to remove it
krit: I don't have a strong feeling
ed: any objections to remove it?
resolution: remove kerning from
... remove kerning property from SVG spec
Tav: we should note that it got removed and how to get the same behavior?
heycam: good idea
<scribe> ACTION: heycam remove kerning and mention to use font-kerning and letter-spacing instead [recorded in http://www.w3.org/2012/05/31-svg-minutes.html#action02]
<trackbot> Created ACTION-3300 - Remove kerning and mention to use font-kerning and letter-spacing instead [on Cameron McCormack - due 2012-06-07].
krit: does spec disallow it?
... question is from implementations point of view
krit: would be more interessting to have marker and stroke as one piece
<ed> so this is talking about <marker opacity="0.5">...</marker>, right?
heycam: I know what you mean, could be interessting
<heycam> ed, yes
Tav: we could use the new keywords
krit: that wouldn't solve the problem that you see that they are not one piece
nikos: that is something the nec compositing spec can help with, let me find a link
krit: the spec does allow opacity on markers, so you are asking for disallowing it explicitly?
<nikos> if they're in a knock-out group it would solve the problem of the stroke and the marker looking like different objects
<nikos> section 8.3 I think you were referring to Cam
heycam: not really. Just wanted to discuss it, was not aware that it is allowed at that point
nikos: was added by rik, and he propably want to work more on it
heycam: looks like we can get the behavior that dirk wants
krit: well, we were asked about it on webkit
(talks about marker and stroke being one unit)
ed: sounds reasonable
<heycam> ISSUE: consider allowing stroke and markers to be rendered as one unit wrt opacity
<trackbot> Created ISSUE-2443 - Consider allowing stroke and markers to be rendered as one unit wrt opacity ; please complete additional details at http://www.w3.org/Graphics/SVG/WG/track/issues/2443/edit .
<g opacity="0.5"><line marker="url()"></g>
<heycam> ISSUE-2443: Maybe the Compositing spec will allow this.
<trackbot> ISSUE-2443 Consider allowing stroke and markers to be rendered as one unit wrt opacity notes added
ed: next topic?
krit: is it about overflow-x/-y
... in CSS it means scrollbars if if affects a bigger region
... in SVG means the same as visible
... auto means in CSS never paint outside the bix, while in SVG always outside the box
... proposal: change behavior to CSS described behavior
... the current behavior of gecko
ed: might cause more clipping and perf lost on SVG
heycam: auto is not the default value
ed: true, hm not sure
krit: I would agree heycam because of consitence with cSS spec
ed: I am not sure if the CSS definition even applies to SVG since there's no scrolling in svg
heycam: For me it is more about
... in HTML content it will clip to the content
... no scrollbars
... so it is more like hidden invisible
... overflow: scroll means the same a overflow: hidden in SVG
ed: I think heycam arguments are good
<ed> I'd agree that auto is more similar to scroll, which in svg is the same as hidden
heycam: anyone against changing defintion of overflow: auto
resolution: Accept the proposal of heycam to go the CSS way for overflow: auto
<scribe> ACTION: heycam will change behavior to CSS way for overflow: auto [recorded in http://www.w3.org/2012/05/31-svg-minutes.html#action03]
<trackbot> Created ACTION-3301 - Will change behavior to CSS way for overflow: auto [on Cameron McCormack - due 2012-06-07].
heycam: should both apply the
same way like for HTML
... don't see any reason why we shouldn't do that
krit: think it can be a benefit for authors
ed: it is not more confusing than
having CSS Transforms on box ....
... what is the usecase in SVG?
krit: different clipping behvairo
heycam: how is it done on webkit?
krit: not fully sure
heycam: anyway, implementations are different now
krit: any conclusion?
ed: we should at least define
what it should do
... would like to see more usecases, but it might make sense
<scribe> ACTION: heycam will work on usecases for overflow-x/-y [recorded in http://www.w3.org/2012/05/31-svg-minutes.html#action04]
<trackbot> Created ACTION-3302 - Will work on usecases for overflow-x/-y [on Cameron McCormack - due 2012-06-07].
RRSAgent: make minutes
This is scribe.perl Revision: 1.136 of Date: 2011/05/12 12:01:43 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/I get throw my actions but did not commit yet/I went through my actions and am working on some edits, but they are not yet ready to be committed/ Succeeded: s/heycam/ cyril/ Succeeded: s/heycam/cyril/ Succeeded: s/??/nikos/ Succeeded: s/applies to SVG/applies to SVG since there's no scrolling in svg/ Found ScribeNick: krit Inferring Scribes: krit WARNING: No "Present: ... " found! Possibly Present: Doug_Schepers ISSUE ISSUE-2443 P20 P21 P25 Tav aaaa cyril ed glenn heycam https krit nikos resolve scribenick thorton trackbot You can indicate people for the Present list like this: <dbooth> Present: dbooth jonathan mary <dbooth> Present+ amy Agenda: http://lists.w3.org/Archives/Public/public-svg-wg/2012AprJun/0067.html WARNING: No meeting chair found! You should specify the meeting chair like this: <dbooth> Chair: dbooth Found Date: 31 May 2012 Guessing minutes URL: http://www.w3.org/2012/05/31-svg-minutes.html People with action items: behavior change heycam kerning mention remove will WARNING: Input appears to use implicit continuation lines. You may need the "-implicitContinuations" option.[End of scribe.perl diagnostic output]