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

[CSSWG] Minutes and Resolutions 2012-08-15 Wed AM II: Fonts, Text

From: fantasai <fantasai.lists@inkedblade.net>
Date: Wed, 29 Aug 2012 19:19:23 -0700
Message-ID: <503ECDAB.8040806@inkedblade.net>
To: "www-style@w3.org" <www-style@w3.org>
Fonts
-----

  - RESOLVED: Accept font-variant-ligatures as written: "normal" is initial
              value, and "none" is added which turns off those features.
  - RESOLVED: Publish a new WD of Fonts.

Text
----

  - RESOLVED: make word-wrap shorthand for overflow-wrap

  - RESOLVED: text-shadow on an element applies to decorations imposed by its
              ancestors, because it is what is most widely implemented now.

  - RESOLVED: blink is value of text-decoration-line and it is deprecated
              with warning that authors should not use it.
  - RESOLVED: add example of implementing <blink> with animations in the UA
              style sheet appendix

  - Need examples for 'text-justify' showing differences among values

  - RESOLVED: split text-decoration into separate module.

  - RESOLVED: Add a new value to text-decoration-skip controlling whether
              decorations are drawn through the padding/border/margin of
              display:inline elements.  This new value is not part of the
              initial value and therefore (change from CSS 2.1) decorations
              imposed by ancestors are drawn through an inline element's
              padding/border/margin by default.

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

