W3C home > Mailing lists > Public > www-style@w3.org > June 2009

[CSSWG] Minutes and Resolutions 2009-05-20

From: fantasai <fantasai.lists@inkedblade.net>
Date: Mon, 08 Jun 2009 04:40:36 -0700
Message-ID: <4A2CF8B4.7080109@inkedblade.net>
To: www-style@w3.org
Summary:

   - Discussed jdaggett's bolder/lighter simplification
       http://lists.w3.org/Archives/Public/www-style/2009May/0145.html
       http://people.mozilla.org/~jdaggett/weightdistinctions.png
     jdaggett will post suggested edits for 2.1

   - Discussed ownership and format of Media Queries test suite

   - RESOLVED: Proposal accepted for CSS2.1 Issue 89
       http://wiki.csswg.org/spec/css2.1#issue-89

====== Full minutes below ======

Attendees:
   David Baron
   Bert Bos
   John Daggett
   Arron Eicholz
   fantasai Etemad
   Sylvain Galineau
   Daniel Glazman
   Peter Linss
   Alex Mogilevsky
   David Singer
   Anne van Kesteren
   Steve Zilles

<RRSAgent> logging to http://www.w3.org/2009/05/20-CSS-irc
Meeting: CSS Working Group Teleconference
Chair: Peter Linss
Scribe: David Baron

Agenda
------

   Peter: Anything to add?
   [silence]

