W3C home > Mailing lists > Public > www-style@w3.org > January 2012

[CSSWG] Minutes and Resolutions Telecon 2012-01-19

From: fantasai <fantasai.lists@inkedblade.net>
Date: Fri, 20 Jan 2012 17:10:18 -0800
Message-ID: <4F1A107A.2000905@inkedblade.net>
To: "www-style@w3.org" <www-style@w3.org>
Summary:

   - Reviewed logistics for Paris F2F; request for agenda items

   - Deferring republication of css3-writing-modes until jdaggett's concerns
     are resolved

   - RESOLVED: Breaks are allowed wherever there was a breakpoint, even if
               it was collapsed away. Clarify CSS3 Text.

   - Discussed problematic behavior of currentColor keyword, which computes
     on the element specified and then inherits, instead of inheriting as
     a keyword and then recomputing on each element. Tab to investigate whether
     SVG depends on this behavior or if we can change it.
     See http://lists.w3.org/Archives/Public/www-style/2012Jan/0521.html

====== Full minutes below ======

Present:
   Glenn Adams
   Rossen Atanassov
   David Baron
   Bert Bos
   Tantek Çelik
   John Daggett
   Elika Etemad
   Simon Fraser
   Sylvain Galineau
   Daniel Glazman
   Arno Gourdol
   Molly Holzschlag
   Koji Ishii
   Brad Kemper
   Peter Linss
   Divya Manian
   Alex Mogilevsky
   Edward O'Connor
   Anton Prowse
   Florian Rivoal
   Alan Stearns

<RRSAgent> logging to http://www.w3.org/2012/01/18-css-irc
Scribe: TabAtkins

February F2F
------------

   <plinss> http://wiki.csswg.org/planning/paris-2012
   plinss: our agenda page is still kinda light, so please enter things as
           soon as you can
   glazou: I need a firm list of people attending the meeting next week
           because I need it for security reasons - there will be badges
           every day.
   glazou: Even if you don't have your flight details, please add yourself asap.
   <sylvaing> the list of msft attendees is complete. well, we even have
              two Alex Mogilevskys
   plinss: Also there are no hotels listed on that page yet?
   glazou: I sent an email a while back with a short list of hotels.
           I'll add that to the wiki page.
   glazou: One thing I'm missing is meal prefs - any food restrictions for
           the group meal?
* sylvaing can only eat delicious food
   glazou: Also there is no food inside the building.  So I can't get catering
           inside.
   glazou: They'll tolerate breakfast, so I'll bring croissants and such, but
           we'll have to get lunch outside.
   glazou: Drinks are allowed.
   glazou: There's a shopping mall on the other side of the street, chinese
           district is walking distance, and plenty of other restaurants.

Status of CSSOM and CSSOM View
------------------------------

   glenn: The work is in progress.  I've been updating and will soon bring a
          draft forward to the group for review.
   sylvaing: Can you characterize the changes?
   glenn: The main changes have been filling out text that was basically blank
          in the spec, and I'm planning to bring that forward for discussion
          at the f2f.

Publishing Writing Modes
------------------------

   plinss: We deferred this from last week, and jdaggett has sent in a bunch
           of comments.
   jdaggett: I posted some issues that I think exist with text-orientation.
             I think we should let some of those discussions continue.
   jdaggett: Koji responded and I need to respond back.
   jdaggett: I think there's some wording about text-orientation and the
             unicode properties, but I don't think it describes editors'
             intent.
   jdaggett: Once those list discussions seem to be resolved, I think I'll
             be okay.
   plinss: Anyone else have thoughts on that?
   <jdaggett> there's new wording for text-orientation but I don't think it
              accurately describes how the editors intended this should work
   <jdaggett> so discussion on the list should continue for a bit I think
   florianr: I haven't followed too closely the details of these issues, but
             I think that what jdaggett is trying to resolve is worth figuring
             out.
   plinss: So do we think it's worth publishing a WD and then publish LC later?
   * scribe missed most of what jdaggett just said due to things cutting out.
   <jdaggett> i think it's impor
   <glazou> even on IRC jdaggett is cut :-)
   plinss: Is there a current conversation going, or does someone need to
           raise an issue?
   <jdaggett> relates to http://lists.w3.org/Archives/Public/www-style/2012Jan/0655.html
   jdaggett: There's currently a convo.  It just nees to resolve.
   plinss: Okay, we'll let it settle and revisit later.

