- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Fri, 11 Mar 2011 22:40:59 -0800
- To: "www-style@w3.org" <www-style@w3.org>
Summary:
- Reviewed some of Bert's edits where the exact edited text was not
yet approved by the WG.
- RESOLVED: For CSS2.1 Issue 224, accept Tab's proposal.
http://wiki.csswg.org/spec/css2.1#issue-224
- RESOLVED: For CSS2.1 Issue 230, make precise numbering of list items
undefined in 2.1. (It's defined in css3-lists.)
http://wiki.csswg.org/spec/css2.1#issue-230
- RESOLVED: For issue 231, accept proposal permit root list-item to
degrade to block.
http://wiki.csswg.org/spec/css2.1#issue-231
- RESOLVED: For issue 236, make the behavior of underlines through
tables undefined. (Address in CSS3 Text, when we have
option to cancel underlines via UA style sheet.)
http://wiki.csswg.org/spec/css2.1#issue-236
- RESOLVED: For CSS2.1 Issue 232, make in-flow mean not out-of-flow,
check that spec remains correct.
http://wiki.csswg.org/spec/css2.1#issue-232
- RESOLVED: For CSS2.1 Issue 233, no change.
http://wiki.csswg.org/spec/css2.1#issue-233
- RESOLVED: For CSS2.1 Issue 235, accept editorial.
http://wiki.csswg.org/spec/css2.1#issue-235
- RESOLVED: For CSS2.1 Issue 239, do not propagate direction from <body>
to <html>. No change to spec.
http://wiki.csswg.org/spec/css2.1#issue-239
- RESOLVED: For issue 240, make min/max-width on internal table elements
explicitly undefined.
http://wiki.csswg.org/spec/css2.1#issue-240
- RESOLVED: For CSS2.1 Issue 241, accept the proposed spec change.
http://wiki.csswg.org/spec/css2.1#issue-241
- RESOLVED: For CSS2.1 Issue 242, no change for now, push to errata
http://wiki.csswg.org/spec/css2.1#issue-242
- RESOLVED: For CSS2.1 Issue 199, use Tab's proposal with edit for
"static position" (instead of "auto position") and then
add tests after PR.
http://wiki.csswg.org/spec/css2.1#issue-199
- RESOLVED: For CSS2.1 Issue 207, no change to spec.
http://wiki.csswg.org/spec/css2.1#issue-207
- RESOLVED: For CSS2.1 Issue 208, no change to spec.
http://wiki.csswg.org/spec/css2.1#issue-208
- RESOLVED: For CSS2.1 Issue 219, fantasai's text accepted.
http://wiki.csswg.org/spec/css2.1#issue-219
- RESOLVED: For CSS2.1 Issue 244, no change to spec (but we agree that
it *is* the rendering tree)
http://wiki.csswg.org/spec/css2.1#issue-244
- RESOLVED: For CSS2.1 Issue 245, no change. See Issue 60.
http://wiki.csswg.org/spec/css2.1#issue-245
- RESOLVED: For CSS2.1 Issue 211, no change.
http://wiki.csswg.org/spec/css2.1#issue-211
- RESOLVED: For CSS2.1 Issue 247, undefined via issue 215.
http://wiki.csswg.org/spec/css2.1#issue-247
- RESOLVED: For CSS2.1 Issue 248, not an issue, so no change.
http://wiki.csswg.org/spec/css2.1#issue-248
- RESOLVED: For CSS2.1 Issue 250, use fantasai's proposed text.
http://wiki.csswg.org/spec/css2.1#issue-250
- RESOLVED: For CSS2.1 Issue 252, no change, fix in CSS3.
http://wiki.csswg.org/spec/css2.1#issue-252
- RESOLVED: For CSS2.1 Issue 253, say in 4.2 that "end of line" means
CR/LF.
http://wiki.csswg.org/spec/css2.1#issue-253
- RESOLVED: For CSS2.1 Issue 254, not an issue: --> is parsed as invalid
tokens in @statement. No change to spec.
http://wiki.csswg.org/spec/css2.1#issue-254
- RESOLVED: For CSS2.1 Issue 255, add "and future versions" to section 3.1.
http://wiki.csswg.org/spec/css2.1#issue-255
- RESOLVED: For CSS2.1 Issue 256, no change.
http://wiki.csswg.org/spec/css2.1#issue-256
- RESOLVED: For CSS2.1 Issue 257, boxes do have properties. No change.
http://wiki.csswg.org/spec/css2.1#issue-257
- RESOLVED: For CSS2.1 Issue 260, no change.
http://wiki.csswg.org/spec/css2.1#issue-260
- RESOLVED: For CSS2.1 Issue 261, no change in 2.1; clarified in
Selectors Level 3
http://wiki.csswg.org/spec/css2.1#issue-261
- RESOLVED: For CSS2.1 Issue 262, no change.
http://wiki.csswg.org/spec/css2.1#issue-262
- RESOLVED: For CSS2.1 Issue 263, nice to have, but no change for now.
http://wiki.csswg.org/spec/css2.1#issue-263
- RESOLVED: For CSS2.1 Issue 264, accept change proposed in the issue e-mail.
http://wiki.csswg.org/spec/css2.1#issue-264
- RESOLVED: For CSS2.1 Issue 265, no change.
http://wiki.csswg.org/spec/css2.1#issue-265
- RESOLVED: For CSS2.1 Issue 266, accept issue 6, defer the others to the errata.
http://wiki.csswg.org/spec/css2.1#issue-266
- RESOLVED: For CSS2.1 Issue 267, accept proposed edit.
http://wiki.csswg.org/spec/css2.1#issue-267
- RESOLVED: For CSS2.1 Issue 203 revisit, already resolved to allow two behaviors.
http://wiki.csswg.org/spec/css2.1#issue-203
- RESOLVED: For CSS2.1 Issue 268, no change; spec is correct.
http://wiki.csswg.org/spec/css2.1#issue-268
- RESOLVED: For CSS2.1 Issue 269, use line box edges instead of block edges.
http://wiki.csswg.org/spec/css2.1#issue-269
- RESOLVED: For CSS2.1 Issue 270, no change for 2.1. Clarify in CSS3 Text.
http://wiki.csswg.org/spec/css2.1#issue-270
- RESOLVED: Undefine bg-pos of aspect-ratio-only images in CSS2.1.
http://wiki.csswg.org/spec/css2.1#issue-282
- RESOLVED: Remove content-computed-value-001 as it is not valid
- RESOLVED: Undefine sizing of replaced elements with intrinsic ratio only
(No passing implementations due to misinterpretation of SVG spec.)
http://wiki.csswg.org/spec/css2.1#issue-283
- RESOLVED: Update CSS 2.1 exit criteria to the current (CSS3 standard)
exit criteria, minus the 30-day implementation requirement.
http://wiki.csswg.org/spec/css2.1#issue-284
====== Full minutes below ======
Present:
Tab Atkins
David Baron
Bert Bos
John Daggett
Tantek Çelik
Arron Eicholz
Elika Etemad
Simon Fraser
Sylvain Galineau
Daniel Glazman
Arno Gourdol
Soonbo Han (LG)
Shinkuro Honda (NTT)
Dave Hyatt (via IRC)
Masayuki Ihara (NTT)
Hiroyuki Ishii (NTT)
Koji Ishii
John Jansen
Brad Kemper
Peter Linss
Håkon Lie
Alex Mogilevsky
Edward O'Connor (Apple)
Kazutaka Yamamoto (NTT)
Steve Zilles
Toru Kobayashi (NTT AC Rep)
<RRSAgent> logging to http://www.w3.org/2011/03/07-css-irc
http://krijnhoetmer.nl/irc-logs/css/20110307
http://krijnhoetmer.nl/irc-logs/css/20110308
Scribe: Tab Atkins
Agenda
======
<glazou> http://wiki.csswg.org/planning/mountain-view-2011
glazou: CSS 2.1 will take up the morning, I expect. What about the
afternoon?
jdaggett: I'd like the Fonts discussion to happen tomorrow, for
Christopher Slye.
dbaron: If Christopher could do wednesday we'd have an easier time,
I believe.
jdaggett: Wednesday AM would be fine.
glazou: Writing Modes, when?
fantasai: Writing Modes should be fine anytime, also Text.
howcome: If we could do hyphenation early, would be great.
jdaggett: And we can do Text this afternoon, if necessary.
glazou: So, start with 2.1.
dbaron: I'll take a dinner count just before lunch.
<szilles> I would strongly prefer to do text on Wednesday
CSS2.1 Issues
-------------
johnjan: The new issues start at 224
<Bert> http://lists.w3.org/Archives/Member/w3c-css-wg/2011JanMar/0271.html
* Ad 153: https://www.w3.org/Style/Group/css2-src/changes.html#q500
The proposed new text (by David Baron) was
| In the following definitions, for inline non-replaced elements,
| the box used for alignment is the box whose height is the
| 'line-height' (containing the box's content area and the
| half-leading on each side). For all other elements, the
| box used for alignment is the margin box.
However, the parenthetical remark in the middle isn't correct. We
explicitly do not define the content area of inlines. I used this
instead:
In the following definitions, for inline non-replaced elements,
the box used for alignment is the box whose height is the
'line-height' (containing the box's glyphs and the
half-leading on each side, see above). For all other elements, the
box used for alignment is the margin box.
And to make sure inline boxes actually have a height of 'line-height', I
changed earlier in that section:
| The height of the inline box is then the smallest such that it
| encloses all glyphs and their leading, as well as all nested inline
| boxes.
to
The height of the inline box encloses all glyphs and their leading
and is thus exactly 'line-height'. Boxes of child elements do not
influence this height.
Bert: ??? [something about issue 153]
szilles: How does the height of the ascenders/descenders work?
Bert: Each glyph gets [something about leading]
Bert: The height of the inline box is only based on its own glyphs, not
its sub-elements. They each have their own inline box.
dbaron: The intent of what I proposed was taht the height of the content
area was based only on the glyphs and not the descendants.
If you are saying that explicitly, that's fine.
Bert: I couldn't say "content area", because 10.6 says it's undefined.
glazou: Accepted edits to 153.
<sylvaing> actually, tiny nitpick: one change specifies the inline box
to be glyphs + half-leading; the other 'all glyphs and their
leading'. I'd prefer saying half-leading both times ?
Bert: Next issue, 181.
Bert: This was an issue about heights in the line box. I needed to explain
that it didn't refer to the content height nor the line box.
Bert: There was a reaction afterwards from Anton Prowse, but I think that's
solved now by the previous issue.
<Bert> http://www.w3.org/mid/201103041709.55059.bert@w3.org
glazou: Accepted edits to 181.
Bert: next issue is 204.
Bert: In 9.4.2 there is text about lineboxes formed from elements without
content.
Bert: It says they're ignored for the purpose of finding adjacent margins.
This wasn't mentioned in 8.3.1, so the action was to make that clear.
glazou: Accepted edits to 204.
Bert: next is 213. We weren't clear if :first applied to the first page
generated by a forced line break, or to the page after it. This
makes that undefined.
glazou: Accepted 213.
Bert: 215 is about an inline with position:relative which is broken over
two lines - what is its containing block?
Bert: We decided to make it undefined.
Bert: This makes the text in 10.1 much shorter.
fantasai: Does this account for elements that have been split by bidi in a
single line?
Bert: I'm not sure; the issue only talks about breaking over multiple lines.
szilles: So if it's on the same line, it does define a box, if they're on
different lines it's undefined?
fantasai: Yes.
ACTION Bert to re-edit 215 to take into account bidi-reordered boxes on
the same line.
<trackbot> Created ACTION-302
<fantasai> So the definition should say that the top left padding box
corner of the leftmost box and the bottom right corner of
the rightmost box define a rectangle which is the containing
block.
<fantasai> If the inline is split across multiple lines, it's undefined
Bert: For 218, I just need a review. I was removing all references to
percentage intrinsic dimensions.
glazou: Accepted edits to 218.
ACTION fantasai: Check the rest of Bert's edits
<trackbot> Created ACTION-303
Bert: For 228, we missed that width and height calcs were subject to
min/max calculations in one place.
Bert: So I added a note saying that the width may have to be calculated
multiple times to satisfy min/max width/height.
glazou: Accepted edits to 228.
Bert: And for 121, an explanation of why line-height works the way it does.
Bert: If you have the same font throughout, you get a constant line-height.
I changed the "generally" line to a more explicit note.
Note. When there is only one value of 'line-height' for all inline
boxes in a block container box and they are all in the same font
(and there are no replaced elements, inline-block elements, etc.),
the above will ensure that baselines of successive lines are exactly
'line-height' apart.
* fantasai suggests using "(and there are no atomic inlines)" to shorten
<fantasai> http://wiki.csswg.org/spec/css2.1#issue-224
fantasai: Issue 224 should be straightforward.
TabAtkins: fantasai, your edit misses the "ratio but no width or height" case.
TabAtkins: My edits are now consistent with the image-sizing rules elsewhere,
and match Opera and IE9, and would match Webkit if used 1em
instead of some weird value.
RESOlVED: Accept Tab's proposal for issue 224.
glazou: Next is 225.
fantasai: 225 needs someone to analyze it and propose some text.
glazou: Now on issue 229.
ACTION dbaron Write a proposal for http://wiki.csswg.org/spec/css2.1#issue-229
<trackbot> Created ACTION-304
fantasai: Second issue 229, for some reason, about numbering in list items.
<fantasai> no, that's 230
RESOLVED: Make precise numbering of list items undefined in 2.1
(it's defined in 3)
RESOLVED: Accept proposal for issue 231.
fantasai: Sometimes ::markers have to be siblings, so they'll have the
desired behavior in overflow:scroll
glazou: Now, issue 232.
dbaron: This is editorial, but it may result in non-editorial changes to
text-decoration which relies on the undefined term "in-flow".
<fantasai> see issue 236
fantasai: I think the best idea for the unresolved issues is to break
into groups of 3, all take a single issue and work on it,
while I go off and file the remaning issues.
glazou: Won't work.
<johnjan> I think we should approach this like this: what does it take
to get done today, not Wednesday. And do our best to achieve
that goal.
+Tantek
fantasai: For 236, which relates to 232, the definition of "in-flow" I
was using "not out-of-flow".
fantasai: We have interop between IE9 and Opera for spreading the
underline down.
fantasai: dbaron brought up a problem with <u> <table/> </u>
dbaron: The HTML5 parsing algorithm surrounding parsing of <table> in an
inline has the consequence of forcing you to not spread underlines.
In particular, if you pass underlines through to <table>, everything
in Ebay becomes underlined.
dbaron: Do we want the same behavior as blocks, or as inline-tables and
inline-blocks?
fantasai: What about flexbox?
arronei: If you had one in a <del>, you'd want the strike-through to go
through it.
arronei: How about for 236, we say the text-decoration propogation for
<table>s is undefined.
arronei: We can disable underlines in CSS3, so we can just fix the UA
stylesheet at that point. For now, CSS 2.1 can punt.
<fantasai> ua.css: u table { text-decoration: no-underline; }
RESOLVED: 236 makes the behavior of underlines through tables undefined.
fantasai: So, back to 232, I say we should just make "in-flow" be
"not out-of-flow".
RESOLVED: 232 Make in-flow mean not out-of-flow, check that spec remains
correct.
ACTION Bert to edit 232 and review for correctness.
<trackbot> Created ACTION-305
dbaron: Next issue, 233. I thought we all fixed this bug this years ago,
so I'm not sure why we want to change it now.
fantasai: I just thought the behavior was really weird - if you have a
4em table-cell and the screen is 80em, and you say text-indent:10%;,
you get an indent of 8em, not .4em.
fantasai: If it's interop, though, whatever.
RESOLVED: No change for issue 233.
glazou: Issue 234 - margin-collapsing and min-height.
fantasai: There are 2 impls that do one thing, and 2 impls that do
something else.
<br dur=10m/>
glazou: Back to issue 234.
arronei: For 234's testcase, we have interop between IE, Opera, and Webkit.
FF is the only one that does something different.
glazou: So we have 3 passes?
arronei: Not sure what the pass condition is, but we have interop.
dbaron: A problem is that, if we change the spec, do we get an infinite
loop? With margin-collapsing and clearance that's possible.
glazou: So if we change the spec and test, we may have 3 passes.
arronei: Maybe. And maybe we'll hit an infinite loop.
<fantasai> while (marginCollapsing in spec) { RewriteSpec(); }
dbaron: What's the spec change that would make the spec match what the
other 3 browsers do?
dbaron: 8.3.1 says an elements' own margins are adjoining if ...
dbaron: The important clause is "if the min-height property is 0".
[looking at a testcase]
<dbaron> The bottom margin of an in-flow block box with a 'height' of
'auto' is adjoining to its last in-flow block-level child's
bottom margin if the element has no bottom padding or border.
<dbaron> has no conditions on min-height
ACTION dbaron reply to Alan's message w.r.t
http://wiki.csswg.org/spec/css2.1#issue-234
http://lists.w3.org/Archives/Public/www-style/2010Sep/0649.html
that (a) this testcase is exercising "The bottom margin of an in-flow
block box with..." and therefore all browsers other than Gecko are
correct and (b) add a test to the CSS 2.1 test suite for post-PR.
<trackbot> Created ACTION-306
glazou: Issue 235 now.
<dbaron> http://lists.w3.org/Archives/Public/www-style/2010Sep/0728.html
glazou: Editorial.
glazou: issue 239.
fantasai: I say no.
dbaron: I think that HTML has a lot of history of authors putting
<html dir> rather than <body dir>.
dbaron: Hyatt says that IE does the <body> propagation, and so he did it
for Webkit.
<dbaron>
http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Chtml%3E%0A%3Cbody%20dir%3D%22rtl%22%20style%3D%22width%3A%20200px%3B%20border%3A%20thin%20solid%20green%22%3Etext%3C%2Fbody%3E
arronei: IE propagates.
<Arron>
http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Chtml%20style%3D%22width%3A%20500px%3B%20border%3A%20solid%20green%3B%22%3E%0A%3Cbody%20style%3D%22width%3A%20250px%3B%20border%3A%20solid%20blue%3Bheight%3A%2050px%3Bdirection%3A%20rtl%3B%22%3E%0A%3C%2Fbody%3E%0A%3C%2Fhtml%3E
<dbaron>
http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Chtml%20style%3D%22border%3A%20thin%20solid%20blue%22%3E%0A%3Cbody%20style%3D%22direction%3A%20rtl%3B%20width%3A%20400px%3B%20border%3A%20thin%20solid%20green%22%3Etext%0A%3Cdiv%20style%3D%22direction%3A%20ltr%3B%20border%3A%20thin%20solid%20fuchsia%3B%20width%3A%20200px%22%3Etext%3C%2Fdiv%3E%0A%3C%2Fbody%3E
dbaron: I'd rather not have propagation.
RESOLVED: Do not propagate direction from <body> to <html>.
<hyatt> that will be a compatibility issue
<hyatt> i guess we'll do it in quirks mode. sigh.
johnjan: We're willing to take the behavior as a bug.
dbaron: For issue 240, I thought we already said that min/max-width was
undefined.
RESOLVED: For issue 240, min/max-width on internal table elements is
undefined.
alexmog: A problem - if you set overflow and direction on <body>, you
get bad behavior.
alexmog: Can we say the same thing as overflow?
dbaron: That's weird because if you have <html dir=ltr><body dir=rtl>,
the rtl will propagate to <html> invisibly.
<dbaron> (alternative is just saying to use the value from body...
though that's really not particularly different.)
<hyatt> TabAtkins_: in webkit body direction only propagates to html
direction if html doesnt' set it
<hyatt> TabAtkins_: (similar to background propagation)
<dbaron> hyatt, what does "doesn't set it" mean?
<dbaron> hyatt, background propagation does it based on whether
background-image is none
<dbaron> hyatt, does it mean whether direction is ltr?
<hyatt> dbaron: we actually detect if any CSS rule sets direction to any
value
<hyatt> on the HTML
<dbaron> We've never had anything like that in the spec
<hyatt> actually maybe we don't do that
<dbaron> we shouldn't cross the value computation line
<hyatt> let me double check
<dbaron> compute values -> do something with the computed values
<hyatt> yeah that is what we do
<hyatt> we set a flag if direction is ever set on the html
<dbaron> is that what IE also does?
<hyatt> i can't remember if i arrived at that because it's what IE did
<hyatt> i discussed it in the bug at the time let me try to find
dbaron: If we propagate, we have to decide how to propagate, and what
Hyatt's describing for Webkit's behavior is pretty weird.
<hyatt> not that weird. to an author, the concept of setting the
direction explicitly via a rule is a simple one
<hyatt> it's just weird since we have never done it before
<johnjan> entire room is easily distracted by ropes flailing outside
the window...
<hyatt> the simpler option might be to just ignore the html whne body
sets it
<hyatt> i.e., just always propagate body
<dbaron> which I think is fine since direction's inherited anyway
<hyatt> i think that is what ie does
<dbaron> I'd prefer that
<hyatt> https://bugs.webkit.org/show_bug.cgi?id=48157
<fantasai> why are FF and Opera getting away with not doing this, if
it's a web compat issue?
<hyatt> looks like my main reasoning for not ignoring the html was just:
<hyatt> "This is in direct violation of CSS2.1 is the problem. It
states that the direction on the root element should be propagated
to the initial containing block. I don't think it makes sense to
actually overwrite the direction specified on the <html> if it is
there just because the <body> specified something different."
<hyatt> so if the spec told me it was ok i'd have matched WinIE :)
<hyatt> i was just concerned about ignoring the value on the html
<hyatt> since that sounded like violating the spec language
<hyatt> so o
<hyatt> i'm fine with making body just overwrite html
<hyatt> would just need the spec to say so
<fantasai> well, CSS2.1 assigns a 'direction' value to HTML whether one's
set explicitly or not
<fantasai> so you're violating the spec either way
<fantasai> by doing this at all
<alexmog>
http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20HTML%3E%0A%3Chtml%20style%3D%22direction%3Altr%3Boverflow%3Ascroll%22%3E%0A%3Cbody%20style%3D%22border%3A10px%20solid%20silver%3B%20width%3A100px%3B%20%20direction%3Artl%3B%22%3Exxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
<fantasai> I don't see anything in the bug explaining *why* you're doing
this, though; there's nothing in the bug that says what the
problem is with just following the spec instead of trying to
copy IE
<hyatt> it's broken out from another bug
<hyatt> let me keep digging
<hyatt> vaguely remember some dhtml menu on israeli sites not positioning
properly
<hyatt> used right: but didn't get computed correctly because the icb
wasn't properly rtl or something
dbaron: We use the direction of body to determine the scrolling direction
of the viewport
dbaron: But we don't actually propagate the 'direction' property
dbaron: So when Gecko determines the scrollbars for root, we use the
direction for <body>, but we don't do any other propagation.
So it's really the scrollbars for the ICB.
dbaron: We don't want a "propagated if not specified" in CSS.
glazou: Let's move on. We're not making immediate progress.
<dbaron> issue 241: http://lists.w3.org/Archives/Public/www-style/2010Nov/0035.html
<dbaron> I'd by happy to just make the change Øyvind suggests
<dbaron> (change the spec)
<dbaron>
http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Cdiv%20style%3D%22left%3A%20100px%22%3E%3Cdiv%20style%3D%22position%3A%20relative%3B%20left%3A%20inherit%3B%20background%3A%20lime%22%3EIs%20this%20indented%3F%3C%2Fdiv%3E
<dbaron> is a simple testcase
RESOLVED: Accept the spec change for 241.
glazou: Now issue 242.
dbaron: I think we just need to action for a proposal.
dbaron: I don't think anything has to be undefined here. We do need to
make the change for consecutive block boxes.
<fantasai> might be able to handle white space interaction in the phantom
line boxes clause
<dbaron> http://wiki.csswg.org/spec/css2.1#issue-142
johnjan: There are some issues, starting with 142, that need an action
for Bert edit.
dbaron: As far as I can tell from reading the spec, the containing block
for a child of a table cell, is the block that contains the table,
which seems like a bug.
dbaron: Boris's comments is asking for whether the table should be the
containing block. It seems to me that the table-cell should be
the containing block, even if it's anonymous.
fantasai: I think the table cell should be a containing block for the
inner table cell box.
dbaron: Is "inner table cell box" even in the spec yet?
fantasai: I don't think so.
dbaron: What Boris is talking about is what the containing block is for
an inner table element, like table-row.
Bert: I think the table-cell is fine; I believe the question was only
about anonymous table-cells.
<br type=lunch duration=1h>
<fantasai> sylvaing: Can you answer http://lists.w3.org/Archives/Public/www-style/2010Nov/0435.html ? :-)
</br>
Scribe: Bert
Topic: Issue 142 http://wiki.csswg.org/spec/css2.1#issue-142
-> http://lists.w3.org/Archives/Public/www-style/2011Mar/0022.html Bert's proposal
dbaron: So it seems we have a proposal. Somebody needs to respond to Boris.
<dbaron> sounds like we concluded that followup 2 was ok since anonymous
boxes can be containing blocks since we define containing blocks
in terms of boxes
Bert: Is that not what my proposed text does?
dbaron: Needs to be explained better.
plinss: So we are still stuck on this issue?
dbaron: [reading the texts]
... In 2c, rule is skipping anonymous boxes.
... That may skip the table cell.
-> http://lists.w3.org/Archives/Public/www-style/2011Mar/0023.html Boris'
last reply
JohnJan: It seems Boris essentially agrees, with maybe clarification.
dbaron: I think anonymous boxes should not be skipped.
Bert: They should be, except for anonymous table cells.
fantasai: They aren't all skipped.
<dbaron> And I think this makes the definition of containing block deviate
from the definition of the box tree.
plinss: Are there functional changes? Or only editorial?
fantasai: We should have only one possible interpretation of the spec.
plinss: If there is no test in the suite that shows the difference,
then let's defer this.
RESOLVED: no change, push to errata
Topic: issue 192
<johnjan> http://wiki.csswg.org/spec/css2.1#issue-192
TabAtkins: What happens to content that precedes the float in the source.
TabAtkins: Implementations never move such content down.
TabAtkins: Instead, they move the float down.
dbaron: That is what the spec says should happen.
dbaron: Float constraint include that top of float must not be above
prior content.
dbaron: So float *has* to be pushed down.
dbaron: That is not stated explicitly, only as implicit result of the
constraints.
TabAtkins: OK, so that everything is fine.
dbaron: Might be worth a note in the spec.
-> http://lists.w3.org/Archives/Public/www-style/2011Mar/0064.html
Bert's msg on 192
plinss: Who is writing that note?
TabAtkins: I could
dbaron: I could, too.
ACTION dbaron: write such a note for issue 192.
<trackbot> Created ACTION-307
Topic: issue 199
-> http://wiki.csswg.org/spec/css2.1#issue-199 Issue 199
-> http://lists.w3.org/Archives/Public/www-style/2010Oct/0707.html
Tab's proposal
TabAtkins: I think I did not test vertical and horizontal margins seperately
dbaron: That may make a difference.
dbaron: "The auto position" is a bit vague. Needs to be defined.
?: Use term 'static position'
plinss: Any tests for this?
JohnJan: Leave text as Tab proposed, with edit for "static" and then add
tests after PR.
RESOLVED: as JJ just said.
Topic: Issue 204
<johnjan> http://wiki.csswg.org/spec/css2.1#issue-204
fantasai: Bert sent an e-mail, which is not yet in this list.
... Probably wherever it says "Bert edit" we don't have to discuss now.
Topic: Issue 207
<johnjan> http://wiki.csswg.org/spec/css2.1#issue-207
-> http://wiki.csswg.org/spec/css2.1#issue-207 Issue 207
dbaron: What do implementtions do?
Arron: Impls are interoperable.
Arron: ... Is the same as margin collapse clear test case.
JohnJan: Spec remains underdefined.
... Is there an edit to do, or an errata later?
plinss: Any proposals?
[People trying to understand...]
dbaron: Defer to errata?
Arron: Seems possible, yes.
RESOLVED: no action on 207
<johnjan> http://wiki.csswg.org/spec/css2.1#issue-208
Topic: issue 208
<dbaron> 11.1.1: "In the case of a scrollbar being placed on an edge of
the element's box, it should be inserted between the inner border
edge and the outer padding edge. Any space taken up by the
scrollbars should be taken out of (subtracted from the dimensions
of) the containing block formed by the element with the scrollbars."
dbaron: So it doesn't say that the width is changed.
... Reason may the case when 'width' is not 'auto'.
Arron: You don't want to make the box bigger when you add scrollbars.
... So the content box width has to shrink.
dbaron: But the value of 'width' doesn't change, and is thus different
from the content box.
dbaron: Is this different for 'height'?
... Assume the block has 'height: auto'
... Does the vertical scrollbar make the box taller?
plinss: No tests for this I think? Should we skip the issue?
Arron: No need to change the spec, it seems.
plinss: Scrolling has always been a UA-dependent thing.
fantasai: Still in scope for CSS, thought maybe not for CSS 2.1.
Arron: Define some tests later and write it into CSS then.
RESOLVED: no action on 208
<smfr> http://wiki.csswg.org/spec/css2.1#issue-219
Topic: issue 219
<fantasai> http://lists.w3.org/Archives/Public/www-style/2011Feb/0669.html
[fantasai proposed text]
RESOLVED: fantasai's text accepted.
<johnjan> http://wiki.csswg.org/spec/css2.1#issue-244
Topic: issue 244
Topic: Issue 245
JohnJan: No change needed.
fantasai: Could do in in level 3.
RESOLVED: no changes for issues 245
Topic: issue 244
dbaron: depends on defining rendering tree.
<johnjan> we are not going to be able to define rendering tree in CSS21
fantasai: should we still add that it depends on rendering tree, even
if the rendering tree is undefined?
<dbaron> http://www.w3.org/TR/CSS21/about.html#organization is quite
out of date
RESOLVED: no change for 244
<dbaron> (but we agree that it *is* the rendering tree)
<johnjan> http://wiki.csswg.org/spec/css2.1#issue-211
Topic: Issue 211
dbaron: Before margin collapsing text was reorganzized, there was a
contradiction.
... We had rules "A collapses with B" and "C does not collapse with D"
and we assumed rules were transitive.
... We should only define what *does* collapse.
fantasai: New text indeed moved in that direction.
dbaron: We had a case with element with bottom and top collapsing together
and the bottom collapsing with parent bottom, or not.
... It was possible that top and bottom were forbidden from collapsing,
but both collapsed with the same other margins, so should collapse
because of transitivity.
Arron: You have a proposal?
dbaron: My proposal might be against an old version of the spec.
<dbaron> bottom margin of a last in-flow child and bottom margin of its
parent if the parent has 'auto' computed height
<dbaron> bottom margin of a last in-flow child and bottom margin of its
parent if the parent has 'auto' computed height and '0' computed
'min-height'
... Change in bullet 3.3 in 2nd list of 8.3.1.
... Because the 4th bullet mentions zero 'min-height' and the 3rd doesn't.
<fantasai> http://wiki.csswg.org/spec/css2.1#issue-234 is related
<dbaron>
http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Cstyle%3E%0A%23one%20%7B%20min-height%3A%202px%20%7D%0A%23one%2C%20%23two%20%7B%20margin-bottom%3A%201em%20%7D%0A%3C%2Fstyle%3E%0A%3Cdiv%20id%3D%22one%22%3E%3Cdiv%20id%3D%22two%22%3EHello%3C%2Fdiv%3E%3C%2Fdiv%3E%0AWorld%0A
dbaron: This morning we discussed 234. Ignore Gecko for that, because it
has a bug.
<dbaron>
http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Cstyle%3E%0A.one%2C%20.three%20%7B%20min-height%3A%202px%20%7D%0A.one%2C%20.two%20%7B%20margin-bottom%3A%201em%20%7D%0A.three%20%7B%20margin%3A%201em%200%7D%0A%3C%2Fstyle%3E%0A%3Cdiv%20class%3D%22one%22%3E%3Cdiv%20class%3D%22two%22%3EHello%3C%2Fdiv%3E%3C%2Fdiv%3E%0AWorld%0A%0AHello%0A%3Cdiv%20class%3D%22three%22%3E%3C%2Fdiv%3E%0AWorld
JohnJan: Seem FF does it the same as everybody else, though.
dbaron: So whether 'min-height' stops collapsing depends on whether it's
own bottom and top margins collapse.
... That test case is wrong.
<dbaron>
http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Cstyle%3E%0A%23one%20{%20min-height%3A%202px%20}%0A%23one%2C%20%23two%20{%20margin-bottom%3A%201em%20}%0A%3C%2Fstyle%3E%0A%3Cdiv%20id%3D%22one%22%3E%3Cdiv%20id%3D%22two%22%3EHello%3C%2Fdiv%3E%3C%2Fdiv%3E%0AWorld%0A
... Say you have an elt with a 'min-height'. Its margins don't collapse.
Now add an empty child. Now it's margins do collapse.
<dbaron>
http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Cstyle%3E%0A.one%2C%20.three%20%7B%20min-height%3A%202px%20%7D%0A.one%2C%20.two%20%7B%20margin-bottom%3A%201em%20%7D%0A.three%20%7B%20margin%3A%201em%200%7D%0A%3C%2Fstyle%3E%0AHello%0A%3Cdiv%20class%3D%22one%22%3E%3Cdiv%20class%3D%22two%22%3E%3C%2Fdiv%3E%3C%2Fdiv%3E%0AWorld%0A%0AHello%0A%3Cdiv%20class%3D%22three%22%3E%3C%2Fdiv%3E%0AWorld
<dbaron> current spec says that last testcase should have a 1em gap and
then a 2em gap
fantasai: Should 3rd bullet check whether min-height has an effect, or
whether it is set?
dbaron: The latter, otherwise infinite loop is possible.
... Gecko still does the former, but has an explicit loop detector.
<dbaron>
http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Cstyle%3E%0A.one%2C%20.three%20%7B%20min-height%3A%202px%20%7D%0A.one%2C%20.two%20%7B%20margin-bottom%3A%201em%20%7D%0A.three%20%7B%20margin%3A%201em%200%7D%0A%3C%2Fstyle%3E%0AShould%20have%20a%201em%20gap%3A%3Cbr%3E%0AHello%0A%3Cdiv%20class%3D%22one%22%3E%3Cdiv%20class%3D%22two%22%3E%3C%2Fdiv%3E%3C%2Fdiv%3E%0AWorld%0A%3Chr%3E%0AShould%20have%20a%201em%20gap%3A%0A%3Cdiv%20class%3D
<dbaron>
%22one%22%3E%3Cdiv%20class%3D%22two%22%3EHello%3C%2Fdiv%3E%3C%2Fdiv%3E%0AWorld%0A%3Chr%3E%0AShould%20have%20a%202em%20gap%3A%0AHello%0A%3Cdiv%20class%3D%22three%22%3E%3C%2Fdiv%3E%0AWorld
<fantasai> That brings me to a brilliant suggestion. How about a
"min-height: contains-floats" keyword, so we can get rid of
all this clearfix junk?
RESOLVED: no change for issue 211
<johnjan> http://wiki.csswg.org/spec/css2.1#issue-247
Topic: issue 247
<dbaron> 9.2.1.1: "When such an inline box is affected by relative
positioning, the relative positioning also affects the
block-level box contained in the inline box. "
dbaron: The test case in the e-mail isn't right. There is a third answer,
which he didn't consider.
<dbaron> I think the test in
http://lists.w3.org/Archives/Public/www-style/2010Nov/0444.html
is only considering 2 possible answers when there are really three
<dbaron>
http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Chtml%3E%0A%3Chead%3E%0A%3Ctitle%3ETest%20of%20position%3Aabsolute%20containing%20block%20when%20closest%20element%20differs%20from%20closest%20box%3C%2Ftitle%3E%0A%3C%2Fhead%3E%0A%3Cbody%3E%0A%3Cdiv%20style%3D%22margin%3A%200%20100px%22%3E%0A%3Cp%3EHere%20is%20a%20paragraph%20containing%20a%20%3Cspan%20style%3D%22position%3Arelative%3B%22%3Eposition%3Arelative%20span%20that%20is%
<dbaron>
20split%20by%20a%20%3Cspan%20style%3D%22display%3Ablock%22%3Eblock-level%20element%20that%20contains%20a%20%3Cspan%20style%3D%22left%3A0%3B%20position%3Aabsolute%3B%20background-color%3Acyan%3B%22%3Eposition%3Aabsolute%20span%3C%2Fspan%3E%20...%20%3Cbr%20%2F%3E%20in%20the%20middle%20of%20it%3C%2Fspan%3E%20before%20this%20remainder%20of%20the%20position%3Arelative%20span%3C%2Fspan%3E%20and%20the%20rest%20of%20the%20paragraph.%3C%2Fp%3E%0A%3C%2Fdiv%3E%0A%3C%2Fbo
<dbaron> dy%3E%0A%3C%2Fhtml%3E
<dbaron> http://dbaron.org/css/test/2011/css21-issue-247
Bert: Is this different from issue 215 from this morning?
dbaron: Issue is that relative pos "affects" the block inside, but not
specified how.
... Nobody does the behavior that I would have liked for that test case.
plinss: So we should make it unefined?
dbaron: Maybe we already did...
<johnjan> Remain undefined in 2.1. Need to verify that this remains
undefined after today's other edits.
fantasai: ... The other edits make inside inline undefined. Is that
inside the box tree or the element tree?
RESOLVED: Undefined via 215.
ACTION dbaron verify that once issue 215 is edited, that the case for
issue 247 is also undefined
<trackbot> Created ACTION-309
Brad: It would make more sense from a web author's perspective for the
relposed <span> to establish the containing block for any abspos
elements inside it, even if they're inside a block that's inside
the <span>.
<johnjan> http://wiki.csswg.org/spec/css2.1#issue-248
Topic: issue 248
<dbaron> http://lists.w3.org/Archives/Public/www-style/2010Dec/0020.html
dbaron: Interesting case is a zero-height float followed by a 1px high
float and the latter is wider.
... Zero-height float can only shorten line box if they have been pushed
down to fall in the middle of a line box.
... Hard to find whether this is implemented correctly, because of other bugs.
... There should be test cases in the test suite already.
... Maybe the float-wrap-top set.
<dbaron>
http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Cdiv%3E%0A%20%20%3Cdiv%20style%3D%22float%3A%20left%3B%20width%3A%2050px%3B%20height%3A%206px%3B%20background%3Ayellow%22%3E%3C%2Fdiv%3E%0A%20%20%3Cdiv%20style%3D%22float%3A%20left%3B%20clear%3A%20left%3B%20width%3A%20100px%3B%20height%3A%200px%3B%20background%3Ared%22%3E%3C%2Fdiv%3E%0A%20%20%3Cdiv%3EHello%20world%3C%2Fdiv%3E%0A%3C%2Fdiv%3E
dbaron: IE seems to do the zero-height float correctly.
... But probably the only browser to do so.
... There probably is no issue. But may need more tests to add later.
RESOLVED: No change for issue 248
<johnjan> http://wiki.csswg.org/spec/css2.1#issue-250
Topic: issue 250
Bert: fantasai's proposed text looks fine.
RESOLVED: use fantasai's proposed text on issue 250.
[Some more discussion about 250: should space not only be allowed, but
required? Result: no.]
<johnjan> http://wiki.csswg.org/spec/css2.1#issue-252
Topic: Issue 252
dbaron: I think Boris's response is wrong, though.
-> http://lists.w3.org/Archives/Public/www-style/2011Jan/0092.html
Boris's response
dbaron: BAD_STRING is not allowed in a block, it seems.
plinss: What does it mean to have a BAD_STRING in a block?
<dbaron> I think BAD_* should be in any
Bert: But the grammar defines what is valid, and BAD_STRING is never valid.
dbaron: But then we have no rules for dealing with the error.
Bert: Those rules are there: skip to the end of the block (or the decl,
as the case may be).
plinss: Do we need to do anything in CSS 2.1?
<dbaron> (maybe not BAD_COMMENT)
<dbaron> 4.1.1 says "The meaning of input that cannot be tokenized or parsed
is undefined in CSS 2.1. "
<dbaron> and we don't want all this error handling to fall into that clause
dbaron: Last sentence of 4.1.1 says unparsable means undefined. But we
have error rules.
<dbaron> Proposal:
dbaron: My proposal is to add BAD_URI and BAD_STRING to the "any" production.
<dbaron> ... and then change "COMMENT tokens do not occur" to "COMMENT and
BAD_COMMENT tokens do not occur"
Bert: Counterproposal is to leave the grammar defining valid CSS, and add
in 4.1.6. s/any tokens/any tokens (except BAD* tokens)/
dbaron: We should remove the sentence "The meaning of input that cannot be
tokenized or parsed is undefined in CSS 2.1 from 4.1.1
plinss: It talks about the tokens that cannot be parsed.
dbaron: But it makes the whole style sheet undefined.
Arron: Usually we talk about "the part of the style sheet" so this seems
to be about the whole style sheet.
plinss: I think parsing is covered by 4.2
dbaron: But what makes something a declaration that you can ignore is the
grammmar.
<dbaron> dbaron: OK, let's just leave it, and fix it in css3.
plinss: Objection to DB's proposal?
Arron: We can always change it back in errata.
dbaron: We can just leave it unchanged.
RESOLVED: No change in 252
<mihara> I ask for Tokyo forum to be discussed in Tue afternoon.
I am not here on Wed.
* sylvaing still has a few 'I have standards' IE9 t-shirts....
* gsnedders appears looking vaguely interested
* gsnedders (in the t-shirt, not in CSS)
<jdaggett> http://www.amazon.com/Avoid-Huge-Ships-John-Trimmer/dp/0870334336/ref=sr_1_1?ie=UTF8&qid=1299540509&sr=8-1
<jdaggett> hint: read the comments!
* sylvaing this seems similar to http://www.amazon.com/Mountain-Three-Wolf-Short-Sleeve/dp/B002HJ377A
* sylvaing I think this is the t-shirt for gsnedders
* gsnedders sylvaing: pff, wolves, not vampires… *shakes head*
* gsnedders sylvaing: there again, I presume the IE9 shirt doesn't haveLayout,
so is just a bunch of random shapes scattered over the shirt
<johnjan> http://wiki.csswg.org/spec/css2.1#issue-253
Topic: Issue 253
plinss: Are we OK with the proposed change of [??]?
dbaron: Relates to last large DL of 4.2.
... Possible to reach end of style sheet and end of string at the same time.
... Should be more clear what end of line means.
<johnjan> http://wiki.csswg.org/spec/css2.1#issue-254
RESOLVED: say in 4.2 more clearly what end of line means.
[That means end of line is a particular character from \r\n]
Topic: Issue 254
Daniel: Does this need edits?
dbaron: Probably not.
fantasai: Issue may be about whether the "-->" in the e-mail is a statement.
Daniel: I propose no chnage.
<johnjan> http://wiki.csswg.org/spec/css2.1#issue-255
RESOLVED: no change for 254
Topic: Issue 255
JohnJan: Just say "HTML specifications"
Daniel: Cannot reference HTML5 as it is not a REc.
Daniel: Just add "in HTML"
Tantek: *any version* of HTML.
plinss: How about XForms?
RESOLVED: "and future versions" added to to section 3.1 for issue 255.
Topic: issue 256
<johnjan> http://wiki.csswg.org/spec/css2.1#issue-256
plinss: Leave it as is.
RESOLVED: No change for issue 256.
<johnjan> http://wiki.csswg.org/spec/css2.1#issue-257
Topic: Issue 257
plinss: I think we do want boxes to have properties.
dbaron: I agree.
plinss: So no chnage?
RESOLVED: no change for issue 257
Topic: Issue 259
<johnjan> http://wiki.csswg.org/spec/css2.1#issue-259
Daniel: Indeed the 'inherit' keyword is never the computed value.
howcome: In css3-values, 'inherit' is not the specified value.
dbaron: We might have changed that already.
Daniel: If 'inherit' is not returned as the specified value, that
breaks editors.
fantasai: Have to distinguish from what the CSSOM says: CSS specified
value is not the same as CSSOM specified value.
howcome: There is a "cascaded value" also, explained in css3-values.
That is what editors need.
... The text in CSS 2.1 is consistent with css3-values.
plinss: So no change?
JohnJan: And do something in level 3?
TabAtkins: Better not have level 3 contradict level 2.
HL/JohnJan: Bahevior isn't different, there is just different terms:
cascaded values.
fantasai: Inconsistency between 3 and 2 is the missing term cascaded value.
... Could add a note about that.
ACTION fantasai: write a proposed text for issue 259
<trackbot> Created ACTION-310
<johnjan> http://wiki.csswg.org/spec/css2.1#issue-260
Topic: issue 260
fantasai: We added that note to clarify something else. Opinions differ
on what is more or less confusing. So no change.
RESOLVED: no change for issue 260
Topic: Issue 261
Daniel: Nobody ever complained. Seems not worth a chnage.
plinss: Is this already in Selectors spec?
Daniel: No, that has the same prose as 2.1.
plinss: No change needed. Selectors is a clearer, that's good enough.
RESOLVED: No change issue 261
[Discussion about issues list and numbers, duplicates]
JohnJan: Issue 262 seems duplicate of 261 and 260.
<johnjan> http://wiki.csswg.org/spec/css2.1#issue-262
Topic: Issue 262
plinss: Propose no change for issue 262.
RESOLVED: No change issue 262
[Discussion about what is best way to deal with minor editorial issues.
At this point, just rejecting it is best, no risk of errors.]
<johnjan> http://wiki.csswg.org/spec/css2.1#issue-263
Topic: Issue 263
Steve: Maybe we can make a boilerplate text for all these editorial
rejected issues.
... For when we reply to the submitter of the issue.
plinss: Seems same case again: Edit is nice to have, but not needed now.
RESOLVED: no change for issue 263
<johnjan> http://wiki.csswg.org/spec/css2.1#issue-264
Topic: Issue 264
dbaron: We discussed zero-height floats already today.
JohnJan: Did the earlier discussion affect this issue?
dbaron: No. The note in the issue is wrong.
RESOLVED: accept change proposed in the issue e-mail for issue 264.
Topic: Issue 265
RESOLVED: No change issue 265
Topic: Issue 266
<johnjan> http://wiki.csswg.org/spec/css2.1#issue-266
fantasai: I think we should make the suggested edits, they fix what we
missied in the previous round for issue 120.
JohnJan: And the ones you were not sure about?
... Issue 3 in the linked e-mail.
[it's about whether table-caption is block-level]
Arron: Doesn't seem to hurt anything to make it block-level.
fantasai: If we don't fix it, we'll have to do it in errata anyway.
[Discussion about how 'overflow' might apply if flex box is added to CSS]
JohnJan: So take none of them, except issue 6.
fantasai: What does Bert think?
Bert: I don't know yet.
RESOLVED: Accept issue 6, defer the others to the errata.
[Above is for issue 266]
Topic: Issue 267
<johnjan> http://wiki.csswg.org/spec/css2.1#issue-267
dbaron: The proposed edit matches impls that I tested.
<dbaron> test is http://dbaron.org/css/test/2011/css21-issue-267
<dbaron> (question is which is on top)
<dbaron> actually, it doesn't test the issue
dbaron: I think it is editorial.
<dbaron> actually, hold on
<bradk> 268 and 269 should be
http://lists.w3.org/Archives/Public/www-style/2011Jan/0087.html
right?
dbaron: Two browsers do one thing, two do the other.
... The proposal matches Opera and Webkit.
RESOLVED: Accept propsoed edit for issue 267.
<johnjan> http://wiki.csswg.org/spec/css2.1#issue-268
Topic: Issue 268
<johnjan> http://wiki.csswg.org/spec/css2.1#issue-203
<johnjan> http://lists.w3.org/Archives/Public/www-style/2010Sep/0665.html
Topic: Issue 203 (again)
JohnJan: Anton Prowse disagrees with our resolution.
-> http://lists.w3.org/Archives/Public/www-style/2010Sep/0665.html Anton's message
dbaron: The reason for the hypothetical top border is so as not to move
the element unnecessarily.
Arron: Test cases are all interoperable.
... See margin-collapse-clear-005
fantasai: Difficult to keep track of which clearance issues are the same
issue.
<johnjan> http://wiki.csswg.org/spec/css2.1#issue-268
<fantasai> http://lists.w3.org/Archives/Public/www-style/2011Jan/0644.html
<fantasai> resolved in that meeting
RESOLVED: 203 was already discussed and we allowed two behaviors.
(See issues list)
<dbaron> s/move the element/move the element up/
<dbaron> (I'm having trouble working out a testcase for why the hypothetical
border edge is useful, though.)
<dbaron> Though actually, maybe I'm misremembering the purpose.
<dbaron> Maybe it's to prevent contradictions.
Topic: Issue 268
fantasai: I think the spec is correct.
[People trying to find out what the issue is]
Arron: Quite a few test cases for this.
<johnjan> actual issue:
http://lists.w3.org/Archives/Public/www-style/2011Jan/0085.html
[Mumble mumble]
RESOLVED: No change for issue 268
[DB and EE discuss some case]
fantasai: All impls seem to agree on what the first formatted line is.
<johnjan> http://wiki.csswg.org/spec/css2.1#issue-269
Topic: Issue 269
fantasai: propose to change to edges of line box, instead of block.
RESOLVED: Use line box edges instea dof block edges in issue 269
<johnjan> http://wiki.csswg.org/spec/css2.1#issue-270
Topic: Issue 270
fantasai: I can propose a text.
dbaron: I might have some issues. I started implementing this.
RESOLVED: No change for issue 270. Do something in level 3.
<johnjan> http://wiki.csswg.org/spec/css2.1#issue-271
Topic: Issue 271
Arron: I think the colon in the spec was intended to mean "e.g."
[Discussion about what issues to discuss. Skip all editorial?]
<fantasai> http://lists.w3.org/Archives/Public/www-style/2010Dec/0312.html
<fantasai> Anton's list of substantive issues ^
dbaron: Turn the email into a wiki page so we can start dealing with it
<fantasai> http://wiki.csswg.org/spec/css2.1/anton-lc-2010
plinss: What can we discuss now?
... How dow we go through Anton's list?
Arron: I have made comments on many of the issues.
... Most of them I found need no change.
<johnjan> so Arron and Elika will get Anton's email into actionable issues
<johnjan> discuss on wednesday.
CSS2.1 Test failures
--------------------
plinss: Background-fixed 4 and 5 were expecting a fix in Gecko.
dbaron: Give me 15 seconds...
Simon: Last week we suggested to leave it undefined.
plinss: I agree with undefined. Unless we have a proposal for a spec change.
dbaron: Gecko might take a month to fix.
fantasai: bg-pos may apply to image with no intrinsic size.
Arron: Is it not already undefined?
dbaron: Might want to make it explicit, and say there is another spec
that defines it.
<fantasai> The background position of background images with an intrinsic
ratio and no intrinsic size is undefined in CSS2.1, see CSS3
Backgrounds and Borders.
RESOLVED: Change bg-pos of images as fantasai just wrote.
dbaron: So the test still needs fixing?
Topic: test bidi-breaking-2
fantasai: should be a may?
<fantasai> http://test.csswg.org/source/contributors/fantasai/submitted/css2.1/bidi-breaking-002.xht
<fantasai> bidi-breaking-002 should work now; removed the HTML <br> bit
of the test (since that's up in the air anyway)
<dbaron> http://test.csswg.org/suites/css2.1/latest/xhtml1/block-in-inline-relpos-002.xht
Topic: block-in-inline-relpos-002
plinss: What do we do with this one?
[DB trying to find out why various browsers fail.]
dbaron: Related to what we discussed earlier, about relative pos. affecting
nested block elements.
... Four browsers that all do different things.
[DB and PL notice that two versions on diff. platforms of Opera do different
things, too.]
[People looking over other people's shoulders to see what various browsers
do on different platforms...]
dbaron: Somebody should take an action to figure out what to do. And not me.
Arron: I can do it.
ACTION Arron: propose a solution for block-in-inline-relpos-002
<trackbot> Created ACTION-311
<howcome> content-computed-value-001
Topic: content-computed-value-001
RESOLVED: Remove the test
Topic: replaced-intrinsic-ratio-001
<smfr> we're going through the blocking tests on
http://wiki.csswg.org/test/css2.1/blocking
dbaron: Close to a patch for Gecko, just need to fix a few more existing
tests.
plinss: It seems to be testing multiple things.
fantasai: [something]
plinss: Are you going to define behavior?
fantasai: I might want to fix this.
... I will propose text.
... For the spec.
howcome: Is this an SVG issue?
fantasai: Yes, affects all SVG that doesn't have a fixed size (i.e.
scalable SVG)
RESOLVED: Change the spec in some way.
fantasai: Proposal is to make sizing of replaced elements with intrinsic
ratio but no size undefined.
RESOLVED: ... and put the current rule in level 3 instead.
Bert: It was put in on request from SVG wasn't it?
<fantasai> no, it was put in a long time ago because it was it wasn't defined
<fantasai> the test is failing because UAs misinterpreted SVG
Topic: uri-016
<johnjan> http://test.csswg.org/suites/css2.1/nightly-unstable/html4/uri-016.htm
plinss: We don't have the exit criteria from other CSS modules in the
CSS 2.1 spec,
... Difference is about experimental builds.
... Didn't we resolve to fix that already?
<fantasai> http://wiki.csswg.org/spec/css2.1#issue-272
RESOLVED: Update CSS 2.1 exit criteria to the current (CSS3 standard)
exit criteria, minus the 30-day implementation requirement.
[End of meeting for today]
Received on Saturday, 12 March 2011 06:41:35 UTC