Issue 111: bolder/lighter
-------------------------

   <jdaggett_sleepy> http://lists.w3.org/Archives/Public/www-style/2009May/0145.html
   jdaggett: I posted http://lists.w3.org/Archives/Public/www-style/2009May/0145.html
             as a proposal for how to get around the problems we've
             discussed for a long time with bolder/lighter.
   jdaggett: Avoids having to carry around a lot of information when
             bolder inherits, etc.
   jdaggett: Instead, have a table that says, given an inherited weight
             and bolder/lighter, what the resulting computed weight is.
   jdaggett: Essentially it mimics a font family with four weights,
             which lets you capture some of the cases where there's a
             heavier or lighter weight than normal/bold.
   jdaggett: Would skip weights if there are a lot of weights in the family.
   dbaron: I like it.
   Bert: I'm not comfortable with it.
   Bert: But it's attractive because it's so simple.
   Bert: But the spec has said for a long time that it should look at
         the available fonts.  Can we change that now?
   jdaggett: An alternative would be to ignore the text contained within
             the element and figure the weights using the first available
             font family, so you'd always inherit a specific weight and
             not need to inherit the 'bolder'.
   jdaggett: It would also mean that the computed weight is a valid
             numerical weight.
   Bert: I'd say let's put it in for a few months before PR and see what
         other people think of it.
   Bert: Another thing I just saw: Thomas Phinney wasn't happy with the
         9 weights and wants more in-between.
   jdaggett: That's an orthogonal problem.  He's also concerned about
             limitations of GDI that have caused font vendors to put
             data in the font that ... .  So I think some of what he's
             talking about are problems font vendors have had with GDI,
             which is something that a user agent can do things to get
             around, and I don't think it affects this issue so much.
   Bert: I don't want to change the number of weights allowed.
   jdaggett: I'm not sure he was saying we needed more weights, rather that
             we need a defined way of dealing with these things out there.
   Sylvain: Is there an implementation of your proposal?
   jdaggett: I could probably do that.
   jdaggett: So the takeaway is to leave it (?) in the spec for now, and
             experiment over the next few months?
   jdaggett: table proposal is already in css3-fonts editor's draft
   Peter: I'm not hearing any objection to that.
   fantasai: What does this mean for 2.1?
   jdaggett: If people seem comfortable with this, I would want to change
             2.1 to correspond.
   Steve: Pushing to 2.1 would probably force people who use multiple-weight
          fonts to use the numbers, and font guys (?) think people aren't
          going to use those.
   Steve: But the complexity of doing something that does the right thing
          (taking the current font into account) that I weakly support
           what you're proposing.  But it means fonts with a lot of weights
           won't really work well.
   <sylvaing> alexmog says "as long as it's not normative" :)
   fantasai: If you have all of the weights, the difference between weights
             can be very subtle.  So with this proposal 'bolder' will actually
             cause a noticeable difference in boldness, whereas the current
             spec doesn't.
   jdaggett: Agreed.
   fantasai: What if you combined the table with checking first available font?
   jdaggett: There's already a way of mapping when the fonts don't have weights.
   Steve: I think what John is proposing is a better computed value.
   ?: How much is 'bolder' used?
   various: not that much?
   jdaggett: On Windows, you generally only have two weights available anyway.
   jdaggett: But with @font-face that will change.
   Peter: If somebody really needs all the different weights, and they
          use @font-face, they'll probably use the numeric control.
   Peter: The danger of bolder/lighter was that it's fragile.  I like
          this proposal; it does the right thing more often than not.
   Steve: It will still have the phenomenon that with only two weights,
          normal->bolder->bolder->lighter gives no change for a font
          with only 400 and 700.
   <jdaggett_sleepy> http://people.mozilla.org/~jdaggett/weightdistinctions.png
   jdaggett: But that's going to be true with existing implementations anyway.
   <Bert> (I'm using bolder quite often, but knowing that for 99% of the
          readers it will not actually be bolder, so I don't use it when
          a weight change is essential for readability.)
   jdaggett: So I will post suggested edits for 2.1 on www-style and we
             can collect more comments based on that.
   ?: sounds good
   fantasai: I have an example: in font with 400, 900: normal -> bolder,
             then in descendant element with font with 400,700, do lighter,
             what happens?
   jdaggett: I think new way is clear to figure out what happens, but
             can be hard to compare to existing proposals.
   <Bert> <span style="font-family: normal-and-black; font-weight: bolder">
            foo
            <span style="font-family: normal-and-bold; font-weight: lighter">
              bar
            </>
          </>
   jdaggett: I think the situations with multiple levels of nesting
             aren't cases that authors would easily understand.
   Steve: Bert's example shows problem with jdaggett's "alternative proposal":
          why you shouldn't use the font.
   Sylvain: Hard to find a solution that works in every case here.
   jdaggett: Strong case for making things simple, so you can at least
             figure out what will happen.
   Sylvain: [???] Hard to get what you want every time.
   Steve: Main reason I like John's proposal.
   jdaggett: I'll try to include examples with the proposal.
   <sylvaing> (not sure we should concern ourselves with authors changing
              font family in descendant *and* using relative font-weight.)

