SV_MEETING_TITLE -- 29 Feb 2012

<TabAtkins_> fantasai: The issues I didn't log were raised after the end of the LC period, iirc.

<tantek> greetings

<tantek> only on IRC this morning

<TabAtkins_> yo, tantek

<plinss> hola

<TabAtkins_> Sigh. If Zakim understands the question, why does me make you rephrase it?

<tantek> TabAtkins_ lazy bot programmer is lazy.

<TabAtkins_> But it's actually *more* work to do that!

<tantek> and failed to obey 2nd law

<jdaggett> ack

<TabAtkins_> lolwut?

<fantasai> TabAtkins: That doesn't mean you don't file them.

<fantasai> TabAtkins: You addressed them, didn't you? If you're going to ignore them because they're after the deadline, fine.

<fantasai> TabAtkins: But if not, they need to be filed and processed.

<smfr> a 386

<fantasai> TabAtkins: The only time we've ever rejected a comment due to being after the deadline is CSS2.1, fwiw.

<TabAtkins_> fantasai: My understanding was that the DoC was for LC issues.

<fantasai> TabAtkins: And that was because if we didn't, we'd never finish.

<TabAtkins_> Outside of the LC comment period, they're just regular comments, and are dealt with in the normal way.

<fantasai> TabAtkins: You're addressing them between LC and CR, they get filed.

<TabAtkins_> I can do that, sure. But don't complain about me not filing them when the instructions about what to file were apparently unclear. ^_^

<scribe> scribe: glenn

<glazou> ScribeNick: glenn

?WD of Flexbox: like to talk about MQ

<nimbu> florianr is florianr

alex: can we publish flexbox

sylvaing: gradients on agenda?

<tantek> TabAtkins, between end of LC period and when you publish the CR it's a bit of a gray area as to what's "required". I think it's up to editor judgment, in which case consider if addressing the comment will improve the spec, and in particular avoid a CR-LC-CR cycle.

glazou: only normative reference on agenda

<danielweck> (again)

glazou: yes if possible

<dstorey> one of those new people is me. Going to try to work out which

<TabAtkins_> tantek: "Addressing" and "filing in the DoC" are very different things. I do the former. I didn't realize I had to do the latter.

alex: discussed LC on flexbox

florianr: would like a WD

alex: will publish by tuesday

chrisl: WD or what?

<TabAtkins_> RESOLVED: Publich Flexbox as WD.

RESOLVE: publish flexbox as WD

