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

[CSSWG] Minutes Tokyo F2F 2013-06-06 Fri PM II: Backporting Changes, Text Decoration, Table Cell Stacking Contexts

From: fantasai <fantasai.lists@inkedblade.net>
Date: Tue, 02 Jul 2013 22:56:37 -0700
Message-ID: <51D3BD15.7080600@inkedblade.net>
To: "www-style@w3.org" <www-style@w3.org>
Backporting Changes

   Principle: A change to L3 spec that would make all 2.1-compliant UAs
              incompliant needs to be backported.

   Note: If it would break content, we shouldn't be making the change.

Text Decoration

   RESOLVED: Text decoration doesn't consider descendant content for
             line thickness or positioning.

   Discussed text-underline-position: alphabetic and auto.

Pseudo-stacking Contexts

   RESOLVED: table cells do create pseudo stacking-contexts (as resolved
             before) but borders and backgrounds (of the cell or its ancestors)
             are not in that pseudo stacking-context

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

Backporting Level 3 Changes to CSS 2.1

   fantasai: My principle is that a change to L3 spec that would make a
             2.1-compliant UA incompliant, that change needs to be backported.
   fantasai:  A L3 client should also be L2 client.
   dbaron: Slight modification: if the change would make _all_ 2.1 clients
   TabAtkins: If there is an error in 2.1 fixed in 3, then should backport.
   fantasai: Level 3 can tighten definitions, but *changes* should be backported

   dbaron: If it would break content, we shouldn't be making the change.

   SimonSapin: When do we stop fixing CSS 2.1?
   fantasai: When the spec has been completely superseded.
   plinss: When a module has replaced parts of it?
   TabAtkins: No, when it's completely replaced.
   fantasai: An L3 spec will replace parts of CSS 2.1
   SimonSapin: Can we deprecate parts of 2.1?
   fantasai: We tend to find issues in sections that haven't been rewritten,
             so I don't worry about it. If they've been rewritten, then
             we've found the inconsistencies.

   plinss: Does everyone agree to that proposal?
   TabAtkins: Might not be worth it always, like every syntax change,
              but as a general principle, yes
   fantasai: Syntax may actually be the most important.
   TabAtkins: They're just really hard to get right.

   SimonSapin: We should be able to deprecate one chapter.
   glazou: What will be the result? 2.1 rev 2, or 2.2?
   dbaron: 2.2 eventually, but not as much effort as 2.1.
   glazou: People should be able to refer to 2.1
   liam: small changes -> 2nd edition.
   dbaron, liam: could be confusing.
   Bert: Pick some time in the future, then bundle and publish errata
   SimonSapin: What's the conclusion?
   fantasai, glazou: As outlined above.
   Bert: We should pick a date
   fantasai: We already picked this F2F.
   Bert: Assign someone to follow-up?
   Bert: I have some other publications to do after the summer. Can follow
         it up October or after.
   glazou: Let's decide later.

