- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Wed, 18 Apr 2012 17:48:04 -0700
- To: "www-style@w3.org" <www-style@w3.org>
Summary:
- RESOLVED: Add new editors from Opera to Device Adaptation
- Request to review Regions new auto-sizing section
http://lists.w3.org/Archives/Public/www-style/2012Apr/0278.html
- RESOLVED: Accept Sylvain's proposal for handling negative animation-delay
http://lists.w3.org/Archives/Public/www-style/2012Apr/0239.html
- RESOLVED: 2^24-1 minimum for numeric types, 30-component minimum for
repetitions, 30-component minimum for calc(), adjust lower if
necessary later
- RESOLVED: Baseline of flexbox is baseline of baseline-aligned boxes if
any, otherwise take first child
- RESOLVED: Use the table for converting display types to block-level types
to determine baselines; effectively this is using display-inside
====== Full minutes below ======
Present:
Tab Atkins
Tantek Çelik (via IRC)
Arron Eicholz
Katie Ellison
Elika Etemad
Sylvain Galineau
Daniel Glazman
Vincent Hardy
John Jansen
Brad Kemper
Chris Lilley
Peter Linss
Alex Mogilevsky
Edward O'Connor
Florian Rivoal
Anton Prowse
Dirk Schulze
Alan Stearns
David Storey
<RRSAgent> logging to http://www.w3.org/2012/04/18-css-irc
Scribe:
ScribeNick: fantasai
Administrative
--------------
Florian: Wanted to add new editors to CSS Device Adaptation
<florianr> https://lists.w3.org/Archives/Member/w3c-css-wg/2012AprJun/0073.html
Vincent: We're looking internally to see if someone might be able to
join as well
plinss: Please take time to add agenda topics to Hamburg wiki
plinss: And some of those there are vague; please add more detail
plinss: One issue left on margin collapsing?
antonp: I'd like to work on other 2.1 issues than that one
antonp: so let's postpone, and for next week I'll try to prepare some other ones
plinss: Ok, ping me when it's ready
glazou: Announce that Backgrounds and Borders / Image Values moved to CR
glazou: missing announcements
TabAtkins: yeah, fantasai and I were working all day on css3-values
TabAtkins: will get to that
Device Adaptation
-----------------
Florian: Current editor for CSS Device Adaptation is going on paternity
leave, so we're proposing two new editors from Opera myself and
Øyvind Stenhaug
Florian: We also invite people from other vendors to join, help us move
this forward
Vincent: What's the status of this module?
Florian: Some open issues, and some editorial work
Florian: Don't think there is a public test suite
Sylvain: We have a partial implementation, might provide feedback soon
Florian: Would be much appreciated
Florian: Noticed you only implemented part of the spec, want to know if
that's because you haven't done it yet or thought better to not
implement it.
Sylvain: Mostly we don't have it yet
RESOLVED: Add new editors from Opera to Device Adaptation
CSS Regions
-----------
<stearns> list intro: http://lists.w3.org/Archives/Public/www-style/2012Apr/0278.html
<stearns> ED section: http://dev.w3.org/csswg/css3-regions/#regions-visual-formatting-details
stearns: Added new sections to Regions to handle auto-height regions
stearns: We've been validating this in code in a WebKit branch, making
sure what we have there is implementable
stearns: would like people to take a look and give us some feedback
stearns: that's all
howcome: I went through it, and I find it hard to read/understand/comprehend
that part
howcome: It may be right, but I find it hard to review and relate to the
regions spec
howcome: when the #1 concern that I and others have raised is not addressed yet
howcome: I would have preferred if that hurdle could be passed.
howcome: Right now, it doesn't seem like this should be something to work on
stearns: It's definitely something we're working o
stearns: what you do with the regions box is not related to how you size it
stearns: we want the sizing algorithm independent of where the box comes from
stearns: I agree we need to address box generation
stearns: don't know that that issue gates auto-sizing regions
howcome: I agree they may be independent, but there's not much motivation to
review the spec when this hurdle remains in the way
<sylvaing> didn't we agree to address this as part of the template work in Paris?
Vincent: We are working on page templates, syntax for generating regions
Vincent: We're trying to address the big issues you and others have raised;
auto-sizing was one of those issues
Vincent: We're not ignoring the other issues
11:14 * tantek is on IRC only for this meeting.
<Zakim> ... [Microsoft.aa], TabAtkins
<Zakim> [Microsoft] has alexmog
<Zakim> +ChrisL
<plinss> ack glazou
11:14 * Zakim sees no one on the speaker queue
glazou: I reviewed document with a fresh eye
glazou: I did not find it hard to read or understand
glazou: I found it pretty easy to read and understand
glazou: The thing I originally missed, and discovered rereading it
glazou: Is that generating boxes is completely independent of notion of regions
glazou: Explanation in Section 7 is needed to explain how regions work
glazou: could be independent of generation of boxes
glazou: We might need for other things in CSS
glazou: Without that, document is not understandable as a whole
antonp: I found it hard to get on the first read through. What could help
is if someone maybe posts a summary of what's going on in Section 7,
to orient the reader a bit?
stearns: maybe I'll post an outline of the section to the list
bradk: I thought Section 7 was easy to understand, esp with examples
bradk: What was hard for me, doesn't have an exact definition of "fragment"
bradk: There's no terminology section
bradk: Afraid it might mean different things in different parts of the
document
Vincent: Referencing CSS3 Fragmentation Spec
stearns: I think I have a task to go through the document and make sure
we have all relevant spec links
stearns: We should have more links to css3-break
bradk: Fragmentation spec talks about portions that occur between breaking
opportunities, right?
bradk: Seemed like in some parts it meant something different, like portion
of element that's within the region box or something like that
bradk: Want to make sure it's consistent
Vincent: If you have any places you notice, point us at them
animation-delay
---------------
<sylvaing> http://lists.w3.org/Archives/Public/www-style/2012Apr/0239.html
sylvaing: Made a fix to clarify ...
sylvaing: But case that's not covered -- negative animation delays
sylvaing: If you have a 2s animation and you have a -1s delay, your
animation starts in the middle
sylvaing: but if you have -5s animation, what does it mean?
sylvaing: Implementations agree that if you have repetition of 1, and you
have delay greater than duration, nothing happens
sylvaing: However if you have more, and you ask for a delay, then you
might skip repetitions
* scribe unsure if that was quite right
Florian: Looks like you didn't test Opera. The behavior we have in Opera,
we don't like it
smfr: Need to define what happens if fill mode is greater than duration
smfr: do you jump to last keyframe even though you didn't run the animation?
smfr: For all cases where the animation either never runs or completes
instantaneously, we need to decide what fill-mode does
smfr: Also define whether event fires
<oyvind> I assume that should say "if you have fill mode and delay is
greater than duration"
plinss: Any objections?
RESOLVED: Accept Sylvain's proposal
<oyvind> or rather "if you have fill mode and negative delay of greater magnitude than duration"
* fantasai wonders what happened to
http://lists.w3.org/Archives/Public/www-style/2010Apr/0110.html
<fantasai> if it ever got filed.
<smfr> fantasai: i don't think it did
<fantasai> smfr, :/
Values and Units
----------------
<glazou> is there a URL for the current topic ?
<Ms2ger> http://lists.w3.org/Archives/Public/www-style/2012Apr/0403.html
TabAtkins: Awhile back, resolved to find minimum required ranges
TabAtkins: we asked Arron for those numbers, but he didn't get back to us
for awhile, so we made some numbers up
TabAtkins: yesterday he suggested 2^27-1 for all numeric types
TabAtkins: He said it doesn't actually match minimums in IE in all places,
but thinks it's reasonable
Florian: Opera used to have extremely random sizes
Florian: We recently changed to use 32-bit, but considering moving to
24-bit representation
Florian: So we might go back low
<ChrisL> 2^24 -1 then?
TabAtkins: That still seems like a large limit
<gsnedders> ChrisL: Yeah
TabAtkins: Should be more than needed for anything except z-index
fantasai: The goal here is to be conservative, so low numbers should be fine
<glazou> and we may need something expressing MAXRANGEVALUE
* ChrisL z-index is an unrestrained binary coded decimal?
z-index:-200000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
TabAtkins: Ok, we'll use 2^24-1; if anyone has another concern bring it
up within the week
<bradk> Wasn't there some talk about making z-index into a float?
TabAtkins: Another issue is repetitions of component values.
TabAtkins: We picked 30
Florian: We used to have a limit of 32, but now limited only by memory
Florian: So we're fine either way
sylvaing: ???
TabAtkins: Any time the grammar has a repetition, e.g. + or *, how many
are required
<glazou> chained lists in memory are so hard to implement ? ;-)
Florian: I believe IE was limited to 20 in some cases
TabAtkins: calc(), I think
TabAtkins: Also have a 30-term min on calc
TabAtkins: So, we'll put this in, and people can object if it's too high;
we'll lower it if necessary
glazou: good strategy
TabAtkins: We can even do that in CR, since it won't make anyone invalid
that was valid before
RESOLVED: 2^24-1 minimum for numeric types, 30-component minimum for repetitions,
30-component minimum for calc(), adjust lower if necessary later
glazou: Should that be tested?
TabAtkins: Yes, the whole point is to allow testing
talk about testing this
TabAtkins: another issue
TabAtkins: Kenny brought up the really fun situation...
TabAtkins: Right now, when we have attr(), we do early syntax checking
if the type and the fallback are appropriate for the place
TabAtkins: I can give an example, where this is still confusing
<TabAtkins> box-shadow: attr(size px, inset) 5px 10px blue;
TabAtkins: So, in this, whether you interpret the attr() as a pixel size
or the 'inset' keyword, but you get completely different
meanings out of the two
TabAtkins: If you have multiple attrs(), you have to do combinatorial
checking of possible values
TabAtkins: We went and restricted it to say that if attr() is the sole
value of the property, you can do whatever you want
TabAtkins: But if you use it as a component value, the fallback has to
be the same type as the declared attr type
fantasai: I'd like to have dbaron check on this before we close
smfr: Going back to value ranges, sometime ago I proposed some text about
roundtripping
smfr: If you supply value that's too large, it gets truncated, you write
it back out it should roundtrip
TabAtkins: Could add some specific requirements if that's needed
smfr: ... z-index ...
TabAtkins: Requirement is that you clamp to the nearest supported value
smfr: So it clamps and then roundtrips, ok that's fine
TabAtkins: I don't think we have anything else right now
fantasai: Stay tuned, we'll have lots of issues to resolve next week!
Flexbox
-------
http://lists.w3.org/Archives/Public/www-style/2012Apr/0225.html
TabAtkins: The issue was a) we didn't define the baseline of a flexbox
TabAtkins: The possibilities are either baseline of first-child, or
somehow do what tables do (don't remember what they do)
alexmog: We came to a conclusion for our implementation
alexmog: Baseline of first child is baseline of flexbox
alexmog: But we didn't have per-item alignment
alexmog: I think what we had then is still ok
alexmog: If there are items with baseline-alignment sharing baseline,
reasonable for that to be baseline of flexbox. Otherwise
take first one
RESOLVED: Baseline of flexbox is baseline of baseline-aligned boxes if
any, otherwise take first child
TabAtkins: Second part is, how do you determine baseline of the first child
TabAtkins: Proposal is use baseline of first child's display type
Florian: We'd prefer not to do that, because if we consider things in
terms of display-inside, display-outside, your display-outside
would be something like flexbox-item, so you can't distinguish
inline-block and block
* fantasai agrees with Florian
TabAtkins: So in practice, we could use the 2.1 conversion table for this
TabAtkins: I don't care much either way, but several implementers said
using display type makes sense to them
<TabAtkins> http://www.w3.org/mid/87pqbfkcex.fsf@aeneas.oslo.osa
fantasai: It's implementable, because we can always look up the computed
style, but that doesn't necessarily mean it makes sense
* sylvaing alternative: flexbox item with the highest z-index wins!
alexmog: I think flexbox child would have it's display type, and just
have an internal display-outside of flexbox-item
Florian: In that case, you shouldn't be using display-outside of inline/
block to determine different alignments
alexmog: That's what I'm saying, inline-block and block should behave
the same
alexmog: Related issue is that suppose you have flexbox with one item,
and that's inline-block or block or table with table cell
alexmog: each with different definition of baseline
alexmog: no way to make us actually ignore that internal baseline entirely
and say that I want the baseline of that box be the bottom of the
box
alexmog: Or can i?
fantasai: I think there were some proposals for that. Might be added to
Line Layout module
TabAtkins: Think we can defer that to later
RESOLVED: Use the table for converting display types to block-level types
to determine baselines; effectively this is using display-inside
<TabAtkins> https://www.w3.org/Bugs/Public/buglist.cgi?product=CSS&component=Flexbox&resolution=---
TabAtkins: I think there are less than 6 weeks of work left on Flexbox,
so I think we're ready for LC.
fantasai: No.
TabAtkins: If there are other issues to bring up, appreciate that happening
now
<ChrisL> that is being ready in 6 weeks
<ChrisL> and there should be no open issues, so its a stable document for
reviewers
fantasai explains that LC doesn't mean "I think I have 6 weeks left of work
on this module" but "I think I'm done, please take a last look
over what we're about to release".
TabAtkins: I don't think there are any major issues left.
ChrisL: If you think you have only one week of work left, then come back
in a week and ask for Last Call
alexmog: I think we're done, we don't have anything else
fantasai: I disagree, and I would like to see the alignment issues
addressed before LC
<ChrisL> I agree with fantasai that if there are pending edits, do them
first before going to last call
plinss: I agree with fantasai [...]
plinss: Major issues / minor issues, whatever.
plinss: Want to present things for people to review.
<ChrisL> so defer that issue as out of scope
<sylvaing> can we just accept/postpone LC?
...
* ChrisL wishes we wouldn't try to rewrite the process every time
Florian: zero bugs is hard to get to
Florian: But you shouldn't go to LC with bugs that you aren't willing
to defer to next level
fantasai: If you are making significant changes between LC and CR, you
need to do another LC. You're not gaining anything there.
Anton: If you've got a bunch of pending edits you haven't made, then
it's not really a Last Call, it's another Working Draft
glazou: Going to LC is decision of the WG. Decisions of the WG is made
based on review of the members. Asking for review before
transition request is fair
sylvaing: maybe we should talk about actual issues?
* glazou does not see a consensus about going to LC anyway
florian: have a small question, fantasai has said several times that
shouldn't go to LC until dbaron reviews.
TabAtkins: AFAIK dbaron is deferring to dholbert
plinss: We don't have consensus to go to LC. So work on the issues,
and we'll come back to it later
sylvaing: There's some issues that require WG discussion, e.g. renaming
everything and going to LC are incompatible
antonp: What exactly do I need to review here?
antonp: Is bugzilla + current editor's draft what's needed to review
this thing?
Tab: yes
plinss: Everyone please review
Meeting closed.
Received on Thursday, 19 April 2012 00:48:38 UTC