IRC log of css on 2011-03-07

Timestamps are in UTC.

19:10:45 [RRSAgent]
RRSAgent has joined #css
19:10:45 [RRSAgent]
logging to
19:11:07 [TabAtkins_]
RESOLVED: Do not propagate direction from <body> to <html>.
19:11:27 [hyatt]
that will be a compatibility issue
19:11:36 [hyatt]
i guess we'll do it in quirks mode. sigh.
19:11:44 [TabAtkins_]
johnjan: We're willing to take the behavior as a bug.
19:12:36 [TabAtkins_]
dbaron: For issue 240, I thought we already said that min/max-width was undefined.
19:12:52 [TabAtkins_]
RESOLVED: For issue 240, min/max-width on internal table elements is undefined.
19:16:38 [TabAtkins_]
alexmog: A problem - if you set overflow and direction on <body>, you get bad behavior.
19:17:07 [TabAtkins_]
alexmog: Can we say the same thing as overflow?
19:17:31 [TabAtkins_]
dbaron: That's weird because if you have <html dir=ltr><body dir=rtl>, the rtl will propagate to <html> invisibly.
19:17:50 [dbaron]
(alternative is just saying to use the value from body... though that's really not particularly different.)
19:20:03 [hyatt]
TabAtkins_: in webkit body direction only propagates to html direction if html doesnt' set it
19:20:13 [hyatt]
TabAtkins_: (similar to background propagation)
19:21:15 [dbaron]
hyatt, what does "doesn't set it" mean?
19:21:23 [dbaron]
hyatt, background propagation does it based on whether background-image is none
19:21:30 [dbaron]
hyatt, does it mean whether direction is ltr?
19:21:44 [hyatt]
dbaron: we actually detect if any CSS rule sets direction to any value
19:21:46 [hyatt]
on the HTML
19:22:00 [dbaron]
We've never had anything like that in the spec
19:22:03 [hyatt]
actually maybe we don't do that
19:22:04 [dbaron]
we shouldn't cross the value computation line
19:22:04 [hyatt]
let me double check
19:22:20 [dbaron]
compute values -> do something with the computed values
19:22:22 [mihara]
mihara has joined #css
19:22:38 [hyatt]
yeah that is what we do
19:22:46 [hyatt]
we set a flag if direction is ever set on the html
19:23:28 [dbaron]
is that what IE also does?
19:23:33 [hyatt]
i cant' remember if i arrived at that because it's what IE did
19:23:43 [hyatt]
i discussed it in the bug at the time let me try to find
19:23:46 [TabAtkins_]
dbaron: If we propagate, we have to decide how to propagate,and what Hyatt's describing for Webkit's behavior is pretty weird.
19:24:20 [hyatt]
not that weird. to an author, the concept of setting the direction explicitly via a rule is a simple one
19:24:26 [hyatt]
it's just weird since we have never done it before
19:25:49 [johnjan]
entire room is easily distracted by ropes flailing outside the window...
19:25:55 [hyatt]
the simpler option might be to just ignore the html whne body sets it
19:26:03 [hyatt]
i.e., just always propagate body
19:26:17 [dbaron]
which I think is fine since direction's inherited anyway
19:26:17 [hyatt]
i think that is what ie does
19:26:24 [dbaron]
I'd prefer that
19:27:08 [hyatt]
19:27:39 [fantasai]
why are FF and Opera getting away with not doing this, if it's a web compat issue?
19:28:26 [hyatt]
looks like my main reasoning for not ignoring the html was just:
19:28:27 [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.
19:28:27 [hyatt]
19:28:37 [hyatt]
so if the spec told me it was ok i'd have matched WinIE :)
19:28:45 [hyatt]
i was just concerned about ignoring the value on the html
19:28:50 [hyatt]
since that sounded like violating the spec language
19:29:18 [hyatt]
so o
19:29:29 [hyatt]
i'm fine with making body just overwrite html
19:29:35 [hyatt]
would just need the spec to say so
19:31:13 [fantasai]
well, CSS2.1 assigns a 'direction' value to HTML whether one's set explicitly or not
19:31:19 [fantasai]
so you're violating the spec either way
19:31:24 [fantasai]
by doing this at all
19:31:33 [alexmog]!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
19:31:51 [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
19:32:07 [hyatt]
it's broken out from another bug
19:32:12 [hyatt]
let me keep digging
19:33:08 [hyatt]
vaguely remember some dhtml menu on israeli sites not positioning properly
19:33:44 [hyatt]
used right: but didn't get computed correctly because the icb wasn't properly rtl or something
19:33:58 [fantasai]
dbaron: We use the direction of body to determine the scrolling direction of the viewport
19:34:07 [fantasai]
dbaron: But we don't actually propagate the 'direction' property
19:34:07 [TabAtkins_]
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.
19:34:17 [dbaron]
s/scrollbars for the root/scrollbars for the ICB/
19:35:24 [TabAtkins_]
dbaron: We don't want a "propagated if not specified" in CSS.
19:36:08 [TabAtkins_]
glazou: Let's move on. We're not making immediate progress.
19:36:24 [dbaron]
issue 241:
19:37:37 [dbaron]
I'd by happy to just make the change √ėyvind suggests
19:37:53 [dbaron]
(change the spec)
19:38:31 [Kazutaka]
Kazutaka has joined #CSS
19:38:56 [dbaron]!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
19:38:58 [dbaron]
is a simple testcase
19:39:01 [TabAtkins_]
RESOLVED: Accept the spec change for 241.
19:39:06 [TabAtkins_]
glazou: Now issue 242.
19:41:15 [TabAtkins_]
dbaron: I think we just need to action for a proposal.
19:43:38 [TabAtkins_]
dbaron: I don't think anything has to be undefined here. We do need to make the change for consecutive block boxes.
19:44:28 [fantasai]
might be able to handle white space interaction in the phantom line boxes clause
19:46:41 [dbaron]
19:46:55 [TabAtkins_]
johnjan: There are some issues, starting with 142, that need an action for Bert edit.
19:50:36 [TabAtkins_]
dbaron: As far as I can tell fro mreading the spec, the containing block for a child of a table cell, is the block that contains the table, which seems like a bug.
19:51:03 [TabAtkins_]
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.
19:51:57 [TabAtkins_]
fantasai: I think the table cell should be a containing block for the inner table cell box.
19:52:05 [TabAtkins_]
dbaron: Is "inner table cell box" even in the spec yet?
19:52:11 [TabAtkins_]
fantasai: I don't think so.
19:52:23 [dbaron]
s/for the inner table cell box/for the boxes inside the cell/
19:53:22 [TabAtkins_]
dbaron: What Boris is talking about is what the containing block is for an inner table element, like table-row.
19:55:48 [TabAtkins_]
Bert: I think the table-cell is fine; I believe the question was only about anonymous table-cells.
19:56:46 [TabAtkins_]
<br type=lunch duration=1h>
19:58:03 [stearns]
stearns has left #css
20:19:01 [TabAtkins_]
TabAtkins_ has joined #css
20:25:56 [sylvaing]
sylvaing has joined #css
20:30:54 [bradk]
bradk has joined #css
20:32:20 [glazou]
glazou has joined #css
20:36:58 [W3C-CSS]
W3C-CSS has joined #css
20:38:31 [davve`]
davve` has joined #css
20:38:43 [arno]
arno has joined #css
20:38:54 [davve`]
davve` has left #css
20:41:12 [plinss_]
plinss_ has joined #css
20:43:09 [arno]
arno has left #css
20:43:20 [arno]
arno has joined #css
20:47:42 [stearns]
stearns has joined #css
20:56:03 [fantasai]
sylvaing: Can you answer ? :-)
20:57:00 [shonda]
shonda has joined #css
21:01:59 [Bert]
Scribe: Bert
21:02:07 [Bert]
Scribenick: Bert
21:02:19 [dbaron]
To remind myself...we have 22 people for dinner at tonight at 7pm.
21:02:37 [Bert]
Topic: CSS 2.1 issues (continued)
21:03:55 [Bert]
Topic: Issue 142
21:05:15 [Bert]
-> Bert's proposal
21:07:14 [Bert]
DB: So it seems we have a proposal. Somebody needs to respond to Boris.
21:07:28 [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
21:08:25 [Bert]
Bert: Is that not what my proposed text does?
21:09:31 [Bert]
DB: Needs to be explained better.
21:11:04 [Bert]
PL: So we are still stuck on this issue?
21:11:32 [Bert]
DB: [reading the texts]
21:12:33 [Bert]
... In 2c, rule is skipping anonymous boxes.
21:12:44 [Bert]
... That may skip the table cell.
21:13:43 [Bert]
-> Boris' last reply
21:14:09 [Bert]
JJ: It seems Boris essentially agrees, with maybe clarification.
21:15:09 [mihara]
mihara has joined #css
21:15:13 [Bert]
DB: I think anonymous boxes should not be skipped.
21:15:33 [Bert]
BB: They should be, except for anonymous table cells.
21:15:47 [Bert]
EE: They aren't all skipped.
21:16:00 [dbaron]
And I think this makes the definition of containing block deviate from the definition of the box tree.
21:16:21 [Bert]
PL: Are there functional changes? Or only editorial?
21:16:37 [mi]
mi has joined #css
21:16:42 [Bert]
EE: We should have only one possible interpretation of the spec.
21:17:18 [Bert]
PL: If there is no test in the suite that shows the difference, then let's defer this.
21:17:42 [Bert]
RESOLVED: no change, pusj to errata
21:17:56 [Bert]
Topic: issue 192
21:18:37 [Bert]
TA: What happens to content that precedes the float in the source.
21:19:01 [Bert]
... Implementations never move such content down.
21:19:10 [Bert]
... Instead, they move the float down.
21:19:22 [Bert]
DB: That is what the spec says should happen.
21:19:53 [Bert]
... Float constraint include that top of float must not be above prior content.
21:20:06 [johnjan]
21:20:09 [Bert]
... So float *has* to be pushed down.
21:20:28 [Bert]
... That is not stated explicitly, only as implicit result of the constraints.
21:20:37 [Bert]
TA: OK, so that everything is fine.
21:20:47 [Bert]
DB: Might be wordt a note in the spec.
21:21:46 [Bert]
-> Bert's msg on 192
21:21:53 [Bert]
PL: WHo is writing that note?
21:22:00 [Bert]
TA: I could
21:22:03 [Bert]
DB: I could, too.
21:22:18 [johnjan]
21:23:08 [Bert]
ACTION dbaron: write such a note for issue 192.
21:23:08 [trackbot]
Created ACTION-307 - Write such a note for issue 192. [on David Baron - due 2011-03-14].
21:23:16 [Bert]
Topic: issue 199
21:23:36 [Bert]
-> Issue 199
21:24:08 [Bert]
-> Tab's proposal
21:24:57 [Bert]
TA: I think I didn not test vertical and horizontal margins seperately
21:25:08 [Bert]
DB: That may make a difference.
21:26:00 [Bert]
DB: "The auto position" is a bit vague. Needs to be defined.
21:26:26 [Bert]
PL: Any tests for this?
21:27:13 [Bert]
JJ: Leave text as TAb proposed, with edit for "static" and then add tests after PR.
21:27:42 [Bert]
RESOLVED: as JJ just said.
21:27:49 [johnjan]
21:27:58 [Bert]
Topic: Issue 204
21:28:45 [Bert]
EE: Bert sent an e-mail, which is not yet in this list.
21:29:20 [Bert]
... Probably wherever it says "Bert edit" we don't have to discuss now.
21:29:25 [Bert]
Topic: Issue 207
21:29:32 [johnjan]
21:29:42 [Bert]
-> Issue 207
21:32:26 [Bert]
DB: What do implementtions do?
21:33:03 [Bert]
AE: Impls are interoperable.
21:34:07 [Bert]
DB: ... Is the same as margin collapse clear test case.
21:34:18 [dbaron]
21:34:20 [Bert]
JJ: Spec remains underdefined.
21:35:00 [Bert]
... Is there an edit to do, or an errata later?
21:36:19 [Bert]
PL: Any proposals?
21:36:41 [fantasai]
ACTION fantasai find margin-collapse-clear-005 issue and make sure it's in the issues list for editing
21:36:41 [trackbot]
Created ACTION-308 - Find margin-collapse-clear-005 issue and make sure it's in the issues list for editing [on Elika Etemad - due 2011-03-14].
21:39:14 [Bert]
[People trying to understand...]
21:41:10 [Bert]
DB: Defer to errata?
21:42:23 [Bert]
AE: Seems possible, yes.
21:42:31 [johnjan]
21:42:51 [Bert]
RESOLVED: no action on 207
21:42:57 [Bert]
Topic: issue 208
21:44:53 [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. "
21:45:51 [Bert]
DB: So it doesn't say that the width is changed.
21:46:24 [Bert]
... Reason may the case when 'width' is not 'auto'.
21:46:49 [Bert]
AE: You don't want to make the box bigger when you add scrollbars.
21:47:09 [Bert]
... So the content box width has to shrink.
21:47:34 [Bert]
DB: But the value of 'width' odesn't change, and is thus different from the content box.
21:48:04 [dbaron]
21:48:44 [Bert]
DB: Is this different for 'height'?
21:49:09 [Bert]
... Assume the block has 'height: auto'
21:49:48 [Bert]
... Does the vertical scrollbar make the box taller?
21:52:08 [Bert]
PL: No tests for this I think? Should we skip the issue?
21:53:03 [Bert]
AE: No need to change the spec, it seems.
21:53:18 [Bert]
PL: Scrolling has always been a UA-dependent thing.
21:53:32 [Bert]
EE: Still in scope for CSS, thought maybe not for CSS 2.1.
21:54:05 [Bert]
AE: Define some tests later and write it into CSS then.
21:54:25 [Bert]
RESOLVED: no action on 207
21:54:31 [smfr]
21:54:39 [Bert]
Topic: issue 219
21:55:34 [fantasai]
21:56:32 [Bert]
[EE proposed text]
21:56:53 [Bert]
RESOLVED: EE's text accepted.
21:57:38 [johnjan]
21:57:44 [Bert]
Topic: issue 244
21:58:39 [Bert]
Topic: Issue 245
21:58:53 [Bert]
JJ: No change needed.
21:58:59 [Bert]
EE: Could do in in level 3.
21:59:44 [Bert]
RESOLVED: no changes for issues 245
21:59:49 [Bert]
Topic: issue 244
22:02:38 [Bert]
DB: depends on defining rendering tree.
22:03:52 [johnjan]
we are not going to be able to define rendering tree in CSS21
22:03:59 [Bert]
EE: should we still add that it depends on rendering tree, even if the rendering tree is undefined?
22:04:19 [dbaron] is quite out of date
22:04:21 [Bert]
RESOLVED: no chnage for 244
22:04:32 [Bert]
22:04:49 [dbaron]
(but we agree that it *is* the rendering tree)
22:04:52 [johnjan]
22:05:08 [Bert]
Topic: Issue 211
22:05:50 [Bert]
DB: Before margin collapsing text was reorganzized, there was a contradiction.
22:06:37 [Bert]
... We had rules "A collapses with B" and "C does not collapse with D" and we assumed rules were transitive.
22:06:50 [Bert]
... We should only define what *does* collapse.
22:07:05 [Bert]
EE: New text indeed moved in that direction.
22:07:43 [Bert]
DB: We had a case with element with bottom and top collapsing together and the bottom collapsing with parent bottom, or not.
22:08:41 [Bert]
... 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.
22:09:01 [Bert]
AE: You have a proposal?
22:09:46 [Bert]
DB: My proposal might be against an old version of the spec.
22:10:03 [dbaron]
bottom margin of a last in-flow child and bottom margin of its parent if the parent has 'auto' computed height
22:10:09 [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'
22:10:39 [Bert]
... Change in bullet 3.3 in 2nd list of 8.3.1.
22:11:31 [Bert]
... Because the 4th bullet mentions zero 'min-height' and the 3rd doesn't.
22:12:52 [Bert]
AE: Issue 225 is not related..
22:13:01 [fantasai]
22:13:09 [fantasai]
22:13:12 [fantasai]
is related
22:13:59 [dbaron]!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
22:14:12 [Bert]
DB: This morning we discussed 234. Ignore Gecko for that, because it has a bug.
22:15:23 [dbaron]!
22:16:19 [Bert]
JJ: Seem FF does it the same as everybody else, though.
22:18:11 [Bert]
DB: So whether 'min-height' stops collapsing depends on whether it's own bottom and top margins collapse.
22:18:27 [Bert]
... That test case is wrong.
22:19:46 [dbaron]!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
22:19:49 [Bert]
... Say you have an elt with a 'min-height'. It's margins don't collpse. Now add an empty child. Now it's margins do collapse.
22:19:56 [Bert]
22:20:06 [Bert]
22:20:52 [dbaron]!
22:20:59 [Bert]
22:22:02 [dbaron]
current spec says that last testcase should have a 1em gap and then a 2em gap
22:23:41 [Bert]
EE: Should 3rd bullet check whether min-height has an effect, or whether it is set?
22:23:56 [Bert]
DB: The latter, otherwise infinite loop is possible.
22:24:50 [Bert]
... Gecko still does the former, but has an explicit loop detector.
22:24:55 [dbaron]!
22:24:56 [dbaron]
22:25:24 [dsinger]
dsinger has joined #css
22:25:37 [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?
22:27:32 [Bert]
RESOLVED: no change for issue 211
22:27:49 [johnjan]
22:27:57 [Bert]
Topic: issue 247
22:31:20 [dbaron] "When such an inline box is affected by relative positioning, the relative positioning also affects the block-level box contained in the inline box. "
22:33:29 [Bert]
DB: The test cas ein the e-mail isn't right. There is a third answer, which he didn't consider.
22:33:33 [dbaron]
I think the test in is only considering 2 possible answers when there are really three
22:33:39 [Bert]
s/cas ein/case in/
22:34:45 [dbaron]!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%
22:34:45 [dbaron]
22:34:48 [dbaron]
22:36:17 [dbaron]
22:37:00 [Bert]
BB: Is this different from issue 215 from this morning?
22:37:25 [Bert]
DB: Issue is that relative pos "affects" the block inside, but not specified how.
22:38:14 [Bert]
... Nobody does the behavior that I would have liked for that test case.
22:39:00 [Bert]
PL: So we should make it nunefined?
22:39:10 [Bert]
DB: Maybe we already did...
22:40:02 [johnjan]
Remain undefined in 2.1. Need to verify that this remains undefined after today's other edits.
22:40:25 [Bert]
EE: ... The other edits make inside inline undefined. Is that inside the box tree or the element tree?
22:41:32 [dbaron]
ACTION dbaron verify that once issue 215 is edited, that the case for issue 247 is also undefined
22:41:32 [trackbot]
Created ACTION-309 - Verify that once issue 215 is edited, that the case for issue 247 is also undefined [on David Baron - due 2011-03-14].
22:42:13 [johnjan]
22:42:15 [Bert]
Topic: issue 248
22:42:48 [Bert]
22:44:38 [dbaron]
22:44:46 [fantasai]
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>.
22:46:23 [Bert]
DB: Interesting case is a zero-height float followed by a 1px high float and the latter is wider.
22:47:13 [Bert]
... Zero-height float can only shorten line box if they have been pushed donw to fall in the middle of a line box.
22:47:21 [Bert]
22:48:53 [Bert]
... Hard to find whether this is implemented correctly, because of other bugs.
22:50:30 [Bert]
... There should be test cases in the test suite already.
22:50:45 [Bert]
... Maybe the float-wrap-top set.
22:50:55 [homata_]
homata_ has joined #CSS
22:53:20 [dbaron]!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
22:53:46 [Bert]
DB: IE seems to do the zero-height float correctly.
22:53:59 [Bert]
... But probably the only browser to do so.
22:54:51 [Bert]
... There probably is no issue. But may need more tests to add later.
22:55:21 [Bert]
RESOLVED: No change for issue 248
22:55:36 [johnjan]
22:56:01 [Bert]
Topic: issue 250
22:56:21 [Bert]
BB: EE's proposed text looks fine.
22:56:39 [Bert]
RESOLVED: use EE's proposed text on issue 250.
22:56:42 [johnjan]
22:57:05 [Bert]
Topic: Issue 252
22:59:35 [Bert]
[Some more discussion about 250: should space not only be allowed, but required? Result: no.]
22:59:38 [johnjan]
23:00:16 [johnjan]
sorry, still on 252
23:01:10 [Bert]
DB: I think Boris's response is wrong, though.
23:01:29 [Bert]
-> Boris's response
23:01:58 [Bert]
DB: BAD_STRING is not allowed in a block, it seems.
23:03:21 [Bert]
PL: What does it mean to have a BAD_STRING in a block?
23:04:32 [dbaron]
I think BAD_* should be in any
23:04:58 [Bert]
BB: But the grammar defines what is valid, and BAD_STRING is never valid.
23:05:11 [Bert]
DB: But then we have no rules for dealing with the error.
23:05:44 [Bert]
BB: Those rules are there: skip to the end of the block (or the decl, as the case may be).
23:06:24 [Bert]
PL: Do we need to do anything in CSS 2.1?
23:06:47 [dbaron]
(maybe not BAD_COMMENT)
23:07:20 [dsinger]
dsinger has joined #css
23:08:25 [dbaron]
4.1.1 says "The meaning of input that cannot be tokenized or parsed is undefined in CSS 2.1. "
23:08:38 [dbaron]
and we don't want all this error handling to fall into that clause
23:08:49 [Bert]
DB: Last sentence of 4.1.1 says unparsable means undefined. But we have error rules.
23:09:56 [dbaron]
23:10:04 [Bert]
DB: My proposal is to add BAD_URI and BAD_STRING to the "any" production.
23:10:16 [tantek]
tantek has joined #css
23:10:30 [dbaron]
... and then change "COMMENT tokens do not occur" to "COMMENT and BAD_COMMENT tokens do not occur"
23:14:11 [Bert]
BB: Counterproposal is to leave the grammar dfining valid CSS, and add in 4.1.6. s/any tokens/any tokens (except BAD* tokens)/
23:15:46 [Bert]
DB: We should remobve the sentence "The meaning of input that cannot be tokenized or parsed is undefined in CSS 2.1.
23:15:55 [Bert]
... from 4.1.1
23:16:32 [Bert]
23:16:43 [Bert]
23:17:14 [Bert]
PL: It talks about the tokens that cannot be parsed.
23:17:26 [Bert]
DB: But it makes the whole style sheet undefined.
23:18:42 [Bert]
AE: Usually we talk about "the part of the style sheet" so this seems to be about the whole style sheet.
23:19:16 [Bert]
PL: I think parsing is covered by 4.2
23:21:05 [Bert]
DB: But what makes something a declaation that you can ignore is the grammmar.
23:22:49 [dbaron]
DB: OK, let's just leave it, and fix it in css3.
23:22:50 [Bert]
PL: Objection to DB's proposal?
23:22:59 [Bert]
AE: We can always change it back in errata.
23:23:08 [Bert]
DB: We can just leave it unchanged.
23:23:27 [Bert]
RESOLVED: No change in 252
23:27:22 [mihara]
I ask for Tokyo forum to be discussed in Tue afternoon. I am not here on Wed.
23:28:38 [myakura]
myakura has joined #css
23:30:14 [jdaggett]
23:30:19 [jdaggett]
hint: read the comments!
23:43:42 [johnjan]
23:46:10 [Bert]
Topic: Issue 253
23:50:35 [Bert]
PL: Are we OK with the proposed change of [??]?
23:50:57 [Bert]
DB: Relates to last large DL of 4.2.
23:51:41 [Bert]
... Possible to reach end of style sheet and end of string at the same time.
23:53:02 [Bert]
... Should be more clear what end of line means.
23:53:16 [johnjan]
23:54:26 [Bert]
RESOLVED: say in 4.2 more clearly what end of line means.
23:55:22 [Bert]
[That means end of line is a particular character from \r\n]
23:56:01 [Bert]
Topic: Issue 254
23:57:20 [Bert]
DG: Does this need edits?
23:57:30 [Bert]
DB: Probably not.
23:57:55 [Bert]
EE: Issue may be about whether the "-->" i the e-mail is a statement.
23:58:02 [Bert]
DG: I propose no chnage.
23:58:17 [johnjan]
23:58:41 [Bert]
RESOLVED: no chnage for 254
23:58:47 [Bert]
Topic: Issue 255
23:58:57 [Bert]