- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Tue, 02 Jul 2013 22:56:37 -0700
- 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
non-compliant.
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
underlining
dbaron: if it crossed multiple pieces of text, you got a single underline.
dbaron: The underline comes from the element with the text-decoration
property.
dbaron: The spec implied that the position and thickness come from that
element.
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:
http://lists.w3.org/Archives/Public/www-style/2012Nov/0129.html
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
problem.
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
Shortnames
----------
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
baseline-aligned.
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
baseline
fantasai: You might want to instead underline the bottom, accounting
underline…
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