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

[CSSWG] Minutes and Resolutions 2011-04-20

From: fantasai <fantasai.lists@inkedblade.net>
Date: Thu, 21 Apr 2011 19:27:11 -0700
Message-ID: <4DB0E77F.6000803@inkedblade.net>
To: "www-style@w3.org" <www-style@w3.org>
   - Reviewed what's left to move Namespaces to PR
   - RESOLVED: Use Bugzilla to track CSS2.1 issues going forward.
               Discussion will remain on the mailing list, however,
               not in the bug tracker.
   - RESOLVED: Don't consider text-transform of accents for Text 3, but possibly
               for Text 4 if there's more information showing it's needed/possible.
   - Discussed module naming. Plan is to publish Snapshots as Notes and push an
     announcement along with the CSS2.1 REC announcement explaining the move to
     year-based Snapshots for CSS overall, using independently levelled modules.
   - Agreed on a clarification to transitions' effect on shorthands:
   - RESOLVED: transforms create a pseudo-stacking context, not a full one.
               z-index doesn't apply (unless the element is positioned, as usual).
   - No dissent on adding disclosure triangle list style to css3-lists
     It was noted that it should respect the writing direction.

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

   Tab Atkins
   David Baron
   Arron Eicholz
   Elika Etemad
   Simon Fraser
   Sylvain Galineau
   Daniel Glazman
   Arno Gourdol
   Vincent Hardy (Adobe)
   Koji Ishii
   Peter Linss
   Edward O'Connor
   Alan Stearns
   Daniel Weck
   Steve Zilles

<RRSAgent> logging to http://www.w3.org/2011/04/20-css-irc
ScribeNick: TabAtkins


   glazou: Any extra agenda items?

   Topic: TPAC questionaire
   glazou: Deadline is the 30th of April.
   glazou: Bert sent an email, but no other answer.
   glazou: What days do we want?  It's from Oct31 to Nov4.
   glazou: What's most convenient for people?
   <glazou> http://www.w3.org/2002/09/wbs/34786/TPAC2011/results
   smfr: No preference, but I suspect we'll want a joint meeting with SVG
         to talk about FXTF stuff.
   glazou: I'll ping shepazu to check when we can meet.
   plinss: And, if possible, no overlap with HTML.
   szilles: And no meeting with the AB, on Thu/Fri.
   glazou: So that leaves us with Mon/Tue, as usual.
   glazou: I'll try for that.
   <plinss> and no overlap with TAG

CSS Namespaces

   glazou: We almost have CSS Namespaces ready to move.  I think we have
   fantasai: The normalization issue is still open.
   fantasai: The i18n WG needs to weigh in on this.
   <fantasai> http://dev.w3.org/csswg/css3-namespace/issues-3
   ACTION glazou to ping Leif and i18n about CSS Namespaces issue 3
   <trackbot> Created ACTION-317

