- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Thu, 14 Feb 2013 14:15:04 -0800
- To: "www-style@w3.org" <www-style@w3.org>
Text Decoration
---------------
- RESOLVED: don't drop text-underline-position
- RESOLVED: not (currently at least) doing the @pattern proposal
- Other issues awaiting i18n input. Tracked at
http://dev.w3.org/csswg/css-text-decor-3/issues-lc-2012
Multi-Col
---------
- Blocked on testcases and a couple spec issues.
- RESOLVED: column rules are painted in the inline content layer
(as described in http://lists.w3.org/Archives/Public/www-style/2012Jul/0546.html),
but below all inline content inside the multicol
====== Full minutes below ======
Text Decoration
---------------
Scribe: dbaron
fantasai: I wanted to review status of various issues.
<fantasai> http://dev.w3.org/csswg/css-text-decor-3/issues-lc-2012
fantasai: we have 5 issues, the first is the trickiest
fantasai: ... and needs the WG's input
<fantasai> http://lists.w3.org/Archives/Public/www-style/2013Jan/0282.html
fantasai: Sebastian Zardner requested we remove text-underline-position
and add an @-rule to generically create random text decorations
using a variety of descriptors
<fantasai> http://lists.w3.org/Archives/Public/www-style/2012Sep/0462.html
fantasai: this message includes some examples of what he was thinking
fantasai: Koji and I propose to request this request
glazou: for the time being or in general?
fantasai: in general; we think the text decoration features should be
restricted to lines
fantasai: and text-underline-position feature is needed for international
text
fantasai: if we want to do something like this it should be a different
feature
fantasai: text-underline-position is for handling something very specific;
it should stay that way
glazou: What about his complaint that it applies only to underline?
fantasai: It can in some cases affect the overline.
fantasai: It can distinguish alphabetic vs. below; can also distinguish
between underline on left vs right in vertical text (which
swaps the overline to the other side).
glenn: This proposal essentially asks for a way to group style properties
and refererentially refer to them by name in other areas
fantasai: It's just about decorating text; not a generic feature.
glenn: Does it generalize to a way to group style properties?
fantasai: no
[discussion between fantasai and glenn about whether this is macro-ing]
fantasai: I don't think text-underline-position either prevents us from
going in this direction or should be dropped.
glenn: If this is something new, I don't think we should spec it out
unless somebody's committed to implementing. Also seems like
@-rules have a lot more overhead than properties.
SimonSapin: Can we see this as a way for images above the text and
generate procedural images images?
fantasai: There was some discussion on the list... proposal to duplicate
background properties.
fantasai: text-decoration is about text and associated with where text
is drawn
fantasai: foreground images would be referencing the box
smfr: what are the use cases for foreground images?
fantasai: a "new" banner across image, sparkles
TabAtkins: "ACTUAL SIZE"
fantasai: It's easy to spec.
smfr: painting order is tricky
fantasai: The proposal is to reject this comment and not drop
text-underline-position.
dbaron: I have questions about some of the values of text-underline-position,
but that's a separate thing.
dbaron: I have comments about some of the values of text-underline-position,
but that's separate.
<SimonSapin> maybe that’s just SVG
smfr: did we resolve we don't want to do the @-rule right now?
TabAtkins: I think @pattern should be something SVG invents and we
*possibly* import; we shouldn't try to innovate with that
in CSS first.
RESOLVED: don't drop text-underline-position
RESOLVED: not (currently at least) doing the @pattern proposal
fantasai: for reference there are 4 other issues on text-decoration
fantasai: LC period closed last week
fantasai: several of those are about combination of emphasis marks
and ruby
fantasai: 2 are about text-decoration-skip
fantasai: We'll bring those to i18n for the correct answers, then
we'll bring back to this WG for comments.
fantasai: If anybody else has issues, please raise them this week.
SteveZ: Implementation status?
fantasai: Mozilla has quite a few; AntennaHouse probably nearly everything
Koji: WebKit has a good amount in progress
fantasai: That's it on text-decoration.
Multi-col
---------
Bert: I'm trying to find the current status. Do we have any ideas when
it might go to PR?
Bert: Are there ways to speed it up?
fantasai: The testing situation -- not enough tests to cover the spec.
fantasai: Also a handful of open issues, most notably one SimonSapin
raised that we didn't resolve at last f2f.
fantasai: We need to get all the issues handled and publish a new CR,
and get more tests.
fantasai: So I think there's a lot of work left to do.
Bert: And implementations?
fantasai: Mozilla's working on areas where we're not compliant; haven't
unprefixed yet.
fantasai: Not a super-high priority; hopefully able to be unprefixed
by end of year.
Bert: Does Mozilla have break-*?
fantasai: no
fantasai: If that's what's holding things up, we'll have fragmentation
in CR, and can drop from multicol.
[something there about WebKit too]
Bert: Prince doesn't do column-span: all; I think others do.
Rossen: We do, I think.
fantasai: Can IE submit tests?
Rossen: I can ask Arron to look into it.
Rossen: Last time I remember talking to Håkon, he said they had tests
ready to submit.
fantasai: Håkon submitted tests, but pretty much useless.
Peter: shepherd reports 129 tests for multicol
Bert: are you seeing the gaps?
fantasai: A lot of things
Peter: have tests across most of chapters, but would need to drill down
Bert: so I hear not this year... that's a pity
fantasai: Primarily gated on test, and a couple of spec issues.
Rossen: One issue about multicol I wanted to discuss.
<Rossen> http://lists.w3.org/Archives/Public/www-style/2013Jan/0251.html
[discussion of IRC bouncer]
Rossen: So there was an issue with column-rule rendering drawing order;
didn't get much traction on the list (link above).
Rossen: So the current spec defines column rules to be rendered just
above the background.
[reads spec text]
Rossen: I think it's a fairly reasonable behavior expectation that when
you have scrollbars, the column rules should scroll along with
the columns.
Rossen: The testcase in that link is an example of taking a fairly
simple case... and I looked through all implementations
supporting multicol at the moment... and most implementations
don't actually scroll the column rules because they treat them
as part of the background.
Rossen: If you also combine that with a case of z-index elements,
some of the implementations appear to start working, but
then don't... it's fairly messy.
Rossen: I think the current specification is fairly weak in its requirements.
Rossen: For us, to implement something that would achieve scrolling
with the content as well as being at the level of background
(under z-index), that means we need a new layer
Rossen: It's going to be a hassle to make that work, for I'm not sure
how much benefit.
Rossen: column rules are more of a design-time requirement (visual aid)
fantasai: I agree column rules should scroll with the columns; should
stay between the columns.
fantasai: With regards to what level; I think it should be below the
content (with no z-index); interesting question as to whether
above or below borders; above borders might make more sense.
[smfr shows Rossen a JSFiddle]
fantasai: If that elements forms a stacking context, at which level
does it paint?
fantasai: I'd say immediately before the text and text decorations
(anonymous text), or immediately above the background.
As long as it's below the text.
fantasai: I don't care about above or below negative z-index stuff.
fantasai: So below anything with a z-index of 0 or auto
smfr: I'd like to avoid a separate layer just for column rules.
Rossen: So just lift them up to the content layer... first in the
content layer.
smfr: Paint all the rules, then the content of the columns
dbaron: Does multi-col form a pseudo-stacking context?
fantasai: Don't know that we thought that far..
dbaron: If multi-col doesn't establish a pseudo-stacking context, then
floats from outside the multi-col propagate through the multi-col
<smfr> http://lists.w3.org/Archives/Public/www-style/2012Jul/0546.html
fantasai: guessing we want before Group A
dbaron: If a multi-col doesn't even establish an A-Group (pseudo-stacking
context)
dbaron: then only way to put it before group A is to give it its own layer
dbaron: but probably it should establish a pseudo-stacking context
[investigation into what forms a pseudo-stacking context]
dbaron: I argued at one point that anything establishing a BFC should
create a pseudo-stacking context, but I think I lost.
dbaron: Was that about tables or about flexbox?
<fantasai> tables don't form stacking contexts, for historical reasons
<fantasai> flexboxen don't either, see
http://dev.w3.org/csswg/css3-flexbox/issues-lc-2012#issue-5
<fantasai> so multi-col shouldn't either
RESOLVED: column rules are painted in the inline content layer
(as described in http://lists.w3.org/Archives/Public/www-style/2012Jul/0546.html),
but below all inline content inside the multicol
<fantasai> so we're painting right below inline layer, in the middle
of Group A
ACTION Rossen to ask Håkon to edit this resolution for column rule
painting order
Created ACTION-530
Peter: Should we consider adding Rossen as a co-editor of css3-multicol?
Peter: Anything we can do moving forward testing-wise?
fantasai: Gerard working on some of mozilla's tests
fantasai: for multicol specifically, and backgrounds and borders
Peter: Anything else on multicol?
fantasai: SimonSapin's issue
Bert: I want to talk to Simon before tonight.
Received on Thursday, 14 February 2013 22:15:37 UTC