- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Wed, 20 Oct 2010 17:27:49 -0700
- To: "www-style@w3.org" <www-style@w3.org>
Summary:
- Discussed status of implementation reports and their aggregation
- Discussed status of test suite publications and fixes
- Discussed status of CSS2.1 edits
- RESOLVED: Publish editor's draft of CSS2.1 publicly ASAP
- Reviewed open CSS2.1 issues
- RESOLVED: Fix CSS2.1 error: overflow applies to inline-table just like tables.
- Discussed TPAC agenda
- Discussed @font-face loading flash-of-unstyled content issue.
Apple wants some kind of author control. Others suggest additional
UA smartness and/or user controls for fallback timeout.
- Discussed writing-modes draft
- Discussed multicol usability issue when columns taller than viewport;
glazou to draft note explaining this issue to add to spec
ACTION EVERYONE: Review proposals for open CSS2.1 issues:
http://wiki.csswg.org/spec/css2.1#issue-101
http://wiki.csswg.org/spec/css2.1#issue-159
http://wiki.csswg.org/spec/css2.1#issue-199
====== Full minutes ======
Present:
Tab Atkins
David Baron
Bert Bos
John Daggett
Beth Dakin
Arron Eicholz
Elika Etemad
Simon Fraser
Sylvain Galineau
Daniel Glazman
Koji Ishii
Chris Lilley
Peter Linss
David Singer
<RRSAgent> logging to http://www.w3.org/2010/10/20-CSS-irc
Scribe: fantasai
CSS2.1 Implementation Reports
-----------------------------
glazou: First agenda item is CSS 2.1.
glazou: I see we have multiple implementation reports
glazou: 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.
CSS2.1 Test Suite
-----------------
arronei: I updated maybe 100 cases or so
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
arronei: 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
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
<fantasai> http://test.csswg.org/source/filename-list
fantasai: That should show who is responsible for the tests.
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.
arronei: 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
arronei: 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.
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.
fantasai: If we do the publish with the understanding that some errors
will still be standing in the test suite, it's no problem.
arronei: How about we talk on Friday and see where we are, then either
publish Friday or next Tuesday
CSS2.1 Edits
------------
<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
jdaggett: And that information is not public.
jdaggett: 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?
Bert: 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.
Bert: 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.
Bert: 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 to move back.
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?
glazou: Ok, let's do the edits into an editor's draft and make it
public asap
RESOLVED: Publish CSS2.1 editor's draft publicly ASAP
CSS2.1 Issues
-------------
Issue 101
<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
ACTION everyone: review 101 for next week
http://wiki.csswg.org/spec/css2.1#issue-101
Issue 154
arronei: Haven't worked on it, because focused on test suite
arronei: 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
+<howcome>
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
RESOLVED: 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.
ChrisL: Turns out some people are arriving on Wed afternoon. So
better to have it on Thursday
Sounds ok to everyone, though glazou will have left already.
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.
glazou: Big big strikes
glazou: I strongly recommend taking the train straight from CDG,
not trying to go to the city
glazou: Taxis may run out of fuel
glazou: my own car is running out of fuel
glazou: Some riots in Lyon, hopefully over by then
glazou: This morning I checked all the arrivals from the US and
India, no problem at all
glazou: 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?
glazou: If you have any extra agenda items, either send to csswg
mailing list or add to wiki or both
@font-face and loading
----------------------
<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
Beth: 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
<ChrisL> q+
Beth: A user preference also makes sense. Some users will hate the
flash of unstyled content, and others will hate not seeing text
Beth: 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
jdaggett: Mozilla renders with the fallback font until the font loads
jdaggett: Our current thinking is to put a timeout
jdaggett: 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
jdaggett: And in some cases this may cause a worse situation
jdaggett: you get two flashes
jdaggett: 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 user-overrideable
ChrisL: 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.
jdaggett: 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
Tab: could set it on the root
sylvain: I think it's weird to have that as a property
fantasai: The appropriate timeout will depend on the network
fantasai: You'd want immediate fallback if you're on dialup
fantasai: but delayed rendering if you're on broadband
<ChrisL> or you have a fast network, but are in Australia
sylvaing: It seems we don't have the implementation experience to
design a property right now
sylvaing: Do we need a property? Why not a UA setting?
sylvaing: 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
jdaggett: if there's no reply to your font download request, no packets,
then you fallback immediately
jdaggett: you can't do that with a timeout property
<howcome> I support Sylvain (on this :)
<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
Beth: We think that a user-controlled property isn't going to solve
the problem for most users
...
Beth: 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
Smfr: Add an event for font download
jdaggett: might be a good idea independent of this issue
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.
glazou: Probably not something we're going to solve now
glazou: Beth and jdagget, can you come up with something more concrete
for tpac?
ACTION Beth and jdaggett: more concrete suggestions to solve font download
flashes problem
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
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: It's an editor's draft, and clearly marked as such. The logical
properties section is even specially marked to be extra-clear
that it's not WG-approved.
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.
fantasai: of course there are not enough details!
jdaggett: we should not be talking about this spec as something that is
ready to go to candidate recommendation
<fantasai> who is talking about this spec as something that is ready for CR?
<jdaggett> the notes from the EPUB discussion
fantasai: EPUB understands this and the notes are wrong
<kojiishi> notes from EPUB was updated since then
CSS3 Multicol
-------------
glazou: Discussion that if the columns are taller than the viewport,
it is very awkward to read
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
glazou: 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
glazou: Setting overflow is a decision from the author
ACTION glazou: Propose note for multicol explaining the problem with
column lengths longer than the viewport
<trackbot> Created ACTION-269
Tab will prepare his proposal and flexbox topics for discussion at TPAC
Meeting closed.
<RRSAgent> http://www.w3.org/2010/10/20-CSS-minutes.html
Received on Thursday, 21 October 2010 00:28:24 UTC