- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Wed, 19 Sep 2012 14:28:14 -0700
- To: "www-style@w3.org" <www-style@w3.org>
Summary:
- Discussed Tokyo F2F dates; currently aiming at June 5-7. Schedule poll at
http://doodle.com/z99cyshc5fy96kbr
- Discussed WG reviews of SVG2 and DOM 3 Events
- RESOLVED: Accept Anton's proposed edits for defining "block container element"
http://lists.w3.org/Archives/Public/www-style/2012Sep/0041.html
with editorial reorg of defining paragraph by fantasai
http://lists.w3.org/Archives/Public/www-style/2012Sep/0356.html
Open issue on whether/how "principal box" needs to be defined.
- RESOLVED: Change all CSS module shortnames to form css-foo-N instead of
css3-foo
- RESOLVED: Unversioned shortname shifts to next level of a spec when it
reaches Snapshot maturity
- Discussed viewport size of reftests
- Discussed prioritization of effort within CSSWG
====== Full minutes below ======
Present:
César Acebal
Rossen Atanassov
David Baron
Ryan Betts
Bert Bos (via IRC)
John Daggett
Arron Eicholz
Elika Etemad
Simon Fraser
Sylvain Galineau
Daniel Glazman
Koji Ishii (late)
John Jansen
Brad Kemper
Peter Linss
Anton Prowse
Florian Rivoal
Simon Sapin
Alan Steanrs
Leif Arne Storset
Steve Zilles
<RRSAgent> logging to http://www.w3.org/2012/09/19-css-irc
Scribe: Anton
Administrative
--------------
plinss: Agenda additions?
jdaggett: css3-fonts WD request - please defer
<fantasai> http://lists.w3.org/Archives/Public/public-css-testsuite/2012Sep/0020.html
fantasai: like to discuss the above post
<fantasai> css3-sizing, FPWD publication status?
https://lists.w3.org/Archives/Member/w3c-css-wg/2012JulSep/0281.html
<fantasai> css3-flexbox CR publication status?
https://lists.w3.org/Archives/Member/w3c-css-wg/2012JulSep/0344.html
Tokyo F2F Dates
---------------
plinss: steve and john have a hard conflict around that time
jdaggett: target date of June 5 through 7 (wed - Fri)
jdaggett: SVG guys could do Mon and Tue, overlap with CSS on Weds
glazou: how many people in CSS will attend SVG on Weds?
jdaggett: Can treat Weds as a CSS day in which SVG guys participate
jdaggett: We can sponsor, but our present base can't hold both groups.
We're hoping we'll find a larger space in time
jdaggett: for now, put down Mozilla Japan as sponsor, but need to
check again in Jan
florian: proposed dates don't work for me, but nor do others
jdaggett: want to accommodate the AC meeting that's also in Tokyo
SteveZ: I have same problem as florian
florian: to accommodate me it'd have to be either a month earlier or
a month later, so don't go too crazy trying to schedule for me
jdaggett: at TPAC we can talk again
* fantasai can start a doodle poll on weeks
jdaggett: I'll update the wiki with relevant info, proposing 5,6,7 June
(with 5 June as crossover day)
florian: If I can only come on Sunday to TPAC, do I have to pay a fee?
SteveZ: no, no fee for that day
dbaron: Given that the next-to-AC-meeting dates don't work for Steve,
doesn't seem like doing next-to-AC-meeting scheduling helps
that many people.
<fantasai> http://doodle.com/z99cyshc5fy96kbr ?
Spec Reviews
------------
TOPIC: svg2 property review
plinss: feedback everyone?
* fantasai still needs to do that...
plinss: minor threads on www-style about IRIs/URLs
glazou: seems to be a point of contention
sylvaing: paintOrderProperty - name is good, but we've used the expression
"paint order" to mean something quite different
plinss: do we need more time to review
glazou: I reviewed it but don't have comments, not really my area
plinss: revisit next week?
dbaron: I'm not that happy about paint-order but don't have better ideas
right now
plinss: should we make that WG feedback, or individual feedback?
dbaron: I don't have a strong opinion, and am not crazy about WG feedback
in general
glazou: we've been asked as a group for feedback
dbaron: In that case, I'd like another week
RESOLVED: revisit next week, after review
ACTION on glazou: contact Cameron about the delay
<trackbot> Created ACTION-508
TOPIC: DOM3 Events
glazou: I reviewed it; it seems fine
<silence>
glazou: CSS is mentioned in 2 places: z-order manipulated by CSS, and
the way in which mouse movements work
glazou: also mouse enter and mouse leave being like hover
smfr: Is "mouse event order" section describing something new, or
something that's implemented?
glazou: seems to me that it's already implemented
SteveZ: seems like our response is "no comments"
RESOLVED: we have no comments on DOM3 Events
ACTION glazou: no comment on DOM 3 Events
<trackbot> Created ACTION-509
CSS2.1
------
Scribe: fantasai
http://lists.w3.org/Archives/Public/www-style/2012Sep/0041.html
antonp: This is about a proposal to introduce the term "block container
element"
antonp: We raised it briefly last week so people could have a week to review
antonp: Noticed fantasai replied today
antonp: Rossen also wanted a chance to review
http://lists.w3.org/Archives/Public/www-style/2012Sep/0356.html
smfr: block container element is ?
antonp: we already have concept of block container box, but we have
problem in CSS2.1 where we mix elements and boxes all over
the place
antonp: would be good to have an element vs. box distinction
antonp: this will help us to write errata with the right terminology
antonp: don't think it introduces anything substantial
smfr: how does it work with anon boxes?
antonp: An anonymous box would never generate a principal box, so
couldn't possibly be a principal block container element
antonp: anon boxes aren't produced by elements anyway, so no issue
antonp: anon boxes often are block boxes, but no corresponding block element
antonp: one question fantasai raised on list was
antonp: suggested some alternative wording of one paragraph, seems good
to me
antonp: also made a comment on "Certain values" phrase
antonp: [talks about "principal box" term, how it's used but not defined]
antonp: I deliberately don't include inline boxes when talking about
principal boxes
antonp: because they behave differently from other boxes
antonp: but fantasai feels that inlines do generate principal boxes
antonp: I don't think we need to answer that question for CSS2.1, which
is why the wording is deliberately vague
antonp: a bit cheating, we can do anything in CSS3, since omitted from
CSS2.1
dbaron: I think if you want something to be undefined, you should say so
dbaron: if it's omitted, it doesn't happen
fantasai: If block-level boxes can be principal, then so can inline boxes
fantasai: Reason inline elements have multiple boxes in CSS2.1 is that
they're fragmented
fantasai: But block elements also get fragmented when they're paginated e.g.
fantasai: I think originally this was not considered by the spec authors
fantasai: inline elements were thought of as having multiple boxes
fantasai: but now we have concept of a "box", which is then fragmented
into "fragments of boxes"
fantasai: And the same phenomenon applies to block-level elements as
to inline ones
antonp: I agree, which is why not objecting to the idea of principal box
for inlines
antonp: But I don't think that ties in with Chapter 10
antonp: I know Bert's model doesn't really match this idea of principal
boxes
antonp: But that said, I think there are actually existing problems in
Chapter 10 anyway
antonp: So don't think ought to be changing our mind on basis of Chapter
10 that might not be the best anyway
antonp: So [...]
antonp: Which brings me back to dbaron's comment
antonp: I suppose, I can't argue against it
antonp: but I do think if you're trying to clarify something thats unclear,
and improve but not all the way, then it's still improvement
antonp: You could argue that either way
antonp: But if others not happy with that [...]
szilles: I think better to leave explicitly undefined
plinss: Do we need to leave it undefined?
Florian: Since tricky to define whether or not they define principal
boxes, would do what Anton says
Florian: Can make decision to define one way or another at some later point
fantasai: I'm fine either way
<florian> I would prefer to mark explicitly undefined for inlines,
but otherwise do what anton says.
plinss: If there are issues in Chapter 10, let's just address them.
fantasai: I'd like to hear from Bert, is he on the call?
* Bert can't call in. Phone (or phone system?) broken :-(
arronei: Can we just accept Anton's text and take the inline portion
for next week?
Florian: That would work for me
fantasai: Can treat Anton's issue as separate from my comment, have
that be another issue
dbaron: Would like it to be explicitly undefined if we don't know yet
rossen: I agree we should move forward with accepting this, but making
the undefined part of it explicitly undefined
<SteveZ> +1 with David and Rossen
<florian> +1
<Bert> I'd like to discuss with Anton why he thinks we need the concept
of "principal" at all. To me, list-items just generate two boxes,
one a block-level box, the other inline-level. We refer to one
as the principal and the other as the marker, but that is just
to describe them for the purposes of that para. There is no
global concept of principal box.
<antonp> Bert: I sent you an e-mail today justifying the need for
"principal box" as a label; I think it's useful to define
these things like block container element
plinss: Not satisfied with leaving another open issue against it?
fantasai: It's not a technical issue, it has no affect on interpretation
of the spec, it's just about tightening up prose. I don't
think we need to draw attention to the fact that we're not
100% certain whether the term Principal applies here or not.
SteveZ: Since Principal is used to identify which elements are
Block-container-elements, we should be clear about the
handling of inline boxes
<fantasai> SteveZ, regardless of whether inline boxes are principal
or not, they're definitely not blocks so it doesn't matter :)
fantasai: I also don't think this is something to spend this much
time on on the call
plinss: Is everyone happy with accepting Anton's text and leaving
principal box of inlines issue open?
fantasai: Are there any objections to accepting Anton's text and
leaving the issue open?
RESOLVED: accept Anton's proposal
Spec Shortname
--------------
plinss: We have three proposals for how to rename our spec shortnames
[to be consistent with CSS modularization/levelling]
plinss: Let's get a resolution on which direction to move in, then
come up with concrete proposals
plinss: Any comments on which naming system to use?
<fantasai> http://wiki.csswg.org/spec/shortnames#versioned-names
<dbaron> A is cssN-foo, B is css-fooN, C is css-foo-N
* stearns prefers C
<SimonSapin> B or C are fine, A is confusing
dbaron prefers C
glazou: I prefer C, too. The N is not related to CSS, it's related
to the module
<SteveZ> +1 for C
plinss: C
* lstorset C++
florian: C
arronei: C
fantasai: So! Anyone for not C? :)
RESOLVED: C
plinss: other question on wiki page was when do we move shortnames
over to next level
http://wiki.csswg.org/spec/shortnames#unversioned-names
<dbaron> A == CR, B == Snapshot acceptance, C == REC
Florian: I would say A
szilles: I'm confused by that. We create version N+1 when we're trying
to split it into pieces we can do now vs later
fantasai: This isn't about when to split the document, but when the
unversioned shortname moves to the next version.
<SimonSapin> Does B imply waiting for the next snapshot?
...
<dbaron> I think I probably also lean towards B.
Florian: What's the criteria for snapshot?
fantasai: We think the module is stable, don't expect any changes or
problems. Have tests and implementations, maybe not enough
to get to REC, but enough to identify problems as bugs that
will be fixed and to be confident the spec can be implemented
as-is.
Florian: In that case, I prefer B
sylvaing: me too
?: Would motivate updating snapshot more often
plinss: Would update redirects when publishing snapshot
<SteveZ> I can live with option B
Florian: Only worry with option B that since it's not very systematic,
would postpone
Florian: Otherwise it's the right level
plinss: Snapshot is note, so we can update quickly
plinss: Objections to B?
RESOLVED: B
SteveZ: Should we reopen whether snapshots should be REC or not?
plinss: There's nothing testable. How do you prove a snapshot?
plinss: could revisit in the future, don't want to open now
Max Viewport Size on reftests
-----------------------------
plinss: min or max?
dbaron: The viewport size
fantasai: The test should still work on larger sizes
http://lists.w3.org/Archives/Public/public-css-testsuite/2012Sep/0020.html
dbaron: It's the minimum size at which you should run the test,
and the maximum size at which the test should have information
for determining pass/fail
fantasai: Mozilla proposed 600x600, Chrome and Opera say they don't
need to go smaller
arronei: Don't think we'd need to go smaller
rossen: Is this for phones?
Leif: We run at desktop resolution only
Florian: May want to run on phones, too
Leif: Might want to, but don't now
Leif: Could look into it more closely
florian: Yeah, because even if not needed right now, if we decide to
do it don't want to rewrite all the tests.
Leif: Ok, will look more into that
fantasai: Do MS or Apple need to look into it more?
smfr: We run at 800x600, and on mobile we scale down
smfr: For tests that test viewport specifically, might need to run at
320xwhatever
MS: Same scenario we have
dbaron: So if you run tests at 800x600...
dbaron: If people write tests at resolutions higher than this
dbaron: Might have existing tests not compatible with smaller resolution
dbaron: This is the reason we don't want to go too small
dbaron: but also have some devices where, for some reason...
smfr: 600x600 sounds constraining for some kinds of tests
dbaron: There are a lot of tests you make things x pixels wide, no
reason to pick that number and not half that number
smfr: More regression tests, where putting things side by side in
same test (?)
lstorset: What kinds of tests would be included here? No idea how big an
impact this decision would have
Florian: Most tests draw a green box, could be just 100px wide
fantasai: Ok, people should look into it. We can come back next week.
dbaron: We need to know whether people have a reason to run at a
smaller size
dbaron: Also whether anyone has a pool of tests planning to contribute
that they can't bring down to this size
Prioritization
--------------
plinss: Haven't gotten much feedback on module prioritization, please
do that
sylvaing: what is it for?
plinss: Will inform glazou and I how to reset priorities for the group
sylvaing: we've answered those things for charters
sylvaing: what are we going to do differently this time?
glazou: When we did this for the charter, it was also to know what
were documents we wanted in the charter
glazou: Not the case here. All documents listed here are in scope.
sylvaing: Every meeting I go to, we start working on some new thing
sylvaing: Don't allocate time based on priorities
sylvaing: Is the plan to take some action based on priorities?
glazou: It's part of the plan
dbaron: One thing I found difficult to answer was
dbaron: How to balance newer specs vs older specs
dbaron: Tried to balance by trying to think about, if we spent time on
issues for one or the other, which was higher priority?
dbaron: But that will also change over time, because function of where
they are in the process
dbaron: Put down priorities for right now, but won't be valid for the
long time
glazou: Not looking for long-term answer, looking for prioritization now.
sylvaing: I'd love to hear more on what you're thinking of to do with
the answers
sylvaing: Fuzzy on that
glazou: You said yourself we have 50 docs on the radar, and new ones
popping up every other week
glazou: We have limited time
glazou: need to dedicate our efforts on a single set of documents that
we can move on rec track quite fast
glazou: we think such a list from you guys could help
sylvaing: So we're talking about when people bring up issue for telecon,
and not high priority, you'll say no?
glazou: If it's low priority, and we have high priority issues, yes.
glazou: That's exactly what we did for CSS2.1
plinss: If we have time available, we'll spend it on low priority issue.
But if not, then no.
glazou: We did this informally already
glazou: We'd discuss on Tuesday, this item isn't critical, so not add
it to agenda
glazou: We want to do this based on your feedback, not just our opinions
glazou clarifies that invited experts are expected to respond
Flexbox
-------
fantasai: So, is Flexbox going to CR?
glazou: Yes
fantasai: So how is it getting there? When/who is publishing?
glazou: Let's discuss that offline.
Meeting closed.
Received on Wednesday, 19 September 2012 21:28:44 UTC