See also: IRC log
<smfr> ha ha
<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...
<glazou> np dsinger_
<glazou> probably my first cold this year...
<TabAtkins_> ScribeNick: TabAtkins_
glazou: First agenda item is CSS
... 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
... But I'll send that feedback in as a group in a bit
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
<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
... 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
<jdaggett> unmute me
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.
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
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
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
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
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: 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
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
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: 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
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
... 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
... 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
... 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?
<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?
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 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
... 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
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
... 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
RRSAgent: make minutes
This is scribe.perl Revision: 1.135 of Date: 2009/03/02 03:52:20 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/are in which tests/are in whose tests/ Succeeded: s/?/TabAtkins/ Succeeded: s/has/had/ Found ScribeNick: TabAtkins_ Found ScribeNick: sylvaing WARNING: No scribe lines found matching ScribeNick pattern: <sylvaing> ... Found ScribeNick: fantasai Inferring Scribes: TabAtkins_, sylvaing, fantasai Scribes: TabAtkins_, sylvaing, fantasai ScribeNicks: TabAtkins_, sylvaing, fantasai Default Present: dsinger, jdaggett, glazou, +1.253.307.aaaa, smfr, +1.650.253.aabb, plinss, TabAtkins_, arronei, kojiishi, Bert, fantasai, sylvaing, David_Baron, dethbakin, ChrisL, +1.650.766.aacc Present: dsinger jdaggett glazou +1.253.307.aaaa smfr +1.650.253.aabb plinss TabAtkins_ arronei kojiishi Bert fantasai sylvaing David_Baron dethbakin ChrisL +1.650.766.aacc WARNING: No meeting title found! You should specify the meeting title like this: <dbooth> Meeting: Weekly Baking Club Meeting WARNING: No meeting chair found! You should specify the meeting chair like this: <dbooth> Chair: dbooth Got date from IRC log name: 20 Oct 2010 Guessing minutes URL: http://www.w3.org/2010/10/20-CSS-minutes.html People with action items: everyone glazou WARNING: Input appears to use implicit continuation lines. You may need the "-implicitContinuations" option.[End of scribe.perl diagnostic output]