- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Mon, 08 Jun 2009 04:40:36 -0700
- 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 UTC