Bugzilla for draft issues

   glazou: Saw several opinions.
   glazou: We need tools to track issues and interesting emails.
   glazou: We're missing a few tools for the good management of the group.
   vhardy: Tracker has proved useful in the groups I've been in to solve
           these kinds of issues.
   smfr: I don't think Tracker has enough features.  I think Bugzilla would
         be more useful.
   smfr: Searching and commenting on issues is easier.
   arronei: I also prefer Bugzilla - I think it's more detailed/flexible.
   arronei: If we do go with Bugzilla, I'd like specs and testcases to be
            two separate things somehow - a field or something.

   dbaron: Some of it comes down to whether you want the discussion to
           happen on the ML or the bug databaes.
   dbaron: Tracker has a bunch of features designed for picking up things
           on the ML.
   dbaron: But to use those features well, you have to pay a little more
           attention to that than we do.
   smfr: I think that is a risk that we should guard against (discussions
         in bugs).

   glazou: The hardest thing, imo, is to identify the interesting messages
           in the ML and turn them into an issue.
   <fantasai> glazou++
   glazou: That requires a permanent observation of the ML and the thread -
           if you don't read everything you don't know if the thread is
           closed or interesting or what.
   hober: The HTMLWG has buzilla mail the list for every bug, so if it's
          interesting to you, you can cc yourself on the bug and follow
          the conversatoin.
   glazou: Bugzilla only works if the whole group reads bugzilla.
   arronei: Shouldn't it be the editor's responsibility to track issues as
   glazou: We can decide that.
   fantasai: What happens in our WG is that an issue may not seem interesting
             at first, but people then chime in afterwards when it turns out
             there is some interesting implementation point.
   fantasai: So tracking things in bugs and having to manually cc yourself
             on things leads to problems.
   sylvaing: Agreed - unless the entire convo moves to the bug, you can
             fork the conversation.
   glazou: Bugzilla can be just for editorial issues, not for conversation.

   TabAtkins: I think the wiki tracking of issues for 2.1 worked well in
              process, it was just not the right tool for that.  using a
              bug tracker in the same way would be good.
   glazou: And we can restrict the bugzilla to just WG members, to limit
           the possibility of technical discussion happening there.
   ?: And we can have bugzilla mail the list to let it know that the issue
      was closed, etc.
   dbaron: That's the Tracker workflow...
   vhardy: [describes Tracker's ability to track conversations and such]

   fantasai: The problem with Tracker is that it's not searchable and it
             has *really* bad UI.  These are fixable, but they're really
             bad problems right now.
   fantasai: And it doesn't have enough statuses to track things.
   fantasai: Which is fine if you just have a single or two editors and a
             small number of issues. Bert and I used it successfully with
   fantasai: But it wouldn't have worked for 2.1, where issues get bounced
             around in responsibility.
   fantasai: And you need to, say, track first-LC issues separately from
             second-LC comments or pre-LC comments.  You can't do that with
             Tracker currently.
   fantasai: It's *really* awkward to make an action-item attached to an
             issue in Tracker.
   fantasai: In the wiki we just annotate the issue, and search for your
             name to find your issues.
   glazou: And bugzilla lets you change multiple bugs at one time.
   smfr: Does Tracker send notification emails?
   glazou: No.
   smfr: Having to go look at it, rather than getting an email about it,
         is inconvenient.

   glazou: So what should we do?  Try out bugzilla?
   sylvaing: What does "try out" mean?  If we decide it's bad, do we have
             to migrate?
   glazou: Yes, that's true for anything.
   sylvaing: I think we should pilot it then, rather than using it for
   fantasai: I think we should start with 2.1, because it's the spec most
             in need of tracking.
   <sylvaing> to clarify, it doesn't sound like we have a strong consensus
              either way so let's try bugzilla where we think it makes sense
              and revisit
   glazou: Objections to start testing bugzilla for CSS 2.1?
   smfr: Do we use the existing w3c installation, or a new one?
   fantasai: w3c's makes sense, I think.
   kojiishi: Is the instance public or member-only?
   fantasai: There's both, and we would use the public one.
   RESOLVED: Try tracking issues with bugzilla for 2.1.
   <glazou> +1 !!!!!

   fantasai: Do we want bugzilla to ping the ML, and do we want conversation
             to happen on bug or ML?
   Tab: I really dislike the way the HTMLWG splits discussions. I think all
        discussions should stay on www-style
   glazou: I don't think bugzilla should ping the ML - it would attract too
           much noise.
   RESOLVED: Discussion happens on www-style, Bugzilla just for tracking it.
             Don't send bug creation pings to the ML.


   glazou: But we don't have Bert or Chris on the call, so we should move this.

Review request for SVG Compositing

   ScribeNick: fantasai
   Tab: I sent some comments there, overall think spec looks good ... painting
   Tab: The review comments I sent to www-svg, linked to them last week in
        www-style... let me go find them
   <TabAtkins> http://lists.w3.org/Archives/Public/www-svg/2011Apr/0017.html
   <TabAtkins> http://www.w3.org/TR/SVGCompositing/
   Tab: left some comments on terminology, especially naming of property/values
   Tab: Anthony is receptive to changing those, so I'm happy
   Tab: Otherwise I'm cool with the spec
   glazou: Has anyone else reviewed the proposal?
   smfr: Don't think there's much overlap with CSS
   Tab: Given feedback from Anthony so far, I'm cool
   ACTION: glazou ping svg with no comments from CSSWG
   <trackbot> Created ACTION-318


   <glazou> http://lists.w3.org/Archives/Public/www-style/2011Mar/0414.html
   fantasai: What I got from the thread is that it doesn't seem particularly
             important to add it right now.
   fantasai: Also there were some concerns about whether its needed at all,
             and whether it's even possible to programmaticly switch been
   fantasai: So I don't think it should be considered for Text 3, but if
             there's more information we might do it for Text 4.
   glazou: So should that be the WG answer?
   RESOLVED: Don't consider text-transform of accents for Text 3, but possibly
             for Text 4 if there's more information showing it's needed/possible.

Module Naming

   glazou: We have some inconsistency in naming right now.
   glazou: Right now it hsould should be "CSS ..." or "CSS ... Level X".
   fantasai: Yes.
   glazou: What about "Module"?  Bert wanted that.
   fantasai: Seems fine.  Bert wanted it to be clear that the spec was part
             of a larger technology rather than something independent.
   fantasai: I think it's unnecessary to mention in some contexts, e.g. spec
             listings, though.
   glazou: That's fine.  Let's just make sure that all new documents contain
           "CSS", "Level", and "Module" if needed.
   plinss: The other part is there is some dissension over whether new modules
           should be level 1 or level 3 or what.
   fantasai: We have a resolution on that.  It's that extending functionality
             is level 3+, but new functionality is level-less at first (but
             possibly "level 2" when it is extended).
   sylvaing: The day we publish something as "level 1" or "level 2", we'll
             confuse people.
   glazou: I agree with what Sylvain said.
   glazou: Does that mean that the next iteration of Namespaces will be
           "Namespaces Level 4"?
   fantasai: No, it'll be level 2.
   dbaron: I think it'll be a problem anyway when we start doing Selectors 4
           when others are just starting at level 3.
   plinss: Yes, and as we go into the future and get things at level 5, 6,
           etc., it will be more of an issue.  This is just an education issue.
   fantasai: The snapshot document was supposed to be the replacement for the
             roadmap document that lays out the monolithic "version" spec,
             while modules leveled independently.
   fantasai: I think the best thing we can do right now is publish the
             snapshot, kill the roadmap which is really out of date, and
             have /TR/CSS point to the right things.
   [lost discussion]
   fantasai: I think I want to try and change the discussion around it first,
             and then revisit if people are still all super-confused.
   sylvaing: Yeah, I think if we try to evangelize it now nobody will care.
             After a "level 2" happens, then we can actually try and see if
             it needs changing.
   <szilles> +1
   plinss: There will be confusion.  If we publish snapshots, we can stop
           talking about "CSS3" and just say "CSS 2011" or "CSS 2012", etc,
           where the module level is less confusing.
   fantasai: So for the snapshots, just publish them as Notes?
   * glazou suspects someone will object
   TabAtkins: Since the modules are our deliverables, I don't think it makes
              sense to track snapshots as real things.  "Note" is fine.
   szilles: Regarding PR, 2.1 is going to come out, and we want people to
            notice we're publishing snapshots.
   szilles: Would be useful to have a PR announcement, maybe combining the
            snapshot+2.1, saying "2.1's here, and now we live through snapshots".
   fantasai: Sounds good.  We could write the Rec announcement with that.
   sylvaing: It seems confusing to me, then, to talk about snapshots as Notes
             at the same time as we talking about Rec stuff.
   glazou: Snapshots are just ToC.
   sylvaing: If Steve is okay with Notes, I'm okay.
   szilles: I prefer something else, but I'm okay with Notes.  It's more
            important to me to get something out.
   glazou: So we should make the snapshot asap, because the Recs will happen
   <sylvaing> (I was ok with notes, but wanted to make sure we all were from
              previous discussions)
   ACTION glazou to let Ian Jacobs know we want to put a special announcement
          for the PR/Rec.
   <trackbot> Created ACTION-319
   * sylvaing ...and now for the non-controversial minute...


   <glazou> http://www.w3.org/mid/045A765940533D4CA4933A4A7E32597E2ABE04E3@TK5EX14MBXC111.redmond.corp.microsoft.com
   TabAtkins: It would be better for me, probably, if we instead start
              next week with this discussion so we have plenty of time.


   smfr: I think I responded and said it should be "any" instead of "all"
         in the spec.
   sylvaing: I agree with that.
   dbaron: I agree as well, though dropping the duplication could also help.


   <glazou> http://www.w3.org/mid/AF6CAE42-3067-4B7F-9F6D-31502ECFE327@me.com
   glazou: Next is about z-index.
   smfr: The Transforms spec says that transformed elements act like
         "relatively positioned element".
   smfr: Webkit has this just create a pseudo-stacking context (like 'opacity'
         does), but FF and maybe IE let z-index work.
   smfr: I argued that we don't let left/top/etc apply, so z-index shouldn't
         either.  So my proposal is that we change the spec to have transforms
         create a pseudo-stacking context like 'opacity' instead.
   dbaron: I don't particularly care, but I think it might be good to ask
   smfr: If authors want to apply z-index, they can just actually make it
   fantasai: I think having to use relpos for z-index is confusing anyway.
   smfr: Stacking contexts are confusing anyway.
   sylvaing: What about opacity?  z-index doesn't apply?
   smfr: No.
   sylvaing: So you're just wanting to make it consistent with opacity.
             Sounds good.
   RESOLVED: transforms create a pseudo-stacking context, not a full one.
             z-index doesn't apply.

list-style-type for disclosure triangle

   fantasai: Works for me!
   hober: I like the use of ::marker, but I think it's kinda confusing
          to use list-style-type to do this, because it's not a list.
   fantasai: Don't be too stuck on the name - the use of the term "list
             item" doesn't mean it's actually a list item.
   fantasai: It just means "I'm a block with a marker thing".
   <fantasai> Note: the spec should make the disclosure triange magic wrt
              writing direciton
   glazou: Because Apple introduced these triangles in OS10 a while ago,
           I think we'll end up with rotating triangles.  So you can't do
           that with separate list types.
   TabAtkins: Just do a transform on ::marker, easy.
Received on Friday, 22 April 2011 02:27:46 UTC

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