- 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