Fonts
-----

   <dbaron> http://people.mozilla.org/~jdaggett/tests/simplekerningligs.html
   jdaggett: I wanted to talk about default font features.
   jdaggett: We talked about it a bit on the call.
   jdaggett: People seemed comfortable, but there were some concerns from
             MS developers.
   jdaggett: So we'll quickly review.
   jdaggett: [shows demo]
   jdaggett: This is showing raw text with no kerning or ligatures, and the
             second line is FF default, with ligatures and kerning.
   florian: The default is influence by data coming from the font?
   jdaggett: No, there is a set of features that are declared as "default"
             in the OT spec.
   jdaggett: Because FF is turning these on by default, the fourth line and
             the second line match.
   jdaggett: However, if we go over to Chrome, the default case is different
             from the random-feature case.
   jdaggett: The internal reason for this is that there's a different rendering
             path with different defaults.
   jdaggett: I'm saying that the default case should be the same as the
             random-feature case.
   jdaggett: So that turning on a random feature shouldn't also turn on random
             other features.

   jdaggett: [shows comparative screenshot]
   jdaggett: What this shows is language-sensitive features.
   jdaggett: In turkish there is a dotted and dotless i.  So when you do
             small caps, you need to put a dot on the i to be correct.
   jdaggett: This is specified with a language tag. This gets sent down to
             the font engine, and that handles things correctly.
   jdaggett: In IE10, this works correctly, but it's not yet implemented in
             webkit.
   jdaggett: But language-sensitive behavior in IE10 isn't on by default
   jdaggett: In serbian, this glyph should be a localized alternate.
   jdaggett: But if you turn on a random feature, FF gives you the same thing,
             but in IE10 all of a sudden the localized feature appears.
   glenn: So the algorithm used by the UA to enable the OT advanced tables
          is different in different browsers.
   jdaggett: Yes, but I'm saying there shouldn't be side-effects from random
             features.
   florian: So either everyone should match FF and keep the default features
            on, or they shouldn't turn on the default at all unless they're
            explicitly asked for.

   sylvaing: (2) when you do ask for a specific font feature, do you get
             just that, or do other things pop up?
   jdaggett: If we go to the OT spec...
   jdaggett: It's a bit scattered.
   jdaggett: These are the default features, across scripts.
   jdaggett: Some specific scripts have extra features by default.
   <dbaron> http://people.mozilla.org/~jdaggett/tests/default-feature-list.html
   jdaggett: [describes the table]
   <dbaron> http://people.mozilla.org/~jdaggett/tests/simpleccmptest.html
   jdaggett: [shows tone marks using one of the default OT features]
   jdaggett: This works in Chrome too, which shows that though they're not
             enabling the features by default, they have some logic that is
             turning on this feature when these characters are used in content

   sylvaing: Do you have a ref to the OT spec?
   jdaggett: In CSS3 Fonts, section 7, there are several links in the text.
   szilles: Which spec? ISO or MS?
   jdaggett: Loosely-defined.
   jdaggett: The ISO version of the OpenType spec is a file-format spec -
             it doesn't cover layout.
   jdaggett: So we have to be a bit looser about what we consider "the spec".
   <glenn> http://www.microsoft.com/typography/otspec/
   jdaggett: Hopefully they'll be more rigorous in the future.
   <glenn> ISO/IEC 14496-22 "Open Font Format" standard. The standard was
           published in 2007, and is now freely available for download from
           ITTF website. OpenType version 1.6 is identical to the
           "Final Draft International Standard" version of ISO/IEC 14496-22
           FDIS "Open Font Format" (second edition).
   <glenn> http://www.microsoft.com/typography/otspec/featuretags.htm

   sylvaing: Our default rendering is consistent across the windows platform
   jdaggett: So if you could review this list and suggest changes, would be
             great.
   jdaggett: I think we're covered here.
   florian: If I'm following you right, there are three ways of doing this.
   florian: One is the Chrome/MS way, which is not ideal.
   florian: Another is the Firefox, which may require an extra switch.
   jdaggett: Let me finish.
   jdaggett: The features in the list in red are those which can be controlled.
   jdaggett: ...via font-variant-ligatures.
   jdaggett: I've put in a "none" value to font-variant-ligatures which
             turns off all defaults for the features controlled by
             font-variant-ligatures.
   jdaggett: That will not disable the required features.
   jdaggett: These are usually specialized features that are *needed* for
             correct rendering of various things.
   glenn: How would someone shut down the rlig feature?
   jdaggett: font-feature-settings: rlig 0;.  It's possible.
   jdaggett: I was going to put in an example of how to turn off all default
             features but that seems like it could be abused
   jdaggett: I think an example showing isolated characters in Arabic would
             be a good example with a clear use-case
   jdaggett: There are some performance considerations.
   jdaggett: As the glyph composition shows, some of these are already
             handled in an ad-hoc way.

   jdaggett: Most fonts, you can do a simple analysis and do a fast path
             if the font doesn't have a feature at all.
   jdaggett: It just means there's a little additional logic before taking
             the fast path.
   jdaggett: So I think we should resolve that the "none" value resolves
             the issue.
   Bert: Is "none" the same as setting "no-*" for all the others?
   jdaggett: Yes.
   sylvaing: What about an "auto" value that is a default?
   jdaggett: I'm keeping "normal" as the default.
   jdaggett: kerning has "auto", because that's more prevalent and can be
             controlled by browser vendors.
   RESOLVED: Accept font-variant-ligatures as written: "normal" is initial
             value, and "none" is added which turns off those features.
   plinss: My only concern is that "normal" seems underdefined.
   jdaggett: There's a section that defines the common defaults.
   glenn: Could you put a link from "common defaults" to its defining section?
   jdaggett: Oh, sure.
   plinss: The reason you're not explicitly saying "'normal' means foo and bar"
           is because it varies on font engine and script?
   jdaggett: Yes.
   RESOLVED: Publish a new WD of Fonts.

<br dur=15min>

