- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Wed, 16 Jul 2008 11:30:16 -0700
- To: www-style@w3.org
Summary: - RESOLVED: Accepted Melinda's proposal to make CSS2.1 Section 2.3 (but not subsections) informative. Filed as Issue 63 http://csswg.inkedblade.net/spec/css2.1#issue-63 - RESOLVED: Unknown media *types* are treated as false: when negated become true. - RESOLVED: Otherwise, invalid media queries are dropped. - Discussed marquee: people want clarifications to its interaction with overflow/overflow-x/overflow-y/scrolling - Discussed logo contest: Jason will talk with Ian Jacobs. Full minutes below. =============================================================================== Attendees: David Baron Bert Bos Giorgi Chavchanidze Arron Eicholz Elika Etemad (scribe) Sylvain Galineau Melinda Grant Ming Gao Molly Holzschlag Anne van Kesteren Håkon Wium Lie Peter Linss David Singer Jason Cranford Teague Steve Zilles Possibly other people from MSFT. <Bert> I gave the link to the new harness to the Math WG as well. It may still miss one or two features for them. ScribeNick: fantasai Peter: Jason wants to do update on logo contest, anyone else for new topics? Peter: Melinda's here, so let's get her item done Melinda's CSS2.1 Issue ---------------------- <melinda> http://lists.w3.org/Archives/Public/www-style/2008Jul/0141.html <plinss> http://lists.w3.org/Archives/Public/www-style/2008May/0265.html Elika: those seem to be 2 completely separate issues <melinda> http://lists.w3.org/Archives/Member/w3c-css-wg/2008AprJun/0303.html Melinda: I'm looking at things from testing perspective, and this section raises some questions (2.3) Melinda: Looks to me the whole section should be labelled informative Melinda: given that it's one possible model Melinda: I thas several problems Melinda: It says parsing is out-of-scope Melinda: I don't think parsing is out of scope Melinda: It also says any discernable output is out of scope Melinda: so I would conclude that discernable output is not something we can test in the test suite Melinda: but formatting structure is in scope -- how would be test that? Melinda proposes: 1. Label the section as "Informative". 2. Remove the verbiage at the end of the section regarding what's in and out of scope. If the group feels that the scoping information is valuable and should be retained, then I would suggest: 1. Change "Step 1" to "The generation of a document tree" 2. Change the second line: - Steps 2-5 are addressed by the bulk of this specification. + Parsing the source document, Steps 2-4 and Step 6 are addressed by the bulk of this specification. 3. Change the third line: s/6/5/. Bert: I think there's a misunderstanding on step one Bert: Step 1 is about parsing the document, not parsing the style sheet Melinda: I don't see that in there Bert: It's talking about the source document David: The spec is very careful to never refer to the style sheet as the document David: The document is always the document the style sheet is applying to Bert: Otherwise, I think it can be explained why step 6 is out of scope Bert: I don't mind how you interpret it, if you make it informative Bert: it is effectively informative anyway No one objects to making this section informative Bert: for 6, what it's saying is that how the page gets rendered -- whether by api calls to graphics system, emitting PDF, etc, -- that is out of scope Bert: Changes are, make section informative Bert: and remove last three sentences Elika: might need to be careful not to make 2.3.1 informative ACTION: Elika file an issue about this RESOLVED: Proposal accepted Media Queries ------------- Peter: There were some comments on the comments last week Anne: I haven't gone through them yet Elika: anything to discuss, or wait until Anne processes feedback Anne will be on vacation for three weeks starting next thursday, probably won't get it done before then Anne: Main thing was feedback from dbaron Anne: I'm not really sure how to deal with it David: my concern about the error-handling thing is that we have that error-handling interoperably implemented David: you're proposing making a significant change I'm not sure is better Anne: It's a change from implementations, not from previous draft David: We're discussing what happens if you have a syntax error inside an expression David: anything you don't recognize inside a parenthesized expression Elika: I think the media query should be dropped. Elika: I don't mind treating unknown media types as false, but I think invalid syntax and media queries should be ignored David: So, if we say that if an expression has something unknown inside it then it's false David: Then either the query or the negation of the query needs to be true David: the currently-implemented behavior was tested in Acid 3 Anne: It still doesn't make sense. Anne: The old draft said always false Anne: Always false doesn't become true when negated Anne quotes from the spec David: I guess I'm ok with it as it is then Anne: I don't really want that the serialized form to contain invalid values David: You need to talk to hixie about getting Acid 3 changed Anne: I believe Acid 3 will be changed for some SVG feature anyway Anne: Implementors are probably ok, since from what I heard it's easy either way Peter: I think the important thing here is to make sure the behavior is best for forwards-compatibility Discussion of treatment of unknown media types David doesn't want to get into the 'aural' vs 'speech' mess RESOLVED: Unknown media *types* are treated as false: when negated become true. RESOLVED: Otherwise, invalid media queries are dropped. Steve: The applies clause had groups named, and I don't know where those are defined. Anne: They're in CSS2.1 in the Media Types section. Anne: 7.3.1 introduces Media Groups Melinda: That section is informative. Does that still work? Elika: That line in the property definitions is informative, too Marquee Module -------------- Elika: I still need to review in detail the definitions and how they relate to writing-mode. Anne: I'd like to see the relation of marquee and overflow-x and overflow-y addressed. Anne: I've said this several times before, I don't know why Bert keeps avoiding the issue. Anne: overflow-x and overflow-y are already implemented Anne: It would be better to address this interaction in the spec than leaving it to implementations to figure out. Bert: Can we set a deadline for review of Marquee when we decide to publish it? Anne: I'm fine with publishing as a working draft, but not with leaving out overflow-x overflow-y Bert: I'm fine to write a draft with that in it for you, but I don't want Marquee to depend on that Anne: But the draft should address their interaction Anne: There are several implementations that support <marquee> and overflow-x and overflow-y <anne> (I believe Opera actually implements the -wap-marquee stuff too, but I haven't tested it.) <anne> And with several above I mean, Internet Explorer, Opera, Firefox, and Safari Molly: IIRC there were some i18n issues about those Molly: from TPAC F2F Elika: Are overflow-x and overflow-y absolute or relative? Anne: I think Markus said they were absolute Peter: So, what I'm hearing is that Anne wants the interaction of overflow-x and overflow-y and marquee defined Peter: And Bert is concerned that adding overflow-x and overflow-y will slow down the module Anne: I don't care where overflow-x and overflow-y are defined, but I want the marquee spec to say /if/ overflow-x and overflow-y are supported, this is how they interact with marquee Elika: You could put it in and mark overflow-x and overflow-y at risk. Elika: Then at least the interaction would be defined. And it won't hold back the module because if it's a problem we can drop it Bert: Marquee basically replaces a scrollbar Bert: If there is a scrollbar, then overflow-style can make it a marquee Bert: If there is no scrollbar, it has no effect Bert explains how marquee works F2F minutes: http://lists.w3.org/Archives/Member/w3c-css-wg/2007OctDec/0267.html David: I'm not seeing what you just said in the spec David: It needs to say when you get marquee, for which values of overflow and overflow-style David: If the answer is, you get a marquee when a scrolling mechanism is present, then you need to say that. David: Then give an example using different values of overflow. Anne: What does it mean if there is no overflow, but overflow: scroll is specified? Anne: would you get a marquee? Anne: that's probably what you want Peter: How much time to people need to review? Anne: Can the draft be moved to public CVS? Peter: Ok, one week. Logo Contest ------------ Jason: I've got the creative brief done. Jason: I wanted to launch it in conjunction for the site launch Jason: Leave a space for the logo, e.g. dotted line "logo goes here" Jason: Been talking about site, planning to have a soft launch end of July Jason: Hard launch around F2F in August SteveZ: Did you talk to Ian Jacobs at all? Steve: There's also a redesign of the W3C site going on Jason: ok, I'll talk to him Molly: I like the idea, building bridges to community Melinda: How are we going to choose the logo? Jason: I've got some rules written up, I'll get those out Jason: Basically the idea is that we'd vet entries for anything that was obviously inappropriate Jason: We'd open it up to voting here at AOL, allow the public to choose the logo that they desire Elika: weren't we going to have the public narrow it down to five, and then some group picks? some discussion about different ways to pick <Bert> Ian Jacobs Agreement that logos public votes on should be everything except ones we cannot use, not some artificially restricted set Steve, Molly: Need to talk with Ian Jacobs about this Elika: need to present winner to W3C to see if it's acceptable -- maybe it violates some trademark Elika: then we pick 2nd' place Elika: much easier to analyze one logo than a hundred Meeting closed
Received on Wednesday, 16 July 2008 18:31:02 UTC