W3C home > Mailing lists > Public > www-style@w3.org > July 2010

Minutes and Resolutions 2010-07-14

From: fantasai <fantasai.lists@inkedblade.net>
Date: Thu, 15 Jul 2010 03:47:20 -0700
Message-ID: <4C3EE738.8070506@inkedblade.net>
To: "www-style@w3.org" <www-style@w3.org>

   - RESOLVED: Look into allowing justification combined with white-space
               values in the future, but go with Proposal A for CSS 2.1
               Issue 53.

   - Reviewed CSS2.1 Issue 138, leaning towards making floats only relpos
     with their containing block.

   - Proposals for CSS2.1 issues 110, 158, and 166 assigned as required reading.
     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

   - 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 ======

   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

   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?
   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

This archive was generated by hypermail 2.4.0 : Monday, 23 January 2023 02:13:48 UTC