CSS3 Text
---------

   <fantasai> http://www.w3.org/Style/CSS/Tracker/products/10

   <fantasai> http://www.w3.org/Style/CSS/Tracker/issues/236
   fantasai: We resolved to postpone to level 4, but now we have a shorthand idea.
   tab: sounds useful, now we have a useful way to address aliasing.
   florian: I'd agree
   fantasai: So resolve that word-wrap is shorthand for overflow-wrap?
   RESOLVED: make word-wrap shorthand for overflow-wrap

   <trackbot> ISSUE-221 -- text-emphasis-color can't recompute color to match
              text on descendants -- raised
   <trackbot> http://www.w3.org/Style/CSS/Tracker/issues/221
   fantasai: there is an errata open, should be posted to css3-color
   <tantek> http://www.w3.org/Style/2011/REC-css3-color-20110607-errata.html
   action bert: add errata to css3-color errata ist about currentcolor,
                (as in above URL)
   <trackbot> Created ACTION-502
   <dbaron> record of currentColor errata is in
            http://lists.w3.org/Archives/Public/www-style/2012May/0541.html

   <trackbot> ISSUE-243 -- graphical effects and text-decoration -- raised
   <trackbot> http://www.w3.org/Style/CSS/Tracker/issues/243
   fantasai: issue with underline and shadow and all these kinds of things
   fantasai: if you have an ancestor,
   fantasai: say whole para is underlined and a text has shadow, etc.
   fantasai: is the underline shadowed?
   SteveZ: Is the underline logically part of the para even if physically it is not?
   fantasai: How about visibility?
   SteveZ: If not visible, also not underlined, I think.
   dbaron: Decoration is associated with the text.
   dbaron: text decoration gets colors from element it comes from.
   fantasai: if invisible, definitely not visible.
   dbaron: You mean opacity?
   fantasai: yes
   dbaron: opacity happens all at once.
   dbaron: I can't imagine another option
   dbaron: opacity on ancestor applies to all descendants.
   fantasai: Then remaining question is filter effects (same way?) and text-shadow,
   tab: filter efect is same yes
   fantasai: part of underline could be shadowed and part not, looks weird.
   SteveZ: looks weird either way you nest them
   fantasai: [draws on white board]
   dbaron: three cases:
   dbaron: shadow on something inside decorated element, on same element,
           on ancestor of element
   dbaron: debate is on inside case
   SteveZ: For emphasis, I think the underline should get shadowed
   fantasai: [draws text with underline, part of it get shadow]
   fantasai: does underline get shadow?
   TabAtkins: I think so. Some case look weird, but bulk is ok.
   dbaron: I have diff. intuition
   <fantasai> http://lists.w3.org/Archives/Public/www-style/2012Jan/att-0265/underline-shadow.png
   sylvaing: ie does shadow the underline
   sylvain: so the test case is para is underlined, and a part of it has shadow?
   fantasai: yes
   sylvaing: webkit shadows the underline, ff also,
   dbaron: what is your test case, sylvaing ?
   <sylvaing> <!doctype html>
   <sylvaing> <style>
   <sylvaing> 	p {
   <sylvaing> 		text-decoration: underline;
   <sylvaing> 	}
   <sylvaing> 	#test {
   <sylvaing> 		text-shadow: 0.1em 0.1em #333;
   <sylvaing> 	}
   <sylvaing> </style>
   <sylvaing> <p>This is <span id="test">underlined</span></p>
   sylvaing: [trying to copy his test case]
   SteveZ: it makes more sense with shadow below than with above.
   sylvaing: looks like opera doesn't shadow the underline
   dbaron: Not sure we could do anything other than what we do. Wonder how
           Opera is able to.
   dbaron: text-shadow is inherited.
   dbaron: we don't even know what is outside or inside
   fantasai: But you do know for underline.
   florian: We don't shadow the underline either way.
   bert: in fantasai's drawing i think without shadow looks better...
   dbaron: To implement, you'd redo your text decoration...
   fantasai: Basically you do your shadow finding the same way as for color
   fantasai: So it is possible to implement, what do we want?
   fantasai: if we decide it is not shadowed, users can still apply a filter
             effect to get a shadow.
   fantasai: It is not  a very common case.
   sylvaing: We have interop between 3 browsers out of 4 i tested.
   SteveZ: General underline rule covers position and color.
   SteveZ: We'd like it to behave the same way.
   SteveZ: Filter effects should apply, we said.
   SteveZ: Authors would be surprised if shadow was absent.
   tab: I don't care that much, lets go with [??]
   plinss: biased towards finding shadow the same way as the color.
   plinss: decoration visually belongs to parent,
   plinss: slight bias.
   SteveZ: So doesn't matter much now, and once it does, we'll put in a
           property to control it.
   plinss: I'm never quite sure how it should behave,
   SteveZ: It's certainly one of the most complex definitions.
   dbaron: inclined to agree with Brad about lower one [no shadow] being
           better.
   SteveZ: I think it depends on the shadow. This shadow is above. Below
           would look less strange.
   plinss: the letter is different color, undelrine visually doesn't belong
           to that text.
   fantasai: I'll look strange no matter what.
   sylvaing: is there a use case where it is a bad thing what browsers do now?
   dbaron: I think i prefer to go the other way, more consistent with the model.
   SteveZ: Despite that filters apply?
   dbaron: Different kinds of things.
   TabAtkins: They just apply to the pixels.
   <dbaron> more consistent with the model and with most of the people who
            expressed an opinion about which is better
   SteveZ: How would the user see the difference whether it is pixel based
           or not?
   sylvaing: Without a use case showing it is clearly wrong, I'd not like
             to change.
   Straw poll on
     http://lists.w3.org/Archives/Public/www-style/2012Jan/att-0265/underline-shadow.png
   glazou: bottom
   sylvaing: top
   Bert: bottom
   koji: top
   SteveZ: top
   glenn: top
   ted: top
   alan: top
   fantasai: abstain
   tantek: abstain
   TabAtkins: top
   dbaron: bottom
   florian: bottom
   leif: bottom
   peter: bottom
   glazou: NO CONSENSUS
   fantasai: How about a public poll?
   sylvaing: Does anybody object to what is already done?
   florian: That would be ok, even if it is against what i prefer.
   dbaron: yep
   RESOLVED: apply shadow, because it is what is most widely implemented now.

   <trackbot> ISSUE-273 -- Interaction of text-decoration longhands and blink -- raised
   <trackbot> http://www.w3.org/Style/CSS/Tracker/issues/273
   fantasai: issue is that text-decoration takes a number of values,
             including blink.
   fantasai: we don't have longhand for blink.
   fantasai: we can make 'blink' a valid value in one of the long hand
             properties.
   fantasai: or we can make a blink property
   fantasai: or we can parse it and throw it away in the DOM
   [jokes about blink]
   fantasai: Could be a text-decoration-style
   TabAtkins: I'm using animation instead of blink
   glazou: [shows his home page with blinking underline]
   dbaron: most browsers haven't implemented blink.
   dbaron: not in webkit and IE.
   Tab: <blink> can be implemented as an animation
   glazou: I don't like special cases. so not fantasai's last option.
   dbaron: We added an additional peroperty -moz-tex-blink to solve this issue.
   glazou: i like that one.
   dbaron: It is an extra property for a feature we might rather remove.
   fantasai: Prefer to not create new property, seems excessive.
   fantasai: prefer to put in on text-decoration-style.
   TabAtkins: Prefer to ignore the blink on the shorthand, parse it, but
              doesn't do anything.
   fantasai: not even store it?
   tab: right, doesn't round trip, only round trips functionally.
   dbaron: it is not backwards-incompatible to put it on anything else than
           text-decoration-style.
   <dbaron> it looks like we still accept 'text-decoration: underline blink overline'
   dbaron: in fact, current spec seems not backwards compatible.
   glazou: do not want to deprecate it.
   TabAtkins: But only two impls, so why not deprecate it?
   plinss: We have two impls.
   <dbaron> We haven't yet implemented the backwards-incompatible change
            that's in the spec
   tantek: deprecate doesn't mean remove.
   plinss: But still needs to be defined, even if deprecated.
   plinss: can you say 'underline red overline'
   dbaron: Not according to spec, and don't thing you should be able to
   plinss: and 'underline solid overline'?
   fantasai: Seems odd ordering.
   fantasai: Inclined to say no.
   dbaron: Easiest path forward is to make 'blink' value of text-decoration-line
   dbaron: the way we make the shorthand is  bit weird.
   dbaron: because one of the longhands is the old property.
   dbaron: We could just have added the new properties
   dbaron: we moved text-decoration functionality.
   dbaron: blink is funny since CSS1.
   [talk about history of netscape]
   florian: Opera has implemented it. I'm not strongly asking for deprecation,
            but in favor of deprecation.
   glazou: If we're going to deprecate it, should have an example explaining
           how to do it with animations.
   SteveZ: You don't really want people to use blink for accessibility reasons.
   fantasai: We can map BLINK tag to animation in user agent style sheet.
   plinss: resolve to put blink on txt-decoration-line and deprecate it?
   florian: so: should not, but are allowed to use blink?
   plinss: it is a warning that it *may* be removed from spec later.
   RESOLVED: blink is value of text-decoration-line and it is deprecated
             with warning that authors should not use it.
   RESOLVED: add example of corresponding animation in the UA style sheet appendix

   <jdaggett> http://people.mozilla.org/~jdaggett/tests/letter-spacing-tests.html
   jdaggett: I did some tests.
   jdaggett: Checking interopreability.
   jdaggett: letter spacing should control spacing on either side of char,
             but should not affect last letter (if right aligned line)
   jdaggett: [shows image]
   jdaggett: But implementations add spacing after last letter.
   jdaggett: [shows another image]
   jdaggett: This image shows fully justified.
   <fantasai> http://dev.w3.org/csswg/css3-text/#letter-spacing
   <fantasai> "Letter-spacing must not be applied at the beginning or
               at the end of a line."
   fantasai: The spec already says what UAs must do.
   jdaggett: It doesn't say *how* spacing is applied.
   jdaggett: at the end of the line you should not get space.
   fantasai: Yes, that is a bug according to the current spec.
   jdaggett: But the spec doesn't say exactly that
   dbaron: the spec is precise, but you are describing a different model,
           equally precise, but different at element boundaries.
   jdaggett: I think you actually have to get into how it works, e.g., in rtl.
   fantasai/dbaron: What impls do is already bug, according to current spec.
   jdaggett: I don't see that text.
   jdaggett: What fantasai quoted is not precise enough.
   fantasai: Give me an example that is not covered by the spec, and we'll
             improve the spec.
   jdaggett: and between ltr trl boundaries?
   fantasai: It is still "between chars" as the spec says.
   SteveZ: Half on each side, and you can't tell the difference.
   fantasai: You can do it as trailing edge internally, but you still have
             to handle the boundaries correctly.
   jdaggett: I'll have to look more.

   jdaggett: I started from looking into justification.
   jdaggett: letter and word spacing is input to justify.
   jdaggett: allowed to expand in different places.
   jdaggett: but the actual algo wasn't clear form the spec, for different
             values.
   jdaggett: Each diff value of text-justify,
   florian: I have a similar concern:
   florian: reading the spec, good algos can be done, but spec doesn't tell
            you how.
   florian: the spec doesn't induce vendors to implement those algos
   SteveZ: It is modeled on systems from well before XSL.
   jdaggett: Now we are designing knobs with semi-undefined justification
             systems.
   jdaggett: how these inputs are used, i don't see differences between
             justify values.
   fantasai: It defines prioritization buckets.
   fantasai: It sorts the expansion opportunities into buckets.
   fantasai: It doesn't tell you the algo precisely.
   fantasai: It is not our job to define the algo.
   jdaggett: That's the pb, Knobs have no precise meaning.
   alan: not undefined, maybe underspecified.
   florian: Intentionally, i think. Don't prevent better algos.
   jdaggett: But we need a mininmum.
   jdaggett: I don't understand the use cases for the different justify values.
   jdaggett: What are the examples.
   jdaggett: I don't see a whole lot of difference in trying them.
   jdaggett: It seems to have been modeled on IE 5.5.
   jdaggett:  Not clear where the difference are.
   jdaggett:  What are the use cases, maybe sylvain can tell?
   jdaggett:  Are the cases till relevant?
   sylvaing: You want to deprecate some?
   jdaggett: Spec is just too vague.
   fantasai: table in spec shows the differences.
   florian: Don't agree. It seems most of these are needed for
            internationaliztion.
   fantasai: One case is mixed scripts on one line.
   fantasai: Inter-word will expand the spaces and nothing else.
   fantasai: ideograph expands between ideographs.
   fantasai: distribute expands both.
   florian: Different countries have different expectation.
   jdaggett: Do we have collected the examples?
   florian: With this spec we can impl an algo that matches the spec.
   florian: But that algo may still not be very good.
   florian: A bad algo can still be conformant.
   fantasai: We cannot define all algos. That's more than a PhD research.
   fantasai: Could spend your whole life researching justification algos
             for the world.
   jdaggett: All I ask is some simple use cases.
   jdaggett: why is it important to have these property values?
   fantasai: You want pictures?
   jdaggett: Conncrete examples.
   jdaggett: Is there enough info in the spec to say if an impl matches?
   jdaggett: Not saying we should deprecate. But I don't see the difference
             when trying them out.
   florian: I'm not sure I'm asking for more specific. That might lock
           into bad algo.
   florian: But I'm generally unhappy.
   florian: Not sure if more defined makes me happier.
   SteveZ: Document what the differences are is one thing
   jdaggett: Spec should at least have rudimentary examples.
   SteveZ: You say we should take things out *until* we can provide examples?
   jdaggett: Posting to www-style is OK, too.
   jdaggett: Would like to ask sylvaing to find where it comes from.
   jdaggett: No doubt came from cases in MS Office.
   jdaggett: can we get more info?
   jdaggett: The description by MS is "this is good for Thai"
   jdaggett: But why is it good?
   fantasai: So you want examples in the spec. I'll take an action.
   sylvaing: And I one to find out about IE5

   jdaggett: We are trying to break it down by script. That is not the
             ideal way.
   jdaggett: Kashida is an example.
   jdaggett: Could apply to cursive in general.
   jdaggett: Even if it is not currently used for latin.
   SteveZ: Swash characters?
   SteveZ They can go across words.
   jdaggett: They extend?
   SteveZ: yes
   jdaggett: This is about elongating.
   ACTION fantasai: put examples of text-justify in the spec.
   <trackbot> Created ACTION-503
   ACTION sylvaing: look into history of text-justify in IE 5+
   <trackbot> Created ACTION-504

   <trackbot> ISSUE-276 -- Split Text Decoration into separate module? -- raised
   <trackbot> http://www.w3.org/Style/CSS/Tracker/issues/276
   jdaggett: Why needed to split?
   fantasai: module is very long.
   fantasai: text-deco no interaction with anything else in spec.
   florian: Useful if that makes things faster. Does it here?
   fantasai: Don't think so now. Maybe future levels may be different.
   fantasai: Table of contents makes more sense if we split
   florian: Somewhat helpful for prioritizing.
   florian: Smaller spec easier.
   jdaggett: I think the spec needs to be smaller. Take things to level 4.
   jdaggett: This spec should be considered for what is specified or not
             and push things out accordingly.
   jdaggett: Don't think text-decoration needs its own spec.
   SteveZ: But splitting makes it easier.
   tantek: Agree.
   florian: I'm happy with split if editors want it and take on editing both.
   jdaggett: *AND* not new features in either part.
   fantasai: Agreed. No new features planned. Just splitting.
   fantasai: But we need to talk about one issue next.
   RESOLVED: split text-decoration into separate module.

   bert: it is so hard to find in which spec a prop is defined.
   <lstorset> Handy CSS property index for split specs:
              http://meiert.com/en/indices/css-properties/
   tantek: That is a global problem. Needs to be fixed.
   glenn: snapshot?
   fantasai: snapshot doesn't incude anything below CR.

   <trackbot> ISSUE-270 -- text-decoration-skip value for border/padding/margin -- raised
   <trackbot> http://www.w3.org/Style/CSS/Tracker/issues/270
   <fantasai> 
