- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Fri, 20 Jan 2012 17:10:18 -0800
- To: "www-style@w3.org" <www-style@w3.org>
Summary:
- Reviewed logistics for Paris F2F; request for agenda items
- Deferring republication of css3-writing-modes until jdaggett's concerns
are resolved
- RESOLVED: Breaks are allowed wherever there was a breakpoint, even if
it was collapsed away. Clarify CSS3 Text.
- Discussed problematic behavior of currentColor keyword, which computes
on the element specified and then inherits, instead of inheriting as
a keyword and then recomputing on each element. Tab to investigate whether
SVG depends on this behavior or if we can change it.
See http://lists.w3.org/Archives/Public/www-style/2012Jan/0521.html
====== Full minutes below ======
Present:
Glenn Adams
Rossen Atanassov
David Baron
Bert Bos
Tantek Çelik
John Daggett
Elika Etemad
Simon Fraser
Sylvain Galineau
Daniel Glazman
Arno Gourdol
Molly Holzschlag
Koji Ishii
Brad Kemper
Peter Linss
Divya Manian
Alex Mogilevsky
Edward O'Connor
Anton Prowse
Florian Rivoal
Alan Stearns
<RRSAgent> logging to http://www.w3.org/2012/01/18-css-irc
Scribe: TabAtkins
February F2F
------------
<plinss> http://wiki.csswg.org/planning/paris-2012
plinss: our agenda page is still kinda light, so please enter things as
soon as you can
glazou: I need a firm list of people attending the meeting next week
because I need it for security reasons - there will be badges
every day.
glazou: Even if you don't have your flight details, please add yourself asap.
<sylvaing> the list of msft attendees is complete. well, we even have
two Alex Mogilevskys
plinss: Also there are no hotels listed on that page yet?
glazou: I sent an email a while back with a short list of hotels.
I'll add that to the wiki page.
glazou: One thing I'm missing is meal prefs - any food restrictions for
the group meal?
* sylvaing can only eat delicious food
glazou: Also there is no food inside the building. So I can't get catering
inside.
glazou: They'll tolerate breakfast, so I'll bring croissants and such, but
we'll have to get lunch outside.
glazou: Drinks are allowed.
glazou: There's a shopping mall on the other side of the street, chinese
district is walking distance, and plenty of other restaurants.
Status of CSSOM and CSSOM View
------------------------------
glenn: The work is in progress. I've been updating and will soon bring a
draft forward to the group for review.
sylvaing: Can you characterize the changes?
glenn: The main changes have been filling out text that was basically blank
in the spec, and I'm planning to bring that forward for discussion
at the f2f.
Publishing Writing Modes
------------------------
plinss: We deferred this from last week, and jdaggett has sent in a bunch
of comments.
jdaggett: I posted some issues that I think exist with text-orientation.
I think we should let some of those discussions continue.
jdaggett: Koji responded and I need to respond back.
jdaggett: I think there's some wording about text-orientation and the
unicode properties, but I don't think it describes editors'
intent.
jdaggett: Once those list discussions seem to be resolved, I think I'll
be okay.
plinss: Anyone else have thoughts on that?
<jdaggett> there's new wording for text-orientation but I don't think it
accurately describes how the editors intended this should work
<jdaggett> so discussion on the list should continue for a bit I think
florianr: I haven't followed too closely the details of these issues, but
I think that what jdaggett is trying to resolve is worth figuring
out.
plinss: So do we think it's worth publishing a WD and then publish LC later?
* scribe missed most of what jdaggett just said due to things cutting out.
<jdaggett> i think it's impor
<glazou> even on IRC jdaggett is cut :-)
plinss: Is there a current conversation going, or does someone need to
raise an issue?
<jdaggett> relates to http://lists.w3.org/Archives/Public/www-style/2012Jan/0655.html
jdaggett: There's currently a convo. It just nees to resolve.
plinss: Okay, we'll let it settle and revisit later.
Processing Model for Transforms
-------------------------------
<plinss> http://lists.w3.org/Archives/Public/www-style/2011Dec/0000.html
dbaron: Tab responded on the list, so nothing needs to be discussed here.
Collapsed space break opportunities
-----------------------------------
<plinss> http://lists.w3.org/Archives/Public/www-style/2012Jan/0408.html
fantasai: We resolved for 2.1 that if you have two spaces that collapse
and the first one is non-breaking (so the breakble one disappears)
you're still allowed to break there.
fantasai: But what happens if you have a bunch of different element
boundaries? Where does this break occur?
fantasai: If the non-breaking was within a border but the breaking was
outside, does the break happen within or without the border?
fantasai: I can see conceptually that breaking at any point previously
occupied by a space is valid.
fantasai: Or I can see saying that the non-breaking space is now breakable,
so that you must break there.
fantasai: These both make sense to me.
fantasai: FF and Opera will break right before the following text (last
breaking opporutunity) even if that's not actually a valid
break point.
fantasai: So I don't really know what we should do.
fantasai: I'm not sure I want to spec what FF/Opera does, because it
doesn't make much sense.
TabAtkins: What does Webkit do?
fantasai: Webkit refuses to render empty inlines, so it's not detectable
what their behavior is.
dbaron: Why do we collapse across visible borders?
fantasai: I dunno.
dbaron: It would seem less crazy if we didn't do that.
plinss: But do you really want the presence of borders to change your
whitespace-collapsing behavior?
dbaron: Doesn't seem that different from the presence of an image.
TabAtkins: collapsing already depends on other properties.
fantasai: I see four options.
fantasai: (1) don't collapse spaces across non-zero borders, non-zero
padding, or non-zero margins.
fantasai: (2) anywhere a space used to be is a break point
fantasai: (3) when a non-breaking space collapses with a breakable,
the resulting space is breakable
fantasai: (4) break right before the next thing after the collapsed stuff
(even if it's not actually a valid breakpoint) (FF/Opera
behavior)
* florianr was confused by fantasai's remark that this is different from
an nbsp characher. What to I read to become smarter?
* TabAtkins a space inside a no-wrap element.
dbaron: You've got borders with width in them in this example, so you
can tell whether there's one breakpoint or multiple.
mollydotcom: If there's a non-breaking and a breakable space, they all
collapse, and that point is the break point. That's #2,
right?
fantasai: Not quite. When you collapse spaces, the first space nominally
stays put, and the rest get dropped.
fantasai: So I've got a space inside the no-wrap, and two empty inlines,
then a B.
mollydotcom: The integrity of the borders shouldn't be broken, right?
Doesn't that make sense?
mollydotcom: If something breaks in a border, a designer will be confused
by that.
dbaron: If you have a multi-word thing wtih a border around it, breaking
inside there is normal.
fantasai: But you wouldn't break *just* within the border on either end.
fantasai: And we can expand that to say you don't break inside an empty
inline, because that's a degenerate case.
fantasai: But we can break *between* the inlines.
mollydotcom: It seems the most natural point to make the break is the
first point where all the space has collapsed and there
is no border.
TabAtkins: So this sounds like break opportunities at the beginning or
end of an element with visible borders or whatever migrate
outside of the element.
fantasai: Yes, there's spec text for that.
fantasai: I think what Molly's saying is that you collapse everything,
then the break point must go at that last point, but if it's
at the end of an element with a border or whatever, move it
outside the element.
bradk: Not just borders, box-shadow too right?
fantasai: It's all boxes, not just those with visible decorations.
fantasai: If you think about it, if you put a word in a box and put it
against the edge of a line, the breakpoint is just inside the
box, technically, but we instead move it outside the box.
fantasai: So what about if the breakpoint determined by this rule is
within the non-breaking area?
<fantasai> <p><nowrap>A <em> </em></nowrap> <em> </em> B
<dbaron> (Did that discussion just conclude something weird about what
happens when the only space is just inside the edge of the border?)
Rossen: In IE we would preserve a break oppurtunity after the </nowrap>
for the case in the email.
fantasai: And waht about the case in IRC?
fantasai: I think the logical place would be to break after the </nowrap>,
but that's between the two empty <em>s.
dbaron: might have more than one breakpoint
Rossen: We still preserve the space inside the nowrap, and break outside
the nowrap.
fantasai: Ok, I propose we spec what IE does, because that makes sense.
* Rossen agrees with fantasai :-)
fantasai: If you look at the last example in the email, Moz breaks right
before the B.
antonp: The last example is the key one - you can't honor both nowraps
unless you break in the middle.
TabAtkins: I think we want to specify that break opportunities collapse
separately from the spaces that generate them, and won't enter
no-break areas.
antonp: Does that mean in the second example in fantasai's email, the space
after the A is preserved, but the whitespace collapsing between
them is independent?
fantasai: There's two phases to whitespace - the first collapses, the
second trims from teh begin/end of the line.
TabAtkins: dbaron had an issue about borders.
fantasai: They'll make the breaks that would visible coincide be visibly
separate.
fantasai: Once you put borders, they'll take up space, so you can see
where the break opportunity happens.
mollydotcom: If you have content, and it's right up to the border, it
would be devasating to have a break right at the end.
fantasai: The migration rule applies to all elements, regardless of
decoration. So that addresses david's issue.
bradk: What if you have a zero-width box with a box-shadow at the end of
a line (and a space inside of it)?
TabAtkins: I think it would migrate the break opportunity both before and
after the box, so the break would happen before it.
fantasai: box-shadow doesn't take up sapce, so it doesn't affect layout
TabAtkins: But the box-shadow lets you tell whether the box is at the end
of one line or the beginning of the next.
antonp: There was a convo about a year ago with Boris about this issue -
whether zero-width boxes stay at the end of a line or wrap around.
antonp: So it may be worth digging that up.
dbaron: Another warning - a fun thing to introduce in text cases is
negative margins.
dbaron: They can give you cases where adding more stuff to the line gives
you an earlier breakpoint.
mollydotcom: I was just imagining that.
dbaron: I don't know if we properly define, given a set of breakpoints,
how you choose the one that is actually used.
<antonp> neg margin was, I think, the main subject of the convo I was
referring to IIRC
dbaron: Because there may be a sequence of breakpoints that are not
monotonically non-processing in the line direction, due to
negative margins.
<dbaron> s/processing/decreasing/
* oyvind not monotonically non-decreasing? confused now
* scribe dbaron I went with precessing because we were talking about a
position, not a value.
* dbaron oyvind, they might have some steps in the sequence with decreases
mollydotcom: [explains an issue]
plinss: I think it just changes where the breakpoint would be between
two elements.
mollydotcom: It seems that even getting down to that level - why would
we want it? I would avoid those.
<Bert> (A line might be overfull already, but after adding the next elt
with negative margins, it is suddenly no longer full...)
* mollydotcom sez keep it simple - avoid any breaking where there might
be a margin or border
<Bert> (Even with 'overflow-wrap: break-word', there won't be a break
between the last letter and the border, I assume?)
fantasai: We don't define which breakpoint gets chosen, only where the
possible breaks are.
fantasai: This is intentional, so you can frex do paragraph-level
breaking/balancing instead of line-level.
<sylvaing> i can't object to that
fantasai: So I think we're done with this issue if everyone's happy with
IE's behavior.
glenn: We're defining sematnics for what is breakpoint or not. Is this
meant to be normative to all scenarios, or just in the absence of
a higher-level protocol.
florianr: The intent is that any breaking algorithm can pick between the
breaking points we define. It can choose any of them, but it
shouldn't break at anywhere that doesn't produce a breaking point.
TabAtkins: For example, a more advanced mechanism that does hyphenation by
finding more breakpoints inside of words.
glenn: I ask because languages like Thai uses a dictionary to determine
breakpoints.
fantasai: I suggest you read the section on line-breaking, because it
covers all this.
RESOLVED: Breaks are allowed wherever there was a breakpoint, even if
it was collapsed away.
<glenn> CSS3 Text §4 answers my question "CSS does not fully define where
line breaking opportunities occur"
currentColor and inheritance in text-emphasis
---------------------------------------------
http://lists.w3.org/Archives/Public/www-style/2012Jan/0521.html
fantasai: The problem is that currentColor *computes* to the color value,
then inherits as that color.
fantasai: We need one that turns into the color at used value time.
fantasai: text-emphasis-color takes a color. By default, they should take
the color of the text.
fantasai: Right now, you compute the color on the root element of the
document, then use that throughout the document.
dbaron: So it sounds like we want a new value.
fantasai: Yes, but there are other places where we may want this behavior -
text-shadow is one such case.
TabAtkins: Small issue - because computed value is used for multiple things,
if it stays as the keyword in computed value, it won't transition.
dbaron: I'd have to look into it, but I think this would be quite a bit more
work to implement for text-shadow than for text-emphasis-color.
fantasai: You already implement it for text-shadow.
dbaron: We implement currentColor, but not the thing that has to inherit
not as a color.
fantasai: That's not true - you do implement it. Testcase coming.
<fantasai>
http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Cstyle%3E%0Abody%20{%20text-shadow%3A%200%200%204px%3B%20}%0A%3C%2Fstyle%3E%0A%0ASOME%20TEXT%20%3Cem%20style%3D%22color%3A%20red%22%3EMore%20text%3C%2Fem%3E%0A
dbaron: It's the "no-color" case. It's not defined, but everyone uses
this behavior.
plinss: So we just need a keyword for this behavior.
<fantasai> current-color ? :)
<tantek> stayCurrentColor
<tantek> ;)
<nimbu> :)))
<tantek> elementColor
Bert: Too late to change currentColor?
TabAtkins: Given the small usage of currentColor, we probably could.
fantasai: And basically no sane person inherits, say, a border-color.
fantasai: (QA persons excepted)
<dbaron> I think Gecko's implementation of the default border-color and
outline-color actually works this way rather than the way
currentColor works
dbaron: In FF, we actually implement border-color and outline-color in
this way, because it's cheaper than the actual implementation
for currentColor.
<tantek> remember, we got the term 'currentColor' from SVG
<tantek> so if they're dependent on a specific interpretation...
<tantek> otherwise we would have called it 'current-color'
fantasai^: If we want to redefine currentColor
fantasai: We should check with SVG on this.
* tantek dislikes camelCase
plinss: Is there any use-case for the current currentColor behavior?
Would we lose anything from it?
TabAtkins: I can take this to SVG and see what they say.
ACTION TabAtkins: Ask SVG about currentColor's computing behavior
Received on Saturday, 21 January 2012 01:10:48 UTC