IRC log of CSS on 2010-08-23

Timestamps are in UTC.

06:44:47 [RRSAgent]
RRSAgent has joined #CSS
06:44:47 [RRSAgent]
logging to
06:47:44 [glazou]
RRSAgent, make logs public
06:50:19 [glazou]
RRSAgent, this meeting spans midnight
06:50:32 [glazou]
glazou has left #css
06:50:38 [glazou]
glazou has joined #css
06:50:38 [glazou]
glazou has left #css
06:50:54 [glazou]
glazou has joined #css
06:56:38 [glazou]
07:02:41 [dsinger]
dsinger has joined #css
07:03:35 [dbaron]
dbaron has joined #css
07:04:13 [TabAtkins_]
TabAtkins_ has joined #css
07:07:37 [howcome]
howcome has joined #css
07:07:54 [TabAtkins_]
ScribeNick: TabAtkins_
07:08:26 [mollydotcom]
mollydotcom has joined #css
07:09:17 [Arron]
Arron has joined #css
07:09:32 [alexmog]
alexmog has joined #css
07:10:01 [dstorey]
dstorey has joined #css
07:10:29 [TabAtkins_]
TabAtkins_ has joined #css
07:11:07 [TabAtkins_]
glazou: There are a few open issues with editorial work. I'd like to browse through them to see if they're ready.
07:11:15 [TabAtkins_]
glazou: First is issue 26 on bert
07:11:24 [TabAtkins_]
07:11:51 [tantek]
tantek has joined #css
07:12:17 [TabAtkins_]
Bert: For 26, I did do the edit, but it's not verified yet.
07:12:20 [TabAtkins_]
Bert: Same for 53.
07:12:39 [TabAtkins_]
Bert: For 56, not done yet.
07:12:44 [TabAtkins_]
Bert: 60, edited.
07:13:00 [TabAtkins_]
Bert: 69, edited.
07:13:07 [TabAtkins_]
Bert: 71, edited.
07:13:16 [TabAtkins_]
Bert: 73, edited
07:13:20 [TabAtkins_]
Bert: 84, edited
07:13:28 [TabAtkins_]
Bert: 85, edited
07:13:39 [TabAtkins_]
dbaron: 101, not done.
07:14:24 [TabAtkins_]
glazou: Anyone else who can pick up 101?
07:14:37 [TabAtkins_]
arronei: I can do a few testcases.
07:15:25 [TabAtkins_]
dbaron: I wrote a few tests. They're not submitted to the testsuite.
07:15:48 [TabAtkins_]
glazou: please send those tests to arronei
07:16:08 [TabAtkins_]
Issue 101 is reassigned to Arron.
07:16:10 [dbaron]
Figuring out what the text should be is the hard part...
07:16:16 [TabAtkins_]
Bert: 107, edited.
07:16:31 [TabAtkins_]
Bert: 109, not done yet.
07:16:58 [TabAtkins_]
Bert: Not sure if it can be done this week, but certainly next week.
07:17:27 [TabAtkins_]
glazou: So by the time of the next conf call?
07:17:29 [TabAtkins_]
Bert: Yes.
07:17:49 [TabAtkins_]
Bert: 110 relies on 109.
07:18:12 [TabAtkins_]
glazou: Was john daggett supposed to be here?
07:18:21 [TabAtkins_]
howcome: Yeah, we're missing jdaggett and szilles.
07:18:34 [TabAtkins_]
Bert: 111, edited.
07:18:40 [TabAtkins_]
glazou: Okay, we need John for those testcases.
07:18:46 [TabAtkins_]
Bert: 114, edited.
07:18:51 [TabAtkins_]
Bert: 115, edited.
07:18:57 [TabAtkins_]
Bert: 117, edited.
07:19:35 [TabAtkins_]
Bert: 118, edited.
07:19:47 [TabAtkins_]
Bert: 119, edited.
07:19:57 [TabAtkins_]
Bert: 120, not done yet.
07:20:14 [TabAtkins_]
glazou: Can you get it by the conf call?
07:20:15 [TabAtkins_]
Bert: Yes.
07:20:37 [TabAtkins_]
Bert: 121, I sent a proposal.
07:20:52 [TabAtkins_]
glazou: Did anyone review that?
07:21:07 [TabAtkins_]
Bert: I just sent it 2 days ago, so maybe people haven't seen it yete.
07:21:19 [dbaron]
is there a url?
07:21:20 [TabAtkins_]
glazou: Action on everyone: review the proposal by next conf call.
07:21:34 [fantasai]
07:22:08 [TabAtkins_]
Bert: 122, not done yet.
07:22:22 [TabAtkins_]
glazou: You already have the dbaron proposal for that, so same ETA?
07:22:24 [TabAtkins_]
Bert: Yes.
07:22:31 [TabAtkins_]
Bert: 127, edited.
07:22:35 [TabAtkins_]
Bert: 128, edited.
07:22:57 [TabAtkins_]
glazou: Open issue now, about backup in tokenizer - 129.
07:23:05 [TabAtkins_]
Bert: I sent a proposal to the list about that last week.
07:23:16 [Bert]
07:23:34 [Bert]
07:25:52 [TabAtkins_]
glazou: Has anyone tested this in an implementation?
07:25:57 [johnjansen]
johnjansen has joined #css
07:26:07 [TabAtkins_]
dbaron: The only real change is that we change how we handle bad urls.
07:26:25 [TabAtkins_]
dbaron: I think that we made the change in Moz a few weeks ago when the group decided to make the change in priciple.
07:26:34 [TabAtkins_]
glazou: No objection? Good.
07:26:53 [TabAtkins_]
RESOLVED: Accept Bert's proposal for 129.
07:27:36 [TabAtkins_]
Bert: 131, I think I've already done it.
07:27:42 [TabAtkins_]
fantasai: I need to go through all of them and make sure.
07:27:50 [TabAtkins_]
glazou: Issue 134.
07:27:55 [fantasai]
and then update the issues list )
07:28:19 [dbaron]
I changed Gecko to match the new url() tokenization in which has been on trunk since June 3.
07:28:25 [TabAtkins_]
arronei: Done.
07:28:54 [TabAtkins_]
Bert: 137, not done yet.
07:29:14 [TabAtkins_]
Bert: 138, not done yet.
07:29:19 [CesarAcebal]
CesarAcebal has joined #css
07:29:47 [TabAtkins_]
Bert: 139, haven't done yet, but should be very easy.
07:30:07 [TabAtkins_]
Bert: 140, sent a proposal yesterday.
07:30:23 [Bert]
07:30:45 [TabAtkins_]
glazou: Everyone, review this so we can decide on it next call.
07:30:58 [TabAtkins_]
Bert: 141, edited.
07:31:07 [TabAtkins_]
Bert: 142, edited.
07:31:32 [TabAtkins_]
Bert: 143, not done yet, but should be easy.
07:32:25 [TabAtkins_]
glazou: 144, text-decoration and visibility. iirc, we didn't finish the discussion and deferred it to the ftf.
07:32:36 [TabAtkins_]
glazou: I think you said that all browsers have interop, which doesn't match the new proposal.
07:32:53 [TabAtkins_]
arronei: Yeah, they all do the same thing - drawing the decoration in the invisible area.
07:33:20 [TabAtkins_]
glazou: So we can either change the spec or tell all the implementors to change. Your choice.
07:33:59 [TabAtkins_]
glazou: I don't think decorations actually matter to authors very much.
07:34:07 [TabAtkins_]
[jdaggett enters the arena]
07:34:24 [TabAtkins_]
dbaron: I know we intentionally changed the image underlining, and I want to keep that.
07:34:35 [lstorset]
lstorset has joined #css
07:37:50 [TabAtkins_]
dbaron: So I want to keep the spec, and change Moz's impl.
07:38:23 [TabAtkins_]
dbaron: Doing so would let us remove the quirks/standards impl for text-decoration.
07:38:34 [TabAtkins_]
dbaron: I think webkit has a similar distinction.
07:38:38 [fantasai]
07:38:38 [TabAtkins_]
07:39:26 [TabAtkins_]
glazou: Hakon, opinion?
07:39:52 [TabAtkins_]
johnjansen: We'd prefer not to change our impl.
07:40:17 [alexmog]!doctype%20html%3E%0D%0A%3Cspan%20style%3D%22color%3Ablue%3B%20%20text-decoration%3A%20underline%3B%0D%0A%22%3E01%0D%0A%3Cspan%20style%3D%22color%3Ared%3B%20%20%20text-decoration%3A%20underline%3B%20%0D%0Avisibility%3Ahidden%3B%22%3E11%0D%0A%3Cspan%20style%3D%22color%3Agreen%3B%20text-decoration%3A%20none%3B%20%0D%0Avisibility%3Avisible%3B%22%3E21%0D%0A
07:40:18 [TabAtkins_]
dstorey: Is it a minor change?
07:40:23 [TabAtkins_]
glazou: Yeah, should be.
07:41:02 [jdaggett]
jdaggett has joined #css
07:42:52 [TabAtkins_]
fantasai: What if you use visibility:collapse?
07:43:25 [TabAtkins_]
dbaron: You don't draw the collapsed cell at all. It's quite different.
07:43:44 [TabAtkins_]
howcome: If we have interop, we should just keep that.
07:43:55 [TabAtkins_]
dbaron: I think the interop behavior is a complete disaster.
07:44:03 [TabAtkins_]
dbaron: And the quirksmode behavior is better than standards mode.
07:44:59 [TabAtkins_]
glazou: Proposal - leave it undefined in 2.1 and leave a note, define it properly in css3.
07:45:39 [TabAtkins_]
RESOLVED: Leave issue 144 officially undefined, add a note that it will be resolved in css3.
07:45:47 [TabAtkins_]
arronei: I'll remove the tests.
07:47:03 [TabAtkins_]
dbaron: The issue is that the spec was unclear about whether text decorations were based on the visibility of the text or the visibility of the element with text-decoration.
07:47:23 [TabAtkins_]
fantasai: The spec is not clear, but the rest of the model that it outlined in the spec is more consistent with one impl than the other.
07:47:43 [TabAtkins_]
glazou: Also, we discussed both underlined text, and about underlining images.
07:47:53 [TabAtkins_]
fantasai: The image underlining issue is taken care of.
07:47:59 [TabAtkins_]
glazou: What about impls?
07:48:11 [TabAtkins_]
arronei: It's inconsistent.
07:48:36 [TabAtkins_]
glazou: So the only ambiguity is about underlining text in a visibility:hidden element?
07:48:39 [TabAtkins_]
fantasai: Yeah.
07:49:16 [TabAtkins_]
Bert: 145, not done yet. I can get it by next call.
07:49:37 [TabAtkins_]
Bert: 146, not done yet.
07:49:45 [TabAtkins_]
Bert: 147, not done yet.
07:49:58 [TabAtkins_]
Bert: 148, not done yet.
07:50:16 [TabAtkins_]
Bert: 149, not done yet.
07:50:59 [TabAtkins_]
glazou: I think Moz already implemented that.
07:51:23 [TabAtkins_]
dbaron: I think other impls have it coming now.
07:51:39 [dbaron]
I think other impls have done it for a while
07:54:20 [TabAtkins_]
glazou: The decision was made during a conf call, and recorded in the minutes. You should be reading the minutes and objecting as soon as possible afterwards if you miss a call.
07:54:54 [TabAtkins_]
dsinger: I think we might want a note that some user agents start off at a zoom factor other than 1.
07:59:44 [TabAtkins_]
howcome: Where in this decision does it say that this only applies to screen media?
08:00:37 [TabAtkins_]
fantasai: It doesn't need to do so explicitly. There is a note that high-res devices should set the in or other physical unit to the true physical size, while low-rez devices are recommended to use the px as the anchor unit.
08:02:17 [TabAtkins_]
jdaggett: I think we shoudl go ahead and draft up some revised text for that.
08:02:27 [TabAtkins_]
glazou: dsinger, can you send a suggestion for the note you want?
08:02:43 [TabAtkins_]
glazou: If Hakon and others have comments, please make them as soon as possible.
08:02:49 [TabAtkins_]
Bert: 150, edited.
08:03:36 [TabAtkins_]
Bert: 151, not done yet. I can get it done by next conf call.
08:03:40 [TabAtkins_]
Bert: 152, edited.
08:04:07 [TabAtkins_]
Bert: 153, not done yet. Next conf call.
08:04:32 [TabAtkins_]
arronei: 154, now that jdaggett and I are both here we can talk about it. Next conf call.
08:04:39 [TabAtkins_]
Bert: 155, not done yet, but should be trivial.
08:05:03 [TabAtkins_]
jdaggett: 156, the edit has been put in, but I think some of the surrounding statements need to be cleaned up to match.
08:05:25 [TabAtkins_]
jdaggett: Is that a new issue or just wrap it up in the current one? I also haven't written a new test case.
08:05:27 [TabAtkins_]
glazou: Not a new issue.
08:05:41 [TabAtkins_]
jdaggett: Ok, I'll make a proposal for further edits tomorrow.
08:06:00 [TabAtkins_]
Bert: 157, not done yet.
08:06:31 [mollydotcom]
Tab: Proposal 831 cleared up some minor collapse issues
08:06:45 [fantasai]
jdaggett, I think the edits didn't make it in 100% as there was a sentence "Once the family's weights..." in the proposal that didn't make it in for 156
08:06:49 [fantasai]
08:07:30 [mollydotcom]
Fantasai: issue 158
08:07:49 [dbaron]
08:07:55 [mollydotcom]
Tab: Anything I've already is probably invalid at this point
08:08:12 [mollydotcom]
Fantasai: I've seen some proposals from Anton, let's sit down and talk it through
08:08:28 [mollydotcom]
Glazou: Do we need to make some time
08:08:50 [mollydotcom]
Tab: Yes, we'll talk by ourselves tonight and then need some time
08:09:01 [mollydotcom]
Glazou: We'll do our best
08:09:23 [mollydotcom]
Glazou: Deferred until discussed
08:09:34 [TabAtkins_]
glazou: Issue 159.
08:09:36 [glazou]
08:10:17 [TabAtkins_]
fantasai: That's what my 8.3.1 rewrite was for.
08:10:27 [TabAtkins_]
TabAtkins_: And I think arronei reviewed it and said it was good.
08:10:27 [glazou]
08:10:36 [TabAtkins_]
dbaron: Link to the latest proposal?
08:10:55 [TabAtkins_]
dbaron: I need more time to review it to make sure it's good.
08:11:15 [TabAtkins_]
glazou: We'll discuss it on the first conf call after the meeting.
08:11:35 [TabAtkins_]
ACTION everyone: review the 8.3.1 proposal
08:11:35 [trackbot]
Sorry, couldn't find user - everyone
08:11:59 [TabAtkins_]
Bert: 160, not done yet.
08:12:23 [TabAtkins_]
Bert: 161, not done yet.
08:12:27 [TabAtkins_]
Bert: 163, edited.
08:12:35 [TabAtkins_]
Bert: 164, edited.
08:12:41 [TabAtkins_]
Bert: 166, edited.
08:12:49 [TabAtkins_]
Bert: 167, edited.
08:12:58 [TabAtkins_]
Bert: 168, edited.
08:13:10 [TabAtkins_]
Bert: 169, edited.
08:13:23 [TabAtkins_]
Bert: 170, not done yet.
08:13:33 [TabAtkins_]
Bert: 171, edited.
08:13:45 [fantasai]
08:13:47 [TabAtkins_]
glazou: Open to the WG, 172 - table caption and content overflows.
08:14:10 [tantek]
FWIW - I reviewed and it looks good to me (fantasai's v3 of Clarifying 8.3.1 Collapsing Margins)
08:14:52 [TabAtkins_]
fantasai: Issue is that the caption overflows in non-useful ways when the table is small.
08:15:19 [TabAtkins_]
fantasai: My proposal was to make the caption act like a cell for purpose of table width.
08:15:25 [TabAtkins_]
dbaron: Does any impl do that?
08:15:32 [TabAtkins_]
fantasai: Yes, Konqueror, and some older browsers, I think ie6.
08:15:52 [TabAtkins_]
fantasai: This changes the computed final width of the table, essentially providing a minimum width for it.
08:16:25 [TabAtkins_]
fantasai: So when you lay out a table, you calculate the actual width, and then use min(that, specified width). I'm proposing using the caption width also.
08:16:55 [fantasai]
08:18:14 [TabAtkins_]
dbaron: It might be worth noting that this only applies to top/bottom captions.
08:18:28 [TabAtkins_]
fantasai: We can note that, sounds like a good idea.
08:22:47 [glazou_]
glazou_ has joined #css
08:23:36 [glazou_]
08:23:48 [glazou_]
jgraham: you have access to ?
08:23:51 [CesarAcebal_]
CesarAcebal_ has joined #css
08:26:28 [TabAtkins_]
fantasai: This proposal will break the table-caption-004 test.
08:27:37 [TabAtkins_]
dbaron: If the caption is large enough to make the page scroll, this change will make the entire table stretch off the page.
08:27:45 [TabAtkins_]
glazou: Will this break anything?
08:28:16 [TabAtkins_]
dbaron: table captions are used so rarely that I don't think it will affect anything significant.
08:29:15 [TabAtkins_]
tantek: If I rewrite the test case to use <table>, I think IEMac5.2 matches your proposal.
08:29:29 [TabAtkins_]
fantasai: Right, a lot of the older generation of browsers do that.
08:30:28 [TabAtkins_]
glazou: Can we reach a decision here?
08:30:43 [TabAtkins_]
dbaron: I'm okay with it. I'm not super happy when the caption is extra wide, but shrug.
08:31:39 [glazou]
gsnedders: mid-afternoon probably
08:31:51 [glazou]
gsnedders: after all issues are browsed and discussed
08:32:22 [TabAtkins_]
dbaron: Probably in the case that the caption width has a small fixed width, we should make it so that the table can be larger than that and the caption stays small.
08:32:51 [gsnedders]
glazou: Okay, I'll probably join then
08:33:05 [TabAtkins_]
RESOLVED: Accept fantasai's proposal for 172.
08:33:23 [TabAtkins_]
<br duration=15min>
08:41:34 [Doofl]
Doofl has joined #css
08:43:09 [lstorset]
lstorset has joined #css
08:45:00 [dstorey]
dstorey has joined #css
08:45:53 [Zakim]
Zakim has left #CSS
08:46:42 [Zakim]
Zakim has joined #CSS
08:46:56 [glazou]
RRSAgent, make logs public
08:47:21 [TabAtkins_]
glazou: Issue 173
08:47:32 [glazou]
Chris joined the meeting
08:47:38 [lhnz]
lhnz has joined #css
08:47:41 [TabAtkins_]
fantasai: I need to work on that.
08:47:53 [TabAtkins_]
glazou: Is it still workable?
08:48:01 [TabAtkins_]
fantasai: I've emailed back and forth with henri.
08:48:16 [TabAtkins_]
fantasai: He says "I want carriage returns inserted wherever to be whitespace."
08:48:29 [TabAtkins_]
fantasai: I said "What kind of whitespace?"
08:49:06 [fantasai]
fantasai: He didn't know. Thought it should be normalized as a line break in pre
08:49:33 [fantasai]
fantasai: But that would make DOM text and generated content text behave inconsistently, because CR is ignored in generated content
08:50:02 [TabAtkins_]
fantasai: I think I'll still need a while to do this.
08:50:08 [TabAtkins_]
fantasai: A couple of hours.
08:51:01 [TabAtkins_]
fantasai: Maybe can do it before we end here, if not, then by the next conf call.
08:51:13 [TabAtkins_]
glazou: Send it by next Wednesday, so we have a week to review it before the conf call.
08:51:23 [TabAtkins_]
glazou: Otherwise it's undefined in 2.1
08:51:52 [TabAtkins_]
chrisl: Does this have any effect on test suites?
08:52:08 [TabAtkins_]
ACTION Elika: Send a proposal by next wednesday.
08:52:08 [trackbot]
Created ACTION-248 - Send a proposal by next wednesday. [on Elika Etemad - due 2010-08-30].
08:52:17 [TabAtkins_]
Bert: 174, 175 edited.
08:52:22 [TabAtkins_]
Bert: 176, edited.
08:52:26 [TabAtkins_]
Bert: 177, edited
08:52:31 [dstorey_]
dstorey_ has joined #css
08:52:58 [TabAtkins_]
TabAtkins_: 178, I was crazy. Mark as invalid.
08:53:20 [TabAtkins_]
Bert: 179, edited.
08:53:23 [TabAtkins_]
Bert: 180, editd.
08:53:49 [TabAtkins_]
fantasai: 181, I don't think it needs to be addressed right now.
08:53:52 [TabAtkins_]
Bert: 182, edited.
08:54:10 [glazou]
08:54:13 [TabAtkins_]
glazou: new open issue, 183 - handling of malformed media types
08:55:14 [TabAtkins_]
glazou: We seem to be saying two different things here about what to do with the malformed queries.
08:55:39 [ChrisL]
ChrisL has joined #css
08:55:47 [TabAtkins_]
chrisl: It should be possible for us to just match up with what MQ says now.
08:56:11 [TabAtkins_]
dbaron: What's the mismatch? Is it just that we have 2.1 say that unknown identifiers dont' match anything, but aren't parse errors?
08:57:54 [TabAtkins_]
fantasai: So 2.1 says to ignore unknown media types, but do you ignore malformed ones or throw them away?
08:58:03 [TabAtkins_]
dbaron: I think we ignore.
08:58:40 [dbaron]
The appendix G grammar says it has to be an identifier in 2.1
08:58:42 [TabAtkins_]
fantasai: I don't think anything is said that media types have to be identifiers
08:58:53 [dbaron]
but it doesn't seem to say that outside the appendix G grammar
08:59:20 [TabAtkins_]
dbaron: Does this affect any impls?
08:59:35 [TabAtkins_]
dbaron: Anyone that doesn't implement MQ that are currently maintained?
08:59:49 [TabAtkins_]
dbaron: Because this change only affects impls that do 2.1 and not MQ.
08:59:56 [TabAtkins_]
fantasai: I think some of the printers may.
09:00:11 [fantasai]
fantasai: But they probably want to implement MQ as awell
09:00:26 [TabAtkins_]
glazou: Can't we just say that MQ supercedes 2.1 here?
09:00:39 [TabAtkins_]
fantasai: That's in the snapshot, but it's still not clear what an "unknown media type" is.
09:01:11 [TabAtkins_]
dbaron: Since we're making Appendix G informative, we should add a note that media types must be identifiers, and non-identifiers make the whole thing invalid.
09:01:25 [TabAtkins_]
dbaron: We should probably go through Appendix G and check for similar occurences like that.
09:01:59 [TabAtkins_]
dsinger: Is there a difference between an unknown and an invalid type?
09:02:09 [TabAtkins_]
fantasai: If it's not an identifier, it's invalid and throw it away.
09:02:18 [fantasai]
"@media and @import rules with unknown media types are treated as if the unknown media types are not present. "
09:02:40 [fantasai]
"@media and @import rules with unknown media types (as identifiers) are treated as if the unknown media types are not present."
09:02:43 [fantasai]
09:02:57 [fantasai]
plus "If an @media rule contains a malformed media type (not an identifier) then the statement is invalid"
09:03:25 [fantasai]
s/as identifiers/that are nonetheless valid identifiers/
09:03:43 [fantasai]
Note: Media Queries supercedes this error handling.
09:04:17 [TabAtkins_]
RESOLVED: Accept the change above for issue 183.
09:04:26 [TabAtkins_]
Action Bert: Make the above edit for issue 183.
09:04:26 [trackbot]
Created ACTION-249 - Make the above edit for issue 183. [on Bert Bos - due 2010-08-30].
09:04:40 [TabAtkins_]
Bert: 184, edited
09:04:52 [TabAtkins_]
Bert: 185, not done yet.
09:05:09 [TabAtkins_]
glazou: We already closed 186.
09:05:54 [TabAtkins_]
ACTION david: Find normative statement in appendix G that should now be written elsewhere.
09:05:54 [trackbot]
Sorry, amibiguous username (more than one match) - david
09:05:54 [trackbot]
Try using a different identifier, such as family name or username (eg. hyatt, dbaron, dsinger2)
09:06:02 [TabAtkins_]
ACTION dbaron: Find normative statement in appendix G that should now be written elsewhere.
09:06:02 [trackbot]
Created ACTION-250 - Find normative statement in appendix G that should now be written elsewhere. [on David Baron - due 2010-08-30].
09:06:38 [TabAtkins_]
fantasai: 187 - The spec is confusing in this case. it's inconsistent about normal bidi working. I can write an email about that tonight.
09:07:04 [TabAtkins_]
fantasai: I may need some time for this Tuesday or Wednesday.
09:07:23 [TabAtkins_]
johnjansen: dbaron, can you do that appendix G trawling by next conf call?
09:07:25 [TabAtkins_]
dbaron: Maybe.
09:07:54 [arronei]
arronei has joined #CSS
09:07:56 [TabAtkins_]
glazou: If we get the issue list closed down, perhaps we can have a firm roadmap for 2.1 by next conf call.
09:08:08 [TabAtkins_]
Bert: 188, edited.
09:08:10 [TabAtkins_]
Bert: 189, edited.
09:08:22 [TabAtkins_]
Bert: 190, not done yet.
09:08:42 [TabAtkins_]
glazou: 191, define stacking level of marker box.
09:08:50 [glazou]
09:10:23 [TabAtkins_]
fantasai: I think arronei and I talked about this, and wanted to make it undefined in 2.1, since you can't move the marker box anyway. Also, there are some significant details that may be affected by implementations, so we want to wait and then spec behavior in CSS3.
09:10:58 [TabAtkins_]
fantasai: We shouldn't put a recommendation in 2.1, but we might put a note saying it's undefined or leave it out completely.
09:11:05 [TabAtkins_]
glazou: I prefer marking it undefined.
09:11:29 [TabAtkins_]
RESOLVED: Add a note about marker box stacking level for outside markers being undefined in 2.1.
09:11:41 [TabAtkins_]
ACTION fantasai: Propose note for issue 191 making marker box stacking level undefined.
09:11:41 [trackbot]
Created ACTION-251 - Propose note for issue 191 making marker box stacking level undefined. [on Elika Etemad - due 2010-08-30].
09:11:46 [glazou]
09:13:00 [TabAtkins_]
dbaron: Anton's proposal for issue 1 looks fine.
09:14:06 [TabAtkins_]
dbaron: I don't think we want to make the second change.
09:14:48 [TabAtkins_]
dsinger: I think the "further" lacks a referent.
09:15:03 [fantasai]
dbaron proposes s/further content/content after the float/
09:15:17 [fantasai]
and s/it/that content/
09:16:09 [TabAtkins_]
TabAtkins_: And the third issue is invalid - Bert gave an example where the content may have to be reflowed onto multiple lines.
09:16:31 [TabAtkins_]
RESOLVED: Accept change for first issue, accept dbarons' change for the second issue, third issue is invalid.
09:16:40 [TabAtkins_]
Bert: I've done the edits for 193.
09:16:55 [TabAtkins_]
fantasai: I haven't written the tests yet.
09:17:09 [TabAtkins_]
fantasai: I can do them this week.
09:18:16 [TabAtkins_]
glazou: 194 is open to the working group - text-indent shouldn't apply to non-first-lines of an element.
09:18:57 [TabAtkins_]
fantasai: The issue is that if you have a block split by another block, thus generating anonymous blocks, you don't want the two halves of the paragraph indented.
09:19:17 [TabAtkins_]
dbaron: Prose text seems fine.
09:19:25 [dbaron]
09:19:36 [TabAtkins_]
RESOLVED: Accept the proposal in the issue list for 194.
09:19:37 [dbaron]
proposed text is
09:20:11 [TabAtkins_]
glazou: Issue 195, clarifiction needed for inline boxes containing block boxes.
09:22:16 [TabAtkins_]
fantasai: The behavior Boris proposes is currently implemented in Gecko.
09:23:09 [TabAtkins_]
glazou: Do we all agree about the clarification needed? Any objections?
09:23:24 [TabAtkins_]
fantasai: Looks like we have Opera and Firefox.
09:23:31 [TabAtkins_]
dbaron: And Chromium seems to do the same thing too.
09:26:52 [glazou]
09:26:56 [TabAtkins_]
TabAtkins_: IE8 doesn't generate the second half.
09:27:06 [TabAtkins_]
glazou: Fantasai, write up proposal.
09:27:20 [TabAtkins_]
ACTION fantasai: Write up a proposal for issue 195.
09:27:21 [trackbot]
Created ACTION-252 - Write up a proposal for issue 195. [on Elika Etemad - due 2010-08-30].
09:27:48 [TabAtkins_]
glazou: Issue 196 - grammar and prose disagree on nbsp inside identifiers.
09:27:56 [TabAtkins_]
dsinger: Do we have impl experience?
09:28:14 [TabAtkins_]
fantasai: In the test, if it's underlined you accept nbsp in an identifier.
09:28:25 [TabAtkins_]
dsinger: Safari is underlining, firefox is not.
09:28:43 [TabAtkins_]
dbaron: Prose says nbsp isn't allowed, grammar says it is.
09:28:55 [TabAtkins_]
glazou: We always say that prose is higher than the grammar.
09:29:11 [TabAtkins_]
ChrisL: Is there a reason to be more restrictive?
09:29:34 [TabAtkins_]
fantasai: Usually we use the prose to be more restrictive, but here there doesn't seem to be any reason for the difference.
09:31:23 [TabAtkins_]
RESOLVED: Change prose to match the grammar.
09:32:04 [TabAtkins_]
dbaron: The prose/grammar mismatch goes all the way back to CSS1.
09:32:25 [TabAtkins_]
<br type=lunch duration=1h>
09:32:39 [TabAtkins_]
ACTION bert: Fix the prose for issue 196 to match the grammar.
09:32:39 [trackbot]
Created ACTION-253 - Fix the prose for issue 196 to match the grammar. [on Bert Bos - due 2010-08-30].
10:15:24 [dsinger_]
dsinger_ has joined #css
10:15:32 [CesarAcebal]
CesarAcebal has joined #css
10:22:05 [Arron]
Arron has joined #css
10:33:43 [glazou]
glazou has joined #css
10:33:53 [dstorey]
dstorey has joined #css
10:37:42 [tantek]
tantek has joined #css
10:39:48 [fantasai]
Resuming meeting
10:39:52 [fantasai]
ScribeNick: fantasai
10:40:11 [fantasai]
Resuming from CSS2.1 Issue 186
10:40:22 [fantasai]
dbaron has pointed out that one of the ranges includes a bunch of control characters
10:41:06 [ChrisL]
ChrisL has joined #css
10:41:36 [fantasai]
fantasai: So there were two related issues, one is that the range given started at A1 instead of A0. We resolved to include A0
10:42:07 [fantasai]
fantasai: The other issue is that the range in between the two formulations of the range used to not be characters
10:42:08 [JohnJansen]
JohnJansen has joined #css
10:42:17 [fantasai]
fantasai: but now are control characters
10:42:27 [fantasai]
fantasai: The spec relied on them not being characters when defining the range
10:42:37 [fantasai]
fantasai: They should instead be explicitly excluded
10:44:11 [fantasai]
RESOLVED: Range should be worded such that these characters are excluded
10:44:49 [glazou]
10:45:01 [jdaggett]
jdaggett has joined #css
10:45:03 [fantasai]
CSS2.1 Issue 197
10:45:12 [fantasai]
10:45:35 [szilles]
szilles has joined #css
10:45:56 [TabAtkins_]
TabAtkins_ has joined #css
10:46:17 [glazou]
10:47:48 [glazou]
10:49:15 [dstorey_]
dstorey_ has joined #css
10:50:59 [fantasai]
fantasai: I think what that's saying is that the 'clear' applies to the run-in if it becomes a block box, otherwise it applies to the parent block that it's been injected into
10:51:44 [fantasai]
dbaron: Do run-ins get injected into the next block box if there is a float in between? Because that would make clear very interesting on run-ins
10:52:51 [dstorey]
dstorey has joined #css
10:53:03 [Arron]
10:53:06 [Arron]
10:55:37 [fantasai]
Molly: Why would you put a float between the header and the beginning of a section
10:55:38 [fantasai]
10:55:53 [fantasai]
dbaron: Suppose you have an article about an image, you might want to float it to the side
10:56:11 [fantasai]
dbaron: Then someone comes and wants to make the headings all run-ins
10:57:18 [dbaron]
(And do run-ins run in to a first child of the following block if the first child is also a block?)
10:57:42 [fantasai]
fantasai and glazou give examples where it makes sense
10:58:21 [davve]
davve has joined #css
10:59:16 [fantasai]
10:59:23 [dbaron]
11:01:00 [futhark]
futhark has joined #css
11:01:05 [mg]
mg has joined #CSS
11:02:42 [fantasai]
the wg studies the run-in-clear-001 testcases, which has very poor wording!
11:04:01 [fantasai]
Agreed on what the spec is intending to say and that it needs to be clarified
11:04:39 [fantasai]
ACTION: fantasai and Bert, clarify spec for CSS2.1 197
11:04:40 [trackbot]
Created ACTION-254 - And Bert, clarify spec for CSS2.1 197 [on Elika Etemad - due 2010-08-30].
11:05:45 [glazou]
issue 198 now
11:05:45 [glazou]
11:08:34 [fantasai]
dbaron: So this isn't as complicated as it looks.
11:08:51 [fantasai]
dbaron: We just need to make sure the spec defines clear in terms of the box tree instead of the element tree.
11:09:41 [fantasai]
dbaron: But that means we need to get the spec to admit that there is a box tree.
11:09:49 [Zakim]
Zakim has left #CSS
11:10:49 [Zakim]
Zakim has joined #CSS
11:11:13 [fantasai]
fantasai: The question here is whether you take floats out-of-flow before or after you process run-ins
11:11:19 [ChrisL]
zakim, remind me in 5 hours to go home
11:11:19 [Zakim]
ok, ChrisL
11:13:13 [fantasai]
Tab: The definition of clearance is based on the element tree, so it's asking the <div> to clear the float here, even though the float would be inside the clearing element
11:13:22 [fantasai]
s/clearing element/clearing box/
11:14:59 [fantasai]
dbaron: We could fix this by adding a parenthetical to the float rules talking about floats inside the clearaing element to explicitly include the contents of run-in elements
11:15:12 [dbaron]
Inside "The 'clear' property does not consider floats inside the element itself or in other block formatting contexts." in 9.5.2
11:16:20 [dbaron]
to something like "The 'clear' property does not consider floats inside the element itself (including floats inside a 'display:run-in' element that runs in to the element) or in other block formatting contexts."
11:16:23 [fantasai]
dsinger: Is it completely clear what "inside" means in that section?
11:16:25 [fantasai]
everyone: noe
11:16:27 [fantasai]
11:17:35 [dbaron]
We also need to fix the float positioning rules in 9.5.1
11:17:39 [dbaron]
because they also go by source order.
11:17:42 [fantasai]
bert: So what if you have a float in between the run-in and the block also?
11:21:04 [dbaron]
and if the float not in the run-in has 'clear' on it then you have an explicit contradiction
11:21:11 [dbaron]
we need a box tree
11:22:03 [fantasai]
discussion of float placement rules
11:22:34 [fantasai]
steve: So instead of saying that the float is inside the element that the float is inside a run-in rendered inside the principal box.
11:22:40 [fantasai]
dbaron: how does that help?
11:23:06 [fantasai]
dbaron: .. old problem. Doesn't help the new problem.
11:23:10 [fantasai]
dbaron: The new problem is if you have
11:23:23 [fantasai]
11:23:27 [fantasai]
11:23:36 [fantasai]
11:23:44 [fantasai]
dbaron: The floats are both left
11:24:05 [fantasai]
floatA, floatB { float: left; }
11:24:15 [fantasai]
floatB, block { clear: left; }
11:24:25 [fantasai]
dbaron: The definition of clear on floats says that floatB has to be below floatA
11:24:38 [fantasai]
dbaron: Because it has to clear any elements earlier *in the source document*
11:25:09 [fantasai]
dbaron: The definition of clear on blocks says that the block has to be below floatB
11:25:35 [fantasai]
dbaron: And the float positioning rules say that floatA has to be even with the top of the block that contains, i.e. at or below the top of the block
11:26:25 [fantasai]
steve: So say for a run-in, that combines with the following block, it is considered a reordering in the source docuent
11:27:28 [dbaron]
so if "below" is "greater than", then floatB < floatA, block < floatB, and floatA <= block, which is a problem
11:27:45 [fantasai]
tab: The more and more we try to patch the definitions here, the more of a mess it's going to get
11:27:57 [fantasai]
tab: Maybe we can patch it here in 2.1 and make a CSS3 Box Tree module
11:28:17 [fantasai]
ChrisL: We don't have to expose the box tree to the dom or anything, but we need to be clear about how it works
11:29:18 [fantasai]
Bert: Another option is to say that floats inside the runin disable the runin
11:30:17 [fantasai]
steve: What if I'm using float to get an initial drop-cap?
11:30:19 [lstorset2]
lstorset2 has joined #css
11:31:39 [fantasai]
steve: We should go with run-in reordering the source tree in certain circumstances, and limit the circumstances where this occurs
11:32:05 [fantasai]
steve: for layout purposes only
11:32:39 [miketaylr]
miketaylr has joined #css
11:32:42 [fantasai]
dbaron: We'd have to go through the whole spec and decide which instances would use the actual source order and which would use the virtual source order
11:32:52 [fantasai]
dbaron: Which is what we mean by defining the box tree
11:33:31 [fantasai]
alex: You'd also need to update Appendix E
11:34:43 [fantasai]
fantasai: so for chapter 8 and above you pretend the source has been reordered
11:36:40 [dsinger_]
but ... what happens if you need to be able to say something on the run-in that applies *without* this re-ordering, because then you would not be able to?
11:37:08 [fantasai]
steve: the def of run-in box says that it's rendered as if it were an inline element in the next block box
11:37:29 [fantasai]
steve: you could just clarify that the contents, including floats and abspos, are includedin this move
11:38:51 [fantasai]
steve: you might need a note that you need an apparent reordering of the source
11:40:00 [fantasai]
11:40:06 [fantasai]
"the run-in box becomes the first inline box of the block box"
11:40:37 [Bert]
11:40:37 [TabAtkins_]
11:41:59 [fantasai]
steve: So we need a note to clarify
11:42:26 [fantasai]
ACTION: Steve write note to clarify that run-in's contents are reordered by rule 2 in 9.2.3
11:43:26 [trackbot]
Could not create new action (failed to parse response from server) - please contact sysreq with the details of what happened.
11:43:26 [trackbot]
Could not create new action (unparseable data in server response: local variable 'd' referenced before assignment) - please contact sysreq with the details of what happened.
11:43:58 [fantasai]
RESOLVED: Add note to be written by Steve for CSS2.1 issue 198 to clarify that this effectively causes a reordering of the source tree as far as all of the layout rules are concerned
11:46:41 [fantasai]
11:48:05 [fantasai]
so line boxes should be created for inline-level content and potentially marker boxes
11:48:14 [fantasai]
collapsed-away whitespace does not create a line box
11:49:01 [fantasai]
jdaggett: so you have a line box with no text in it. What font metrics do you use for it?
11:49:07 [fantasai]
dbaron: known problem
11:49:18 [fantasai]
Bert: We need to pick a font for finding the 'ex' unit
11:50:02 [fantasai]
jdaggett: We don't have a font-finding algorithm that works without text
11:50:19 [fantasai]
several you want to check against the first available font
11:50:33 [fantasai]
steve: match against the empty string. Every font will match
11:50:54 [TabAtkins_]
11:53:31 [fantasai]
discussion of the phantom line boxes in 9.4.2
11:53:34 [fantasai]
11:54:34 [fantasai]
11:55:29 [fantasai]
fantasai: You need the phantom line boxes to handle abspos static positioning
11:56:02 [fantasai]
fantasai: but you need to ignore it for margin collapsing
11:56:47 [ChrisL]
calling it 'potential' line box (which later resolves to no line box, or a real line box, may be better than 'phantom'
11:59:48 [fantasai]
ACTION: Tab propose text for CSS2.1 Issue 199
11:59:48 [trackbot]
Created ACTION-255 - Propose text for CSS2.1 Issue 199 [on Tab Atkins Jr. - due 2010-08-30].
11:59:51 [mollydotcom]
ScribeNick: mollydotcom
12:00:03 [Arron]
I feel that potential is a better term than phantom
12:00:36 [mollydotcom]
Daniel: Last issue on the radar, then we will decide to stop on these issue or not
12:01:07 [fantasai] and
12:01:20 [mollydotcom]
12:01:26 [fantasai]
RESOLVED: Accept proposal for CSS2.1 Issue 201 with "table wrapper box" as the term
12:02:29 [mollydotcom]
szilles and fantasai discussing vertical-align
12:02:51 [mollydotcom]
szilles: undefined is fine
12:03:54 [mollydotcom]
Daniel: CSS 2.1 issues freeze
12:04:17 [mollydotcom]
Daniel: stop registering issues now
12:04:31 [mollydotcom]
David: As long as we keep a list of them
12:05:00 [mollydotcom]
dsinger_: Will likely end up in errata or moved to CSS3
12:06:03 [mollydotcom]
fantasai: We are publishing a last call working draft, we are required to accept comments. FOr this round of editing, there's no reason why we shouldn't close down, publish, and consider anything else last call issues
12:06:18 [mollydotcom]
fantasai: they will have four weeks to comment
12:06:48 [mollydotcom]
12:07:02 [mollydotcom]
(no objections, very strong support)
12:08:23 [mollydotcom]
Glazou: if we have interop shown by reports, we go directly to pr
12:08:31 [mollydotcom]
(no objections)
12:10:01 [mollydotcom]
Glazou: Everything relies on implementation reports - completion of test suites, so let's discuss
12:10:12 [fantasai]
RESOLVED: LC->PR if we have exit criteria for 2.1
12:10:18 [mollydotcom]
Glazou: What remains on the radar with the test suite and when are we able to say it's ready?
12:10:49 [mollydotcom]
Fantasai: we have to have "no suspected" issues, when that's complete I can publish
12:11:11 [mollydotcom]
jdaggett - there are tests that don't pass in any browsers
12:11:22 [mollydotcom]
dbaron: a bunch of people did respond to the tests in that list
12:12:07 [mollydotcom]
jdaggett: I've actively try to go to people I thought would care but I fear they will comment
12:12:15 [mollydotcom]
Glazou: at some point we have to freeze things
12:13:21 [mollydotcom]
Glazou: Browser vendors: you want css2.1 published but your teams have not evaluated the tests, have not already implemeted, even if we are going to CR/PR
12:13:39 [mollydotcom]
Glazou: if you want it published, we rely on your implementations. The entire thing is in your hands, not the WGs
12:14:24 [mollydotcom]
Fantasai: If there's a problem with the test
12:14:37 [mollydotcom]
Fantasai: Email the list, and then we will take a look at the test
12:14:45 [mollydotcom]
Fantasai: THEN we will push it to the WG
12:14:53 [mollydotcom]
Glazou: Not an issue with the spec
12:15:10 [mollydotcom]
fantasai: info on the wiki
12:15:25 [mollydotcom]
Glazou: suggest 1 Oct. for test suite
12:16:28 [mollydotcom]
Deadlines: Edits should be done for next conference call
12:16:35 [mollydotcom]
Bert: I'll be able to do my edits
12:17:27 [mollydotcom]
dsinger, fantasai: discussing automation of tests
12:18:31 [fantasai]
+jgraham and gsnedders
12:19:22 [mollydotcom]
gsnedders: Opera can help provide some help with that too
12:20:13 [mollydotcom]
jdaggett, dbaron: discussing tests and windows limitations
12:20:46 [mollydotcom]
Jdaggett: there are some tests that don't pass on any windows implementation but do pass on other platforms
12:20:49 [dbaron]
dbaron: Aaron, could you share the list of which tests pass on which browsers?
12:21:33 [mollydotcom]
jdaggett: for font tests this will be hard. Bold and non-bold versus bolder/lighter
12:21:47 [fantasai]
jdaggett: On windows you only have bold and nott bold
12:21:59 [fantasai]
jdaggett: you need to test on e.g. MacOS to get the full range of testing
12:22:07 [fantasai]
jdaggett: Windows will allow trivial passes
12:22:34 [fantasai]
glazou: The test suite isn't supposed to demonstrate interop, it'e supposed to demonstrate implementability
12:22:50 [fantasai]
glazou: The tests aren't conformance tests, they're spec implementability tests
12:23:04 [fantasai]
steve: You're testing for interoperable implementability
12:23:26 [fantasai]
jdaggett: When I say font-weight 100, it should pick the 100 weight font not the 400 weight font
12:23:40 [fantasai]
jdaggett: but on Windows you only get the 400 weight font
12:24:02 [fantasai]
dsinger_: The problem is what if you have two section so fthe spec that can be implemented, but not at the same time
12:24:44 [fantasai]
steve: The requirement is that there exist at least 2 impls
12:25:00 [fantasai]
dbaron: You can also get tests that fail in all windows implementations, and you need to find non-Windows implementations to get passes
12:25:02 [dsinger_]
s/section so fthe/sections of the/
12:25:50 [fantasai]
glazou: Next step is writing the implementation reports..
12:25:59 [fantasai]
dbaron: Arron, can you share that list of which tests pass on which browsers?
12:26:03 [fantasai]
JohnJansen: No, we can't
12:26:31 [fantasai]
ChrisL: The full data is a matrix in a spreadsheet that shows which tests pass in which versions of which browsers.
12:26:55 [fantasai]
JohnJansen: It's a very expensive process
12:27:43 [ChrisL]
And I would like to talk to Microsoft managers to get the relevant parts of that released to the working group. It will get us out of CR earlier
12:27:55 [fantasai]
glazou: For Selectors, hixie and I had to write the implementation reports ourselves
12:28:21 [fantasai]
glazou: It's always the case that some Members put in more resources into the WG on some things than others
12:29:08 [fantasai]
ChrisL: We wouldn't be asking MS to provide the data if you didn't already have it.
12:29:34 [fantasai]
dbaron: I don't consider it worth my time to go through the test suite.
12:29:53 [fantasai]
dbaron: But if you provide a set of tests that we fail, then I will review those tests.
12:30:02 [fantasai]
dbaron: So could you share the list of tests that fail in at least one browser?
12:30:16 [fantasai]
Arron: I've shared the lists of tests that don't pass in any browser, and those that I think are invalid
12:30:35 [fantasai]
Arron: Once we decide the test suite is solid, and we're getting there with Gérard reviewing a lot of the tests,
12:30:57 [fantasai]
Arron: Then when you run the tests you can look more closely at the tests you fail
12:31:28 [fantasai]
howcome: dbaron has 2 points I would like to emphasis
12:31:40 [fantasai]
howcome: One is that the tests are too many and give us too little
12:31:58 [fantasai]
howcome: We've all found ourselves in situations doing work on behalf of other browsers.
12:32:14 [fantasai]
howcome: And you have done that -- all the tests you've contributed
12:32:21 [fantasai]
glazou: It's perfectly normal.
12:32:32 [fantasai]
glazou: Microsoft wants 2.1 to be released ASAP, because you rely on it.
12:32:44 [fantasai]
glazou: Contributing the results of the tests will speed up the process. Not contributing it will slow us down.
12:33:01 [fantasai]
glazou: It's in your interest to contribut the results.
12:33:07 [fantasai]
Steve: The issue isn't the test results, the issue is the implementation reports
12:33:19 [ChrisL]
I would like to see Arron's list of 'tests passed by no windows browser' on the wiki, then remove tests that are passed on other platforms
12:33:38 [fantasai]
Steve: So we're not asking for a contribution of test results, we're asking for contribution of to the implementation reports
12:34:01 [fantasai]
Arron: These are only the HTML test results, not the XHTML tests
12:34:27 [dbaron]
dbaron: So there could be additional tests that don't pass in any browser.
12:35:18 [fantasai]
JohnJansen: We shared a lot of the data we have. The list of suspected invalid tests, and the list of tests that don't match.
12:35:23 [fantasai]
s/match/ pass/
12:35:56 [fantasai]
howcome: Can you provide the list of tests that fail in any one browser?
12:36:22 [fantasai]
glazou: A few years ago the only company interested in print was YesLogic.
12:36:27 [fantasai]
glazou: And afterward HP
12:36:35 [fantasai]
glazou: But not the other vendors were interested in print
12:36:45 [fantasai]
glazou: But we contributed time to working on those specs
12:37:02 [fantasai]
JohnJansen: The tests we contributed are available to anyone to run
12:37:15 [fantasai]
JohnJansen: We're not hiding anything.
12:37:40 [fantasai]
Arron: It's our time and money that we've put into creating the test results
12:38:14 [fantasai]
dsinger_: I'm grateful if he gives me the data, I don't think I can ask him to do that work for me and save me that time and money.
12:38:35 [fantasai]
JohnJansen: I wouldn't want you to trust our results either.
12:40:24 [fantasai]
dsinger_: Can we keep a page on the wiki of tests that are suspected to be wrong?
12:41:48 [fantasai]
ACTION: fantasai make said wiki page
12:41:48 [trackbot]
Created ACTION-256 - Make said wiki page [on Elika Etemad - due 2010-08-30].
12:41:52 [howcome]
howcome has left #css
12:42:47 [fantasai]
fantasai: People can start on implementation reports now. I can even throw out a beta 4 on Monday
12:43:00 [fantasai]
fantasai: But whenever I publish a release now I list all tests that have changed
12:43:14 [fantasai]
fantasai: So between releases you'd only have a handful of test results you might need to run
12:43:43 [fantasai]
glazou: I am requesting browser vendors to start implementation reports now.
12:44:28 [fantasai]
Arron: It takes 16 hours to run the tests by hand
12:44:39 [fantasai]
dsinger asks about automating them
12:44:48 [fantasai]
fantasai and Arron say it will take much longer to automate them
12:45:07 [fantasai]
dsinger_: How good is the coverage of the test suite
12:45:28 [fantasai]
gsnedders: Automating the tests isn't just a one time thing, because everyone would want to run them as regression tracking
12:45:36 [fantasai]
gsnedders: if they're manuall, they won't be run very often
12:45:44 [fantasai]
gsnedders: Automating the tests wont' just save time once
12:46:57 [fantasai]
jdaggett: For CSS3 modules do we have to follow this pattern?
12:48:13 [fantasai]
glazou: If we don't get your implementation reports, things are going to slow down.
12:48:41 [fantasai]
glazou: It relies on you.
12:48:46 [fantasai]
glazou: The sooner we get it, the better.
12:48:51 [fantasai]
dsinger_: Coverage?
12:49:01 [fantasai]
12:49:20 [fantasai]
dbaron: There's questions of how you measure test coverage
12:49:32 [fantasai]
dbaron: you'd have to measure e.g. code coverage
12:49:41 [glazou]
gsnedders: exactly.
12:51:19 [fantasai]
fantasai explains what we have
12:51:34 [fantasai]
dbaron: The spec has lots and lots of interactions among features, many of which are not obvious
12:51:45 [fantasai]
dbaron: We don't have good coverage of those interactions.
12:52:08 [fantasai]
dbaron: There are sentences in the spec that require hundreds or thousands of tests just for that sentence. And we don't have that coverage.
12:53:00 [fantasai]
glazou: Anything else on the test suite and the roadmap?
12:53:10 [fantasai]
glazou: I remind you that the goal is still PR before the end of the year.
12:53:18 [fantasai]
glazou: This is important for both the WG and the W3C itself.
12:53:27 [fantasai]
glazou: We started this roughly ten years ago
12:53:51 [fantasai]
ChrisL: If the CSS2.1 can get to PR by the end of the year, there's still a chance that SVG 1.1 can normatively point to CSS2.1.
12:53:55 [fantasai]
ChrisL: I'd like that to happen.
12:54:14 [fantasai]
glazou: if we move 2.1 to PR, Selectors can move to REC, we solve a lot of dependencies.
12:54:35 [ChrisL]
s/1.1/1.1 Second Edition/
12:54:50 [fantasai]
JohnJansen: If we got to PR by the end of the year, does that put REC at the end of January?
12:56:21 [fantasai]
scheduled charter discussion for after the break
12:56:22 [fantasai]
13:06:04 [dstorey]
dstorey has joined #css
13:06:52 [dstorey_]
dstorey_ has joined #css
13:07:59 [szilles]
szilles has joined #css
13:17:26 [szilles]
szilles has joined #css
13:23:13 [glazou]
Next topic is WG Charter
13:24:06 [JohnJansen]
note: answer to earlier question from JohnJansen about REC at end of January: Yes.
13:26:10 [dsinger]
dsinger has joined #css
13:26:21 [glazou]
glazou has joined #css
13:26:21 [tantek]
tantek has joined #css
13:26:28 [jdaggett]
jdaggett has joined #css
13:26:38 [szilles]
szilles has joined #css
13:26:40 [dstorey]
dstorey has joined #css
13:28:12 [fantasai]
Topic: Charter
13:28:23 [fantasai]
glazou: Current topic ends at the end of November
13:28:32 [fantasai]
glazou: We need to discuss the charter itself, goals, deliverables, scope, etc.
13:28:38 [fantasai]
glazou: Make sure everyone in the WG agrees
13:28:49 [TabAtkins_]
TabAtkins_ has joined #css
13:29:49 [glazou]
13:30:00 [fantasai]
13:31:30 [fantasai]
fantasai: Propose to add Media Queries to 2007 snapshot text and call it Snapshot 2010
13:31:40 [fantasai]
WG reviews the Scope section of CSS Charter
13:32:33 [ChrisL]
ChrisL has joined #css
13:32:48 [fantasai]
Everyone happy with 1.0
13:32:56 [ChrisL]
rrsagent, here
13:32:56 [RRSAgent]
13:33:49 [tantek]
note to ChrisL - has been updated per your request to make edits to Dependencies section, replacing "predefined" with color keywords, and removal of n/a rules in suggested style sheet that were using dropped attr() function.
13:34:04 [fantasai]
Now looking at 1.1 -- list of modules
13:34:13 [fantasai]
glazou: I think we need to shuffle soem of these items
13:34:14 [szilles]
szilles has joined #css
13:34:20 [fantasai]
glazou: We should preserve CSS2.1?
13:35:12 [fantasai]
ChrisL: How about a 2 month extension to the current charter, then move it into maintenance
13:35:34 [fantasai]
Tantek: And consider 2.1 Errata as the work item
13:37:16 [fantasai]
Going through the list one at a time
13:37:30 [fantasai]
CSS2.1 - expect PR by end of year
13:38:24 [fantasai]
CSS3 Backgrounds and Borders - CR within 1.5 months, have implementations, need test suite, no PR by end of year, likely to REC within next period
13:38:31 [fantasai]
CSS3 Color - PR by end of this year
13:38:41 [fantasai]
CSS Mobile Profile - nobody here cares
13:39:30 [glazou]
13:39:37 [fantasai]
It's in CR right now
13:40:35 [fantasai]
No testing done
13:40:47 [fantasai]
Tantek, Bert: To exit CR, you need two complete implementations.
13:41:44 [fantasai]
dsinger: Send OMA a liaison asking if they have finished it
13:42:02 [fantasai]
dbaron: It depends on specs not in CR
13:42:40 [fantasai]
fantasai: css3-marquee is in CR right now
13:43:36 [miketaylr]
miketaylr has joined #css
13:43:39 [fantasai]
RESOLVED: Move to low priority, send OMA liaison about this
13:44:09 [fantasai]
CSS Namespaces - Almost ready for PR, waiting for a pass on one test
13:44:54 [fantasai]
remains high priority
13:45:00 [fantasai]
CSS Object Model View - ask anne
13:45:13 [dbaron]
I'd say cssom-view is medium priority, but anyway...
13:47:20 [fantasai]
CSS Paged Media Level 3 - needs a lot more work to get to LC, then back to CR
13:48:26 [fantasai]
high priority for several industries, but we are low on resources b/c we the editors are booked with other things
13:48:33 [fantasai]
assigned medium priority right now
13:48:48 [szilles]
szilles has joined #css
13:48:53 [fantasai]
CSS Snapshot 2007 - rename to CSS Snapshots
13:48:55 [fantasai]
keep high priority
13:49:05 [fantasai]
CSS Variables - drop to low priority -- hasn't changed in 2 years
13:49:53 [fantasai]
dbaron: Some of what stopped variables' progress is a misunderstanding
13:50:05 [fantasai]
dbaron: We wanted more data on it, to show that we're going in the right direction
13:50:21 [fantasai]
dbaron: rather than using up core bits of syntax wrongly
13:50:27 [fantasai]
dbaron: That got interpreted as we don't want it
13:50:28 [ChrisL]
ChrisL has joined #css
13:50:50 [fantasai]
howcome: There's also complexity -- e.g. dom access to variables is more complicated than constants
13:50:59 [fantasai]
howcome: It's not just a question of signing up an editor
13:51:44 [dsinger]
dsinger has joined #css
13:51:52 [fantasai]
Daniel: I could do the editorial work, ibut I need implementors who want to do this. [A
13:51:55 [glazou]
glazou has joined #css
13:51:56 [tantek]
tantek has joined #css
13:51:59 [dstorey]
dstorey has joined #css
13:52:00 [jdaggett]
jdaggett has joined #css
13:52:22 [szilles]
szilles has joined #css
13:52:23 [fantasai]
CSS Variables dropped to medium
13:52:29 [fantasai]
Media Queries remains high priority
13:52:35 [fantasai]
Selectors -> maintenance mode
13:53:04 [fantasai]
Need to create a new one for maintenance
13:53:11 [fantasai]
new group
13:53:20 [fantasai]
glazou: Selectors 4?
13:53:28 [fantasai]
dbaron, Tantek: Put it on low or medium priority
13:53:38 [fantasai]
fantasai, Tab: We have items to work on, but it's not a high priority
13:54:06 [fantasai]
moved to low priority
13:54:10 [fantasai]
Selectors 4
13:54:21 [szilles]
szilles has joined #css
13:55:53 [fantasai]
dbaron: HTML5 defines when CSS3 Selectors and CSS3 UI selectors apply to HTML
13:56:44 [ChrisL]
ChrisL has joined #css
13:56:57 [fantasai]
dbaron: But does not introduce new ones
13:57:02 [fantasai]
13:57:15 [TabAtkins_]
TabAtkins_ has joined #css
13:57:21 [TabAtkins_]
13:59:16 [fantasai]
CSS3 UI added as high priority, edited by Tantek
14:01:17 [fantasai]
CSS3 Basic Box Model
14:01:46 [fantasai]
stays at medium priority
14:01:49 [fantasai]
CSS3 Fonts
14:01:51 [fantasai]
high priority
14:01:57 [fantasai]
jdaggett aiming for LC by end of the year
14:02:01 [fantasai]
hopefully REC by end of next year
14:02:46 [szilles]
szilles has joined #css
14:03:58 [fantasai]
CSS3 Generated and Replaced Content
14:04:19 [fantasai]
low priority
14:04:26 [fantasai]
Tab Atkins
14:04:32 [fantasai]
CSS Grid Positioning
14:04:40 [fantasai]
low priority
14:05:40 [fantasai]
jdaggett: I think there's a dependency from vertical text on Grid
14:05:53 [fantasai]
fantasai disagrees
14:06:32 [fantasai]
glazou: kept in charter, low priority
14:06:39 [fantasai]
CSS Marquee -
14:06:44 [fantasai]
Tab: That's only for mobile phones
14:06:55 [fantasai]
Bert: That's indeed only for mobiel phones, the desktop browsers didn't want it
14:07:08 [ChrisL2]
ask OMA
14:07:10 [fantasai]
Bert: Maybe send in same liaison to OMA
14:07:34 [fantasai]
low priority
14:07:39 [Peter]
WebKit implements a large part of it in Chrome/Safari
14:07:46 [fantasai]
CSS Multi-column Layout -
14:07:52 [fantasai]
high priority
14:07:57 [fantasai]
CSSOM - ask Anne
14:08:03 [fantasai]
CSS Ruby -
14:08:29 [fantasai]
fantasai: medium priority; Mozilla is implementing
14:08:39 [fantasai]
CSS Template Layout -
14:08:48 [fantasai]
Tab: keep at medium
14:08:53 [fantasai]
CSS Transforms -
14:08:55 [fantasai]
high priority
14:08:58 [fantasai]
CSS Transitions -
14:09:00 [fantasai]
high priority
14:09:18 [fantasai]
CSS Values and Units
14:09:38 [fantasai]
fantasai: medium priority
14:09:40 [fantasai]
glazou: low
14:09:45 [fantasai]
dbaron: high
14:10:09 [fantasai]
dbaron: I'd like to see it in CR by the end of next year
14:10:53 [fantasai]
howcome doesn't want to finish it
14:12:07 [fantasai]
howcome: What happens if e.g. grid module needs a new unit?
14:12:13 [fantasai]
jdaggett: rev the module
14:12:18 [fantasai]
fantasai: or define it in the grid module
14:12:22 [fantasai]
-> high priority
14:12:42 [fantasai]
CSS3 Extended Box Module
14:12:53 [fantasai]
discuss low or dropped?
14:13:16 [fantasai]
14:13:30 [fantasai]
CSS Flexbox
14:13:35 [fantasai]
medium priority
14:14:13 [fantasai]
14:14:15 [fantasai]
Please update!
14:14:38 [fantasai]
14:14:44 [fantasai]
howcome: We have 2 implementations
14:15:00 [fantasai]
dbaron and fantasai are skeptical of whether it's ready
14:15:49 [kubal]
kubal has joined #css
14:16:02 [fantasai]
for CR
14:16:37 [fantasai]
fantasai: I think it should be at least medium priority, but it's not ready for CR
14:17:01 [fantasai]
fantasai: Much of it is underdefined
14:18:15 [fantasai]
ChrisL: high priority
14:18:29 [fantasai]
jdaggett: We have a lot of high priority items
14:18:40 [fantasai]
JohnJansen: So what's the definition of high priority?
14:18:48 [fantasai]
glazou: We need to list everything we want to work on
14:19:09 [fantasai]
glazou: The high priority ones are the ones that we need to be in a good state, that the AC reps will check on
14:19:13 [fantasai]
GCPM -> medium
14:19:16 [fantasai]
CSS Lists
14:19:18 [fantasai]
14:19:21 [fantasai]
CSS Tables
14:19:29 [fantasai]
glazou: Any work done on Tables?
14:19:44 [fantasai]
dbaron: Lots of work 2 years ago, but nothing since really
14:20:12 [fantasai]
Alex: That was Markus. The work being done was trying to define existing behavior
14:20:43 [fantasai]
dbaron: I would go for low priority, and keep it on the list. It's very similar to 2.1 maintenance -- it's an issue we deferred it because it was difficult, but it's 2.1 level work
14:21:44 [fantasai]
dbaron, alex: if someone comes to work on it, should be able
14:21:44 [fantasai]
14:21:50 [fantasai]
CSS3 Text and CSS3 Text Layout
14:21:54 [fantasai]
medium priority
14:21:58 [fantasai]
needed for EPUB in Japan
14:22:05 [fantasai]
glazou: Anything else not in the list?
14:22:37 [fantasai]
Tantek: CSS4 UI
14:22:55 [fantasai]
glazou: We can just write CSS UI under high priority, and nott list the level
14:23:11 [fantasai]
dbaron: We should add Transforms 3D to the list
14:23:16 [fantasai]
dsinger: add it to low priority
14:23:25 [fantasai]
dbaron: We're implementing 3D, so we're getting to 2 implementations
14:23:29 [fantasai]
dbaron: suggest medium
14:24:28 [fantasai]
howcome: CSS Backgrounds and Borders Level 4
14:27:34 [fantasai]
jdaggett: Line Box module?
14:27:54 [fantasai]
jdaggett: I'd like to have something that's clearer on how text with different baselines is aligned
14:28:14 [fantasai]
CSS Line Box
14:28:16 [fantasai]
-> low priority
14:28:48 [fantasai]
dbaron: The current draft is Michel Suignard's draft from 2001
14:28:59 [fantasai]
dbaron: Plus a half-finished pile of edits I made to make it match 2.1 better
14:29:14 [fantasai]
dbaron: And then some new features, we may or may not want
14:29:35 [fantasai]
Tab: CSS3 Images
14:29:52 [fantasai]
fantasai: we probably want that high priority
14:30:20 [nimbupani]
nimbupani has joined #css
14:31:04 [fantasai]
Bert: Speech?
14:31:20 [fantasai]
dbaron: There's an incubator group working on speech
14:31:28 [fantasai]
dbaron: Not sure if they'd be interested in this
14:32:51 [fantasai]
kept off
14:33:04 [fantasai]
dbaron: Scoping?
14:33:22 [fantasai]
dbaron: HTML5 has scoped style sheets. We might want to put it back in the charter in case we need to work on it
14:33:29 [fantasai]
dbaron: It's probably a feature at risk in HTMl5
14:34:02 [fantasai]
s/Line Box/Line Layout/
14:34:11 [smfr]
smfr has joined #css
14:34:30 [fantasai]
fantasai: style attribute, high priority
14:35:26 [fantasai]
ChrisL: Other things to talk about from the old charter
14:35:53 [fantasai]
ChrisL: We should produce a report on the old charter, what we accomplished on the high priority list
14:36:03 [fantasai]
Chris: how close they get to REC
14:37:00 [fantasai]
ChrisL: Wrt liaisons, CDF closed
14:37:35 [fantasai]
ChrisL: Also, I suggest having two groups, one where we have dependencies and one where we don't
14:37:53 [fantasai]
Dependencies - HTML, SVG, WebApps, Webfonts
14:38:20 [fantasai]
ChrisL: And add MathML
14:38:56 [fantasai]
Daniel: Make maintenance list with 2.1 and Selectors, say that any other documents that go to REC will switch to maintenance
14:39:55 [szilles]
szilles has joined #css
14:40:12 [fantasai]
ACTION: Bert, glazou, CHrisL, Peter - draft charter 2010
14:40:12 [trackbot]
Sorry, couldn't find user - Bert,
14:41:46 [SteveZ2]
SteveZ2 has joined #css
14:41:56 [fantasai]
Discussed changing conference times
14:42:00 [fantasai]
14:42:18 [fantasai]
once a month to allow people in other countries to join
14:42:43 [fantasai]
ChrisL: Also, is 1 hr/wk enough?
14:42:53 [fantasai]
glazou: I think what we have now is a good compromise
14:43:48 [fantasai]
dsinger: I suggest we put 5-minute decision-and-cut items at the front of the agenda
14:43:57 [fantasai]
dsinger: and put technical discussions after that
14:44:09 [smfr]
14:44:25 [fantasai]
glazou: It's very difficult for us co-chairmen to know if we're about to close on something
14:44:57 [fantasai]
glazou: Sometimes we seem close to consensus, and then the discussion goes *rollercoaster sign*
14:45:27 [fantasai]
dbaron: Might be a little extreme, but.. try and put things on the agenda
14:45:42 [fantasai]
dbaron: ask people to respond by email if they have additional points to discuss
14:45:54 [fantasai]
glazou: Once 2.1 is out, things are going to change.
14:46:09 [fantasai]
dbaron: It will encourage people to read the agenda before the telecon and figure out what they think about things
14:46:26 [fantasai]
glazou: I think the past few months the agenda was a collection of potential discussion topics, but reality it was 2.1, period.
14:46:36 [ChrisL]
ChrisL has joined #css
14:46:50 [fantasai]
alexmog: If we defer things for months, people working on css3 would take their own direction
14:46:59 [fantasai]
glazou: we don't have unlimited resources, sorry
14:47:03 [fantasai]
glazou: we do our best
14:47:31 [fantasai]
5 minutes break, then viewport discussion
14:47:49 [szilles]
szilles has joined #css
14:47:53 [anne5]
anne5 has joined #css
14:47:56 [fantasai]
??? introduces himself
14:48:02 [fantasai]
working at opera 10+ years
14:48:06 [fantasai]
???? introduces himself
14:48:21 [TabAtkins_]
First ??? is Rune, second ??? is Oyvind.
14:48:24 [fantasai]
I'm Andre??, I lead our developer relations
14:48:33 [anne5]
14:48:35 [fantasai]
I'm just here to listen
14:48:41 [fantasai]
anne5, yes, see howcome's email
14:48:48 [TabAtkins_]
anne5: Yeah, we are. There's an email about it from Hakon.
14:49:03 [fantasai]
5 minutes break
14:49:44 [smfr]
apologies, i won't be able to dial in for the viewport discussino
14:49:55 [smfr]
i have to go and get some stitches removed
14:54:05 [smfr]
14:55:16 [fantasai]
Topic: Viewport Proposal
14:55:38 [fantasai]
Rune: I wrote an internal spec to explain how we implement the viewport meta tag that Safari implements
14:55:50 [fantasai]
Rune: I've also written a propsoed CSS syntax for that functionality
14:55:56 [fantasai]
Rune: Here's the URL to the proposal
14:56:09 [dbaron]
14:56:13 [fantasai]
14:56:21 [howcome]
howcome has joined #css
14:56:30 [alexmog]
14:56:42 [fantasai]
Rune: Not ging to go over proposal in detail, just have a couple of slides
14:56:42 [SteveZ2]
SteveZ2 has joined #css
14:56:54 [fantasai]
Rune: Problem is that in mobiel browsers you have a very narrow viewport.
14:57:10 [fantasai]
Rune: If you format the page with the viewport as the ICB, most documents on the Web will look really bad
14:57:24 [fantasai]
Rune: What mobile browsers now do is use a different ICB, more like a desktop width
14:58:10 [fantasai]
Rune: Since the desktop width is being used, if page authors want to make pages specifically for smaller screens, they need to override that desktop width that the browser uses
14:58:29 [fantasai]
Rune: THe current status is that Apple introduced a viewport meta tag
14:58:38 [fantasai]
Rune: Several browser vendors have made their own implementation
14:58:51 [fantasai]
Rune: Here's an example, you can specify a device width and set the zoom scale
14:59:13 [fantasai]
Bert: You set the initial zoom. That's the reader's business, not the author
14:59:32 [fantasai]
Bert: It's the wrong way around. If I want a specific width, I should just set this.
14:59:38 [fantasai]
Tantek: I strongly agree with your problem statement.
14:59:56 [fantasai]
Tantek: But what does this get you that max-width on the root element does not
14:59:57 [fantasai]
15:00:11 [fantasai]
fantasai: (or min-width?)
15:00:19 [fantasai]
Tantek: I think the meta tag idea was just dumb
15:00:52 [fantasai]
Tantek: If the author has set a max-width, the device didn't need to zoom out any more
15:00:57 [fantasai]
Tantek: There's no need for the meta tag
15:01:19 [fantasai]
Tantek: This was bad design by someone who did not understand how CSS works.
15:01:57 [fantasai]
Tantek: I'm addressing your third point -- the need for the author saying that a document is made to fit for smaller screen sizes
15:02:06 [fantasai]
dbaron: I think that's not entirely true.
15:02:17 [fantasai]
dbaron: Another problem that come up with pages that use this is pages that have a lot of text.
15:02:28 [fantasai]
dbaron: You really just want to read the text. You don't want to zoom out, and then zoom in to read the text.
15:02:43 [fantasai]
dbaron: It doesn't matter how wide the page is. You want the font size to be readable on the device.
15:03:00 [fantasai]
dbaron: In some cases you have a layout that works for anything from 150 to 400 pixels
15:03:12 [fantasai]
dbaron: e.g. i want to read a newspaper article on a mobile phone
15:03:39 [fantasai]
dbaron: I just want the text readable. I don't necessarily want to set a max-width.
15:04:20 [fantasai]
Alex: fixed positioning is also not fixed by max-width
15:05:08 [fantasai]
Tantek: I agree that dbaron's use case is valid. But it's not the problem solved by viewport meta tag, which *is* solved by max-width.
15:05:33 [fantasai]
Tantek: I would like to see better guidance, with the UA understanding and using and trusting max-width on the root element.
15:09:14 [fantasai]
Tantek: That solves the common use case.
15:09:29 [szilles]
szilles has joined #css
15:09:55 [fantasai]
glazou: Let's hear out the rest of the presentation, and we'll discuss that afterwards
15:10:28 [fantasai]
Rune: Proposed syntax is to standardize the viewport meta functionality in CSS syntax
15:11:13 [fantasai]
Rune: Proposal is an @viewport block similar to @page block
15:11:25 [fantasai]
Rune: Properties include width, hieght, minimum-scale, maximum-scale, etc.
15:11:52 [fantasai]
glazou: I suggest changing "initial-scale" to "zoom"
15:12:18 [fantasai]
Rune: Issues include fixed positioning
15:12:33 [fantasai]
Rune: Fixed positioning is defined relative to the viewport
15:13:00 [fantasai]
Rune: with a containing block that matches the ICB
15:13:15 [fantasai]
Rune: The actual viewport here won't be the same as the ICB
15:13:24 [fantasai]
alexmog: That's why we have this concept of a virtual viewport
15:13:50 [fantasai]
Rune explains how the small viewport moves around the virtual viewport, and then pushing it beyond that boundary causes the content to jump
15:14:10 [fantasai]
Rune: My propose defines an extra viewport. I'm not sure if it's a good idea to call it the viewport or not.
15:14:55 [fantasai]
Rune: Other issues are, is this out-of-scope for CSSWG?
15:15:02 [fantasai]
Rune: e.g. the scaling values
15:15:11 [fantasai]
glazou: I think it's in scope, just question of whether we want to work on it
15:15:28 [fantasai]
Rune: You can also argue that aturhos should make pages that look good on all devices in the first place
15:16:12 [fantasai]
Bert: The problem with this it that it breaks all pages that are designed to work on mobile browsers
15:16:29 [fantasai]
Bert: My mobile browser worked fine, honored media queries, etc.
15:16:34 [fantasai]
Bert: But on Safari it doesn't work.
15:16:43 [fantasai]
Bert: I had to add this extra thing to make them readable.
15:17:03 [fantasai]
Bert: The ones that used to be readable on devices, no longer are readable.
15:17:22 [fantasai]
glazou: What is the interaction with Media Queries?
15:17:35 [fantasai]
Rune: The width and height media queries will match the ICB
15:17:45 [fantasai]
glazou: So what is the parsing order?
15:20:02 [fantasai]
fantasai: Paged media has the same problem with @page { size: ... }, see spec text there
15:20:24 [fantasai]
fantasai: I share dbaron and bert's concerns about universal design
15:20:40 [fantasai]
dbaron: i tried to design a page for iPhone both on landscape and portrait mode, and failed
15:21:12 [fantasai]
dbaron: The logic of the implementation in Safari is somehow wrong
15:22:01 [fantasai]
Andreas: Does it behave differently if load it in portrait mode first vs landscape mode first?
15:24:04 [fantasai]
+smfr over phone
15:24:27 [fantasai]
Tantek: I said that for the fixed width use case, the author can width or max-width today.
15:24:36 [fantasai]
smfr: I filed a bug on Apple, we just need to fix that.
15:24:51 [fantasai]
Tantek: For the device-width case, I do believe it belongs in CSS
15:25:11 [fantasai]
Tantek: I'll state for the record I proposed @viewport in 2004, and it was rejected :)
15:25:58 [fantasai]
Simon: I've been looking at feedback on the mailing list
15:26:12 [fantasai]
Simon: A problem is that a lot of the specs refer to a viewport
15:26:32 [fantasai]
Simon: This proposeal introduces 2 viewports, and you need to specify which viewport is being talked about
15:26:48 [fantasai]
Simon: And also the interaction between the 2 viewports needs to be specified.
15:27:05 [fantasai]
Rune: Yeah, I'm not sure if "viewport" is the right name
15:27:14 [fantasai]
Rune: esp. fixed positioning
15:27:20 [fantasai]
Simon: Fixed positioning is really difficult
15:27:31 [fantasai]
Simon: It gets really weird, especially with scaling
15:27:59 [fantasai]
Simon: Another concern I have is, I'm worried that we're settling on an implementation detail
15:28:11 [fantasai]
Simon: Some of them do real scrolling behavior, others do panning
15:28:29 [fantasai]
Simon: I'm worried that this is trying to specify something that different UAs will want to do differently.
15:28:52 [fantasai]
Tantek: There's wording around the way that overflow is specified in CSS that provides a lot of flexibility in how UAs do "scrolling"
15:29:04 [fantasai]
Tantek: I would like to see similar flexibility in this case as well.
15:29:16 [fantasai]
Tantek: So I think it's possible to address your concern.
15:29:34 [lstorset]
lstorset has joined #css
15:29:35 [fantasai]
dbaron: So, with regards to how much of this to specify
15:29:56 [fantasai]
dbaron: I think one of the criteria of how much to specify is what's going to break web content if someone else decides to go do it differently.
15:30:11 [fantasai]
dbaron: I think for some of the things you metnioned in CSSOM View, there's only one way that'll make e.g. events work right
15:30:15 [fantasai]
wrt clientX, etc.
15:30:23 [fantasai]
dbaron: You have to go with the assumptions the pages are making
15:30:50 [fantasai]
Simon: Another thing is what authors need
15:31:08 [fantasai]
Simon: e.g. some use cases need getClientRects to be relative to the visual viewport
15:31:48 [fantasai]
Rune: I think in most cases you want things relative to the layout viewport
15:32:22 [fantasai]
Rune: I see the visual viewport as a peephole over the layout viewport
15:33:12 [tantek_]
tantek_ has joined #css
15:33:15 [dsinger]
dsinger has joined #css
15:33:26 [glazou]
glazou has joined #css
15:33:27 [dstorey]
dstorey has joined #css
15:33:30 [jdaggett]
jdaggett has joined #css
15:33:44 [TabAtkins_]
TabAtkins_ has joined #css
15:34:04 [smfr]
gotta go
15:34:40 [fantasai]
Simon: I would survey current mobile browsers and see what they do in terms of scorlling, clientrects, etc.
15:34:58 [fantasai]
Rune: I have a comment about the scale values.
15:35:14 [fantasai]
Rune: The constraining procedure that has been taken from the Apple implementations
15:35:33 [fantasai]
Rune: they alter the effect of the width and height values
15:35:52 [tantek]
for the record - my original thoughts on styling the viewport (from 1998!) and my proposal for @viewport with width and height properties from 2004:
15:37:16 [mollydotcom]
mollydotcom has joined #css
15:37:45 [fantasai]
fantasai says some stuff
15:39:34 [fantasai]
about how allowing fixed sizes but not ranges is bad
15:39:45 [ChrisL]
ChrisL has joined #css
15:41:56 [fantasai]
Tantek: We could put this in CSS4 UI
15:42:12 [fantasai]
fantasai: or make a new module
15:42:30 [fantasai]
Rune: If we remove the CSS syntax, what I have is the viewport meta tag
15:43:01 [fantasai]
Tantek: How soon would you implement this?
15:43:22 [fantasai]
Rune: Well, we have to support the meta tag. We don't have any pressing reason to support @viewport
15:43:37 [fantasai]
Rune: It doesn't take too much time to implement it, but that depends on internal priorities
15:43:47 [fantasai]
howcome: I think the approach makes sense
15:43:55 [fantasai]
howcome: The big question is WebKit, what are they going to do
15:44:01 [fantasai]
dsinger: We're happy to discuss it
15:45:19 [fantasai]
glazou: My personal opinion is that it should be its own module.
15:45:25 [fantasai]
glazou: Should we add it to the scope of the new charter?
15:45:27 [fantasai]
howcome: Yes
15:47:48 [fantasai]
Tantek: Feels like something good to whiteboard during a break
15:47:59 [fantasai]
glazou: Should we add that to the charter?
15:48:19 [fantasai]
fantasai: yes
15:48:31 [fantasai]
what to call it?
15:48:33 [fantasai]
CSS Viewport?
15:48:37 [fantasai]
CSS Device Adaptation?
15:48:48 [fantasai]
steve: put it in the charter for IPR commitments
15:49:37 [fantasai]
Tantek: I think there's a level of urgency here
15:50:05 [fantasai]
Steve: So the anser is, IPR commitments apply only to things that become REC.
15:50:24 [fantasai]
Steve: There are two points where you can issue a call for exclusions. first one is FPWD, and the other is CR
15:52:02 [Curt`]
Curt` has joined #css
15:52:43 [fantasai]
fantasai: So, Rune, will you edit the spec?
15:52:47 [fantasai]
Rune is hesitant
15:53:41 [fantasai]
RESOLVED: CSS Device Adaptation added to charter at medium priority, Rune to edit along with someone from Apple
15:57:03 [dstorey]
dstorey has joined #css
16:00:34 [dsinger_]
dsinger_ has joined #css
16:00:46 [tantek]
tantek has joined #css
16:01:32 [fantasai]
meeting closed
16:11:20 [Zakim]
ChrisL, you asked to be reminded at this time to go home
16:13:22 [Zakim]
Zakim has left #CSS
16:35:21 [glazou]
glazou has joined #css
16:50:05 [nimbupani]
nimbupani has joined #css
17:09:58 [tantek]
tantek has joined #css
18:23:06 [tantek]
tantek has joined #css