SV_MEETING_TITLE -- 20 Oct 2010

<smfr> ha ha

<jdaggett> greetings

<glazou> hi jdaggett

<glazou> got your email just had no time to answer yet

<glazou> hi dsinger_

<jdaggett> enjoying your strikes?

<glazou> jdaggett: only 1/4th of tank in my car...

<jdaggett> heh

<jdaggett> yup

<glazou> np dsinger_

<glazou> probably my first cold this year...

<TabAtkins_> ScribeNick: TabAtkins_

glazou: First agenda item is CSS 2.1.
... I see we ahve multiple implementation reports
... Peter is aggregating the results, but some are from RC1 and RC2.

plinss: Most tests didn't change between, so I have a script that's grandfathering RC1 results that are still valid.

glazou: Any idea of the number of tests passed by two impls?

plinss: No idea until I finish combining all of the IRs.

Craps, one sec.

<glazou> waiting for you TabAtkins_

<sylvaing> ScribeNick: sylvaing

<fantasai> ScribeNick: fantasai

arronei: I updated maybe 100 cases or so

<sylvaing> arronei: a large set of updates came in; about 100 cases

arronei: Now we have a lot of feedback from IR coming in

dbaron: I reported 494 tests as invalid

arronei: Not all of those are actually invalid. I have feedback on why they're not invalid
... But I'll send that feedback in as a group in a bit

dbaron: 496

glazou: So let's wait for Peter's results and arronei's updates

arronei: I'm concerned about other updates, from boris and gerard and fantasai. No idea how those are tracking

dbaron: Do we have a mechanism for tracking which errors are in whose tests?

arronei: that's kinda tricky

<TabAtkins_> fantasai: We do have a list that maps filenames to their location in the source tree.

<oyvind> http://wiki.csswg.org/test/css2.1/issues has some sort of grouping

http://test.csswg.org/source/filename-list

<TabAtkins_> fantasai: That should show who is responsible for the tests.

<TabAtkins_> fantasai: If it's in "approved", it's us as the WG's responsibility to maintain the tests. If it's in a contributor's directory, we can find out who's responsible.

dbaron: The other thing is, when arron has responses, I'm probably going to have responses to his responses. So it's better to send them out sooner

arronei: Well, there's a lot of duplicates. So I'm trying to group those together as much as possible.
... That's part of the reason I want to publish on Friday. Even if I'm not done with everything, at least I get all the edits in asap
... I think it's better to get releases out faster, even if not all edits are in. We'll have smaller updates instead of larger ones.

<TabAtkins_> fantasai: If I don't have to actually fix tests before I publish (because I don't know how long it'll take to finish mine), publishing takes a couple of hours, so it's deifnitely something we can do on Friday.

<TabAtkins_> fantasai: If we do the publish with the understanding that some errors will still be standing in the test suite.

arronei: How about we talk on Friday and see where we are, then either publish Friday or next Tuesday

CSS2.1 edits

<jdaggett> unmute me

<glazou> http://www.w3.org/mid/1692182533.109045.1287455881677.JavaMail.root@cm-mail03.mozilla.org

jdaggett: There are a number of places where the spec has changed significantly, e.g. the table of bolder/lighter mappings
... And that information is not public.
... I wanted to know if we can take whatever edits we have so far and make a publication of that?

Bert: We'll have a last call in 2 weeks, after TPAC. Why can't we wait a little bit more?
... All the edits we have so far will be done by TPAC, so just after TPAC. If we decide on more edits at TPAC, then it will take longer

<ChrisL> there is a lot of time in 'after'. 'soon after' is better

jdaggett: It's hard to have discussions about things that are not in the public spec

dbaron: I had to tell gtalbot that a test in the test suite was invalid because of edits that I could not describe because they were not anywhere public

jdaggett: Why don't we say whatever edits we have in before TPAC, we try to put those out a few days after TPAC ends, and any extra edits will be dealt with later.

Bert: It's possible. It takes a bit of time to publish.
... There's one other thing I don't like about that is that if we publish, it will be a normal WD, not even an LCWD.
... It's a bad signal to give to people wrt stability of the spec.

jdaggett: But if we very quickly follow that with an LCWD, how is that different?

glazou: Bert has a point. If we go back to normal WD, since we always said that we are almost ready to move along the REC track, it's a very bad signal.

dbaron: Can we have the editor's draft public? Which would solve this problem?

sylvaing: Yes, all the CSS3 drafts are publicly accessible, so that makes sense.

Bert: well, all the errata are public. Everything that has been edited is public.

TabAtkins_: It's much much harder to diff the public CSS2.1 with the errata than it is to look at the edited draft.

