IRC log of css on 2008-03-28

Timestamps are in UTC.

00:00:05 [Bert]
Fantasai's variant (link 0121 above) is a better wording.
00:01:19 [Bert]
[David describes the parsing algorithm anddealing with incorrect expressions, such as "+-3"]
00:01:59 [Bert]
[3n+2 has to be rejected]
00:02:14 [Bert]
David: 3n++2 has to be rejected, too.
00:02:28 [Bert]
Steve: The spec doesn't actually say anything about ++
00:03:04 [Bert]
Tantek: Better not mess with something that has been CR for so long, five years, already.
00:03:34 [Bert]
David:I'm OK with relaxing restriction in the future, but not for this version.
00:04:04 [Bert]
Peter: We don't have to note in the spec that we may lift the restriction.
00:04:22 [anne]
Anne: I think allowing an+-b is fine
00:04:35 [Bert]
Steve: Question if it is editorial or not depends on if it changes the conformance.
00:04:43 [anne]
(and an-+b for that matter)
00:05:26 [Bert]
Strawpoll on Elika variant of David's proposal:
00:05:47 [Bert]
Numerous in favor, no opposition.
00:07:09 [Bert]
[Discussion about what the spec allows or not about spaces]
00:08:26 [Bert]
ACTION: Daniel to make changes to spec for Selectors to allow spaces as per David/Elika's proposal.
00:08:26 [trackbot-ng]
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 [fantasai]
00:10:22 [fantasai]
which is issue 38
00:11:20 [Bert]
Are attribute selectors [att~="x x"] (i.e., with a space) allowed or not?
00:11:47 [fantasai]
RESOLVED: Copy wording from Selectors 3 to CSS2.1
00:11:59 [Bert]
ACTION: Bert to make change to CSS 2.1 as per Elkia's proposal.
00:11:59 [trackbot-ng]
Created ACTION-21 - Make change to CSS 2.1 as per Elkia's proposal. [on Bert Bos - due 2008-04-04].
00:12:24 [fantasai]
00:12:35 [Bert_lap]
Bert_lap has joined #css
00:12:43 [Bert_lap]
scribenicK bert_lap
00:12:47 [fantasai]
00:12:49 [Bert_lap]
scribenick: bert_lap
00:13:06 [Bert_lap]
Topic issue 24
00:13:20 [Bert_lap]
Topic issue 32
00:13:36 [Bert_lap]
Topic: issue 32
00:13:54 [SteveZ2]
The definition of a substantive change (which can trigger a return to WD) is:
00:13:57 [SteveZ2]
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 [Bert_lap]
David gives example: @media screen { p {color: green} div }
00:15:07 [Bert_lap]
The last } doesn't close the @media according to the spec.
00:15:56 [tantek]
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 [tantek]
and I know exactly what this will be used for. >:D
00:20:21 [Bert_lap]
Bert: I'm not sure I agree with David's analysis.
00:21:39 [fantasai]
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 [Bert_lap]
Peter: Do you always close an open paren on the stack before any other recovery rule?
00:23:33 [fantasai]
and it should apply everywhere, not only in declaration blocks
00:24:24 [Bert_lap]
Steve: After an error, stop as soon as possible?
00:26:20 [Bert_lap]
Peter: Other example: @media screen { p {color: green} div:nth-child( }
00:26:39 [Bert_lap]
Peter: Now there is a { and an ( open.
00:28:16 [Bert_lap]
Anne: And if it were a different @-rule, say a future one, that does not have rules inside?
00:29:21 [Bert_lap]
Anne: Or consider a UA that doesn't implement @media.
00:30:24 [Bert_lap]
Anne: The example of David is well-formed.
00:32:19 [Bert_lap]
David's proposal to fix the spec is
00:35:11 [Bert_lap]
David gives another example: p {width: calc(3px }
00:35:29 [Bert_lap]
Fantasai: this would eat the } as part of the calc.
00:36:05 [Bert_lap]
Daniel: There is an error and thus you look for a }, which you find right away.
00:36:49 [Bert_lap]
Fantasai quotes from text that says to skip tokens but match paren pairs.
00:37:11 [anne]!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 [anne]
(try removing the closing parenthesis)
00:37:48 [fantasai]
"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 [fantasai]
from 4.2
00:38:14 [Bert_lap]
ACTION: Arron to come up with more tests.
00:38:14 [trackbot-ng]
Created ACTION-22 - Come up with more tests. [on Arron Eicholz - due 2008-04-04].
00:38:31 [Bert_lap]
Topic: Issue 25
00:38:38 [fantasai]
00:38:41 [fantasai]
Define what effect } has in style attribute syntax.
00:39:12 [anne]
(I wonder if it's defined that '{}html { background:lime }' should apply)
00:39:34 [Bert_lap]
David: There are actually different rules in Firefox in quirks vs standards mode.
00:39:45 [fantasai]
style="color: red; } ; color: green; "
00:39:50 [fantasai]
is it red or green?
00:40:38 [Bert_lap]
Peter: Is it an HTML question or CSS question?
00:41:12 [Bert_lap]
David: I suspect HTML says something vague like: expects style data...
00:41:25 [Bert_lap]
Anne: HTML5 says a declaration block, I think.
00:41:59 [glazou]
The syntax [p.57] of the value of the style attribute is determined by the default
00:41:59 [glazou]
style sheet language [p.186] . For example, for [[CSS2]] inline style, use the
00:41:59 [glazou]
declaration block syntax described in section 4.1.8 (without curly brace delimiters).
00:41:59 [Bert_lap]
Daniel: HTML says the style sheet language chose determines the syntax.
00:42:19 [anne]
it should be somewhere here:
00:42:57 [anne]
00:43:02 [anne]
"The style attribute, if specified, must contain only a list of zero or more semicolon-separated (;) CSS declarations."
00:43:20 [fantasai]
00:44:18 [plinss]
00:44:31 [plinss]
00:44:34 [anne]
style="color:lime; (; color:red"
00:44:57 [anne]
(though per HTML5 that could be argued to be red)
00:45:37 [Bert_lap]
Daniel: Peter's first example is thrown away, the second has one valid declaration.
00:46:10 [Bert_lap]
Anne: Can split at ":" first and then parse each part, or parse the whole as a CSS block.
00:46:21 [anne]
00:47:07 [Bert_lap]
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 [trackbot-ng]
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 [dbaron]
For example, for [[CSS2]] inline style, use the declaration block syntax described in section 4.1.8 (without curly brace delimiters).
00:47:40 [Bert_lap]
Tantek: So HTML should not define any rules?
00:47:40 [dbaron]
is what HTML 4.01 said
00:48:23 [Bert_lap]
Tantek: The CSS module for Style attribute syntax was supposed to define this.
00:48:56 [Bert_lap]
Tantek: Could strip that module to just the piece that describes the current style attribute and take it to PR immediately.
00:49:32 [Bert_lap]
RESOLVED: a mismatched closed brace in a style attr is treated as an invalid token.
00:50:22 [anne]
style="} background:red " versus style="}background:red "
00:50:37 [anne]
versus style="};background:red "
00:52:05 [fantasai]
00:52:10 [anne]!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 [Bert_lap]
Topic: empty substring attribute selectors
00:53:07 [Bert_lap]
David: Previously we decided they were parse errors.
00:53:39 [Bert_lap]
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 [Bert_lap]
Peter: Previously we said it was valid but matches nothing.
00:55:13 [Bert_lap]
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 [Bert_lap]
Peter: How about [x~=" "] (*two* spaces), is that an empty word between two spaces?
00:56:03 [anne]
(I like what Opera does for style attributes. Open the block, close it when you hit }.)
00:56:16 [Bert_lap]
Peter: Existing behavior is that it matches nothing, in three implementations
00:56:55 [Bert_lap]
Peter: So propose to revert previous decision and say it is valid (but matches nothing).
00:57:14 [fantasai]
ACTION: Elika write testcase for CSS2.1
00:57:14 [trackbot-ng]
Created ACTION-24 - Write testcase for CSS2.1 [on Elika Etemad - due 2008-04-04].
00:57:15 [Bert_lap]
Peter: Spec should makes this explicit.
00:57:46 [fantasai]
ACTION: Elika write empty attr selector testcases for CSS3, investigate :not()
00:57:46 [trackbot-ng]
Created ACTION-25 - Write empty attr selector testcases for CSS3, investigate :not() [on Elika Etemad - due 2008-04-04].
00:58:14 [Bert_lap]
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 [Bert_lap]
00:59:15 [fantasai]
s/write empty/check in Alan Gresley's/
01:00:06 [Bert_lap]
Peter: Would like similar behavior from all attribute selectors.
01:00:32 [Bert_lap]
David: Matching on words with ~= is somewhat different from matching substring, though.
01:02:27 [Bert_lap]
Proposal: *= ~= ^= $= all accept empty string, but match nothing
01:03:04 [Bert_lap]
01:03:37 [Bert_lap]
Question about two spaces in [x~=" "] was not further discussed.
01:03:48 [Bert_lap]
End of meeting.
01:04:02 [Bert_lap]
Dinner: meet in hotel lobby at 6:45 pm
01:06:37 [dbaron]
We should consider adding
01:06:37 [dbaron]
ot txet cinodehportsuob
01:06:37 [dbaron]
Cascading Style Sheets.
01:08:38 [glazou]
01:10:28 [dbaron]
RRSAgent, make logs public
01:12:48 [jason_cranfordtea]
jason_cranfordtea has joined #css
01:13:21 [alexmog]
alexmog has joined #css
01:20:17 [fantasai]
ACTION: Elika post page-break-inside examples to www-style
01:20:17 [trackbot-ng]
Created ACTION-26 - Post page-break-inside examples to www-style [on Elika Etemad - due 2008-04-04].
01:33:27 [Hixie]
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 [Hixie]
and that the spec will be fixed in due course
01:41:34 [anne]
anne has left #css
06:40:21 [anne]
anne has joined #css
07:04:42 [Arron]
Arron has joined #CSS
07:36:50 [tantek]
tantek has joined #css
10:43:35 [bjoern]
bjoern has joined #css
16:15:57 [RRSAgent]
RRSAgent has joined #css
16:15:57 [RRSAgent]
logging to
16:15:59 [trackbot-ng]
RRSAgent, make logs member
16:15:59 [Zakim]
Zakim has joined #css
16:16:01 [trackbot-ng]
Zakim, this will be Style_CSS FP
16:16:01 [Zakim]
I do not see a conference matching that name scheduled within the next hour, trackbot-ng
16:16:02 [trackbot-ng]
Meeting: Cascading Style Sheets (CSS) Working Group Teleconference
16:16:02 [trackbot-ng]
Date: 28 March 2008
16:16:08 [tantek]
RRSAgent, make logs public
16:16:26 [glazou]
glazou has changed the topic to: CSS WG face-to-face meeting, San Diego, 28-mar-2008, TOPIC is technical
16:17:19 [tantek]
Zakim, remind me in 365 days to remind me of this statement.
16:17:19 [Zakim]
I don't understand the last part of that, tantek; about what am I supposed to remind you?
16:17:30 [dbaron]
dbaron has joined #css
16:17:57 [molly]
molly has joined #css
16:18:08 [tantek]
Zakim, remind in 365 days of to repeat this statement.
16:18:08 [Zakim]
I don't understand the last part of that, tantek; about what am I supposed to remind you?
16:18:16 [anne]
anne has joined #css
16:19:12 [tantek]
Zakim, remind me in 365 days to upgrade your natural language parser.
16:19:12 [Zakim]
I don't understand the last part of that, tantek; about what am I supposed to remind you?
16:19:33 [molly]
zakim: who is your daddy?
16:19:43 [glazou]
zakim, who is your daddy?
16:19:43 [Zakim]
Ralph is taking good care of me but you all are my family, glazou
16:19:58 [glazou]
I love you too, Zakim
16:20:19 [tantek]
Zakim, remind me in 32767 hours
16:20:19 [Zakim]
ok, tantek
16:21:36 [glazou]
ScribeNick: SteveZ2
16:21:40 [SteveZ2]
ScribeNick: SteveZ2
16:22:01 [dbaron]
Meeting: CSS Working Group Face-to-Face Meeting, San Diego, CA
16:22:03 [SteveZ2]
Topic: CSS Object Model View
16:22:07 [anne]
16:22:39 [SteveZ2]
AVK: the introduction needs to be edited
16:22:50 [dbaron]
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 [SteveZ2]
AVK: most of the comments have been replied to
16:23:14 [SteveZ2]
AVK: there are no examples in the spec
16:23:48 [SteveZ2]
AVK: there are test (not exactly a test suite)
16:24:52 [SteveZ2]
CL: put a section in the spec that links to a W3C CSS test page which will link to the test
16:25:15 [SteveZ2]
Action: AVK: put link to CSS test page in the document
16:25:15 [trackbot-ng]
Sorry, couldn't find user - AVK:
16:25:40 [SteveZ2]
Action: Anne put link to CSS test page in the document
16:25:40 [trackbot-ng]
Created ACTION-27 - Put link to CSS test page in the document [on Anne van Kesteren - due 2008-04-04].
16:26:36 [glazou]
16:27:05 [SteveZ2]
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 [SteveZ2]
CL: this statement should be in the document
16:27:28 [plinss]
ack glazou
16:28:28 [SteveZ2]
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 [SteveZ2]
CL: should have an example, screen shot from some browser, that shows the handling of scroll bars
16:29:59 [SteveZ2]
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]
chris has joined #css
16:30:53 [chris]
rrsagent, here
16:30:53 [RRSAgent]
16:31:35 [SteveZ2]
AVK: was a proposal to extend the client rect interface with an explicit height and width (not implemented by anyone yet)
16:32:02 [anne]
s/client rect/ClientRect/
16:32:06 [SteveZ2]
AVK; these values can be computed using top and bottom and left and right
16:32:57 [SteveZ2]
EE: these seem useful and simple to implement. Why not put them in and mark them "at risk".
16:33:57 [SteveZ2]
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 [SteveZ2]
Resolve: take the CSSOM spec to last call after the edits are made
16:35:47 [SteveZ2]
Topic: CSS Object Model discussion
16:36:09 [anne]
My draft:
16:36:39 [chris]
s/CSSOM spec/CSSOM-View spec/
16:36:44 [SteveZ2]
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]
mjs has joined #css
16:37:14 [SteveZ2]
DG: usage of some of the facilities, esp get computed style
16:37:44 [SteveZ2]
DG: should we improve the model, to make it more useful
16:38:10 [SteveZ2]
AVK: we should clarify the existing model before extending it; I am working on the clarification
16:39:22 [SteveZ2]
AVK: doing CSS animations would likely solve many of the use cases for an extended Object Model
16:39:53 [SteveZ2]
AVK: we should wait and see what is left to do after CSS animation is done
16:39:54 [chris]
16:41:25 [glazou]
ack chris
16:41:35 [chris]
16:41:40 [SteveZ2]
PL: should we require every module to identify the extensions to the CSS Object model that come from that module
16:42:24 [anne]
16:42:30 [SteveZ2]
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 [fantasai]
16:43:20 [SteveZ2]
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 [plinss]
ack fantasai
16:44:07 [SteveZ2]
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 [chris]
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 [SteveZ2]
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 [SteveZ2]
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 [chris]
I agree that its intrinsic to the property
16:48:00 [SteveZ2]
BB: put the canonicalization information into CSS is adding information that does required for a non-DOM implementation of CSS
16:48:22 [chris]
s/does/is only/
16:48:26 [SteveZ2]
16:49:33 [Bert]
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 [SteveZ2]
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 [SteveZ2]
16:52:08 [SteveZ2]
Strawpoll: Should the canonicalization information be put in the specification for non-CR modules
16:52:19 [SteveZ2]
Vote: 10 yes, 1 no
16:52:36 [SteveZ2]
BB: I am strongly opposed to adding this information in the CSS spec
16:52:42 [chris]
s/Vote/Straw poll/
16:52:48 [chris]
rrsagent, here
16:52:48 [RRSAgent]
16:54:26 [SteveZ2]
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 [SteveZ2]
Action: Anne develop a list of the existing canonicalizations
16:54:48 [trackbot-ng]
Created ACTION-28 - Develop a list of the existing canonicalizations [on Anne van Kesteren - due 2008-04-04].
16:55:03 [dbaron]
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 [SteveZ2]
Action: Anne e-mail the group with information on how to create and document the Object Model part of a module
16:56:39 [trackbot-ng]
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 [chris]
scribenick: chris
16:58:35 [chris]
BB: What to do with comments in the CSSOM?
16:58:59 [chris]
DG: We allow comments everywhere in CSS, even between tokens, so extremely hard to preserve them
16:59:18 [chris]
... only if we restricted comments to occur between rules would it be tractable
16:59:30 [chris]
AVK: All comments dropped during parsing
16:59:49 [chris]
DG: Big issue for editors, need to preserve rules and comments not understood
17:00:00 [chris]
AVK: Editors need a specialised CSS OM
17:00:19 [chris]
... but no need to standardise it, browsers will not expose it
17:00:59 [SteveZ2]
CL: if you "content editiable" how is that handled
17:01:14 [chris]
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 [chris]
BB: Want to use this for pretty printing etc and preserve all comments and rules
17:01:56 [chris]
DG: How to rrepresent a comment between two values?
17:02:24 [chris]
SZ: Agree an editor needs this but a presenter does not and the burden on implementation is much harder
17:02:51 [chris]
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 [chris]
DG: Online editors use browsers and are iincreasingly common
17:03:42 [chris]
SZ: The interface that gives you comments can be different
17:03:54 [chris]
AVK: Not relevant to Teh Web
17:04:07 [SteveZ2]
17:04:24 [chris]
DG: Inserting comments has to be test based, not object based
17:05:09 [Bert]
17:05:12 [chris]
AVK: Still doesnt help if you also drop declarations
17:06:32 [chris]
s/The Web/Teh Web (tm)/
17:06:53 [SteveZ2]
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 [chris]
AVK; Would break existing stuff if we no longer preserve rules not understood
17:07:30 [chris]
PL: Normal interface would skip, but if preserved then it could be reserialised
17:08:19 [chris]
AVK: 80% case is scripts in browsers, editor case is not relevant and is the 2% case
17:08:34 [chris]
... editor needs a complete new model
17:08:51 [chris]
PL: This is more for a future editor model, do we need one
17:09:30 [chris]
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 [Bert]
(I could use a CSSOM to replace, e.g., -moz-opacity by opacity in all rules.)
17:09:50 [chris]
AVK: Those are mosyly not dom based, they are textarea based
17:10:08 [chris]
DG: No, increasingly they are DOM based and this is improving
17:10:45 [chris]
DG: CSS OM released in 98, saw first uses only 4 years ago
17:12:57 [chris]
SZ: This is a new (potential) module and not something to add to the existing omne, so it needs an advocate
17:13:06 [chris]
17:13:19 [chris]
PL: Any advocate?
17:13:33 [chris]
DG: (... pause ..... ) YES
17:14:30 [chris]
Resolved: Daniel is the advocate for a CSS DOM Editing Module
17:15:07 [fantasai]
17:15:08 [chris]
Topic: CSS Namespaces
17:15:22 [SteveZ2]
scribenick: SteveZ2
17:15:46 [SteveZ2]
DG: the XHTML2 WG issued a formal objection:
17:16:17 [SteveZ2]
DG: can we have the exact date that their comment was rejected and the minutes
17:17:06 [SteveZ2]
EE: it was raised formally on 27 March, 2008
17:17:30 [SteveZ2]
EE: the rejection was sent by Anne on 13 March, 2008
17:18:31 [chris]
DG: Its up to the WG not the editor to decide formal objections
17:18:46 [SteveZ2]
DG: the WG did not formally consider this rejection, therefore it was not formally rejected.
17:19:41 [SteveZ2]
AVK and EE: the editors sent the response with the rationale based on their best judgement
17:21:09 [SteveZ2]
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 [SteveZ2]
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 [chris]
The rejection was here, by fantasai
17:26:46 [SteveZ2]
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 [chris]
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 [chris]
Fantasai summed it up well:
17:28:35 [fantasai]
17:28:39 [chris]
======== quote ===
17:28:43 [chris]
Nobody is forcing authors to declare a default namespace. They can rely
17:28:43 [chris]
on prefixes only. But they also have the option of declaring a default
17:28:43 [chris]
namespace. This allows the author to choose whether backwards-compatibility
17:28:43 [chris]
would be better served by hiding the rules or letting them fall back to
17:28:43 [chris]
more generous matching.
17:28:55 [chris]
===== end quote =======
17:29:38 [dbaron]
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 [SteveZ2]
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 [SteveZ2]
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 [SteveZ2]
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 [SteveZ2]
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 [chris]
It is possible to add more discussion and then ask for the formal objection to be withdrawn
17:39:50 [SteveZ2]
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 [SteveZ2]
DG: Use "I disagree" instead.
17:42:28 [SteveZ2]
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 [SteveZ2]
DG: do not "request a formal objection" unless that action is taken by the WG.
17:44:53 [SteveZ2]
Break till 11:00
17:56:37 [mjs]
mjs has joined #css
18:14:12 [SteveZ2]
The meeting restarts
18:14:48 [SteveZ2]
Topic: Technical discussion of the Namespace comment from
18:15:29 [plinss]
ack fantasai
18:15:54 [SteveZ2]
Action: chris propose a response to the XHTML2 WG comment on namespaces based on the e-mail log on this issue
18:15:54 [trackbot-ng]
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 [SteveZ2]
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 [SteveZ2]
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 [SteveZ2]
CL: the next step is to develop a note for the spec that would resolve their issue.
18:22:07 [chris]
chris has joined #css
18:22:50 [SteveZ2]
SZ: it is up to the commentor to decide if the comment was satisfactorily resolved
18:23:04 [SteveZ2]
Topic: Test Suites
18:23:30 [SteveZ2]
s/Suites/Suites for Namespaces/
18:23:53 [SteveZ2]
EE and AVK: there are tests
18:24:49 [SteveZ2]
AVK: there is agreement on the spec, but there are some areas where implementatons need to be brought up the spec
18:26:51 [SteveZ2]
AVK: these are whether you can declare the empty string to be the default namespace and the handling of case sensitivity
18:27:25 [SteveZ2]
AVK: otherwise the existing implementations do the spec and would support a positive implementation report
18:27:33 [chris]
It would be useful to collect that implementation experience in a draft implementation report
18:27:52 [SteveZ2]
Topic: Status of Test Suite
18:28:42 [SteveZ2]
AE: Microsoft released 700 tests and there is a need for help in reviewing these tests; note that more are coming
18:29:08 [SteveZ2]
DB: what is the process for re-releasing test that have recieved comments?
18:29:20 [SteveZ2]
AE: that is still under discussion
18:30:04 [SteveZ2]
AE: areas were there are issues are: background positions, language selector, EM and EX calculations
18:30:40 [SteveZ2]
AE: will probably release additional tests with each IE8 beta release.
18:31:31 [SteveZ2]
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 [SteveZ2]
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 [Bert]
18:33:37 [SteveZ2]
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 [SteveZ2]
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 [SteveZ2]
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 [SteveZ2]
18:39:30 [SteveZ2]
18:41:44 [SteveZ2]
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 [fantasai]
18:42:10 [fantasai]
"Neither the name of the <ORGANIZATION> 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 [SteveZ2]
TC: it is the community exposure and process that will protect against such claims.
18:50:45 [SteveZ2]
EE: I am willing to solicit the pair of licensed needed to implement a double posting of tests
18:51:34 [SteveZ2]
CL and SZ: asking the lawyers to change the licensing requirements introduces a long delay in getting tests posted
18:51:40 [SteveZ2]
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 [fantasai]
ACTION: Elika update contribution guidelines to require agreement to BSD 3-clause
18:52:45 [trackbot-ng]
Created ACTION-31 - Update contribution guidelines to require agreement to BSD 3-clause [on Elika Etemad - due 2008-04-04].
18:53:01 [fantasai]
ACTION: Elika update scripts to generate BSD and non-BSD copies of test suite
18:53:01 [trackbot-ng]
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 [fantasai]
ACTION: Elika update test suite documentation to reflect licensing
18:53:13 [trackbot-ng]
Created ACTION-33 - Update test suite documentation to reflect licensing [on Elika Etemad - due 2008-04-04].
18:54:15 [tantek]
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 [tantek]
public domain per
18:55:50 [SteveZ2]
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 [SteveZ2]
Topic: Color Module
18:56:19 [dbaron]
but most of our current tests aren't in the CSS test suite format, so it will be a gradual process
18:57:20 [SteveZ2]
CL: the current conformance requirements mean that an implementation can conform doing almost nothing.
18:58:32 [SteveZ2]
CL: at the moment the only requirement for color profiles is that the be parsed; this makes testing difficult
18:58:43 [mjs]
mjs has joined #css
18:59:08 [dbaron]
18:59:23 [fantasai]
CL: I don't object to dropping this feature
18:59:41 [dbaron]
18:59:46 [SteveZ2]
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 [SteveZ2]
CL: this is an OK plan
19:00:51 [SteveZ2]
DB: I have reiviewed all the messages that I could find concerning CSS3 Color; there are 24 issues
19:02:10 [SteveZ2]
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 [SteveZ2]
DB: there are a number of editorial issues; the editor will handle these
19:03:52 [SteveZ2]
DB: there are a bunch of comments that I propose to reject; these are primarily ones adding features to the spec.
19:05:06 [SteveZ2]
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 [SteveZ2]
DB: summarizing issue 2; remove the ATTR fcn to remove dependendcy on Values level 3
19:06:36 [SteveZ2]
DB: Issue 5: clarifying the defintion on 3D borders
19:06:52 [SteveZ2]
DB: Issue 4; the most complex issue
19:07:53 [Bert]
19:08:05 [SteveZ2]
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 [SteveZ2]
CL: can i see the wording
19:09:04 [SteveZ2]
DB: "the red, green and blue values must be changed to lie within the gamut"
19:09:43 [SteveZ2]
DB: there are examples that imply a component by component by comoponent clip
19:10:59 [chris]
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 [SteveZ2]
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 [SteveZ2]
DB: has done an update to specify the HSL clipping to attempt to preserve the Hue
19:14:39 [chris]
I agree with these changes for HSL processing
19:14:54 [SteveZ2]
DB: another issue is that we have not defined the clamping for the "A" versions of RGB and HSL
19:17:08 [SteveZ2]
DB: the proposed solution is that clamping of the color gamut occur before the compositing occurs
19:17:52 [SteveZ2]
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 [SteveZ2]
Action: bert ask Chris L to gather the information on compositing clamping are report that back to the WG.
19:18:41 [trackbot-ng]
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 [chris]
19:19:39 [chris]
14.2 Simple alpha compositing
19:20:05 [SteveZ2]
DB; Issue 9 site section 14.2 of SVG 1.1 for definition of what opacity means
19:21:28 [SteveZ2]
DB: Issue 16, people have argued that "system colors" should not be deprecated
19:21:39 [fantasai]
CL: Deprecated means that new content shouldn't use the feature, and implementations need to support the feature.
19:22:08 [SteveZ2]
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 [SteveZ2]
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 [SteveZ2]
19:23:56 [SteveZ2]
DB: Issue 17, current color works like EM and font-size
19:24:27 [chris]
what is the computed value for color: currentColor ?
19:25:13 [SteveZ2]
DB: the computed value should be color; when this happens is not so clear
19:25:19 [chris]
dbaron: the computed (ie actual) actual color (of the parent)
19:25:52 [SteveZ2]
DB: we should remove "at parse time" from the current description
19:26:03 [SteveZ2]
No objections were raised
19:26:41 [SteveZ2]
DB: Issue 20 this is my issue which I have rejected
19:27:29 [SteveZ2]
Issue 22 which requests a more formal grammer for something that is not clear; resolution please propose text if you want me to make a change
19:27:42 [anne]
bjoern, ^^
19:28:26 [Bert]
19:29:03 [SteveZ2]
PL: as a matter of process we cannot always expect that a commentor can provide :"proposed text" so we should ask for clarification and if it can be provided proposed text
19:30:51 [SteveZ2]
DB: given Anne's new issues (25 and 26) the draft is not quite ready for last call
19:31:42 [dbaron]
bjoern, the <name> thing is a dropped feature -- no longer in the spec
19:31:48 [dbaron]
is in a dropped feature
19:31:49 [bjoern]
19:33:10 [SteveZ2]
DB: once I have test for the new issues I will also publish a new test suite
19:34:12 [chris]
19:35:00 [SteveZ2]
DB: I think Firefox 3 passes all the test currently in the test suite
19:35:24 [SteveZ2]
This topic is closed
19:35:34 [SteveZ2]
LUNCH till 1:30
19:36:03 [anne]
19:57:04 [chris]
20:00:03 [molly]
21:03:17 [molly]
scribe: nick
21:03:21 [molly]
scribe: molly
21:03:27 [fantasai]
ScribeNick: molly
21:03:42 [chris]
zakim, help
21:03:42 [Zakim]
Please refer to for more detailed help.
21:03:44 [Zakim]
Some of the commands I know are:
21:03:46 [Zakim]
xxx is yyy - establish yyy as the name of unknown party xxx
21:03:48 [Zakim]
if yyy is 'me' or 'I', your nick is substituted
21:03:51 [Zakim]
xxx may be yyy - establish yyy as possibly the name of unknown party xxx
21:03:53 [Zakim]
I am xxx - establish your nick as the name of unknown party xxx
21:03:55 [Zakim]
xxx holds yyy [, zzz ...] - establish xxx as a group name and yyy, etc. as participants within that group
21:03:58 [Zakim]
xxx also holds yyy - add yyy to the list of participants in group xxx
21:03:58 [anne]
Zakim, please stop
21:04:00 [Zakim]
who's here? - lists the participants on the phone
21:04:03 [Zakim]
who's muted? - lists the participants who are muted
21:04:06 [Zakim]
mute xxx - mutes party xxx (like pressing 61#)
21:04:08 [Zakim]
unmute xxx - reverses the effect of "mute" and of 61#
21:04:10 [Zakim]
is xxx here? - reports whether a party named like xxx is present
21:04:12 [Zakim]
list conferences - reports the active conferences
21:04:14 [Zakim]
this is xxx - associates this channel with conference xxx
21:04:15 [Zakim]
excuse us - disconnects from the irc channel
21:04:16 [Zakim]
I last learned something new on $Date: 2008/02/29 01:55:37 $
21:04:17 [Zakim]
I don't understand 'please stop', anne
21:04:26 [chris]
zakim, thanks for sharing ... TOO much :)
21:04:26 [Zakim]
I'm glad that smiley is there, chris
21:04:27 [anne]
Zakim, I don't get you either
21:04:28 [Zakim]
I don't understand 'I don't get you either', anne
21:04:30 [glazou]
glazou has joined #css
21:04:56 [molly]
topic: tree list styles
21:06:14 [glazou]
21:06:18 [plinss]
21:06:56 [molly]
Daniel: Issues: rendering or behavioral, I don't know where the limit is in this proposal
21:07:00 [shepazu]
shepazu has joined #css
21:07:19 [Bert]
Earlier similar proposal:
21:07:21 [molly]
Daniel: If it doesn't do the folding/unfolding it does fit under rendering
21:07:36 [molly]
Daniel: It solves something that authors implement
21:08:07 [molly]
Daniel: Proposal is okay based on rendering rather than behavior
21:08:20 [molly]
Daniel: will help a lot of web designers
21:08:32 [molly]
SteveZ: what does just rendering mean in your sentence?
21:09:09 [molly]
Daniel: Purely stylistic
21:09:28 [molly]
David: Two concerns here. One: This is one of those areas where authors are going to be somewhat picky visually about results
21:09:57 [molly]
David: And I'm not sure if we have a proposal that's going to satisfy 90% that it's useful - hard for me to tell whether this is useful to many or few
21:10:58 [molly]
David: The problem is that there's a bunch of different cases within trees; node; child; visually the last child looks different - some of those things seem like they'd be better addressed using selectors with multiple types
21:11:20 [molly]
Daniel: I see your point, but I think the intent is to get rid of selectors, one value for tree
21:11:37 [molly]
David: Can we write rules for how the equivalent of those selectors would work
21:12:27 [molly]
Daniel: The problem is ensuring pixel precise, drawing the line
21:12:37 [fantasai]
21:12:38 [molly]
David: I should respond to the proposal on list
21:12:57 [molly]
Fantasai: Authors want to control design of lines - color, width, etc.
21:13:08 [molly]
Peter: Proposal suggested using outline
21:13:27 [molly]
Daniel: Agree with David if we solve 80% of cases
21:13:42 [fantasai]
Fantasai: without that control, we can't solve 80% .. more like 10%
21:13:45 [molly]
Arron: I think the color issue is probably easy to address if we support the marker pseudo element
21:14:31 [molly]
Daniel (at whiteboard): Can markers span? How can you make sure it acquires exactly the height of the element
21:15:19 [Bert]
Some things that need to be specified: What parts of the style do authors want to control? color? more? What happens with 'list-style-position: inside'. Anything automaticly drawn for nested lists with the same style?
21:15:53 [molly]
Anne: Think this out and write a proposal?
21:16:01 [molly]
Daniel: We have to see the interest
21:16:10 [molly]
Bert: Some brainstorming
21:16:42 [molly]
SteveZ: The way you solve the element with margin and treeline, three cases - same as shaping in Arabic. Initial, final, medial
21:16:56 [molly]
the medial treeline is one that goes from the top to the bottom of that element /including/ any margins
21:17:59 [molly]
Peter: Instead of it being part of the market that's part of the list item make it belong to the list
21:18:47 [fantasai]
Daniel: you should be able to combine tree-line and a bullet
21:18:47 [molly]
Bert: We don't have an object for the list at the moment in CSS
21:19:26 [molly]
Daniel: display-tree or whatever the name will be
21:20:25 [Bert]
s/display-tree/'display: tree'/
21:20:25 [fantasai]
Molly: Seems to me, what authors would really like..
21:20:32 [Bert]
(I think that is what Daniel meant)
21:20:39 [fantasai]
Molly: Steve says there are these initial, middle, and final pieces of the tree
21:20:54 [fantasai]
Molly: If you gave authors control over what these look like, that should give authors enough control
21:21:20 [Bert]
We call it a tree, but it's actually a sequence. It has a first element, but not a root.
21:22:49 [molly]
SteveZ: the marker is the horizontal piece and the line is what connects them - the line goes from the top of the list - that defines the bar
21:22:55 [molly]
Daniel: That's good
21:23:05 [molly]
SteveZ: that gives us places to put all the color and so forth
21:23:26 [molly]
Fantasai: No because if the parent has its own marker, you need something other than :: marker.
21:24:09 [Bert]
(Steve gives a model in which there are two pieces: the parent's piece is the verticla bar, the childrens' piece is a symbol that is connected to that bar.)
21:25:54 [molly]
action: Daniel to contact Andrew regarding joining group
21:25:54 [trackbot-ng]
Created ACTION-35 - Contact Andrew regarding joining group [on Daniel Glazman - due 2008-04-04].
21:26:27 [chris]
trackbot-ng, status
21:27:00 [molly]
action: Daniel report back to Andrew re: tree proposal
21:27:00 [trackbot-ng]
Created ACTION-36 - Report back to Andrew re: tree proposal [on Daniel Glazman - due 2008-04-04].
21:27:38 [molly]
Next Topic: Multi-style elements
21:27:52 [molly]
Daniel: This was commented on
21:28:09 [molly]
Bert: Collapsing is what's mentioned, but I think that's not the right concept. It's an element with two styles
21:28:44 [molly]
Bert: Like XSL fewer/more
21:29:03 [molly]
Bert: My idea was to have either one or two pseudo classes - normal and alternative
21:29:14 [molly]
Daniel: How will this be linked to the document tree
21:30:08 [molly]
Anne: The user agent will provide the UI to toggle between element styles
21:31:17 [fantasai]
Elika, Daniel: Need to define a toggleable element
21:31:17 [molly]
toggleable elements
21:32:16 [fantasai]
Bert's proposal is that simply defining the different styles makes the element toggleable
21:32:32 [fantasai]
Peter: Merely offering an alternative style doesn't make it toggleable
21:32:41 [molly]
Peter: That behavior should not be defined by CSS
21:33:55 [molly]
SteveZ: I'm arguing that you have two presentations and you toggle between the two - this is within the scope of CSS
21:34:20 [molly]
SteveZ: it seems reasonable that if you have alternative presentations that makes those elements styles accessible in some way
21:35:42 [molly]
Peter: I don't have a problem with a property or display type to change to toggleable: The presence of a pseudo classes in a selector should not give me the ability to toggle
21:35:58 [molly]
:hoverability :)
21:36:23 [molly]
propose :toggleability pseudo class
21:36:35 [anne]
hmm, :toggle
21:36:48 [fantasai]
This sounds related to Presentation Levels
21:36:55 [anne]
anyway, I think it would make sense to move on
21:37:08 [molly]
Bert: Do we need two states or any?
21:37:09 [anne]
there's no concrete proposal here
21:37:15 [molly]
Peter: All elements have n states
21:37:26 [molly]
Bert: I didn't propose that because the syntax becomes ugly
21:38:13 [glazou]
21:39:58 [molly]
Chris: So you're saying :hover sets a precedence
21:40:11 [molly]
Peter: :hover is a clearly defined state, toggled is not
21:40:24 [molly]
Anne: :hover isn't either, in mobile devices
21:41:52 [molly]
Peter: Daniel talked about extensible pseudo classes
21:42:01 [chris]
hover is very clearly defined in mobile decices. Unless there is a pointer device, nothing *can* be hovered; but its very clearly defined
21:42:02 [molly]
Daniel: It's an old dream / I know that Bert is going to scream
21:42:46 [molly]
Daniel: Needs for extension in selectors. script+extending the set of pseudo classes for a specific web site only
21:43:00 [molly]
Daniel: The performance could be terrible, but that's the web site's problem
21:43:40 [molly]
Daniel: Not saying it's the best, but could be useful
21:43:50 [molly]
Anne: How's this better than manipulating classes?
21:44:06 [molly]
Bert: If you have a script already, why don't you manipulate the variable in the script
21:44:14 [molly]
Pete: the idea is that it would be outside the DOM
21:45:02 [molly]
Bert: What does this have to do with CSS
21:45:14 [chris]
so you avoid triggering mutation events. plus point for doing it outside the document tree
21:46:50 [molly]
Fantasai: I don't want to execute any functions
21:47:20 [glazou]
I suggests :hasUserData(key)
21:47:27 [fantasai]
Molly: I'm not following this discussion. I think that says something about how useful it would be to authors
21:47:29 [glazou]
or an equiv
21:47:31 [anne]
(you could've setState(state, boolean) ...)
21:47:45 [fantasai]
David: Getting a property in JS executes getters
21:47:46 [anne]
(and :matches-state(state) { } )
21:48:05 [fantasai]
Steve: Daniel is asking for scriptable selectors.
21:48:05 [glazou]
21:48:11 [chris]
scribenick: fantasai
21:48:14 [anne]
(but this can be done using classes pretty easily)
21:48:24 [fantasai]
Steve: The issue of a selector for a node is, "does this selector apply to this node"
21:48:37 [fantasai]
Steve: The idea is that you determine this with a function that takes a node and returns true or false
21:48:55 [fantasai]
Molly: If this were implemented, we're basically putting in CSS hooks for JS to be able to manipulate..
21:49:32 [fantasai]
David: Allowing JavaScript to manipulate the DOM tree while you're matching selectors is very scary
21:49:46 [fantasai]
David: As in "this feature probably won't get past security review" scary
21:49:56 [Bert]
I'd rather not have machine-readable definitions of extensions, unless those definitions are in a declarative language.
21:51:55 [chris]
doing this with classes thrashes the DOM. Better to hold that state outside the DOM
21:52:47 [fantasai]
Going back to multi-state
21:52:55 [fantasai]
Bert volunteers to advocate that
21:53:24 [fantasai]
Steve: part of the issue seems to be how this releates to the UA
21:53:36 [fantasai]
Steve: how does toggle get determined?
21:53:42 [Bert]
A first write-up:
21:54:15 [fantasai]
ACTION: Bert update proposal
21:54:15 [trackbot-ng]
Created ACTION-37 - Update proposal [on Bert Bos - due 2008-04-04].
22:20:42 [fantasai]
22:21:29 [fantasai]
Topic: Web Fonts
22:23:17 [glazou]
22:23:56 [fantasai]
Anne: I'd like it to be in scope for the next charter. That's all.
22:24:13 [fantasai]
Anne: Advocate was Jason, secondary is me.
22:24:52 [fantasai]
Anne: The proposal is to remove all features except those implemented by WebKit and Opera
22:25:52 [fantasai]
Chris: SVG's editor now has some time, should be able to work on it some
22:26:08 [fantasai]
Chris: So I'm putting together a spec
22:28:06 [fantasai]
Chris: IPR issues will need to be resolved before this becomes a workable solution, but that doesn't go in the spec
22:29:51 [fantasai]
Peter: So should that be in our charter or stay in SVG's?
22:30:09 [fantasai]
Chris: We'd want review from this group before last call
22:30:16 [fantasai]
Steve: Could list as a joint project with SVG
22:30:35 [fantasai]
Anne finds this acceptable
22:30:55 [fantasai]
Anne: I'm not opposed to them owning it
22:31:15 [fantasai]
Chris: Most implementations use the XML syntax, not CSS syntax
22:31:42 [fantasai]
Chris: All the font synthesis and font emulation stuff is being dropped
22:32:05 [fantasai]
RESOLVED: Add web fonts to charter as coordinated effort with SVG group
22:32:22 [fantasai]
Topic: Constants
22:32:29 [chris]
Would certainly like early review by this group
22:32:58 [fantasai]
22:33:16 [fantasai]
Daniel: Main use case is colors..
22:33:26 [fantasai]
Daniel: Don't want to repeat values over and over in style sheet
22:33:34 [fantasai]
Daniel: Has been constant request from web designers since 1997
22:33:42 [chris]
<!ENTITY myteal "#307F5C " >
22:33:46 [fantasai]
Daniel: I'm not saying we have to do it, but we should give a reply. Either we do it, or we don't do it because
22:33:54 [chris]
oh -whoops, no xml syntax
22:33:55 [fantasai]
David: I know there have been a lot of requests for it
22:34:14 [fantasai]
David: What I've tried to extract the use cases, and at which points in the style sheets does that require constants to be allowed
22:34:25 [fantasai]
David: That has a lot of effect on how hard it is to implement
22:34:37 [fantasai]
David: It could be that the ones people care about are all easy to implement
22:36:11 [fantasai]
Elika explains that if we want to do this, we should do it for values, for property declaration lists, and for selectors
22:36:43 [fantasai]
Elika: These are requests coming in from the WaSP feedback
22:37:17 [fantasai]
Elika: They term them differently, with ideas of "explicit inheritance" and stuff like that.. but it seems what they're trying to solve would all be solved by macros for these three things
22:37:37 [fantasai]
22:38:01 [fantasai]
Daniel: Importing a style sheet of constants would replace system colors, would allow site-wide corporate colors to be used consistency
22:38:20 [fantasai]
Chris: Use case is replacing search and replace where you don't want to replace, e.g. all instances of 'black'
22:38:35 [fantasai]
Steve: Sounds like &substitution; in XML, and the only warning I'd give is
22:38:48 [fantasai]
Steve: They removed that in XML.
22:38:50 [fantasai]
Chris: No they didn't
22:39:02 [fantasai]
Daniel: XMLization of CSS is not on the radar.
22:39:50 [fantasai]
Chris: You could do it inside the <style> element
22:39:53 [anne]
(I think at this point we need use cases/problem statements and proposals.)
22:39:55 [fantasai]
Peter: You could do it in PHP
22:39:59 [chris]
in an xhtml document for example
22:40:02 [anne]
(Which are probably better dealt with on the list)
22:40:04 [fantasai]
Daniel: I think authors want the substitution on the client side
22:42:53 [fantasai]
Elika reads some comments from
22:44:28 [fantasai]
Elika: I think being able to have macros for values, sequences of declarations, and selectors would solve 90%+ of the use cases
22:45:36 [fantasai]
Elika: It would be expanded and then parsed
22:46:09 [fantasai]
Elika: Although I'd keep it well-formed, restricted to a parseable value, a parseable sequence of declarations, a parseable selector
22:46:32 [fantasai]
I think we should use variables
22:46:37 [fantasai]
er.. that was Daniel
22:46:48 [fantasai]
Daniel: I think we should have variables, that can be impacted by scripting
22:47:15 [fantasai]
Daniel writes:
22:47:18 [fantasai]
@var foo white;
22:47:28 [fantasai]
p {background-color: var(foo)}
22:49:16 [fantasai]
Anne: Note that it's different from namespaces because namespaces are local to the file.
22:49:30 [fantasai]
Chris: You should be able to import them, but they shouldn't cross style sheet boundaries otherwise
22:50:08 [anne]
s/the file/the style sheet/
22:50:19 [anne]
(there could actually be multiple style sheets in the same file)
22:52:20 [fantasai]
Elika explains that CSS doesn't have a concept of step-by-step process, that the content of the style sheet and the content and the DOM and the rendered result must always be in sync even as the style sheet and the DOM change
22:52:43 [fantasai]
Elika: So whether we call it macros or variables or whatever, if you update the statements in the style sheet they would apply to the document.
22:55:08 [fantasai]
Daniel, David: We need more detailed use cases.
22:55:19 [fantasai]
Elika: If you put out an open call for use cases, you will get hardly any. We've done that so many times before
22:56:19 [fantasai]
Elika: We get syntax proposals, hardly any detailed use cases.
22:56:42 [fantasai]
Steve: Post a simple straw man proposal and ask "does this solve your use case, and if not, why not?"
22:57:50 [fantasai]
ACTION: Daniel post straw man proposal of constants and ask web designers "does this solve your use case, and if not, why not?"
22:57:50 [trackbot-ng]
Created ACTION-38 - Post straw man proposal of constants and ask web designers \"does this solve your use case, and if not, why not?\" [on Daniel Glazman - due 2008-04-04].
22:58:02 [fantasai]
ACTION: Elika post Daniel's post to
22:58:02 [trackbot-ng]
Created ACTION-39 - Post Daniel's post to [on Elika Etemad - due 2008-04-04].
22:58:59 [fantasai]
glazou, I would suggest looking at as well
22:59:29 [fantasai]
glazou, and
22:59:43 [fantasai]
Topic: text-orientation vs glyph-rotation
23:00:25 [fantasai]
Steve writes
23:01:13 [fantasai]
england [zhong][guo] LEARSI
23:01:23 [fantasai]
---> ---> <---
23:01:46 [fantasai]
If I rotate this right, I get *draws sideways version of the above*
23:02:16 [fantasai]
(the chinese glyphs are sideways too)
23:02:31 [dbaron]
england 中国 LEARSI
23:02:37 [fantasai]
The next step is that for the characters that are traditionally upright, I put them in upright form
23:02:52 [fantasai]
This is at least semi-readable
23:03:17 [fantasai]
In glyph-orientation this is the default mode
23:03:30 [fantasai]
It rotates right all the character, then rotate left the fullwidth characters to make them upright
23:03:34 [fantasai]
and the ordering is in this order
23:03:39 [glazou]
fantasai: thx for links
23:05:21 [fantasai]
If I apply 180deg glyph orientation to these pieces, then the glyphs rotate individually
23:05:38 [fantasai]
and that makes the characters are effectively ordered in reverse
23:06:20 [fantasai]
Steve draws something that is "unreadable"
23:06:52 [dbaron]
"england 中国 יִשְרָאֵל"
23:08:34 [fantasai]
Steve: The essence of why we're doing this is that you want to spin runs, not rotate individual glyphs
23:09:45 [fantasai]
Steve: We're introducing a new property called text-orientation, which operates on runs
23:10:06 [fantasai]
Steve: If its value is normal, then you do the default order
23:11:33 [fantasai]
Steve: It has a hang-down value that orders characters in storage order and rotates them to handle RTL vs LTR
23:11:49 [fantasai]
Steve: And it has an 'upright' value that keeps each syllabic unit upright
23:12:26 [fantasai]
Steve: We're not sure if required ligatures are kept or split in this case.. so there are some details not worked out
23:12:40 [fantasai]
Steve: all values are keywords
23:12:52 [anne]
(If we have some time left after this semi-understandable topic can we maybe get back to Media Queries for a few minutes?)
23:13:04 [fantasai]
Steve: in the 80/20 rule, we've left rotate-left as a partially solve problem
23:13:31 [fantasai]
Almost all uses of vertical text are rotate-right or upright
23:15:42 [fantasai]
Topic: Changing the Subject of the Selector
23:15:56 [fantasai]
Daniel: This was proposed many years ago, and implemented in my batch processor
23:16:24 [fantasai]
Daniel: There have been many requests over the years to select not just descendants, but also ancestors and previous elements
23:16:58 [fantasai]
Elika: One major use case is links that have images vs links that don't have images
23:17:05 [anne]
we need [#col=4] for that or something
23:17:15 [anne]
for column matching
23:17:39 [fantasai]
Daniel: The technology has improved a lot in these past 10 years
23:17:53 [fantasai]
Daniel: We have faster processors and better layout engines
23:17:56 [fantasai]
Daniel: Can we do it now
23:18:05 [Hixie]
my proposal was to make [#foo=...] match on DOM attributes, iirc
23:18:20 [fantasai]
no for column selectors :)
23:18:33 [fantasai]
colum // cell or something
23:18:42 [fantasai]
but based on table source
23:18:46 [fantasai]
not layout, obviously
23:18:51 [Hixie]
the // combinator was for matching across semantic references
23:18:58 [fantasai]
23:19:01 [Hixie]
e.g. img /usemap/ map
23:19:04 [fantasai]
IIRC if it was empty it worked for columns
23:19:10 [fantasai]
that's what I remember, perhaps I misremember
23:19:22 [fantasai]
Elika: I absolutely agree that we should have this functionality in Selectors 4
23:19:31 [Hixie]
i prefer [#col=4], [#row>3] etc for tables
23:19:46 [fantasai]
my problem with that is that it requires numbers
23:19:52 [fantasai]
I would want to select based on classes on <col>
23:20:01 [Hixie]
oh well // could work for that too
23:20:04 [Hixie]
col // td
23:20:09 [Bert]
I think // was originally meant for following sibling (back in 1995/6), but it could be child selector, too.
23:20:16 [Hixie]
col[char=.] // td { text-align: "."; }
23:20:22 [fantasai]
Tantek: I would recommend getting declaration of strong interest from implementors
23:20:27 [Hixie]
er, [char="."] i guess
23:21:14 [fantasai]
Tantek: I agree that we shouldn't put it in and take it out, but I think you need to find a strongly interested implementor
23:21:33 [fantasai]
Daniel: Elika, you had some syntax proposal?
23:21:44 [fantasai]
Elika: Yes, just a suggestion. I just don't want us to use pseudo-class syntax for this
23:21:53 [fantasai]
Daniel: I originally proposed using ! in front of the selector
23:22:45 [fantasai]
Elika: My suggestion was also to use punctuation in front of the sequence-of-simple-selectors
23:23:04 [fantasai]
Tantek, Molly: It's very confusing because for people with programmer background it means "not"
23:23:18 [glazou]
23:23:27 [tantek]
23:23:59 [fantasai]
Elika: My suggestion was to use a $ sign (for "subject") but other punctuation is ok, too
23:24:17 [glazou]
:$ubject ?
23:25:22 [fantasai]
inverted exclamation point :)
23:25:38 [fantasai]
Daniel: I think we all agree that we need Selectors Level 4
23:26:23 [fantasai]
Elika: As soon as Selectors 3 is published as CR, I'm happy to see Selectors Level 4
23:26:33 [fantasai]
Steve: We should discuss priorities first.
23:26:49 [plinss]
23:27:06 [fantasai]
Steve: We need to realistically assess what we are going to do in this period.
23:27:18 [fantasai]
Steve: We have more work than we can finish in 2 years
23:27:32 [glazou]
plinss: hey you need charmap on windows to type that :)
23:28:36 [fantasai]
Steve: And if everyone is working on their own drafts, then we can't review the drafts
23:29:04 [fantasai]
Elika: I think a FPWD of Selectors 4 is a reasonable thing to expect within the next 2 years
23:30:05 [fantasai]
Elika: Not a CR, just a FPWD
23:30:39 [fantasai]
Topic: Advanced Layout and Non-rectangular Slots
23:31:06 [fantasai]
Bert: All the designers I've spoken to want to put images in the middle or in the corners etc and wrap text around it
23:31:21 [fantasai]
Bert: You can do that in Advanced Layout if we allow non-rectangular slots
23:31:29 [fantasai]
Bert: If you know the height, that's not as much of a problem
23:31:38 [fantasai]
Bert: But if you have to do auto height, it's much more difficult
23:32:29 [fantasai]
Bert: Want to know what implementors think about how hard it would be to implement
23:32:47 [fantasai]
Elika: If you define it to behave exactly like floats, and don't have holes in the shape, it shouldn't be too difficult
23:32:53 [fantasai]
Elika: if you know the size
23:34:37 [fantasai]
Bert: If you want to do a C shape that has as much text above as below, then it's still difficult
23:35:25 [fantasai]
David: That gets into constraint solving
23:35:48 [fantasai]
Elika: It's like the case Alex showed us where you wanted to center a paragraph while wrapping it around a non-rectangular float that doesn't move...
23:37:56 [fantasai]
Elika: In the interests of finishing Advanced Layout and getting it to the implementors, I think we should make this version rectangular regions only
23:38:09 [fantasai]
Elika: And tackle non-rectangular regions in a next version
23:40:00 [molly]
ScribeNick molly
23:40:25 [molly]
topic: advanced layout
23:40:49 [molly]
Elika: width and height restrictions?
23:41:42 [molly]
Bert: what about :slot
23:41:50 [molly]
Elika: Designers want it, for backgrounds
23:42:09 [molly]
Elika: I have more comments I need to write up but I believe we need some kind of a syntax that allows for more properties
23:42:29 [glazou]
deezainorz ?
23:43:25 [molly]
Elika: I also think we should remove some of the stuff in the draft that isn't about templates
23:43:49 [molly]
Elika: Suggest CSS Template Layout Module
23:44:45 [molly]
Resolved: CSS Template Layout Module
23:45:13 [molly]
(replaces advanced layout module)
23:46:16 [molly]
Elika: need to address rows and columns but not slots
23:46:27 [molly]
Elika: width and height should not apply to slots
23:46:38 [fantasai]
Elika: only to columns and rows respectively
23:46:49 [fantasai]
Elika: Need to brainstorm some syntax for this
23:47:13 [molly]
Peter: Any other items wrt template
23:47:34 [molly]
Peter: any other items at all?
23:47:40 [fantasai]
ACTION: Elika write up Template Layout comments
23:47:40 [trackbot-ng]
Created ACTION-40 - Write up Template Layout comments [on Elika Etemad - due 2008-04-04].
23:48:02 [molly]
David: Is it worth discussing CSS 2.1 editing issues?
23:48:12 [molly]
Bert: There is a request from Anne from media queries still
23:48:30 [molly]
Elika: I'd like to resolve the page-break-inside issue
23:50:39 [molly]
Anne: Testing hasn't been done but my recollection of CSS 2.1 was wrong
23:52:02 [molly]
Elika: I explained the use cases in detail yesterday
23:52:15 [molly]
Bert: I'm worried bcause you can't overwrite avoid
23:52:26 [molly]
Bert: With this change you can't until CSS3
23:53:00 [molly]
Bert: I'd like to reserve some time to object to this
23:59:22 [molly]
Resolved with one week open for objections
23:59:37 [molly]
Peter: CSS 2.1 editorial
23:59:59 [plinss]
topic: CSS 2.1 Editorial