Processing Model for Transforms
-------------------------------

   <plinss> http://lists.w3.org/Archives/Public/www-style/2011Dec/0000.html
   dbaron: Tab responded on the list, so nothing needs to be discussed here.

Collapsed space break opportunities
-----------------------------------

   <plinss> http://lists.w3.org/Archives/Public/www-style/2012Jan/0408.html
   fantasai: We resolved for 2.1 that if you have two spaces that collapse
             and the first one is non-breaking (so the breakble one disappears)
             you're still allowed to break there.
   fantasai: But what happens if you have a bunch of different element
             boundaries?  Where does this break occur?
   fantasai: If the non-breaking was within a border but the breaking was
             outside, does the break happen within or without the border?
   fantasai: I can see conceptually that breaking at any point previously
             occupied by a space is valid.
   fantasai: Or I can see saying that the non-breaking space is now breakable,
             so that you must break there.
   fantasai: These both make sense to me.
   fantasai: FF and Opera will break right before the following text (last
             breaking opporutunity) even if that's not actually a valid
             break point.
   fantasai: So I don't really know what we should do.
   fantasai: I'm not sure I want to spec what FF/Opera does, because it
             doesn't make much sense.
   TabAtkins: What does Webkit do?
   fantasai: Webkit refuses to render empty inlines, so it's not detectable
             what their behavior is.

   dbaron: Why do we collapse across visible borders?
   fantasai: I dunno.
   dbaron: It would seem less crazy if we didn't do that.
   plinss: But do you really want the presence of borders to change your
           whitespace-collapsing behavior?
   dbaron: Doesn't seem that different from the presence of an image.
   TabAtkins: collapsing already depends on other properties.

   fantasai: I see four options.
   fantasai: (1) don't collapse spaces across non-zero borders, non-zero
                 padding, or non-zero margins.
   fantasai: (2) anywhere a space used to be is a break point
   fantasai: (3) when a non-breaking space collapses with a breakable,
                 the resulting space is breakable
   fantasai: (4) break right before the next thing after the collapsed stuff
                 (even if it's not actually a valid breakpoint) (FF/Opera
                 behavior)
   * florianr was confused by fantasai's remark that this is different from
              an nbsp characher. What to I read to become smarter?
   * TabAtkins a space inside a no-wrap element.

   dbaron: You've got borders with width in them in this example, so you
           can tell whether there's one breakpoint or multiple.
   mollydotcom: If there's a non-breaking and a breakable space, they all
                collapse, and that point is the break point.  That's #2,
                right?
   fantasai: Not quite.  When you collapse spaces, the first space nominally
             stays put, and the rest get dropped.
   fantasai: So I've got a space inside the no-wrap, and two empty inlines,
             then a B.
   mollydotcom: The integrity of the borders shouldn't be broken, right?
                Doesn't that make sense?
   mollydotcom: If something breaks in a border, a designer will be confused
                by that.
   dbaron: If you have a multi-word thing wtih a border around it, breaking
           inside there is normal.
   fantasai: But you wouldn't break *just* within the border on either end.
   fantasai: And we can expand that to say you don't break inside an empty
             inline, because that's a degenerate case.
   fantasai: But we can break *between* the inlines.
   mollydotcom: It seems the most natural point to make the break is the
                first point where all the space has collapsed and there
                is no border.
   TabAtkins: So this sounds like break opportunities at the beginning or
              end of an element with visible borders or whatever migrate
              outside of the element.
   fantasai: Yes, there's spec text for that.
   fantasai: I think what Molly's saying is that you collapse everything,
             then the break point must go at that last point, but if it's
             at the end of an element with a border or whatever, move it
             outside the element.
   bradk: Not just borders, box-shadow too right?
   fantasai: It's all boxes, not just those with visible decorations.
   fantasai: If you think about it, if you put a word in a box and put it
             against the edge of a line, the breakpoint is just inside the
             box, technically, but we instead move it outside the box.
   fantasai: So what about if the breakpoint determined by this rule is
             within the non-breaking area?
   <fantasai> <p><nowrap>A <em> </em></nowrap> <em> </em> B
   <dbaron> (Did that discussion just conclude something weird about what
            happens when the only space is just inside the edge of the border?)
   Rossen: In IE we would preserve a break oppurtunity after the </nowrap>
           for the case in the email.
   fantasai: And waht about the case in IRC?
   fantasai: I think the logical place would be to break after the </nowrap>,
             but that's between the two empty <em>s.
   dbaron: might have more than one breakpoint
   Rossen: We still preserve the space inside the nowrap, and break outside
           the nowrap.
   fantasai: Ok, I propose we spec what IE does, because that makes sense.
   * Rossen agrees with fantasai :-)

   fantasai: If you look at the last example in the email, Moz breaks right
             before the B.
   antonp: The last example is the key one - you can't honor both nowraps
           unless you break in the middle.
   TabAtkins: I think we want to specify that break opportunities collapse
              separately from the spaces that generate them, and won't enter
              no-break areas.
   antonp: Does that mean in the second example in fantasai's email, the space
           after the A is preserved, but the whitespace collapsing between
           them is independent?
   fantasai: There's two phases to whitespace - the first collapses, the
             second trims from teh begin/end of the line.
   TabAtkins: dbaron had an issue about borders.
   fantasai: They'll make the breaks that would visible coincide be visibly
             separate.
   fantasai: Once you put borders, they'll take up space, so you can see
             where the break opportunity happens.
   mollydotcom: If you have content, and it's right up to the border, it
                would be devasating to have a break right at the end.
   fantasai: The migration rule applies to all elements, regardless of
             decoration.  So that addresses david's issue.
   bradk: What if you have a zero-width box with a box-shadow at the end of
          a line (and a space inside of it)?
   TabAtkins: I think it would migrate the break opportunity both before and
              after the box, so the break would happen before it.
   fantasai: box-shadow doesn't take up sapce, so it doesn't affect layout
   TabAtkins: But the box-shadow lets you tell whether the box is at the end
              of one line or the beginning of the next.
   antonp: There was a convo about a year ago with Boris about this issue -
           whether zero-width boxes stay at the end of a line or wrap around.
   antonp: So it may be worth digging that up.

   dbaron: Another warning - a fun thing to introduce in text cases is
           negative margins.
   dbaron: They can give you cases where adding more stuff to the line gives
           you an earlier breakpoint.
   mollydotcom: I was just imagining that.
   dbaron: I don't know if we properly define, given a set of breakpoints,
           how you choose the one that is actually used.
   <antonp> neg margin was, I think, the main subject of the convo I was
            referring to IIRC
   dbaron: Because there may be a sequence of breakpoints that are not
           monotonically non-processing in the line direction, due to
           negative margins.
   <dbaron> s/processing/decreasing/
   * oyvind not monotonically non-decreasing? confused now
   * scribe dbaron I went with precessing because we were talking about a
            position, not a value.
   * dbaron oyvind, they might have some steps in the sequence with decreases

   mollydotcom: [explains an issue]
   plinss: I think it just changes where the breakpoint would be between
           two elements.
   mollydotcom: It seems that even getting down to that level - why would
                we want it? I would avoid those.
   <Bert> (A line might be overfull already, but after adding the next elt
           with negative margins, it is suddenly no longer full...)
   * mollydotcom sez keep it simple - avoid any breaking where there might
                 be a margin or border
   <Bert> (Even with 'overflow-wrap: break-word', there won't be a break
           between the last letter and the border, I assume?)

   fantasai: We don't define which breakpoint gets chosen, only where the
             possible breaks are.
   fantasai: This is intentional, so you can frex do paragraph-level
             breaking/balancing instead of line-level.
   <sylvaing> i can't object to that
   fantasai: So I think we're done with this issue if everyone's happy with
             IE's behavior.

   glenn: We're defining sematnics for what is breakpoint or not. Is this
          meant to be normative to all scenarios, or just in the absence of
          a higher-level protocol.
   florianr: The intent is that any breaking algorithm can pick between the
             breaking points we define.  It can choose any of them, but it
             shouldn't break at anywhere that doesn't produce a breaking point.
   TabAtkins: For example, a more advanced mechanism that does hyphenation by
              finding more breakpoints inside of words.
   glenn: I ask because languages like Thai uses a dictionary to determine
          breakpoints.
   fantasai: I suggest you read the section on line-breaking, because it
             covers all this.
   RESOLVED: Breaks are allowed wherever there was a breakpoint, even if
             it was collapsed away.
   <glenn> CSS3 Text §4 answers my question "CSS does not fully define where
           line breaking opportunities occur"