<ChrisL> CSS WG is supposed to work in public. CSS2.1 not being in public is a problem; at least its a short-lived problem.

dbaron: The errata don't always have the exact text.

glazou: Seems like everyone wants to have an updated public draft.

<ChrisL> concur

glazou: Is there consensus to make the editor's draft public?
... Ok, let's do the edits into an editor's draft and make it public asap

RESOLUTION: Publish CSS2.1 editor's draft publicly ASAP

CSS2.1 Issues

<TabAtkins_> http://lists.w3.org/Archives/Public/www-style/2010Oct/0428.html

TabAtkins_: After reading the extra feedback on the thread, I believe my text is still correct, I just needed to change the reference from "parent" to "containing block"

glazou: I suppose we need some time to review and approve

<scribe> ACTION: everyone to review 101 for next week [recorded in http://www.w3.org/2010/10/20-CSS-minutes.html#action01]

<trackbot> Sorry, couldn't find user - everyone

http://wiki.csswg.org/spec/css2.1#issue-101

Issue 154

arronei: Haven't worked on it, because focused on test suite
... Should be ready for next week

glazou: Let's do that. Let's try to have all issues resolved before TPAC

Issue 159

<TabAtkins_> http://wiki.csswg.org/spec/css2.1#issue-159

http://wiki.csswg.org/spec/css2.1#issue-159

arronei: MS has reviewed most of this, but haven't gotten all feedback from our margin collapsing dev yet

dbaron: Haven't gotten to this since last week; pretty busy w/ implementation report

glazou: Ok, deferred to next week. But please make sure you have reviewed the proposal for next conf call

Issue 199

Tab sends an email

TabAtkins_: There was one particular question on the previous wording, so this is an update on the previous proposal

glazou: so let's give a week to review this proposal

<glazou> http://www.w3.org/mid/20101016195038.GA17927@pickering.dbaron.org

glazou: Last question is, should overflow apply to inline table elements?

dbaron: Yeah, there was a test in the test suite, it semed odd to apply to inline-table but not table

Bert: Looks like an editing error

RESOLUTION: overflow applies to inline-table just like tables

TPAC

glazou: Request from Janina to have a joint meeting to talk about accessibility

ChrisL: We also discussed having an FX taskforce meeting.
... Turns out some people are arriving on Wed afternoon. So better to have it on Thursday

sounds ok

glazou will be away

dbaron: Can we do it in the part of Thursday that doesn't overlap the AC meeting?

ChrisL: Of course.

<ChrisL> so thursday, not overlapping ac meeting.

glazou: Let me give you a short report in France right now.
... Big big strikes
... I strongly recommend taking the train straight from CDG, not trying to go to the city
... Taxis may run out of fuel
... my own car is running out of fuel
... Some riots in Lyon, hopefully over by then
... This morning I checked all the arrivals from the US and India, no problem at all
... The trains were running normally, at least from Paris to Lyon

<smfr> bring a donkey and cart

glazou: I'm going to send reports to csswg mailing list when I have more information as we get closer to TPAC

fantasai: Do we have a joint meeting scheduled with i18n?

glazou: yes

http://wiki.csswg.org/planning/tpac-2010

glazou: We should start prioritizing our work for CSS3

sylvaing: Are we moving css3-background to CR?

fantasai: yes, working on LC DoC this week

sylvaing: MS would like to discuss layout topics

dbaron: Conditional on how much time I have to look at stuff before TPAC, might want to discuss CSS3 Values

sylvaing: dbaron, we also had some discussions about what happens to the test suite and the spec after CSS2.1 goes to REC

glazou: Anything else?
... If you have any extra agenda items, either send to csswg mailing list or add to wiki or both

@font-face

<glazou> http://lists.w3.org/Archives/Public/www-style/2010Oct/0161.html

Beth: So, I think unfortunately we have not come up with any syntax that makes sense, but after thinking it over, if we think it's a real problem
... which I think we do, given the bug reports that have come in,

Bether: We think there should be a way for authors to say what they would want to happen

<ChrisL> having a descriptor puts all the capability with the author. a property would allow author control and user preference override

Beth: A user preference also makes sense. Some users will hate the flash of unstyled content, and others will hate not seeing text
... I don't have any concrete suggestions

glazou: Just to summarize, it's a fallback mechanism to say what happens if the font has not downloaded yet

jdaggett: WebKit shows no content until the font loads
... Mozilla renders with the fallback font until the font loads
... Our current thinking is to put a timeout
... Initially you don't show anything, but after a certain time, you fall back to the fallback font

<howcome> Opera has a user-setable timeout

jdaggett: The question is what's the right timeout
... And in some cases this may cause a worse situation
... you get two flashes
... It's a tradeoff between readability and usability and not having these flashes

glazou: howcome says they have a user-setable timeout

jdaggett: My thought was to put it in a user-controllable setting

<howcome> Indeed, it's a tradeoff. Complex equation with many variables.

Beth: We would prefer an author control

ChrisL: The problem is that the suggestion was a descriptor, which isn't author-overrideable
... There were two parts suggestion: you could say whether you wanted a blank or a fallback, and you could also set a timeout

jdaggett: You could get fallback immediately by setting a zero timeout.
... The one thing about a property is that it doesn't make sense as something in the cascade.

fantasai: Cascading it makes sense. Per-element doesn't make sense

TabAtkins: could set it on the root

sylvain: I think it's weird to have that as a property

<ChrisL> or you have a fast network, but are in Australia

fantasai: The appropriate timeout will depend on the network
... You'd want immediate fallback if you're on dialup

sylvaing: It seems we don't have the implementation experience to design a property right now
... Do we need a property? Why not a UA setting?
... I don't think we've proved that we need a property instead of a UA setting.

jdaggett: You could make a rule that you have a timeout, but it's influenced whether there's any network activity happening at all
... if there's no reply to your font download request, no packets, then you fallback immediately

<howcome> I support Sylvain (on this :)

jdaggett: you can't do that with a timeout propert

<ChrisL> @timeout(torrents-on, 5s)

glazou: Do you want a normative note?

jdaggett: I think it makes sense to discuss this in the spec, but I'm not sure that it should be an author-controlled property

Beth: I think we would still like an author-controlled property, but I recognize it's an odd thing
... We think that a user-controlled property isn't going to solve the problem for most users
...
... I can see the author wanting to note that this font is critical to the page, but this other one is a nice-to-have

<dsinger_> Maybe a 'temporary substitute' font indication from the source?

Smfr: Could also control this via JavaScript

<bradk> bradk had joined #css

Smfr: Add an even tfor font download

jdaggett: might be a good idea independent of this issue

<dsinger_> S/even tfor/event for/

ChrisL: drawing with canvas is tricky, since you currently don't know when the font is there

glazou: You also need an event to know the font is not loaded, could not be loaded

or UA is waiting

smfr: we have the same problem for images

glazou: I think the two approaches are really interesting.
... Probably not something we're going to solve now
... Beth and ?, can you come up with something more concrete for tpac?

yes

writing-mode

glazou: Lots of messages from hyatt

fantasai: I just need to work those comments into the spec as I draft it; nothing to discuss here today.

<jdaggett> http://www.asahi-net.or.jp/~eb2m-mrt/epub/rec2WG.html

jdaggett has concerns about the fact that logical properties are in the draft

and that people think it will be approved by the CSSWG

<glazou> aaah :)