Text Decoration

   <fantasai> http://dev.w3.org/csswg/css-text-decor-3/issues-lc-2013
   fantasai: Main issue: Position of underlines if you have an entire
             paragraph underlined
   fantasai: Where should the underline be placed?
   fantasai draws on whiteboard: big and small text within an element
   fantasai: Do we use the ancestor's underline? 2.1 leaves this undefined.
   fantasai: Rossen posted a TC where if each line has different sizes,
             they get different sizes
   dbaron: That's contrary to the 2.1 model.
   fantasai: We want to have one line.

   <fantasai> http://jsfiddle.net/4sC2T/1/
   fantasai: for web compat, we probably need to stick with that behavior.
   dbaron: In Gecko, the underline is constant thickness.
   dbaron: and position
   dbaron: There were a bunch of tradeoffs in implementing 2.1
   dbaron: We got rid of quirks mode in text decoration
   dbaron: There was a quirk that wasn't compatible enough with 2.1
   dbaron: We came up with a new, unitary model for decorations.
   dbaron: One of the important requirements: Not do ransom-note style
   dbaron: if it crossed multiple pieces of text, you got a single underline.
   dbaron: The underline comes from the element with the text-decoration
   dbaron: The spec implied that the position and thickness come from that
   dbaron: The 2.1 spec has one part where we disagreed about the grammar.

   jdaggett: What about vertical-align variations?
   dbaron: In 2.1 the underline is generated by the element with the
           text-decoration property. The various properties of the underline
           come from that.
   dbaron: So superscript and subscript come from that.
   dbaron: But there was a quirk.
   dbaron: so be careful.
   * plh notes that IE and Opera behaves one way, and Firefox and Chrome
         behaves differently

   dbaron: fantasai's proposing that we switch to a model where we don't
           just use info from that model, but also its descendents.
   dbaron: The union of them and all their fonts.
   dbaron: Problematic because it's hard to implement and is slow
   dbaron: and it breaks a number of invariants authors don't realize they
           depend on.
   dbaron: Authors would be surprised if they have six things underlined,
           and one of the them is subscripted, and behavior changes.
   fantasai: They'd also be surprised when underline goes through subscript.
   dbaron: Yes, one author problem is fixed, another is caused.

   <fantasai> Previous discussion on exactly this topic:

   Bert: One solution that we discussed about crossing the subscript is to
         interrupt the underline.
   dbaron: The text-decoration model has a property to allow that.
   r12a: isn't another solution to put a text-decor property on the subscript
   dbaron: That needs canceling out
   fantasai: Deferred to level 4
   dbaron: Some people say text-decor feels like an inherited property, but
           it's not, to allow even baseline and thickness for entire element.

   dbaron: I feel like this change would add a lot of complexity to fix one
           problem and cause another.
   fantasai: We discussed this last year.
   fantasai: Aryeh sent feedback that big text in strikethrough, the big text
             isn't struck through
   fantasai: That resulted in the current text.
   dbaron: I didn't understand it sufficiently at the time.
   dbaron: I would not have agreed to averaging over descendants.
   fantasai: So how can we solve both problems at once?
   dbaron: We don't have a reasonable solution yet. We should stick with the
           existing model.
   fantasai: Then I have to tell Aryeh that we're reverting the fix for his
   dbaron: We can't fix everything.
   dbaron: And I really don't want to rewrite our text-decoration code every
           two years.
   RESOLVED: Revert the change to text-decoration behavior.
   fantasai: Actually, this was a clarification, not a change, and we don't
             want to go back, we want something completely different.

   glazou: Other text-decoration issues?
   Bert: We're already in LC, we will have another one.

   liam: If I take the obscure big-text example, and I add an underline in
         the middle of the big text, it gets its own, thicker underline?
   fantasai: If you put a span in there, it gets a suitable underline.
   liam: Lots of test cases needed here!
   dbaron: If you specify three underlines on three elements, you should
           get three, even if they might cover each other up
   <liam> [ http://jsfiddle.net/Xfb9v/3/ - example ]

Pseudo-stacking Contexts

   dbaron: At some point we discussed whether flex items should be psc,
           and we decided that they should
   dbaron: but table cells should be too.
   dbaron: But then: table backgrounds and borders are complicated
   dbaron: should they be included in the psc?
   dbaron: Four issues with table backgrounds and borders:
   dbaron: backgrounds versus borders
   dbaron: separated vs. collapsed
   dbaron: Okay with different answers for those
   dbaron: But don't want different answers for backgrounds for separated
           vs. collapsed

   dbaron: If we look at appendix E of 2.1
   dbaron: Table background painting is already described as part of the
           z-order in 2.1
   dbaron quotes the spec
   dbaron: Table through cell are painted in the backgrounds layer
   dbaron: That says that if table cells establish a PSC, that even cell
           backgrounds are not inside it
   dbaron: Because painting them is associated with the table
   dbaron: At this point I've already explicitly disagreed with fantasai
           and TabAtkins
   dbaron: But I'm against changing any of this.
   dbaron: table borders are also painted in this layer.
   dbaron: This is a bit ambiguous
   dbaron: If we don't change it, then all we need to do is decide that
           tables form SC
   dbaron: and cells are not part of that SC

   fantasai: If we transform a table cell with backgrounds and borders,
             what do I get?
   dbaron: the interesting part: do borders and backgrounds even move?
   dbaron: in the collapsed model, shouldn't move.
   fantasai: In some impls, if you set a transform, the background paints
             on top of the border.
   dbaron: A bug.
   dbaron: and poorly tested
   fantasai: Probably all the implementations.
   dbaron: I'm ok with cells being PSCs
   dbaron: if it means that the PSC doesn't include the border and background
   dbaron: Need a lot more work to define paint order inside cells.
   dbaron: Are people ok with what cells being PSCs means?
   dbaron: if so, just resolve.
   TabAtkins agrees.
   RESOLVED: table cells do create pseudo stacking-contexts (as resolved
             before) but borders and backgrounds (of the cell or its ancestors)
             are not in that pseudo stacking-context


   jdaggett: When we publish a new spec, since the TR URL changes,
             do we need permission from plh?
   plh: yes
   jdaggett: can we get css3-fonts changed to css-fonts-3?
   fantasai: Was going to do it all at once but can do it piecemeal
   plh: I agree with the change
   plh: All specs should be consistent
   Bert: But will be hard to find old mailing-list messages
   plinss: It's already been resolved.

Text decoration

   one more issue
   <koji> http://lists.w3.org/Archives/Public/www-style/2013May/0159.html
   fantasai: text-underline-position: alphabetic
   fantasai: says use font metrics
   fantasai: is that reasonable?
   jdaggett: Sounds like existing behavior.
   dbaron: Part of the question is what the underlining metrics in CJK fonts
           look like
   dbaron: Ideographic baseline?
   jdaggett: have to look it up
   dbaron: What is existing behavior?
   fantasai: auto behavior says to do whatever you want, but don't cross
             through glyphs that shouldn't be crossed
   jdaggett: We have a blacklist of fonts in Gecko, where we modify the
             underline if it's in the blacklist.
   jdaggett: That is more that the underline metrics are not in line with
             the font
   fantasai: It's suggested that auto should do the right thing for the text,
             in cases like CJK.

   jdaggett: My concern: different fonts on the line, would the underline vary?
   fantasai: No, would pick one position for the underline.
   fantasai: Currently pick the lowest alphabetic position, but dbaron said
             we shouldn't do that. That gives interesting results if not

   dbaron: The spec has two values, with auto the initial value.
   dbaron: not clear to me how auto matches current behavior or how
           implementable alphabetic is.
   dbaron: also how useful alphabetic was
   jdaggett: I got an e-mail about this…
   jdaggett: Not clear to me what you mean by 'alphabetic'. Are you trying
             to override the font metrics?
   jdaggett: Are you basing it on the baseline?
   fantasai: Expectation that font specifies the position relative to the
   fantasai: You might want to instead underline the bottom, accounting
   jdaggett: You use the metrics to infer where the underline would be
             relative to the baseline?
   fantasai: yes
   jdaggett: What happens to implementations?
   dbaron: Depends on how well 'auto' match implementations and how hard
           to implement alphabetic.
   ACTION jdaggett to investigate those two questions
   <trackbot> Created ACTION-564
Received on Wednesday, 3 July 2013 05:57:05 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:39:12 UTC