W3C home > Mailing lists > Public > www-style@w3.org > April 2011

[CSSWG] Minutes and Resolutions 2011-04-27

From: fantasai <fantasai.lists@inkedblade.net>
Date: Wed, 27 Apr 2011 11:07:45 -0700
Message-ID: <4DB85B71.1000108@inkedblade.net>
To: "www-style@w3.org" <www-style@w3.org>
   - Discussed draft charter <http://www.w3.org/2010/09/CSSWG/charter.html>
   - CSSOM and CSSOM Views was seen as very important, but needing another
     editor to help Anne, who is stretched thin
   - Discussed CSS Snapshots and prefixes, trying to word Sylvain's suggestion
     that prefixes only be dropped after CR *and* once an implementation report
     is submitted (with testcases if necessary)
   - RESOLVED: Publish updated Working Draft of CSS3 Writing Modes
   - Long argument over Tab's request to create a Variables/Mixins spec, ending
     with a homework assignment to create a requirements doc to frame the
     discussion, for continuation at the F2F

====== Full minutes below ======


   Tab Atkins
   David Baron
   Bert Bos
   Arron Eicholz
   Elika Etemad
   Simon Fraser
   Sylvain Galineau
   Daniel Glazman
   Vincent Hardy
   Koji Ishii
   John Jansen
   Brad Kemper
   Håkon Wium Lie
   Chris Lilley
   Peter Linss
   Edward O'Connor
   Geoffrey Sneddon
   Alan Stearns
   Daniel Weck
   Steve Zilles

