- 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