- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Thu, 15 Jul 2010 03:47:20 -0700
- To: "www-style@w3.org" <www-style@w3.org>
Summary: - RESOLVED: Look into allowing justification combined with white-space values in the future, but go with Proposal A for CSS 2.1 Issue 53. http://wiki.csswg.org/spec/css2.1#issue-53 - Reviewed CSS2.1 Issue 138, leaning towards making floats only relpos with their containing block. http://wiki.csswg.org/spec/css2.1#issue-138 - Proposals for CSS2.1 issues 110, 158, and 166 assigned as required reading. http://wiki.csswg.org/spec/css2.1#issue-110 http://wiki.csswg.org/spec/css2.1#issue-158 http://wiki.csswg.org/spec/css2.1#issue-166 ACTION Tab: Update 110 with link to proposal. (Meaning, if you're reading this and it's not done, do it now. :) - RESOLVED: Accept dbaron's proposal for CSS2.1 Issue 174 http://wiki.csswg.org/spec/css2.1#issue-174 - writing-mode spec sync with SVG deferred to September, when fantasai has time to work on it - RESOLVED: Add CSS Styling Attributes spec to 2007 Snapshot ====== Full minutes below ====== Present: César Acebal Tab Atkins David Baron Beth Dakin Arron Eicholz Elika Etemad (via IRC) Simon Fraser Sylvain Galineau Brad Kemper Peter Linss <RRSAgent> logging to http://www.w3.org/2010/07/14-CSS-irc Administrative -------------- plinss: No additions to the agenda. <fantasai> plinss, I would like to add the CSS Snapshot and the Styling Attributes spec to the agenda CSS2.1 Issues ------------- plinss: Issue 53, spent a lot of time on it last week, not sure if anything got resolved. <plinss> http://wiki.csswg.org/spec/css2.1#issue-53 <fantasai> I remember why pre-wrap isn't justified in Mozilla <fantasai> It's because of tabs tabatkins: Conclusion from browser testing - anything with collapsed whitespace can be justified, anything with preserved whitespace can't be. <fantasai> So I would suggest adopting Proposal A bradk: How do the tabs come into it, fantasai? <fantasai> How do you justify tabs? <fantasai> They're supposed to push text to the next tab stop <fantasai> but if spaces stretch or shrink <fantasai> then the text moves around <fantasai> and the tabs might need to push to the *next* tab stop * TabAtkins thinks that Word still lets you justify with tabs. <fantasai> so they have to be recalculated <fantasai> and the text *has* to be rebroken <fantasai> without the tabs problem, you never *need* to alter line breaks due to justification <fantasai> it's just an option that can sometimes make the results better <bradk> I thought a tab was just a seres of spaces in HTML <fantasai> bradk, no, it aligns to a tab stop <fantasai> bradk, the tab stops are a multiple of 8 spaces apart <fantasai> bradk, starting from the containing block edge <bradk> Thanks, I didn't realize that. <plinss> you can lay out the text with tabs, then justify from the last tab stop to the end of the line <fantasai> plinss, that makes sense. I like that definition. <fantasai> plinss, seems like it would handle most cases tabatkins: What plinss just suggested appears to be exactly what word processors do. * fantasai is happy with plinss's definition <fantasai> I'll note that SteveZ was concerned about CR exit, so if we go with this then we should mark justification of pre-wrap text as at-risk tabatkins: Going with plinss's definition, we'll still have no implementations. Is that ok? smfr: This question is specifically about CSS 2.1. What are we going to do right now? <fantasai> smfr, I don't think we have implementations to exit CR with pre-wrap justification right now, and given the implications with tabs, it's not as simple as throwing a few switches bradk: We could say "Not justified" right now, and then change it in the future. <fantasai> bradk, that works as long as we are clear about our future plans <fantasai> bradk, we'd have to say that this may change in CSS3 plinss: [talks about new mode that collapses spaces but not tabs] <fantasai> bradk, And probably remark that justification is allowed if the UA supports it tabatkins: Fine with just going with current behavior for CSS2.1 and fixing it in the future. <smfr> phew RESOLVED: Accept proposal A for issue 53. <fantasai> If the intention is to allow justification in the future then we need a resolution to allow for that <fantasai> If the intention is not to allow justification in the future, then I'd like a resoluttion for /that/ * fantasai wants to know whether to reraise this in CSS3 or just copy from CSS2.1 RESOLVED: Look into allowing justification combined with white-space values in the future, but go with Proposal A for CSS 2.1. <fantasai> Thankyou <bradk> does centering text with tabs in it also change the white space? <fantasai> bradk, good question, I don't know what happens <fantasai> bradk, it's a similar problem <TabAtkins> It does something odd here in OOo Writer. <TabAtkins> Not sure what the behavior is exactly. <bradk> If so, then we should treat centering and justifying the same way... <fantasai> bradk, well, we don't have implementations to do it in 2.1, but since we're leaving it open for CSS3 we can do that in CSS3 <bradk> fantasai, OK, I can live with that <plinss> http://wiki.csswg.org/spec/css2.1#issue-101 plinss: dbaron, you have any idea when you'll be able to look at 101? dbaron: Not sure. <plinss> http://wiki.csswg.org/spec/css2.1#issue-110 tabatkins: I pointed last week to the proposal that I was happy with making. I need to edit the wiki and resend to the list so people actually know what it is. <plinss> http://wiki.csswg.org/spec/css2.1#issue-138 tabatkins: For dbaron's response on the list, I think the "float in inline" was precisely what we were testing. dbaron: The actual discussion on the list was about different things; only some of them were about floats, and I think all of them involved a float in a block in an inline. dbaron: For the testcase I posted yesterday, it appears that floats directly inside inlines are agreed by browsers to not relpos along with the inline. dbaron: If we want to say that relposing moves a float inside the content tree but not in the containing block, we should say that in general, not just in the case you have a block-in-inline split. <dbaron> ... but I don't think we should. <dbaron> http://dbaron.org/css/test/2010/css21-issue-138-simple-float-test dbaron: What I see in Gecko and Chrome is that the first line isn't offset, but the second one is. tabatkins: So in the block-in-inline case, the block is the containing block for float? dbaron: Yes. <dbaron> I'm also not sure if there's anything in the spec that says exactly what relative positioning affects... tabatkins: That makes sense. I'd be fine with revising my proposal to say that floats move with their containing block. Then somehow making it clear that, in the block-in-inline case, the block is what moves with the inline's relpos, even though officially the inline is broken around the block. sylvaing: In IE8 and IE9, both of them move 200px away from the edge. tabatkins: If IE is moving the float, I'm a bit scared to change it, just because I know that we authors count on floats doing really odd things. <dbaron> So I'd note that we should probably have a separate 2.1 issue on nothing in the spec saying which descendants of an element are affected by relative positioning. tabatkins: So, I need to (a) change the proposal to make floats only care about their containing blocks getting relpos, (b) ensure that the block-in-inline case appropriately moves the block if the inline is relposed, and (c) build some confidence that this won't break IE. tabatkins: My only solace is that Firefox does something substantially different, so as long as an author tests in both FF and IE they won't depend on this behavior. bradk: Unless it somehow fixes a separate IE bug. tabatkins: Right. plinss: IE guys, are you theoretically okay with this change? sylvaing: It makes sense to me to make floats move with their containing blocks only, but I'd have to check with Alex to see what he thinks re: compat. sylvaing: Alex is in Moscow right now, so we'll probably have to catch him on email. ACTION Sylvain: Contact AlexMog to see if changing things for Issue 138 will hurt web compat for IE. <trackbot> Created ACTION-245 <plinss> http://wiki.csswg.org/spec/css2.1#issue-158 <TabAtkins> Same as last week, the proposal is linked on the wiki and just needs someone to review it for acceptability. plinss: Anyone reviewed it? [silence] plinss: Everyone, read the proposal for Issue 158, and we'll discuss it next week. <plinss> http://wiki.csswg.org/spec/css2.1#issue-166 tabatkins: I have not reviewed this yet, though I like how few changes there had to be. tabatkins: Looks good at first blush, I just need about 10 minutes to read it in depth. plinss: Good. Everyone take a look at it so we can quickly resolve on it next week. <plinss> http://wiki.csswg.org/spec/css2.1#issue-167 tabatkins: Latest action on it is dbaron's feedback, but Zack hasn't responded to it yet. I think dbaron needs to poke Zack to respond. dbaron: Ok. plinss: We also had a note to get better testcases on this. Are our testcases okay right now? arronei: We have a couple. I'll look around and add them to the wiki. plinss: Would be good to get together an idea of what we're doing and what we want to do. <plinss> http://wiki.csswg.org/spec/css2.1#issue-174 <dbaron> http://dbaron.org/css/test/2010/css21-issue-174 dbaron: I think this is a straightforward case of the prose disagreeing with the grammar, and everyone following the grammar. dbaron: I checked Gecko and Chrome. <smfr> i confirm <fantasai> Opera and Konqueror match FF arronei: IE and Opera show the testcase bradk: Safari too. RESOLVED: Accept dbaron's proposed change to resolve issue 174. <fantasai> If we're done with CSS2.1 issues, I'd like to propose adding the CSS Styling Attributes spec to the 2007 Snapshot <fantasai> Also, I'd like some guidance on what to do with that spec, since it's in LC, and all issues were addressed, but the SVGWG never confirmed whether they were happy with my responses. <fantasai> http://dev.w3.org/csswg/css-style-attr/issues-lc-2009 tabatkins: Did that one just describe reality, or was it the one that tried to allow scope and MQ and such inside of @style? <fantasai> Just describes reality <fantasai> no new features <TabAtkins> kk, then I'm cool with i. <fantasai> otherwise I wouldn't suggest backporting it to 2007 :) plinss: I'm fine with it. Objections? [no objections] RESOLVED: Add CSS Styling Attributes spec to the 2007 snapshot <fantasai> Second question then is, should we move to CR or action someone to pester the SVGWG again for a response? <plinss> http://lists.w3.org/Archives/Public/www-style/2010Jun/0644.html <fantasai> plinss, For the writing-mode question, I suggest waiting until end of September <fantasai> plinss, because I won't have time to work on it until then <fantasai> plinss, but I do intend to sync with SVG <TabAtkins> fantasai, that's just an issue of whether to accept SVG's shorthands, right? <TabAtkins> fantasai, since we don't want to drop our bt-* ones. <fantasai> it might be, it might mean other things <fantasai> right, we'd make a superset <fantasai> but there might be some changes to behavior also required <shepazu> [the SVG WG intends to match CSS for SVG 2] plinss: You okay with deferring this, Sylvain? <shepazu> [please let us know if there are changes to behavior, of course... but we're open to changes, if they make sense] sylvaing: yeah. Meeting closed. <TabAtkins> shepazu, should we bug SVGWG more about Styling Attribute? <shepazu> TabAtkins_: what's the issue? <TabAtkins> SVGWG never confirmed if they were okay with the resolutions to the CSS Styling Attributes spec LC issues. <fantasai> http://dev.w3.org/csswg/css-style-attr/issues-lc-2009 <fantasai> issues list is there ^ <shepazu> hmmm. I thought we'd resolved that... I think Chris has the ball. IF you would be so kind, write us another follow-up email about the remaining issues, and we will resolve on it for our next telcon <shepazu> and send a clear response
Received on Thursday, 15 July 2010 10:48:02 UTC