00:00:05 Fantasai's variant (link 0121 above) is a better wording. 00:01:19 [David describes the parsing algorithm anddealing with incorrect expressions, such as "+-3"] 00:01:59 [3n+2 has to be rejected] 00:02:14 David: 3n++2 has to be rejected, too. 00:02:28 Steve: The spec doesn't actually say anything about ++ 00:03:04 Tantek: Better not mess with something that has been CR for so long, five years, already. 00:03:34 David:I'm OK with relaxing restriction in the future, but not for this version. 00:04:04 Peter: We don't have to note in the spec that we may lift the restriction. 00:04:22 Anne: I think allowing an+-b is fine 00:04:35 Steve: Question if it is editorial or not depends on if it changes the conformance. 00:04:43 (and an-+b for that matter) 00:05:26 Strawpoll on Elika variant of David's proposal: 00:05:47 Numerous in favor, no opposition. 00:07:09 [Discussion about what the spec allows or not about spaces] 00:08:26 ACTION: Daniel to make changes to spec for Selectors to allow spaces as per David/Elika's proposal. 00:08:26 Created ACTION-20 - Make changes to spec for Selectors to allow spaces as per David/Elika's proposal. [on Daniel Glazman - due 2008-04-04]. 00:09:45 http://lists.w3.org/Archives/Public/www-style/2008Mar/0166.html 00:10:22 which is issue 38 http://csswg.inkedblade.net/spec/css2.1#issue-38 00:11:20 Are attribute selectors [att~="x x"] (i.e., with a space) allowed or not? 00:11:47 RESOLVED: Copy wording from Selectors 3 to CSS2.1 00:11:59 ACTION: Bert to make change to CSS 2.1 as per Elkia's proposal. 00:11:59 Created ACTION-21 - Make change to CSS 2.1 as per Elkia's proposal. [on Bert Bos - due 2008-04-04]. 00:12:24 http://csswg.inkedblade.net/spec/css2.1#issue-32 00:12:35 Bert_lap has joined #css 00:12:43 scribenicK bert_lap 00:12:47 http://csswg.inkedblade.net/spec/css2.1#issue-24 00:12:49 scribenick: bert_lap 00:13:06 Topic issue 24 00:13:20 Topic issue 32 00:13:36 Topic: issue 32 00:13:54 The definition of a substantive change (which can trigger a return to WD) is: 00:13:57 A substantive change (whether deletion, inclusion, or other modification) is one where someone could reasonably expect that making the change would invalidate an individual's review or implementation experience. 00:14:50 David gives example: @media screen { p {color: green} div } 00:15:07 The last } doesn't close the @media according to the spec. 00:15:56 and according to David, Firefox properly ignores the last } and keeps processing "inside" the @media block, whereas *other* (not named) implementations close the @media block by that last } 00:16:10 and I know exactly what this will be used for. >:D 00:20:21 Bert: I'm not sure I agree with David's analysis. 00:21:39 Elika: Extending this (issue 24), we should have the matching-brackets principle apply generally across CSS and be the strongest parsing rule after strings 00:23:31 Peter: Do you always close an open paren on the stack before any other recovery rule? 00:23:33 and it should apply everywhere, not only in declaration blocks 00:24:24 Steve: After an error, stop as soon as possible? 00:26:20 Peter: Other example: @media screen { p {color: green} div:nth-child( } 00:26:39 Peter: Now there is a { and an ( open. 00:28:16 Anne: And if it were a different @-rule, say a future one, that does not have rules inside? 00:29:21 Anne: Or consider a UA that doesn't implement @media. 00:30:24 Anne: The example of David is well-formed. 00:32:19 David's proposal to fix the spec is http://lists.w3.org/Archives/Public/www-style/2008Mar/0353.html 00:35:11 David gives another example: p {width: calc(3px } 00:35:29 Fantasai: this would eat the } as part of the calc. 00:36:05 Daniel: There is an error and thus you look for a }, which you find right away. 00:36:49 Fantasai quotes from text that says to skip tokens but match paren pairs. 00:37:11 http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%0A%3Cstyle%3E%20%23x%20{%20background%3Aurl(x}%20)%20}%20%23x%20{%20background%3Alime%20}%20%3C%2Fstyle%3E%0A%0A...%3Cdiv%20id%3Dx%3E%20xxx%3Cdiv%20id%3Dy%3E%20%3C%2Fdiv%3E%20%3C%2Fdiv%3E%0A%0A 00:37:22 (try removing the closing parenthesis) 00:37:48 "Malformed declarations. User agents must handle unexpected tokens encountered while parsing a declaration by reading until the end of the declaration, while observing the rules for matching pairs of (), [], {}, "", and '', and correctly handling escapes. For example, a malformed declaration may be missing a property, colon (:) or value." 00:37:57 from 4.2 00:38:14 ACTION: Arron to come up with more tests. 00:38:14 Created ACTION-22 - Come up with more tests. [on Arron Eicholz - due 2008-04-04]. 00:38:31 Topic: Issue 25 00:38:38 http://csswg.inkedblade.net/spec/css2.1#issue-25 00:38:41 Define what effect } has in style attribute syntax. 00:39:12 (I wonder if it's defined that '{}html { background:lime }' should apply) 00:39:34 David: There are actually different rules in Firefox in quirks vs standards mode. 00:39:45 style="color: red; } ; color: green; " 00:39:50 is it red or green? 00:40:38 Peter: Is it an HTML question or CSS question? 00:41:12 David: I suspect HTML says something vague like: expects style data... 00:41:25 Anne: HTML5 says a declaration block, I think. 00:41:59 The syntax [p.57] of the value of the style attribute is determined by the default 00:41:59 style sheet language [p.186] . For example, for [[CSS2]] inline style, use the 00:41:59 declaration block syntax described in section 4.1.8 (without curly brace delimiters). 00:41:59 Daniel: HTML says the style sheet language chose determines the syntax. 00:42:19 it should be somewhere here: http://www.whatwg.org/specs/web-apps/current-work/multipage/section-wysiwyg.html 00:42:57 http://64.233.167.104/search?q=cache:NGAhkwJnYLMJ:www.whatwg.org/specs/web-apps/current-work/multipage/section-presentational.html+html5+style+attribute&hl=en&ct=clnk&cd=2&gl=us&client=opera 00:43:02 "The style attribute, if specified, must contain only a list of zero or more semicolon-separated (;) CSS declarations." 00:43:20 http://lists.w3.org/Archives/Public/www-style/2007Dec/0167.html 00:44:18 style="color:red}" 00:44:31 style="color:red;}" 00:44:34 style="color:lime; (; color:red" 00:44:57 (though per HTML5 that could be argued to be red) 00:45:37 Daniel: Peter's first example is thrown away, the second has one valid declaration. 00:46:10 Anne: Can split at ":" first and then parse each part, or parse the whole as a CSS block. 00:46:21 s/":"/";"/ 00:47:07 ACTION: Daniel report to HTML WG that def of style attr in HTML5 is incompatible with def in HTML4 and probably problematic from point of view of CSS parsing rules. 00:47:07 Created ACTION-23 - Report to HTML WG that def of style attr in HTML5 is incompatible with def in HTML4 and probably problematic from point of view of CSS parsing rules. [on Daniel Glazman - due 2008-04-04]. 00:47:22 For example, for [[CSS2]] inline style, use the declaration block syntax described in section 4.1.8 (without curly brace delimiters). 00:47:40 Tantek: So HTML should not define any rules? 00:47:40 is what HTML 4.01 said 00:48:23 Tantek: The CSS module for Style attribute syntax was supposed to define this. 00:48:56 Tantek: Could strip that module to just the piece that describes the current style attribute and take it to PR immediately. 00:49:32 RESOLVED: a mismatched closed brace in a style attr is treated as an invalid token. 00:50:22 style="} background:red " versus style="}background:red " 00:50:37 versus style="};background:red " 00:52:05 http://lists.w3.org/Archives/Public/www-style/2008Mar/0166.html 00:52:10 http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0D%0A...%3Cdiv%20id%3Dx%20style%3D%22background%3Ared%20%22%3E%20xxx%3Cdiv%20id%3Dy%3E%20%3C%2Fdiv%3E%20%3C%2Fdiv%3E%0D%0A%0D%0A 00:52:44 Topic: empty substring attribute selectors 00:53:07 David: Previously we decided they were parse errors. 00:53:39 David: But it also seems to affect ~= in CSS2, so now I think we should not do that, because it affects CSS2. 00:53:55 Peter: Previously we said it was valid but matches nothing. 00:55:13 David: CSS 2.1 says it;s a space-separated list of words, an empty string has no words, so matches nothing. 00:55:49 Peter: How about [x~=" "] (*two* spaces), is that an empty word between two spaces? 00:56:03 (I like what Opera does for style attributes. Open the block, close it when you hit }.) 00:56:16 Peter: Existing behavior is that it matches nothing, in three implementations 00:56:55 Peter: So propose to revert previous decision and say it is valid (but matches nothing). 00:57:14 ACTION: Elika write testcase for CSS2.1 00:57:14 Created ACTION-24 - Write testcase for CSS2.1 [on Elika Etemad - due 2008-04-04]. 00:57:15 Peter: Spec should makes this explicit. 00:57:46 ACTION: Elika write empty attr selector testcases for CSS3, investigate :not() 00:57:46 Created ACTION-25 - Write empty attr selector testcases for CSS3, investigate :not() [on Elika Etemad - due 2008-04-04]. 00:58:14 David: For the other attribute selectors, the empty string *always* matches, rather than never. Only Mozilla matches nothing, but I can chnge that. 00:58:21 s/chnge/change/ 00:59:15 s/write empty/check in Alan Gresley's/ 01:00:06 Peter: Would like similar behavior from all attribute selectors. 01:00:32 David: Matching on words with ~= is somewhat different from matching substring, though. 01:02:27 Proposal: *= ~= ^= $= all accept empty string, but match nothing 01:03:04 Resolved. 01:03:37 Question about two spaces in [x~=" "] was not further discussed. 01:03:48 End of meeting. 01:04:02 Dinner: meet in hotel lobby at 6:45 pm 01:06:37 We should consider adding 01:06:37 ot txet cinodehportsuob 01:06:37 Cascading Style Sheets. 01:08:38 ADJOURN FOR TODAY 01:10:28 RRSAgent, make logs public 01:12:48 jason_cranfordtea has joined #css 01:13:21 alexmog has joined #css 01:20:17 ACTION: Elika post page-break-inside examples to www-style 01:20:17 Created ACTION-26 - Post page-break-inside examples to www-style [on Elika Etemad - due 2008-04-04]. 01:33:27 if anyone is still here who is near daniel, let him know that i agree with his comment on style="" and html5 01:33:33 and that the spec will be fixed in due course 01:41:34 anne has left #css 06:40:21 anne has joined #css 07:04:42 Arron has joined #CSS 07:36:50 tantek has joined #css 10:43:35 bjoern has joined #css 16:15:57 RRSAgent has joined #css 16:15:57 logging to http://www.w3.org/2008/03/28-css-irc 16:15:59 RRSAgent, make logs member 16:16:01 Zakim, this will be Style_CSS FP 16:16:01 I do not see a conference matching that name scheduled within the next hour, trackbot-ng 16:16:02 Meeting: Cascading Style Sheets (CSS) Working Group Teleconference 16:16:02 Date: 28 March 2008 16:16:08 RRSAgent, make logs public 16:16:26 glazou has changed the topic to: CSS WG face-to-face meeting, San Diego, 28-mar-2008, TOPIC is technical 16:17:19 Zakim, remind me in 365 days to remind me of this statement. 16:17:19 I don't understand the last part of that, tantek; about what am I supposed to remind you? 16:17:30 dbaron has joined #css 16:17:57 molly has joined #css 16:18:08 Zakim, remind in 365 days of to repeat this statement. 16:18:08 I don't understand the last part of that, tantek; about what am I supposed to remind you? 16:18:16 anne has joined #css 16:19:12 Zakim, remind me in 365 days to upgrade your natural language parser. 16:19:12 I don't understand the last part of that, tantek; about what am I supposed to remind you? 16:19:33 zakim: who is your daddy? 16:19:43 zakim, who is your daddy? 16:19:43 Ralph is taking good care of me but you all are my family, glazou 16:19:58 I love you too, Zakim 16:20:19 Zakim, remind me in 32767 hours 16:20:19 ok, tantek 16:21:36 ScribeNick: SteveZ2 16:21:40 ScribeNick: SteveZ2 16:22:01 Meeting: CSS Working Group Face-to-Face Meeting, San Diego, CA 16:22:03 Topic: CSS Object Model View 16:22:07 http://dev.w3.org/csswg/cssom-view/ 16:22:39 AVK: the introduction needs to be edited 16:22:50 Present: Daniel Glazman, Tantek Çelik, David Baron, Chris Lilley, Jason Cranford-Teague, Steve Zilles, Bert Bos, Anne van Kesteren, Arron Eicholtz, Molly Holzschlag, Ming, Elika Etemad, Peter Linss 16:22:54 AVK: most of the comments have been replied to 16:23:14 AVK: there are no examples in the spec 16:23:48 AVK: there are test (not exactly a test suite) 16:24:52 CL: put a section in the spec that links to a W3C CSS test page which will link to the test 16:25:15 Action: AVK: put link to CSS test page in the document 16:25:15 Sorry, couldn't find user - AVK: 16:25:40 Action: Anne put link to CSS test page in the document 16:25:40 Created ACTION-27 - Put link to CSS test page in the document [on Anne van Kesteren - due 2008-04-04]. 16:26:36 q+ 16:27:05 AVK: most of the attributes come from Internet Explorer, but the spec does not mimic them exactly, instead it is a union of what the browsers do 16:27:20 CL: this statement should be in the document 16:27:28 ack glazou 16:28:28 DG: strongly suggests that the spec document whether or not the width of the scroll is taken into account in the computations 16:29:26 CL: should have an example, screen shot from some browser, that shows the handling of scroll bars 16:29:59 AVK: two new things, the media type and a way to find whether a media type applies to the current view 16:30:28 chris has joined #css 16:30:53 rrsagent, here 16:30:53 See http://www.w3.org/2008/03/28-css-irc#T16-30-53 16:31:35 AVK: was a proposal to extend the client rect interface with an explicit height and width (not implemented by anyone yet) 16:32:02 s/client rect/ClientRect/ 16:32:06 AVK; these values can be computed using top and bottom and left and right 16:32:57 EE: these seem useful and simple to implement. Why not put them in and mark them "at risk". 16:33:57 AVK: most of the changes suggested are editorial so we should be able to go to last call after these edits are made 16:34:52 Resolve: take the CSSOM spec to last call after the edits are made 16:35:47 Topic: CSS Object Model discussion 16:36:09 My draft: http://dev.w3.org/csswg/cssom/ 16:36:39 s/CSSOM spec/CSSOM-View spec/ 16:36:44 DG: Since 1998-9 where has been a view that the CSS object model is badly designed, but an effort to fix it went nowhere 16:36:46 mjs has joined #css 16:37:14 DG: usage of some of the facilities, esp get computed style 16:37:44 DG: should we improve the model, to make it more useful 16:38:10 AVK: we should clarify the existing model before extending it; I am working on the clarification 16:39:22 AVK: doing CSS animations would likely solve many of the use cases for an extended Object Model 16:39:53 AVK: we should wait and see what is left to do after CSS animation is done 16:39:54 q+ 16:41:25 ack chris 16:41:35 http://www.w3.org/TR/SVG/svgdom.html#RelationShipWithCSSOM 16:41:40 PL: should we require every module to identify the extensions to the CSS Object model that come from that module 16:42:24 http://dev.w3.org/csswg/cssom/#history 16:42:30 CL: I would like to ask that other specs that use the CSS Object Model be considered in any changes to the spec 16:42:36 q+ 16:43:20 AVK: I have attempted to be clear about what is happening to the spec and notify relevant people. There is a complete change history in the spec 16:43:35 ack fantasai 16:44:07 EE: can we action AVK to create a list of what needs to be defined for new properties added in other modules 16:44:11 Please review the spec section I linked to above to see what impact that will have on implementations that did the existing CSSOM 16:45:01 AVK: I do not plan to introduce new interfaces so you would only need to define the string representation (canonicalize) for the property values 16:46:04 AVK: this "text" interface can also be used to set values, but it is not clear what parsing rules need to apply in this case 16:47:42 I agree that its intrinsic to the property 16:48:00 BB: put the canonicalization information into CSS is adding information that does required for a non-DOM implementation of CSS 16:48:22 s/does/is only/ 16:48:26 s/put/putting/ 16:49:33 The canonicalization info is required for the DOM, it should be in the DOM spec. It's not required for implementing CSS, it should not be in the CSS spec. 16:49:43 Many: that the canonicaltion information is part of the property definition and, therefore, is best put with the property in the CSS specification. 16:50:35 s/canonicaltion/canonicalization/ 16:52:08 Strawpoll: Should the canonicalization information be put in the specification for non-CR modules 16:52:19 Vote: 10 yes, 1 no 16:52:36 BB: I am strongly opposed to adding this information in the CSS spec 16:52:42 s/Vote/Straw poll/ 16:52:48 rrsagent, here 16:52:48 See http://www.w3.org/2008/03/28-css-irc#T16-52-48 16:54:26 DB: is there a document that shows what has been done w.r.t. canonicalization for existing properties. This information would help drive future canonicalization 16:54:47 Action: Anne develop a list of the existing canonicalizations 16:54:48 Created ACTION-28 - Develop a list of the existing canonicalizations [on Anne van Kesteren - due 2008-04-04]. 16:55:03 and just that at least the part for existing properties ought to be reviewed as a coherent whole rather than reviewed (or, more likely, not noticed) during the review of each module. 16:56:38 Action: Anne e-mail the group with information on how to create and document the Object Model part of a module 16:56:39 Created ACTION-29 - E-mail the group with information on how to create and document the Object Model part of a module [on Anne van Kesteren - due 2008-04-04]. 16:58:05 scribenick: chris 16:58:35 BB: What to do with comments in the CSSOM? 16:58:59 DG: We allow comments everywhere in CSS, even between tokens, so extremely hard to preserve them 16:59:18 ... only if we restricted comments to occur between rules would it be tractable 16:59:30 AVK: All comments dropped during parsing 16:59:49 DG: Big issue for editors, need to preserve rules and comments not understood 17:00:00 AVK: Editors need a specialised CSS OM 17:00:19 ... but no need to standardise it, browsers will not expose it 17:00:59 CL: if you "content editiable" how is that handled 17:01:14 CL: If you have editable text and the editing is ricjh, so has editable styling, it might be relevant to a browser ... 17:01:39 BB: Want to use this for pretty printing etc and preserve all comments and rules 17:01:56 DG: How to rrepresent a comment between two values? 17:02:24 SZ: Agree an editor needs this but a presenter does not and the burden on implementation is much harder 17:02:51 PL: If the browser throws all comments but an editor preserves them, a script may run in a browser and fail in an editor 17:03:10 DG: Online editors use browsers and are iincreasingly common 17:03:42 SZ: The interface that gives you comments can be different 17:03:54 AVK: Not relevant to Teh Web 17:04:07 s/Teh/The/ 17:04:24 DG: Inserting comments has to be test based, not object based 17:05:09 s/test/text/ 17:05:12 AVK: Still doesnt help if you also drop declarations 17:06:32 s/The Web/Teh Web (tm)/ 17:06:53 CL; in the regular DOM people oftern want to run a pass that eliminates spaces because they are irrelevant to most processes 17:07:07 AVK; Would break existing stuff if we no longer preserve rules not understood 17:07:30 PL: Normal interface would skip, but if preserved then it could be reserialised 17:08:19 AVK: 80% case is scripts in browsers, editor case is not relevant and is the 2% case 17:08:34 ... editor needs a complete new model 17:08:51 PL: This is more for a future editor model, do we need one 17:09:30 SZ: DG said a standard one would be good, so what is the reason for one? Are editor scripts needed to be cross-implementation? 17:09:32 (I could use a CSSOM to replace, e.g., -moz-opacity by opacity in all rules.) 17:09:50 AVK: Those are mosyly not dom based, they are textarea based 17:10:08 DG: No, increasingly they are DOM based and this is improving 17:10:45 DG: CSS OM released in 98, saw first uses only 4 years ago 17:12:57 SZ: This is a new (potential) module and not something to add to the existing omne, so it needs an advocate 17:13:06 s/omne/one/ 17:13:19 PL: Any advocate? 17:13:33 DG: (... pause ..... ) YES 17:14:30 Resolved: Daniel is the advocate for a CSS DOM Editing Module 17:15:07 http://dev.w3.org/csswg/css3-namespace/issues-2 17:15:08 Topic: CSS Namespaces 17:15:22 scribenick: SteveZ2 17:15:46 DG: the XHTML2 WG issued a formal objection: 17:16:17 DG: can we have the exact date that their comment was rejected and the minutes 17:17:06 EE: it was raised formally on 27 March, 2008 17:17:30 EE: the rejection was sent by Anne on 13 March, 2008 17:18:31 DG: Its up to the WG not the editor to decide formal objections 17:18:46 DG: the WG did not formally consider this rejection, therefore it was not formally rejected. 17:19:41 AVK and EE: the editors sent the response with the rationale based on their best judgement 17:21:09 DB: it is reasonable that the editors issue a reply and not bring it to the WG unless the commenter stays unhappy 17:24:24 DG: using "we" means that the commentor could not tell whether it was the editor or the WG had taken the action 17:24:27 The rejection was here, by fantasai http://lists.w3.org/Archives/Public/www-style/2008Mar/0283.html 17:26:46 CL: in addition, saying in the reply, the if the commentor was unsatisfied they should raise a formal objection before the WG had reviewed the comment was not the right step 17:28:00 The original comment seemed reasonable to me; the arguments against also seem well argued. I don't see that this needed to go to a formal objection; there was resoned discussion on both sides 17:28:32 Fantasai summed it up well: 17:28:35 q+ 17:28:39 ======== quote === 17:28:43 Nobody is forcing authors to declare a default namespace. They can rely 17:28:43 on prefixes only. But they also have the option of declaring a default 17:28:43 namespace. This allows the author to choose whether backwards-compatibility 17:28:43 would be better served by hiding the rules or letting them fall back to 17:28:43 more generous matching. 17:28:55 ===== end quote ======= 17:29:38 I'm tired of one or two people in a WG who are interested in another WG's spec to use the authority of the WG they're in to raise the level of the conflict (as in so many comments from some people being "this is the XHTML2 WG's comment" when it's really just one person in that WG who has an opinion on the spec), and thus turning it into a WG coordination issue 17:32:55 CL: note that having the editors "reject" a comment is the same thing as having a subset of the WG speaking with authority of the WG 17:33:58 EE: I was under the impression that asking for a formal objection was the correct next step in the discussion of this comment. 17:35:37 DG and PL: But, the affect of taking this step is to take the resolution of the issue out of the hands of the WG (before the WG has officially considered it) and putting it in the hands of the Director 17:37:08 TC: The process that has been followed is the editor replies to the commentor and asks if the commentor is satisfied. If the commentor is not satisfied, then they should reply to the editor and these comments are then reviewed by the WG 17:38:33 It is possible to add more discussion and then ask for the formal objection to be withdrawn 17:39:50 DG: please do not use "we reject" unless it is the action of the WG. It is the use of "we" that is ambiguous. It is also the case that "reject" should not be used because ti is a word that has a formal meaning in the W3C. 17:40:19 DG: Use "I disagree" instead. 17:42:28 PL: It is not likely the case that the WG disagrees with your conclusions nor your rationale, it is simply that the WG did not have the opportunity to make that assessment prior to requesting a formal objection. 17:44:34 DG: do not "request a formal objection" unless that action is taken by the WG. 17:44:53 Break till 11:00 17:56:37 mjs has joined #css 18:14:12 The meeting restarts 18:14:48 Topic: Technical discussion of the Namespace comment from 18:15:29 ack fantasai 18:15:54 Action: chris propose a response to the XHTML2 WG comment on namespaces based on the e-mail log on this issue 18:15:54 Created ACTION-30 - Propose a response to the XHTML2 WG comment on namespaces based on the e-mail log on this issue [on Chris Wilson - due 2008-04-04]. 18:18:07 DG: I hope that continuing the discussion with the XHTML2 WG will help them withdraw their formal objection and hopefully resolve the open issue. 18:18:50 DB: it seems that the comment might be satisfied by a note which gives guidance to authors on how to use the facility 18:21:24 CL: the next step is to develop a note for the spec that would resolve their issue. 18:22:07 chris has joined #css 18:22:50 SZ: it is up to the commentor to decide if the comment was satisfactorily resolved 18:23:04 Topic: Test Suites 18:23:30 s/Suites/Suites for Namespaces/ 18:23:53 EE and AVK: there are tests 18:24:49 AVK: there is agreement on the spec, but there are some areas where implementatons need to be brought up the spec 18:26:51 AVK: these are whether you can declare the empty string to be the default namespace and the handling of case sensitivity 18:27:25 AVK: otherwise the existing implementations do the spec and would support a positive implementation report 18:27:33 It would be useful to collect that implementation experience in a draft implementation report 18:27:52 Topic: Status of Test Suite 18:28:42 AE: Microsoft released 700 tests and there is a need for help in reviewing these tests; note that more are coming 18:29:08 DB: what is the process for re-releasing test that have recieved comments? 18:29:20 AE: that is still under discussion 18:30:04 AE: areas were there are issues are: background positions, language selector, EM and EX calculations 18:30:40 AE: will probably release additional tests with each IE8 beta release. 18:31:31 EE: HP is contributing tests on the Paged Media module; EE is reviewing these and they will be posted when that reivew is completed 18:32:27 EE: Ming has another Team working on the test suite, esp. the harness. It is an extension of the level 1 harness that will less interfer with the tests and give better implementation reports 18:32:41 s/reivew/review/ 18:33:37 EE: Main issue is the test suite licensing; we need to agree on that. EE wants to change the test suite license or post a second copy under the BSD license. 18:37:06 BB: I want it to be clear what the W3C test suite is. I would like the license to say that a user cannot change the test and make any claims for compliance 18:38:59 Many: It is not necessary to say anything in the test itself. it suffices to say in the doucment where the official test suite is and that the tests at that location have the WeC document license 18:39:14 s/WeC/W3C/ 18:39:30 s/doucment/document/ 18:41:44 EE: Any extra licensing requirements on the "open" tests would only help protect against claims based on derived tests; it would not help with claims based on newly contributed tests 18:42:03 http://www.opensource.org/licenses/bsd-license.php 18:42:10 "Neither the name of the nor the names of its contributors may be used to endorse or promote products derived from this software without specific prior written permission." 18:42:32 TC: it is the community exposure and process that will protect against such claims. 18:50:45 EE: I am willing to solicit the pair of licensed needed to implement a double posting of tests 18:51:34 CL and SZ: asking the lawyers to change the licensing requirements introduces a long delay in getting tests posted 18:51:40 Resolved: the intent of the WG to post two coies of the test suite, one with the W3C license and one with the BSD 3 clause license; the copy with the W3C license is the W3C CSS test suite. 18:52:45 ACTION: Elika update contribution guidelines to require agreement to BSD 3-clause 18:52:45 Created ACTION-31 - Update contribution guidelines to require agreement to BSD 3-clause [on Elika Etemad - due 2008-04-04]. 18:53:01 ACTION: Elika update scripts to generate BSD and non-BSD copies of test suite 18:53:01 Created ACTION-32 - Update scripts to generate BSD and non-BSD copies of test suite [on Elika Etemad - due 2008-04-04]. 18:53:13 ACTION: Elika update test suite documentation to reflect licensing 18:53:13 Created ACTION-33 - Update test suite documentation to reflect licensing [on Elika Etemad - due 2008-04-04]. 18:54:15 please consider all my contributions to the CSS working group as an invited expert to be placed into the public domain. This includes any test cases, examples, and text submitted for working drafts or other working group documents. 18:54:53 public domain per http://creativecommons.org/licenses/publicdomain/ 18:55:50 DB and AVK: Provided the above policy on test case goes into implementation, Mozilla and Opera will submit test cases to the test suite. 18:55:59 Topic: Color Module 18:56:19 but most of our current tests aren't in the CSS test suite format, so it will be a gradual process 18:57:20 CL: the current conformance requirements mean that an implementation can conform doing almost nothing. 18:58:32 CL: at the moment the only requirement for color profiles is that the be parsed; this makes testing difficult 18:58:43 mjs has joined #css 18:59:08 http://csswg.inkedblade.net/spec/css3-color 18:59:23 CL: I don't object to dropping this feature 18:59:41 http://lists.w3.org/Archives/Public/www-style/2008Mar/0304.html 18:59:46 AVK: currently, color profiles are not implemented in CSS; the current plan is to drop the color profile feature for Lv3 and add it back in Lv4 19:00:02 CL: this is an OK plan 19:00:51 DB: I have reiviewed all the messages that I could find concerning CSS3 Color; there are 24 issues 19:02:10 DB: 2 of these were to remove features that have not evidenced 2 implementaitions: these features are: color profile property, the rendering intent property, the @color -profile #rule and the flavor value 19:03:15 DB: there are a number of editorial issues; the editor will handle these 19:03:52 DB: there are a bunch of comments that I propose to reject; these are primarily ones adding features to the spec. 19:05:06 DB: The answer should be that the suggestion is reasonalble, but the document has been in CR and we want to progress it. Such suggestion will be considered in the next version. 19:06:01 DB: summarizing issue 2; remove the ATTR fcn to remove dependendcy on Values level 3 19:06:36 DB: Issue 5: clarifying the defintion on 3D borders 19:06:52 DB: Issue 4; the most complex issue 19:07:53 http://www.w3.org/Style/Group/css2-src/syndata.html#color-units 19:08:05 DB: in RGB space, values outside the device gamut are clamped to the border of the gamut on a component by component basis (this does not, of course, work) 19:08:27 CL: can i see the wording 19:09:04 DB: "the red, green and blue values must be changed to lie within the gamut" 19:09:43 DB: there are examples that imply a component by component by comoponent clip 19:10:59 system-color test file://localhost/data/WWW/WWW/Graphics/SVG/Group/repository/testsuite/1.2T/htmlObjectHarness/tiny-paint-color-04-t.html 19:12:53 SZ: we can add an explicit provision that "this specification does not define how the adjustment is made to get a within gamut value' 19:14:13 DB: has done an update to specify the HSL clipping to attempt to preserve the Hue 19:14:39 I agree with these changes for HSL processing 19:14:54 DB: another issue is that we have not defined the clamping for the "A" versions of RGB and HSL 19:17:08 DB: the proposed solution is that clamping of the color gamut occur before the compositing occurs 19:17:52 CL: compositing has a lot of implementation outside of CSS and I would like to see what those do before making a decision on this part of the spec 19:18:41 Action: bert ask Chris L to gather the information on compositing clamping are report that back to the WG. 19:18:41 Created ACTION-34 - Ask Chris L to gather the information on compositing clamping are report that back to the WG. [on Bert Bos - due 2008-04-04]. 19:19:30 http://www.w3.org/TR/SVG/masking.html#SimpleAlphaBlending 19:19:39 14.2 Simple alpha compositing 19:20:05 DB; Issue 9 site section 14.2 of SVG 1.1 for definition of what opacity means 19:21:28 DB: Issue 16, people have argued that "system colors" should not be deprecated 19:21:39 CL: Deprecated means that new content shouldn't use the feature, and implementations need to support the feature. 19:22:08 CL: 'deprecated" means that new content should not use the feature and, because old content may have the feature new implementation must implemented it. 19:23:15 TC: the was already resolved in the existing disposition of comments; no new information has been raised. the existing rejection is re-affirmed 19:23:25 s/the/this/ 19:23:56 DB: Issue 17, current color works like EM and font-size 19:24:27 what is the computed value for color: currentColor ? 19:25:13 DB: the computed value should be color; when this happens is not so clear 19:25:19 dbaron: the computed (ie actual) actual color (of the parent) 19:25:52 DB: we should remove "at parse time" from the current description 19:26:03 No objections were raised 19:26:41 DB: Issue 20 this is my issue which I have rejected 19:27:29