<RRSAgent> logging to http://www.w3.org/2011/04/27-css-irc
Scribe: fantasai


   plinss: Reminder that meeting starts at 9am, not 9:10. Please call in
           before 9am so things move quicker.
   plinss: Last week we talked about Namespaces. Daniel, you were going
           to ping i18n?
   glazou: Did not do that yet, will do that today.


   ChrisL: Incorporated most feedback so far.
   ChrisL: Would like to alphabetize them within sections.
   ChrisL: Going through from dbaron's comments from April 19th
   ChrisL: Did have a question, since modules no longer say CSS3 Blah, wasn't
           sure how to word CSS4 UI
   <fantasai> CSS UI, Level 3
   <fantasai> CSS UI, Level 4
   <glazou> can we get here on IRC a URL to the last visible version of the
            charter with those edits?
   <ChrisL> http://www.w3.org/2010/09/CSSWG/charter.html
   ChrisL: Could put it in the charter as CSS UI, then both are in scope
   ChrisL: Other question about fullscreen. Some suggest part of UI, some
           part of separate module
   <Bert> Did we agree to create UI level 4 already? I'm not sure I want a
          level 4. Rather a "Fullscreen level 3."
   fantasai: CSS3 UI is aiming for PR soon, so can't put it in there.
   fantasai: Tantek wants it as a separate module because it's very high
             priority for Mozilla
   fantasai: Also it's not quite related to the other UI things
   ChrisL: Priority?
   fantasai: depends on who writes tests how fast :)
   ChrisL: ok, I'll list fullscreen as medium
   ChrisL: What about Selectors 4?
   glazou, fantasai: low priority
   plinss: I like the idea of leaving the levels out of the Charter
   ChrisL: Allows us to split modules as we see fit.
   <szilles> +1 for leaving off level #
   glazou: sounds good

   plinss: Grid Positioning should be medium, not low
   fantasai: Grid Layout, yo umean
   some discussion of various modules with 'grid' in the title

   plinss: Media Queries OM?
   glazou: Only an editor's draft atm, but Mozilla and ? are starting to
           implement parts of it
   ChrisL: Should I add that as low priority
   glazou: yes
   dbaron: This was part of the CSSOM View spec
   ChrisL: CSSOM Views is there already
   dbaron: Splitting it out probably isn't crazy, but it's a bit small for
           its own spec
   ChrisL: Can do either.
   <dbaron> http://dev.w3.org/csswg/cssom-view/#extensions-to-the-window-interface
   fantasai: If it's in CSSOM View, then splitting it out later if needed
             might make more sense than putting it in the charter
   sylvaing: What's the priority of CSSOM View?
   glazou: From WG perspective, or authors perspective?
   glazou: From author's perspective it's pretty high
   <dbaron> Actually, I think most of cssom-view is pretty stable.
   sylvaing: And we've been talking it more and more.
   <dbaron> cssom, not so much
   fantasai: Problem is lack of an editor. Spec moves as fast as Anne has time.
   <ChrisL> we need a good, active editor for that spec
   dbaron: Are we talking about CSSOM or CSSOM View
   dbaron: I skimmed through CSSOM View, and most of it is pretty stable
   dbaron: Most of it is old features implemented for a long time, and then
           there are a few new features.
   sylvaing: CSSOM View is separate document, very focused. Can move to CR
             and beyond on its own.
   sylvaing: Thinking of CSSOM as a whole.
   sylvaing: It's very important.
   TabAtkins: I can help out. Can't take over the spec, but would like to
              help out.
   ChrisL: You're also sliced pretty thin.
   glazou: We need someone with a strong commitment to one spec and not
           doing many things outside that field. Both Anne and you do that.
   glazou: It's not a bad thing, it's just factual.
   sylvaing: Don't want to rathole discussion on charter on this point,
             but still concerned about CSSOM being at the end of the train.
   <ChrisL> We need more Tabs
   * plinss Tab expansion property?
   <glazou> #tab { expanded: super-expanded} ?
   sylvaing: It's a lot of work, including for implementers
   fantasai: bottom line, need more spec-editing capacity
   sylvaing: I'll see what I can do on our end

   plinss: Any other charter comments?

   SteveZ: medium priority has template layout but not grid layout, they're
           kindof combined now
   fantasai: Think we should list them both, then see what happens

   ChrisL: Last time we wanted to recharter, W3C told us we need to get
           CSS2.1 to PR first.
   ChrisL: Now that's done, this could go to AC within a week or two, after
           CSSWG is done with it.
   SteveZ: What does AC look at?
   ChrisL: Mostly managerial issues. FTEs vs. work, etc.
   ChrisL: For CSSWG, there were concerns about too much work, you'll never
           get it done, etc.
   ChrisL: But that's less of an issue now, considering recent progress.

   * glazou will try writing a Test Suite for CSS Styling Attribute so we could move to PR
   * dbaron glazou, <p style="color: green">This should be green.</p> ?
   <Ms2ger> glazou, fwiw, I wrote a couple of simple tests for css-style-attr
            at http://www.w3c-test.org/html/tests/submission/Ms2ger/global-attributes/style-01.html
   <glazou> Ms2ger: thanks !
   <fantasai> glazou, http://test.csswg.org/source/contributors/fantasai/submitted/css-style-attr/
   <glazou> fantasai: coool
   [side discussion of some specific tests, see IRC logs if you want details]


   plinss: fantasai posted some updates
   <ChrisL> Still not sure of the relevance of more than one dated snapshot
   fantasai: Just to update the spec so it's not WD, it's done
   ChrisL: Why is it 2010 not 2011?
   fantasai: First published in 2010
   ChrisL: Will there be 2011?
   fantasai: If we have anything to add, yes
   plinss: Should publish as often as necessary, even if twice a year
   fantasai doesn't disagree
   fantasai: Back to 3.4
   sylvaing: Where do we define experimental vs. non-experimental?
   fantasai: hm... nowhere, need to do that
   fantasai: Can steal definition in CR exit criteria
   sylvaing: Should also make a case for *enough* test coverage, as
             determined by WG.
   some discussion of how to wording this
   plinss: s/they consider/they can demonstrate/
   <szilles> +1 for "demonstrated"
   <bradk> demonstrated to the satisfaction of the WG
   SteveZ: why would I do an experimental implementation
   plinss: Implementation before CR is experimental
   SteveZ: maybe reverse order of paragraphs
   <fantasai> "The test cases used for the implementation report must be
               sufficient to demonstrate something to the satisfaction of
               the CSS WG"
   <fantasai> "and are subject to review by the CSSWG" ?
   <fantasai> "The testcases used for the implementation report must be
               sufficient to demonstrate interoperability and are subject
               to review by the CSSWG"
   * glazou thinks we should reserve the last 15 minutes to Variables
   plinss: Anything else on snapshot? Happy with it modulo prefix edits?
   * bradk has to leave. bye.
   SteveZ: No, but I'll send out response to sylvain's comment
   fantasai: moved to mailing list