Media Queries Test Suite
------------------------

   Peter+Daniel: Opera won't have the resources to lead the effort for
                 this test suite.
   Daniel: We have 3 implementations, mostly interoperable.
   Daniel: Most features in spec are testable.
   Daniel: All we need for PR is test suite + impl. reports.
   Daniel: I started writing a few tests; David Baron posted a large number
           from Mozilla.
   Daniel: I'm not sure we can use David's as-is.
   Daniel: It's one of the candidates for a quick PR.
   fantasai: Someone needs to take ownership of that test suite.
   David: Why can't the tests I posted be used pretty much as-is?
   fantasai: Maybe they can; somebody needs to put together an index of all
             tests submitted.
   Anne: We can't go directly to PR; we have to wait at least 150 days.
   Daniel: Yes, but after that, I'd want us to go as soon as possible.
   <fantasai> where are these tests?
   * fantasai can't find any posts by dbaron to public-css-testsuite wrt
              media queries
   Daniel: Do tests work in browsers other than Mozilla?
   <glazou> http://lists.w3.org/Archives/Public/www-archive/2009Apr/att-0063/test_media_queries.html
   David: Yes, the tests function, except a lot of the parsing tests
          depend on recent changes to spec that Opera and WebKit don't
          implement yet, I think.
   Anne: Yes, we fail similar tests in Bert's test suite.
   ...
   <fantasai> dbaron, can you send your message to public-css-testsuite ?
   <fantasai> www-archive is not the right mailing list
   David: The reason I didn't send to public-css-testsuite is because
          the discussion started on w3c-css-wg
   David: Didn't get a change to send to public-css-testsuite yet
   Daniel: Who wants to take ownership of this test suite?
   fantasai: I'm happy to provide guidance to whoever takes over
   fantasai: Basically we want a directory of files that we can put on www.w3.org
   fantasai: That are coherent and have enough instructions that it is
             understandable how to use the test suite and what the
             requirements are
   Anne: I disagree that it needs to be coherent.
   fantasai: They can be inconsistent in their format, that's fine, but
             incoherent means they don't make sense.
   Anne: I didn't quite understand what fantasai meant by coherent.  I
         think it's fine to have some automated tests and other
         non-automated tests, and have requirement for all of them to pass.
   fantasai: I think that's fine, just need index page that explains this.
   Peter: Still leaves question of who will own this.
   Anne: Lachlan has some tests that require PHP on the server.
   Daniel: I can take ownership, but availablity in next 2 months is uncertain.
   fantasai: Can probably copy index page from namespaces.
   <annevk> (I haven't quite discussed this with Charles by the way,
            but I was planning on doing something with the Media Queries
            Test Suite in due course. I think I said the same to glazou.)

text-overflow and vertical overflow
-----------------------------------

   fantasai: Should defer to F2F, if Anne's ok with that.
   Anne: I'm ok with deferring to F2F, but we would like to have some kind
         of answer soonish.
   Peter: Ok, at F2F then.
   <alexmog> f2f is fine. I do have an opinion though. I think IE7 behavior
             is correct.

Other CSS 2.1 issues?
---------------------

   Peter: Anything that takes 5 minutes discussion?
   fantasai: Issue 89
   <fantasai> http://wiki.csswg.org/spec/css2.1#issue-89
   <fantasai> http://dev.w3.org/csswg/css3-page/#allowed-pg-brk
   <fantasai> http://www.w3.org/TR/CSS21/page.html#allowed-page-breaks
   <dbaron> I'd note that it would be helpful to have the list of CSS 2.1
            issues we plan to discuss on the agenda so that we can think
            about them beforehand.
   Bert: I think we can allow a page break there:  with more than one line,
         we allow a page break, so why forbid it when it drops to one line.
   fantasai: Implementations already do this with a fixed height block;
             some just truncate the box.
   fantasai: I think IE8 and Firefox will split the block over multiple pages.
   <sylvaing> testcases  http://fantasai.inkedblade.net/style/tests/ad-hoc/pagination/allowed-breaks-000
   fantasai: I think Opera truncates.
   Steve: Without the extra space you wouldn't have allowed break, so why
          with it?
   fantasai: Makes more sense with a fixed height block, rather than an
             auto height block.
   fantasai: This is different from padding, conceptually.
   Steve: In this case I'd shove the whole block to the next page.
   fantasai: That's not the distinction here: it's a question of whether
             you have to pull the last line to the next page along with
             the bottom padding/border.
   Steve: I think "can't break when there's only one line box" is a good
          thing.
   Peter: I don't see why not breaking is good when the container is much
          larger than the line.
   Steve: I sort of see that as a fallback.
   Steve: OK, I can live with it, but I think it's encouraging something
          that shouldn't be encouraged.
   fantasai: I'd rather break there than truncate there.
   <alexmog> I don't think this break as an "allowed" break. It is a
             forced break.
   Peter: Any objections?
   Bert: How does this work with 'widows' and 'orphans'?
   RESOLVED: Accept proposal for issue 89
   Peter: see you next week
   <Bert> Orphans cannot be 0, doesn't that exclude Fantasai's solution?
   <fantasai> Bert: That's an interesting take :)
   * fantasai didn't think of it that way
Received on Monday, 8 June 2009 18:58:00 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:20:18 GMT