<ChrisL> ACTION: ChrisL to publish flexbox wd [recorded in http://www.w3.org/2012/02/29-css-minutes.html#action01]

<trackbot> Created ACTION-453 - Publish flexbox wd [on Chris Lilley - due 2012-03-07].

<tantek> TabAtkins, agreed. If it's a cross-WG comment then I tend to be more liberal toward including in the DoC as it tends to improve inter-WG relations and reduce static/friction in future interactions.

<smfr> http://lists.w3.org/Archives/Public/www-style/2012Feb/1083.html

glazou: post msg from david with list of issues

<tantek> TabAtkins, do you have a URL/webpage example of the new flexbox syntax/functionality/algorithm that shows it "working" (even prefixed) in 2+ implementations? (just curious what state of spec vs implementation is.

dbaron: order as in email
... animation of images and gradients
... rules in spec about animation of gradients
... work in css4 images about that, should defer to that and remove from spec

<tantek> thanks smfr for the link

florianr: what is meant by defer?

<ChrisL> I agree with all the ones in the postpone category, having read through them

florianr: impls free to do what the want

<sylvaing> ChrisL, +1

listening

go ahead

<dbaron> Tab: people will depend on whatever the implementations do, no matter what the spec says

<tantek> dbaron's clustering of issues postpone/easy/medium/hard is a good approach for helping advance these specs quickly.

smfr: webkit has cross fade
... will do transitions using cross fade, agrees should be undefined how accomplished

dbaron: thinks that wk is impl newer spec
... should not have normative statement if will soon override

chrisl what is wrong with saying undefined?

worried if you say can't animate, or if you say can animate but not what happens

fantasai: should specify that whether and how it's animated is undefined
... then mention how it will be defined in future spec

chrisl: if spec says you should not try to animate this, will have no test

dbaron: css1/2 have said ignore props not defined in spec
... yet css3 is defining new props

glazou: has to drop/rejoin due to sip problem, peter pls chair in mean time

<dbaron> dbaron: I think that's fine

<glazou> (sorry, no change, very difficult to hear you all, sound is cut)

<glazou> Bert: probably

<smfr> i'm fine with florianr's wording

???: such and such is not expected to animate, but different ? will defines how this works

dbaron: are we talking just about images/gradients or everything not animatable?
... thinks we're talking about everything, concerned about putting in big loop hole

<florianr> This level of css does not expect XXX to animate. Different modules or later levels may define how to animate them.

chrisl: (1) animatable and known, (2) not animatable and known, (3) others not sure

???: is it clear on (2) vs (3)

scribe: rather be specific when possible

dbaron: ok if we have statement about limited set of props
... should i take an action to write that statement?
... most of the rest aren't properties

glazou: would like a decision

<smfr> i agree

chrisl: agrees with entire list of things to postpone
... to which sylviang agreed

<smfr> https://www.w3.org/Bugs/Public/show_bug.cgi?id=14609

dbaron: transitions about value types you can't interpolate
... things would animate that people aren't expecting to animate

Tab: can define special timing model for discrete things

chrisl: in SVG discrete changes interpolate

dbaron: are people not worried about this?
... will put constraints on what we can do

tab: if transitions immediately after non-zero, then should work

<smfr> transition: all 2s 2s;

tab: find with leaving or fixing, simple to fix

smfr: thinks not simple to fix

tab: shouldn't have transition all

florianr: suggests postponing

dbaron: should work within constraints just now, is ok with postponing

<smfr> i'm ok with postponing

RESOLUTION: postponing ??? items

<smfr> https://www.w3.org/Bugs/Public/show_bug.cgi?id=15844

<dbaron> s/???/the items listed as postpone in http://lists.w3.org/Archives/Public/www-style/2012Feb/1083.html/

tnx

tab: can't having impls doing different things...

dbaron: don't want webkit behavior

<dbaron> smfr: WebKit treats 'auto' as '0'

dbaron: how to match lists of different lengths
... in transition * properties
... background is the length that matters

<ChrisL> agree with the truncated/repeated proposal

dbaron: use beginning of list ignore the rest

<smfr> agreed

dbaron: proposes ???

<dbaron> RESOLVED: resolve bug 14604 as proposed

dbaron: next, reverse animation using opposite timing function, people ask for feature
... postpone adding such feature, but add example showing how it can be used now
... a little confusing, but not too hard

glazou: good compromise

<dbaron> RESOLVED: resolve bug 14611 as proposed

dbaron: spec mentions grid and zoom props

<smfr> agreed

dbaron: grid isn't any spec, zoom is; propose removing refs

<ChrisL> agreed

tab: agree

<dbaron> RESOLVED: resolve bug 14618 and 14626 as proposed

<smfr> agreed

dbaron: vertical align is animatable (according to spec), but what does animating keywords mean?

florianr: should we say "no keywords" or just enumerate the subset of what can animate?

<dbaron> RESOLVED: resolve bug 14988 as proposed

dbaron: last of easy items

<smfr> https://www.w3.org/Bugs/Public/show_bug.cgi?id=15838

<Bert> (Animating from 'top' to 'bottom' makes sense, but doesn't seem needed.)

dbaron: no transition when both transition delay and ??? are zero seconds

<ChrisL> agree on the zero transition

dbaron: nothing says it

tab: doesn't like because it is discontinuous behavior

dbaron: the default is delay/duration not transition property

tab: ok, need to make not a transition

smfr: does the spec say this?

<dbaron> smfr: implication of transition not occurring is that no events fire?

<fantasai> tab: oh, we default to transition-property: all; and transition-duration / ?? to zero

<Bert> ". By default the value is ‘0s’, meaning that the transition is immediate"

<dbaron> smfr: does the spec say that?

<TabAtkins_> Specifically, the current "no transitions" default is implemention with a property of "all" and a delay/duration of "0".

<Bert> " (i.e. there will be no animation)."

fantasai: why do we have default of zero?

<fantasai> s/zero/all\/zero/

bert: specs no animation in that case

tab: events are important part

<smfr> i approve

<TabAtkins_> smfr: [explained the original reasoning between the current defaults vs defaulting to a property of 'none' and some default duration]

<dbaron> RESOLVED: resolve bug 15838 as proposed

<Bert> smfr: [there are usability reasons for defaults of 'all' and '0s']

glazou: moving to Z-axis intersection issue for transforms
... is dirk here?

<smfr> http://lists.w3.org/Archives/Public/www-style/2012Feb/1202.html

Z-Axis intersection for transforms

florianr: opera does not have impl of 3d transforms
... in favor of saying do intersection in spec
... not in favor of saying should

dbaron: talked to Robert O'Callahan, and he agreed the correct behavior (plane splitting) is obvious but we don't do it correctly now, but we should

tab: would like to do correctly, impl is tricky

<smfr> RESOLVED: transform spec should make intersection behavior a MUST

jdaggett: possible problem with mirroring specs
... multiview?

<fantasai> scribenick: fantasai

<glenn> ... proposal to mirror to csswg, thinks it is bad idea

jdaggett: proposal was to host specs on csswg.org

jdaggett: means all ..., and all editor's drafts have to point to csswg.org
... I don't see that using Apache is necessary. We can use <meta> to do redirection.
... Not ideal, but better than having csswg.org be a point of failure

<glenn> jdaggett: not necessary to use .htaccess facilities

<tantek> I agree, I'd rather delay the source control transition if it means we can avoid one or more temporary places for specs.

<scribe> Scribenick: glenn

plinss: timing to be finalized today
... infrastructure in place
... wishes better docs, but working on them today
... no addl burden on editors

jdaggett: questions using URLs to refer to csswg.org host

<tantek> I have not had time to retry the hg instructions again to see where I get stuck next btw.

plinss: suggests reverse proxy on dev.w3.org

bert: pretty sure its possible

<dbaron> (Why do a reverse proxy on a w3c server if we could just do a checkout on a w3c server?)

plinss: this is just a stop gap, i.e., using csswg.org

<tantek> exactly, what dbaron said

jdaggett: doesn't see need for interim step

<tantek> can we delay transition and avoid stopgaps?

<tantek> what's the rush?

plinss: if we use reverse proxy, nobody will know

<tantek> I agree with the concerns that jdaggett has raised.

plinss: will start with proxy on dev.w3.org to csswg.org

jdaggett: doesn't like having csswg.org as a point of failure

plinss: only for a few weeks/months

jdaggett: doesn't see this step as necessary

<dbaron> If there's a chance we can make this happen in a matter of days, I think we should try to get that to happen.

<dbaron> I think it's preferable to have the editors drafts have w3.org URLs

plinss: what's the big deal?

jdaggett: sounds like extra work for nothing
... had breakage previously

<fantasai> plinss: They'll be served from dev.w3.org URLs

glazou: pls take to email or irc after call

<fantasai> plinss: so why do you care

css3 images

fantasai: DoC but won't get through them today

<dbaron> http://dev.w3.org/csswg/css3-images/issues-lc-2012 is the thing to discuss?

fantasai: all should review DoC and discuss issues during next telecon

<dbaron> er, to review?

<TabAtkins_> http://dev.w3.org/csswg/css3-images/issues-lc-2012

fantasai: suggests talking now about taking V&U to LC

glazou: reds need review

fantasai: all are pretty tricky

tab: need other people looking at them

glazou: action on all to review DoC and comment

<sylvaing> title of css3-images DoC is 'CSS Backgrounds and Borders Level 3'

glazou: what else to say now about this doc?

tab: just discuss DoC

florianr: like to go back to MQ
... current TS is not latest version

fantasai: already has action item to do this

florianr: will write results for opera

<fantasai> https://lists.w3.org/Archives/Member/w3c-css-wg/2012JanMar/0309.html

florianr: also some editorial changes, should republish
... question about when

<florianr> http://my.opera.com/desktopteam/blog/2012/02/28/precision-engine

fantasai: suggests passing (opera) build first
... go to LC then hopefully PR

<fantasai> fantasai: or are they only editorial?

<fantasai> florianr: Borderline

<fantasai> florianr: Not changing what they say, just what people understand them to say

florianr: a request on ML for example

fantasai: no opinion

<BobBie> hi

florianr: suggest not adding this specific example because it refers to feature not referenced
... request for example using rem unit

glazou: think is not needed

dbaron: but may help clarify spec text, units never based on results of declarations
... unambiguous that rem behaves same way

<dbaron> Add to "Relative units in media queries are based on the initial value."

dbaron: add to sentence "relative units ..."

florianr: sounds good, will edit and republish

<glazou> RESOLUTION: Add to "Relative units in media queries are based on the initial value."

dbaron: previous version link in draft points to previous previous version

chrisl: if all editorial, don
... don't need another LC
... or is proposal to go to PR?

dbaron: possible in one week
... depends on impl reports

florianr: can have IRs tomorrow

fantasai: agreed

dbaron: mozilla passes all the tests in the repo

florianr: should we list previous editors as current editors or previous?
... currently listed as previous

<jdaggett> previous editors seems fine

glazou: no opinion

tab: list as previous

stevez: long tradition

<dbaron> though sometimes the "previous editors" is editors for a previous level of the spec, which is sort of different...

<Bert> RESOLVED: move editors of MQ who are no longer active to "Former editor"

<dbaron> fantasai: Everybody ok with removing the comma between attribute name and type in the attr() function?

fantasai: is everbody ok with removing comma between ? and ?

glazou: not fair to ask this now at end of call

<Bert> (I don't like it without the comma, but can live with it.)

<dbaron> peterl: We discussed it at f2f, and howcome was only dissenter.

<dbaron> peterl: And howcome just said he's ok with it.

<fantasai, pls type resolution>

<dbaron> RESOLVED: publish last call of css3-values

glazou: adjourned

<fantasai> RESOLVED: drop comma between attribute name and type in attr()

<TabAtkins_> RESOLVED: publish V&U as LCWD.

trackbot, end meeting

<fantasai> Bert, is CSS Speech CR in the pipeline yet?

- DRAFT -

SV_MEETING_TITLE

29 Feb 2012

Attendees

Contents

Z-Axis intersection for transforms

css3 images

Summary of Action Items

Scribe.perl diagnostic output