- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Wed, 14 Jul 2010 07:31:51 -0700
- To: "www-style@w3.org" <www-style@w3.org>
Summary:
- Reviewed status of CSS2.1 test suite and issues
- Discussed whether soft-wrapped lines in pre-wrap text
should be justified when text-align: justify is specified.
====== Full minutes below ======
Present:
Tab Atkins
Bert Bos
Beth Dakin
Arron Eicholz (via IRC)
Elika Etemad (via IRC)
Simon Fraser
Sylvain Galineau
Brad Kemper
Peter Linss
David Singer
Steve Zilles
<RRSAgent> logging to http://www.w3.org/2010/07/07-CSS-irc
ScribeNick: TabAtkins
Administrative
--------------
plinss: Any new agenda items?
plinss: Seems like no.
Test Suite
----------
plinss: Test suite updates?
<fantasai> I am not able to call in
Tab: I was able to get a contractor hired to help out with reviewing tests.
<arronei> I'm only on IRC today. But on my end I am getting a list
of test cases that are invalid.
<arronei> I will send out that list by the end of the week.
CSS2.1 Issues
-------------
plinss: Okay, open issues.
plinss: 53 is still open
<plinss> http://wiki.csswg.org/spec/css2.1#issue-53
plinss: Daniel was getting feedback from Thunderbird people,
I believe he did.
plinss: They said they were okay with ignoring justification
in preformatted text, I believe.
<fantasai> I'm not ok with ignoring justification
<fantasai> http://lists.w3.org/Archives/Public/www-style/2010Jul/0055.html
Elika's suggestion is that we respect justification everywhere
(even preformatted), but not on lines that end in a
hard wrap.
Tab: Bonus of that is that it's a pretty nice simplification.
bradk: Elika's suggestion makes sense.
plinss: But if you're preformatted, differing numbers of spaces may
not be the proper width anymore.
<fantasai> Because that's what you asked for
<fantasai> you asked for preformatted, not monospace
<fantasai> you didn't ask for grid layout
<fantasai> you asked to preserve whitespace and to justify
<fantasai> if you didn't mean justify, then don't ask for it
plinss: My concern is that justification is inherited, so the
justification might come up from further in the chain.
bradk: What about word-spacing? Different fonts are formatting too.
<fantasai> Then add pre { text-align: initial; } to the defualt
UA style sheet
plinss: word-spacing applies to every character individually,
so I think that's okay.
<fantasai> no it doesn't it only applies to spaces
<fantasai> letter-spacing applies to every grapheme cluster individually
<fantasai> word-spacing only applies to spaces
* plinss actually said letter-spacing, error in minutes
Tab: I don't think that distinction is justified. You can use
fonts with varying ratios of character to space widths
in pre text, and get all sorts of differing renderings.
szilles: So the question is what properties should apply in pre text?
Tab: I think they all should.
<fantasai> pre should mean "preserve white space", not "turn off
random features to more closely approximate plaintext
sans formatting"
<fantasai> imo
Bert: Justification can move linebreaks around, which isn't
compatible with preformatted text.
<fantasai> Bert, how can it move linebreaks around?
<fantasai> Bert, justification happens *after* linebreaking
<TabAtkins> apparently TeX can do that with its more complex justification.
<fantasai> Ok, true, but if you're soft-wrapping, you're already handing
over line-breaking to the layout engine anyway
<fantasai> hard line breaks don't move
Tab: Elika's suggestion is to only justify soft-wrapped lines.
A preformatted text block with only hard breaks won't justify.
plinss: So we've talked about this for a while. Anyone being convinced?
TabAtkins: I like Elika's suggestion. It seems to respect the
restrictions of preformatted text while still letting
authors do things complex if they want.
<Bert> (Fantasai, if you are allowed to stretch/compress word spaces,
you may want to chose your line breaks such that adjoining
lines both stretch or both shrink. TeX does that. Also to
avoid "rivers" of white.)
<fantasai> (Bert, that's cool, but as I said, hard line breaks
don't move, and soft ones are UA-determined anyway)
<fantasai> (The UA may choose breaks to reduce the raggedness of
a ragged edge, too, for example)
<fantasai> (In which case a different UA with the same fonts and
containing block width won't give the same soft breaks)
<Bert> (Yes, and so I agree with your proposal. :-) )
plinss: I guess I'm okay with it. I'm slightly concerned if this
changes anything in existing preformatted text.
<fantasai> peter, then I recommend to add the pre rule to the
default UA stylesheet
<fantasai> peter, because most pre text in the wild is probably
in <pre> elements
smfr: Webkit doesn't do text-align:start in <pre> by default.
szilles: Can someone make some tests and find out what is actually
used? Because there might be a lot of files out there
that depend on the current behavior (e.g. no justification
in preformatted text).
<fantasai> szilles: preformatted text does not wrap
<fantasai> szilles: it's only pre-wrap that you'd have to check
szilles: Since hittin pre-wrap is such an edge case any way, I
don't know if it's worth making it act weird with justification.
[discussion about letter-spacing, and whether or not it preserves
formatting - it only does so in monospace text]
bradk: If we punt, there's a chance we could be locked in by implimentations.
plinss: Thunderbird was "okay" with preventing justification in
pre-wrap text (which they use in composing mail messages).
plinss: I like Elika's proposal, I just don't know if we want to
bring up a new behavior for 2.1.
szilles: The way we usually fix these is to spec what is done today,
and later come up with a new value for the new behavior if
we still want it.
<fantasai> What's done today doesn't match the spec anyway
<fantasai> Also, if we lock ourselves in here, the author has no control
<fantasai> szilles, What new control do you want to introduce in CSS3?
text-align: justify-no-I-really-mean-it?
<szilles> Elika, no I would introduce a "pre-wrap-justify" value
dsinger: Maybe someone could write up a matrix of a text-align,
whitespace, and point out where we've got gaps in either
the spec or reality?
Tab: I can do that.
<fantasai> szilles: That's ridiculous. It mixes up white-space with
text-alignment and justification in addition to it's
already mixed up text-wrap and ws-collapse behavior.
<fantasai> szilles: We could define different behavior for values
of text-justify
<fantasai> szilles: auto means pre doesn't justify, anything else
means it does
* bradk deferring to mailing list for pre issue
<szilles> fantasai, I would agree that your argument about justify
and pre-wrap makes sense. My argument is that, currently,
this is so much an edge case that requiring changes in
all implementations is not reasonable at this time and
could inhibit getting out of CR.
plinss: Next is 101 on dbaron, he's not here.
<plinss> http://wiki.csswg.org/spec/css2.1#issue-110
Tab: http://lists.w3.org/Archives/Public/www-style/2010May/0483.html
TabAtkins: After talking with Elika, I'm happy with presenting my
last proposal to the list, from May. ^^^
TabAtkins: Module the minor changes suggested by Brad and Peter
Moulder in the immediate responses.
Tab: I think Boris is the only implementor who has given the issue
110 proposal serious feedback so far, so anyone else who would
be working on table-stuff that could look at it would be great.
<plinss> http://wiki.csswg.org/spec/css2.1#issue-138
plinss: Anyone reviewed this?
* fantasai would like to know where the whole proposal lives
* fantasai also thinks getting iterop on the static position will be
way harder than pre justification :)
Tab: Summary is that floats will follow the relpos of their parent,
even if their parent is an inline that is officially broken
around it.
szilles: I'm somewhat concerned about floats being treated as part
of the content as a general principle.
<fantasai> What does 'opacity' do?
szilles: That is, what about things like footnotes?
<fantasai> If 'opacity' affects the float, then I think relpos
should also affect the float
<fantasai> They're both filtery effects
<fantasai> graphical transformations, whatever
Tab: Floats are a weird half-space, where they are out-of-flow for
some things and in-flow for some things. It's a different
space entirely from abspos and footnotes, which move completely
independently of the "surrounding content".
plinss: Who has to change for this?
Tab: IE8 appears to use the suggested behavior. Gecko is close.
Opera and Webkit are substantially different.
Tab: I'll bug Hyatt and try to bug Opera people about the feasability
of this today.
<plinss> http://wiki.csswg.org/spec/css2.1#issue-140
Bert: I haven't managed to do #140 yet.
Bert: Next week seems possible.
http://wiki.csswg.org/spec/css2.1#issue-140
http://wiki.csswg.org/spec/css2.1#issue-142
Bert: Same thing. But I think maybe fantasai was supposed to do this
one? I can't remember if it was this one or another that she
said she would do.
<fantasai> Bert, I'm doing 120 for you
plinss: 158, I don't think we'll do that in 4 minutes.
Tab: Plus, there was a *lot* of feedback on that over the weekend
which I haven't been able to process yet.
<plinss> http://wiki.csswg.org/spec/css2.1#issue-167
[summary of the proposal]
* bradk abstains from voting on this one
* Tab me too
* fantasai thinks dbaron should be consulted
plinss: Any testcases on what implementations do on this one?
Meeting closed.
Received on Wednesday, 14 July 2010 14:32:30 UTC