W3C home > Mailing lists > Public > www-style@w3.org > October 2010

[CSSWG] Minutes and Resolutions 2010-10-20

From: fantasai <fantasai.lists@inkedblade.net>
Date: Wed, 20 Oct 2010 17:27:49 -0700
Message-ID: <4CBF8905.2050409@inkedblade.net>
To: "www-style@w3.org" <www-style@w3.org>

   - 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:

====== Full minutes ======

   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
   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

   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
   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
   RESOLVED: overflow applies to inline-table just like tables


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

   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

   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
   <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


   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: 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

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:38:40 UTC