jdaggett: We shouldn't be representing these as anything that is stable or approved by the CSSWG

<howcome> I share John's concerns on this.

jdaggett: People are going off and implementing this with the idea that this is going to work into the later stage

fantasai: So what do you want me to do?

<howcome> I suggest removing that part of the spec for now, or add the other credible proposals as well and ask for feedback

jdaggett: These have a lot of side effects on all properties, and there is not enough detail in the spec about these interactions

fantasai: I AM NOT DONE DRAFTING THIS YET.
... obviously there are not enough details!

<jdaggett> jdaggett: we should not be talking about this spec as something that is ready to go to candidate recommendation

who is talking about this spec as something that is ready for CR?

<jdaggett> jdaggett: the notes from the EPUB discussion

multicol

glazou: Discussion that if the columns are taller than the viewport, it is very awkward to read

<kojiishi> notes from EPUB was updated since then

glazou: The first proposal is to have a note saying that giving a higher height than the viewport to a multicol element provides accessibility/usability issues
... The second one is to add another control to have more control over the height of the multicol element

<ChrisL> it would be nice to fix that for tables too

sylvaing: We have the same issue with tables

glazou: I would suggest a note, I will send to the mailing list, to make it clear

Bert: overflow on any element causes problems

glazou: Tables and multicol are the ones where you have to scroll back and forth a lot
... Setting overflow is a decision from the author

<scribe> ACTION: glazou to Propose note for multicol explaining the problem with column lengths longer than the viewport [recorded in http://www.w3.org/2010/10/20-CSS-minutes.html#action02]

<trackbot> Created ACTION-269 - Propose note for multicol explaining the problem with column lengths longer than the viewport [on Daniel Glazman - due 2010-10-27].

Tab will prepare his proposal and flexbox topics for discussion at TPAC

Meeting closed.

RRSAgent: make minutes

- DRAFT -

SV_MEETING_TITLE

20 Oct 2010

Attendees

Contents