Writing Modes

   fantasai: We were going to discuss publishing CSS3 Writing Modes 3 weeks
   plinss: anyone reviewed it?
   <fantasai> Added http://dev.w3.org/csswg/css3-writing-modes/#appendix-b-intrinsic-sizing
              to have some definitions, but otherwise no changes since
              3 weeks ago
   <glazou> let's not diverge please, Variables !
   howcome: The multicol things in there, is that related to the other
            proposal ?
   fantasai: related, but not the same. 7.3.2 takes an element that is not
             multicol and turns it into a multicol element
   howcome: So you tell some content that is not multicol content to behave
            as a multicol element
   plinss: You just want to publish WD, right?
   plinss: Can we just resolve to publish that and take detailed discusison
           offline? Is there a reason not to publish?
   SteveZ: If it's a WD, no, there is no reason not to publish.
   plinss: No objections?
   RESOLVED: Publish WD of CSS3 Writing Modes


   TabAtkins: Everybody knows what they are and what they do.
   TabAtkins: I want to take editorship of one or two drafts and work on
              those officially.
   fantasai: What else is on your list?
   TabAtkins: Lists and Flexbox. Later this summer, position-layout, then
              variables and mixins
   TabAtkins: Variables are CSS values, mixins are CSS declaration blocks
   TabAtkins: Distinction isn't important in simplistic case
   TabAtkins: We think it's needed to have parametrized mixins
   TabAtkins: At that point they become distinct enough that you want
              different concepts
   SteveZ: And variables still have all of their problems
   TabAtkins: Depends on what you mean by problems.
   TabAtkins: Variables I have are global in scope
   TabAtkins: All various syntax issues, I believe I have reasonable answers
              to these.
   TabAtkins: Discussion stalled at "want to write something out officially"
   TabAtkins: We're working on this experimentally, but want to discuss
              working in WG
   glazou: When hyatt and I proposed variables, there was a strong discussion
           of what do we really need. Do we ned variables, constants, mutable
   TabAtkins: I believe what is useful to authors is true variables,
              changing them via script
   TabAtkins: Seems to open a lot of interesting applications
   glazou: That was the original proposal, and members of the group
           objected to that.
   glazou: I think it makes sense to have consensus on what we want to
           accomplish before we start working on it.
   SteveZ: I agree sortof with what you're saying, but our discussion
           always seem to laps into details to have a discussion.
   SteveZ: Might make more progress with a concrete proposal
   glazou: That's what we did with our proposal
   glazou: What I'm afraid of is Google going really really fast and
           implementing as soon as it is written
   glazou: Same problem as with apple, they had to remove their
           implementation because of lack of agreement from the WG
   glazou: I really want variables. But I don't want to end up in a
           vicious circle.
   TabAtkins: How do I make progress?
   fantasai: Write a requirements document.
   fantasai: Say "we need script-mutable variables and this is why and
             here are the use cases and here is why the other ways of
             addressing this are insufficient"
   fantasai: And say "we need mixins and this is why and here are the
             use cases we need to solve and here is why the other ways
             of addressing similar concepts is insufficient"
   some discussion on why we should address this issue at all
   howcome: we already have JavaScript
   TabAtkins: That's not an actual argument
   TabAtkins: This is not making CSS a programming language. This is
              taking the massive repetition in a style sheet and reducing it
   TabAtkins: It's taking a color and naming it so you can change it later
   ChrisL: You can do that with search and replace, but only if you only use
           that color for one thing
   howcome: I encourage everyone to read Bert's essay
   TabAtkins: I encourage everyone to read Alex Russell's rebuttal to that essay
   sylvaing talks about six-or seven style sheets and managing them being painful
   lots of argument
   sylvaing: If something's in JQuery, it should be interesting for us
   * ChrisL Tab asserts that JQuery is not magic! I thought it ran on unicorns ....
   howcome: This isn't going to be useful in the near term.
   howcome: It will take many years
   glazou: Variables was user feedback number one from 1998
   <Bert> (B.t.w, results of 1998 survey were (1) transparency, (2) columns,
          (3) leaders. Symbolic constants was 16th, out of 67.)
   sylvaing: Nevermind timeline, it may be easy to do in JavaScript you have
             an API that makes it easy to deal with.
   sylvaing: We won't have that for years.
   sylvaing: We don't have APIs that make it easy to navigate style rules
             and change colors
   sylvaing: Don't want to parse CSS in JavaScript
   <Bert> (Can't we create a Web Macro Language WG, to create something that
          works for also for HTML, SVG, scripts, etc.?)
   <dbaron> I think most of the use cases presented in the discussion didn't
            require variables as distinguished from constants.
   <sylvaing> dbaron, true. my own need is mostly constants
   <fantasai> My concern is that people will use variables when they only
              need constants.
   <fantasai> variables are heavyweight, they require a lot of maintenance
              in the OM
   <fantasai> I don't want people to be using variables when they don't need
              script interactions
   * sylvaing is otherwise puzzled Opera would rather run script-based parsing
              on phones or Opera Mini servers
   dbaron: I think we need the stuff that is interchanged across the web
           to be simpler, not complicated
   dbaron: Because that's the stuff that needs to be reimplemented when you
           create a new layout engine, which I expect to happen again
   TabAtkins: Yes, we shouldn't throw tons of complexity at the client.
   TabAtkins: but I think this is important enough
   dbaron: I thinks some of it is and some of it isn't
   * fantasai shares dbaron's concern
   <sylvaing> strongly agrees this should be carefully scoped. Start very simple.
   <glazou> +1
   fantasai is not minuting this argument
   Someone suggests going over this at the F2F
   <dbaron> Daniel probably wants later in the day Japan time
   plinss: So Tab, you'll produce some requirements documents and this heated
           debate will continue another time

Meeting closed.
Received on Wednesday, 27 April 2011 18:08:17 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:38:45 UTC