- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Wed, 27 Apr 2011 11:07:45 -0700
- To: "www-style@w3.org" <www-style@w3.org>
Summary:
- 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 ======
Present:
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
Administrative
--------------
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.
Charter
-------
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]
Snapshots
---------
plinss: fantasai posted some updates
http://dev.w3.org/csswg/css-2010/#testing
<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
ago?
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
Variables/Mixins/Constants
--------------------------
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
constants?
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