http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Cstyle%3E%0Ap%20{%20font-size%3A%203em%3B%20text-decoration%3A%20line-through%20}%0Aa%20{%20xpadding%3A%200.2em%3B%20}%0Aa%3Ahover%20{%20background%3A%20yellow%3B%20}%0A%3C%2Fstyle%3E%0A%3Cp%3Eone%20%3Ca%3Etwo%3C%2Fa%3E%20%3Ca%3Ethree%3C%2Fa%3E%20%3Ca%3Efour%3C%2Fa%3E%20%3Ca%3Efive%3C%2Fa%3E%20six
   fantasai: [explains example above]
   fantasai: Here is an example of a bunch of links. The author decided to
             color them on :hover
   fantasai: To make it look good, adds padding.
   fantasai: Now the strike through is fragmented.
   fantasai: looks really bad.
   dbaron: We discussed text-decoration models a lot.
   dbaron: We came up with one. Took many years to get it implemented.
   dbaron: FF implemented it. Now you say we don't want that model.
   fantasai: This came up with editor's names on drafts.
   fantasai: I added padding around the links.
   fantasai: That broke strike through.
   fantasai: Any kind of padding on inline elements will break text-decoration
   alan: padding is not content, text-decoration should not apply.
   glazou: Say in an editor I select a paragraph, and it has modification
           marks, highlighted with line through.
   fantasai: But the para is a block.
   fantasai: Issue is if ancestor is striking through inline elements.
   dbaron: Proposal?
   fantasai: I propose keyword 'box-decoration' for 'text-decoration-skip'
   dbaron: On inline elements only?
   fantasai: Yes.
   <dbaron> (display:inline, not inline-block, etc.)
   fantasai: If text-deco is applied by ancestor
   fantasai: then is is applied from margin edge to margin edge.
   tantek: We had long discussions long ago.
   tantek: about how box properties apply to inlines
   tantek: We all did something different with CSS2
   tantek: We settled on a model that looks reasonable.
   tantek: We had to make exceptions for blocks
   tantek: This seems like same problem. We missed an exception.
   tantek: Same case as how borders and bgs apply to boxes.
   tantek: Rather than add property, we need to fix the definition.
   tantek: We did it with borders and bg, I think we should try to do the
           same here.
   glazou: It's only inline?
   fantasai: Yes, strictly.
   fantasai: Either define as default behavior, or add value (or both).
   <fantasai> for text-decoration-skip
   dbaron: We aren't yet interop on the CSS 2.1 behavior.
   dbaron: So I'm ok with it even though it's a change from 2.1.
   tantek: Maybe apply an optimistic change and give authors a way to
           scream if it breaks pages.
   tantek: Evaluate case by case, then change default accordingly.
   glazou: I can live with proposed change.
   glazou: Makes no sens for non-inline.
   fantasai: Should try to do it by default.
   dbaron: Drawing the text-decoration is thus independent of the text.
           Draws through margins.
   florian: what does it mean?
   dbaron: May be detectable in cases with nested inlines.
   dbaron: E.g., with relative pos.
   dbaron: Add new value to text-decoration-skip. Not part of initial value.
           Default is to draw decoration from margin edge to margin edge.
   <dbaron> difference between "from margin to margin" and "through inlines"
            is detectable with painting order, e.g., with
            <span padding><span relpos>text</span></span>
   <fantasai> Default is to draw decoration on margin/padding/border
   RESOLVED: Add a new value to text-decoration-skip controlling whether
             decorations are drawn through the padding/border/margin of
             display:inline elements.  This new value is not part of the
             initial value and therefore (change from CSS 2.1) decorations
             are drawn through padding/border/margin of inlines by default.

<br type="lunch"/>
Received on Thursday, 30 August 2012 02:19:58 GMT

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