- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Wed, 29 Aug 2012 19:19:23 -0700
- 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 UTC