- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Wed, 04 Aug 2010 13:05:20 -0700
- To: "www-style@w3.org" <www-style@w3.org>
Summary:
- RESOLVED: Proposal for CSS2.1 Issue 120 accepted with changes mentioned
in minutes.
- RESOLVED: Proposal accepted for CSS2.1 Issue 167 as corrected by Bert
- Discussed CSS2.1 Issue 167 and definition of em box
- RESOLVED: For CSS2.1 Issue 184, "Pseudo-elements behave just like real
elements except as described below and elsewhere (i.e. section
12.1)"
- Discussed zero-height floats. (CSS2.1 Issue 185) Proposed resolution to
not consider them for line-box shortening.
====== Full minutes below ======
Present:
Tab Atkins
David Baron
Bert Bos
Arron Eicholz
Elika Etemad
Simon Fraser
Sylvain Galineau
Daniel Glazman
John Jansen (Microsoft)
Brad Kemper
Peter Linss
David Singer
Steve Zilles
<RRSAgent> logging to http://www.w3.org/2010/08/04-CSS-irc
Administrative
--------------
no more agenda items to add
CSS Test Suite
--------------
arronei: Lots of tests need updating in response to review comments. Plan to get these done before the F2F.
CSS2.1
------
<glazou> http://wiki.csswg.org/spec/css2.1#issue-120
glazou: Asked everyone to review issue 120, and if no comments, it's accepted
glazou: Are there any comments?
Bert: I just sent my review of the text. I had three places where
I didn't agree with the replacements.
http://lists.w3.org/Archives/Public/www-style/2010Aug/0050.html
Bert: block-level is not defined
Bert: second issue is the definition of atomic inline box
Bert: I'm wondering if it's necessary -- it's only used in one place
fantasai: That seems alright to me.
Steve: I'm fine with that as a resolution. However if we ever get around
to Tab's split of the 'display' property or something similar,
it would be a useful term to have.
Steve: The concept is a useful one for people to understand
fantasai agrees with Steve
Steve: If there's no harm in introducing it here, it could be useful in
the future.
Bert: My third comment is wrt its use in the z-index property description,
where I don't think we should use it.
Bert: So we would define the term but not use it anywhere in CSS2
Steve: That's fine, I think just the recognition that there is such a
thing would be useful.
* oyvind doesn't like "atomic" but doesn't have a better suggestion
Bert: The other changes seem fine to me.
fantasai: There were some comments on the mailing list, mostly editorial,
about improving the text there. I will need to incorporate
those as well.
RESOLVED: Proposal for 120 accepted with changes mentioned above.
<glazou> http://wiki.csswg.org/spec/css2.1#issue-167
Bert's response to 167: http://lists.w3.org/Archives/Public/www-style/2010Aug/0052.html
Bert: In some cases a backslash is not an escaping mechanism.
Bert: The way he defines that is to say it has "no special meaning",
and then defines "no special meaning" inside a note, which is
a non-normative part.
Bert: Otherwise I think his changes are fine, other than the
non-normative part.
Bert: I would rather not define "no special meaning", but instead
just say that the backslash stands for itself directly.
glazou: Other comments?
fantasai: I agree with Bert's changes, and I trust Bert to have made
sure the proposal is correct
RESOLVED: Proposal accepted for issue 167 as corrected by Bert
<glazou> http://wiki.csswg.org/spec/css2.1#issue-118
Steve: Basically I went back and looked at OpenType standard, and
then checked with some font guys at Adobe to make sure I
understood it.
Steve: The catch is, the em-box a) isn't really defined, other than
to say that the coordinate system used in other values is
given in units per em
Steve: and b) its position is not really defined
Steve: The ascent and descent values which dbaron mentioned are
related to this
Steve: There are three sets of such values
Steve: One that tends to be Mac-centric
Steve: One set tends to be Windows-centric
Steve: And the third set, were put in to be platform independent.
Steve: Those should be used if they exist.
Steve: Then it's recommended that the distance between them equal
one em, but it's not required.
Steve: There are fonts for which it doesn't hold.
Steve: I suggest the difference between that and an em be split,
half above and half below, just like leading
Steve: The last point is, the reason you need to do that is that
leading + embox = line height.
glazou: Do you mean we can't rely on the font's definition of
embox because it doesn't exist?
Steve: Right. I didn't get as far as suggesting a rewording of the text.
Steve: I got hung up on what centering meant.
Bert: I can come up with wording for that.
Bert: I have one concern which is, this applies to OpenType, but
what about other font formats?
Steve: I think the general approach I talk about works for any
font with ascent and descent information. We assume that
information exists.
dbaron: We could say more broadly for any font that has any
measurement relating the baseline to the edges of it
dbaron: What Steve describes matches what we implement more than
Bert's definition.
dbaron: Although we never calculate the em-box, we just use the
ascent and descent and compute the half-leading differently --
which is a shortcut for the same results.
Bert: Do we still keep the references to OpenType fields?
Steve: I would put it in an appendix or a note.
fantasai: I would suggest putting the field names in a note, but
using ascent and descent generically in the normative text.
Brad would like to make sure there's interop for the use of
OpenType tables.
Steve suggests writing a test.
fantasai and Steve note that CSS tries to be font format agnostic.
Bert: I think we can't make this more precise wrt OpenType in CSS2.
glazou: Do you have enough to come up up with wording?
Bert: I think so
ACTION: Bert to write updated proposal for 167
<trackbot> Created ACTION-247 - Write updated proposal for 167
glazou: Any progress on other issues?
glazou: Let's have proposals done by the F2F
<dbaron> TabAtkins_, Where's the message you mentioned sending that had questions about margin collapsing?
<TabAtkins_> dbaron, http://lists.w3.org/Archives/Public/www-style/2010Jul/0525.html and 528
glazou: Issues assigne to the WG:
glazou: Issue 184
<glazou> http://wiki.csswg.org/spec/css2.1#issue-184
Tab: I think several things are way easier if you consider pseudo-elements
as part of the element tree
Bert: But then the element tree is not a tree
glazou: Could say which sections pseudo-elements are treated as elements
fantasai: That would be pretty much the entire spec except the Selectors
chapter
SteveZ: I support the "except" proposal in the issues list
dbaron: I might go so far as saying :before and :after are treated as
real elements except where specified, and have :first-line and
:first-letter just be defined by the Selectors chapter
fantasai: That doesn't give them enough definition -- e.g. how do we
assign properties to them?
dbaron: That's already pretty bizarre
fantasai: But the way we do define it is explained as differences from
normal behavior. We don't want to duplicate the spec of
normal behavior here just for :first-line and :first-letter.
glazou: "Pseudo-elements behave just like real elements except as
described below and elsewhere."
Steve: But then I have to search the entire spec.
Steve: At least point to the relevant sections
fantasai: I think the relevant section is 12.1
RESOLVED: "Pseudo-elements behave just like real element except as
described below and in section 12.1"
<glazou> http://wiki.csswg.org/spec/css2.1#issue-185
dbaron: There are 2 different cases here, and I'm not sure which one
he tested.
dbaron: There's one where you have a zero-height float whose position
is right at the edge of a line
dbaron: And the other is where you have a zero-height float whose
position is in the middle of the line (e.g. below another float)
dbaron: If the top of a float is even with the bottom of a line, or
the bottom of a float is even with the top of a line, that's
not considered an intersection.
dbaron: I'm not sure about the case of a zero-height float in the
middle of a line
dbaron: But we should be careful that we're testing the right cases here.
...
dbaron: There's another bug in browsers where floats that don't
intersect the top of a line are not considered. This shows
up in Wikipedia a lot because they use floats for their
intended purpose.
dbaron: The only browsers that handle that right are IE6/7 and recent
versions of Gecko
<dbaron> I think
Tab: If you have two floats stacked on top of each other, one which
is at the top of a line, and then a cleared float in the middle
of the line, that second float doesn't push the line box even
if it's wider than the line box.
Tab: In Gecko it pushes only if it's visible; if it's zero height it
doesn't.
Tab: I don't mind Gecko's current behavior. And everyone else who
doesn't match, they have a bug anyway.
Tab: I could go either way on it -- detecting or not detecting
zero-height floats both make sense.
SteveZ: It makes sense for consistency to ignore it; since when it
falls between lines it's ignored.
SteveZ: Why would one have a zero-height float?
SteveZ: I understand how it can happen; but is there a use case for it?
Tab can't think of one
Bert: It's a bit like positioned elements, that it's positioned at
the auto position
Bert: I don't know if it would make sense to use a zero-height float
instead of abspos, but if you wanted to make it overlap...
Brad: What about a transition from zero-height to another height?
Brad: You might want to cause reflow vertically, but not horizontally.
SteveZ: Is there a use case that isn't an edge use case for this?
glazou: If we have no use case, what do you suggest?
SteveZ: If we have interop, then it seems strange to break that.
* TabAtkins_ suggests that we just spec what browsers do in that case.
Bert: What interop do we have?
dbaron: The other possibility is that we say zero-height floats never
push lines. Which is nice, because it makes one implementation
strategy easier.
dbaron: We split each side of a bfc into vertical ranges, and we check
for whether to push lines by checking for an intersection.
dbaron: If we need to check for zero-height floats, then we need to
deal with zero-height ranges, which is a bit of a pain.
glazou notes we are over time
<TabAtkins_> Isn't that exactly what's being proposed?
dbaron: If floats are changing height, there will be a lot of reflow anyway
SteveZ: So, proposed to make zero-height floats not affect line boxes,
will ask for objections and resolve next week.
Meeting closed.
Received on Wednesday, 4 August 2010 20:05:58 UTC