currentColor and inheritance in text-emphasis
---------------------------------------------

   http://lists.w3.org/Archives/Public/www-style/2012Jan/0521.html
   fantasai: The problem is that currentColor *computes* to the color value,
             then inherits as that color.
   fantasai: We need one that turns into the color at used value time.
   fantasai: text-emphasis-color takes a color.  By default, they should take
             the color of the text.
   fantasai: Right now, you compute the color on the root element of the
             document, then use that throughout the document.
   dbaron: So it sounds like we want a new value.
   fantasai: Yes, but there are other places where we may want this behavior -
             text-shadow is one such case.
   TabAtkins: Small issue - because computed value is used for multiple things,
              if it stays as the keyword in computed value, it won't transition.
   dbaron: I'd have to look into it, but I think this would be quite a bit more
           work to implement for text-shadow than for text-emphasis-color.
   fantasai: You already implement it for text-shadow.
   dbaron: We implement currentColor, but not the thing that has to inherit
           not as a color.
   fantasai: That's not true - you do implement it.  Testcase coming.
   <fantasai> 
http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Cstyle%3E%0Abody%20{%20text-shadow%3A%200%200%204px%3B%20}%0A%3C%2Fstyle%3E%0A%0ASOME%20TEXT%20%3Cem%20style%3D%22color%3A%20red%22%3EMore%20text%3C%2Fem%3E%0A
   dbaron: It's the "no-color" case.  It's not defined, but everyone uses
           this behavior.
   plinss: So we just need a keyword for this behavior.
   <fantasai> current-color ? :)
   <tantek> stayCurrentColor
   <tantek> ;)
   <nimbu> :)))
   <tantek> elementColor

   Bert: Too late to change currentColor?
   TabAtkins: Given the small usage of currentColor, we probably could.
   fantasai: And basically no sane person inherits, say, a border-color.
   fantasai: (QA persons excepted)
   <dbaron> I think Gecko's implementation of the default border-color and
            outline-color actually works this way rather than the way
            currentColor works
   dbaron: In FF, we actually implement border-color and outline-color in
           this way, because it's cheaper than the actual implementation
           for currentColor.
   <tantek> remember, we got the term 'currentColor' from SVG
   <tantek> so if they're dependent on a specific interpretation...
   <tantek> otherwise we would have called it 'current-color'
   fantasai^: If we want to redefine currentColor
   fantasai: We should check with SVG on this.
   * tantek dislikes camelCase
   plinss: Is there any use-case for the current currentColor behavior?
           Would we lose anything from it?
   TabAtkins: I can take this to SVG and see what they say.
   ACTION TabAtkins: Ask SVG about currentColor's computing behavior
Received on Saturday, 21 January 2012 01:10:48 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:20:48 GMT