[CSSWG] Minutes and Resolutions 2008-07-09

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