Minutes and Resolutions 2010-07-07

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