- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Thu, 21 Apr 2011 19:27:11 -0700
- To: "www-style@w3.org" <www-style@w3.org>
Summary:
- 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:
http://lists.w3.org/Archives/Public/www-style/2011Apr/0118.html
- 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
http://lists.w3.org/Archives/Public/www-style/2011Apr/0163.html
It was noted that it should respect the writing direction.
====== Full minutes below ======
Present:
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
Administrative
--------------
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
everything.
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
bugs?
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
css3-background.
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
everything.
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.
Charter
-------
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
text-transform
--------------
<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
accents/non-accents.
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
first.
<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...
Variables/Mixins
----------------
<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.
Transitions
-----------
http://www.w3.org/mid/045A765940533D4CA4933A4A7E32597E2ABE04E3@TK5EX14MBXC111.redmond.corp.microsoft.com
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.
Transforms
----------
<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
authors.
smfr: If authors want to apply z-index, they can just actually make it
relpos.
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
---------------------------------------
http://lists.w3.org/Archives/Public/www-style/2011Apr/0163.html
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