- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Thu, 02 Aug 2012 15:46:56 -0700
- To: "www-style@w3.org" <www-style@w3.org>
Summary:
- RESOLVED: Publish FPWD of the Compositing draft.
- RESOLVED: order affects abspos, Flexbox goes to CR
- Discussed interpolation of transforms
- RESOLVED: Accepted the following clarifying edits to CSS2.1:
https://www.w3.org/Bugs/Public/show_bug.cgi?id=17121#c2
https://www.w3.org/Bugs/Public/show_bug.cgi?id=17121#c5
https://www.w3.org/Bugs/Public/show_bug.cgi?id=17122#c1
https://www.w3.org/Bugs/Public/show_bug.cgi?id=15686#c2
- Discussed whether/how 'overflow' applies to table elements
- Action: review css3-text ED for publication request next week
====== Full minutes below ======
Present:
Glenn Adams
Rossen Atanassov
Tab Atkins
David Baron
Bert Bos
Rik Cabanier
Arron Eicholz
Katie Ellison
Elika Etemad
Simon Fraser
Sylvain Galineau
Daniel Glazman
John Jansen
Anton Prowse
Florian Rivoal
Dirk Schulze
Alan Stearns
David Storey (via IRC)
Leif Arne Storset (Opera Software)
Steve Zilles
<RRSAgent> logging to http://www.w3.org/2012/08/01-css-irc
Scribe: fantasai
Administrative
--------------
glazou: any additions to agenda?
glazou: If you plan to attend or not attend, please add your name to
the wiki so we know who is coming / when / where
<glazou> http://wiki.csswg.org/planning/sandiego-2012#participants
Florian: For TPAC meeting, Opera is joining Adobe as a sponsor
glazou: Thank you very much
glazou: Any other organization?
Glenn: Sunday before or Sunday after?
glazou: before
Compositing FPWD
----------------
<cabanier> https://dvcs.w3.org/hg/FXTF/rawfile/4b53107dd95d/compositing/index.html
<glazou> https://dvcs.w3.org/hg/FXTF/rawfile/tip/compositing/index.html
Rik: SVGWG already approved to move to FPWD
Rik: Think the spec is in reasonable shape.
Rik: need to get more consensus on CSS keywords
Rik: There are many; some people requested fewer
Rik: As WD will get more exposure
Rik: e.g. dbaron gave me very good feedback
Rik: Think it's in readable shape, would like to move to WD
glazou: Opinions?
Florian: I haven't read everything, but I like it so, yeah
Tab: I approve
dbaron: The biggest thing I was worried about was z-ordering stuff,
possible I confused people
dbaron: If it's either fixed, or there's a note that it needs to be fixed,
I'm ok with it
Rik: I rewrote it with stacking context, like you said, and linked to
Appendix E
Rik: ... add an example that shows what is happening, ppl will not get
confused.
glazou: So, no objections against FPWD of compositing?
glazou: Okay, so let's do that.
RESOLVED: Publish FPWD of the Compositing draft.
glazou: Anything else wrt compositing?
Bert: It's part of CSS and SVG, who does the publishing, is that me?
Rik: I think it's part of CSS, so we opened a Bugzilla as part of CSS
Rik: FX will not get as much exposure, and it's not specific to SVG,
just adding CSS properties
Rik: Let me know if I need to change anything
ACTION Bert: Publish Compositing FPWD
<trackbot> Created ACTION-487
Flexbox
-------
<glazou> http://dev.w3.org/csswg/css3-flexbox/
Tab: We concluded last week with some resolutions that should cover
what we need to do, and left actual details to me and fantasai
Tab: We tried to go with Option D, and to match it thematically with
how abspos works in block layout
Tab: You look for your next/previous item and attach it there
Tab: fantasai worked out how to treat it as a placeholder and just
do some packing-space suppression
Florian: As long as Morten is happy, it's good with me
<fantasai> Morten's response -
http://lists.w3.org/Archives/Public/www-style/2012Aug/0023.html
szilles: If there's a sequence of abspos, they are processed and
attached to the same edge
fantasai: yes
szilles: And order means that I don't choose the adjacent edge until
after I've finished reordering.
szilles: If you could make the wording a little more obvious in that
direction, would be helpful
Tab: wrt first one, we do talk about in-flow items--abspos is out of flow
Tab: Second one, we're explicit that you run reordering first.
Florian: Maybe clarify in a note or something
szilles: great job
Tab: One bit that's important, last week WG officially resolved that
'order' doesn't apply to abspos
Tab: Wanted to ask WG if ok with reverting that.
Tab: As written right now, order affects the abspos.
Florian: Sounds fine to me. Was only concerned about applying to
placeholders.
Tab: Morten's ok with it, and chrome is ok today
* fantasai notes bzbarsky said it would be easy for Gecko
Anton: I'm wondering, do we expect abspos static positioning to work
with layout models in this way?
Anton: It's ok, but I think we need to think about the consequences
with other layout models
Anton: Note also that float or clear doesn't affect abspos
Anton: Might decide that's an anomaly
fantasai: or maybe it was added for compat
Tab: Could have principle that do layout, then position abspos
dbaron: Concerned about that. Don't really want to do layout
...
Florian: I think it's in line with what we called the Rossen Principle.
In block layout, if you abspos and don't give coordinates it
goes where it would have been
Florian: Flexbox does roughly the same thing
Florian: Don't think anything very different here wrt high-level view
Tab: I think dbaron just wants a clarification of whether for future
models you do any work
Florian: Hard to discuss without a specific case in mind
Rossen: Wrt Grid, we always position in the origin of a grid cell in Grid
Rossen: You honor grid-row/grid-column positioning, but otherwise put
in origin
Rossen: I do agree there's a higher-order question of should it follow
block/flow layout model in other layout models, where that
doesn't make any sense?
Rossen: Or go with something simpler, like Tab was suggesting (origin
of flex container) last week
Rossen: I'm still in favor of going for something simpler in layout
models that have no concept of flow.
...
szilles: Positioning of flexboxes is ...
* fantasai reminds everyone that we should close the topic
<dbaron> For reference, my position in last week's straw poll would
have been A.
Tab: Want to request resolution of reversing order, and of going to CR
RESOLVED: order affects abspos, Flexbox goes to CR
ACTION Bert: send Flexbox CR transition request
<trackbot> Created ACTION-488
dbaron: The idea of this model is that you apply order to the abspos to
figure out where it goes in the order, and then use that as the
static position?
Tab: yes
Anton: You're not really treating it as a flex item, you're using order
to figure out which item is the next/previous item to attach its
position to that.
dbaron: So I'm not really happy with adding 100 lines of code for
something I haven't heard a use case for
Tab: Brad produced some things in the mail thread
fantasai: ...
glazou: But you are not objecting to the change?
dbaron: No. Close to it, but no.
glazou: Ok, let's move on
* sylvaing #dbaron { objection: 0.99; /* that was close */ }
Transforms
----------
<glazou> http://wiki.csswg.org/topics/transform-interpolation
Krit: Issue was ...
Krit: Request from implementers that we don't do that, that we interpolate
on each function pair
Krit: So changed the spec to do interpolate on function pairs
Krit: For perspective we do matrix decompse then interpolate [??]
Krit: Thought it'd be a perf issue, but browsers didn't think so
Krit: Have request from smfr that functions along same axis are interpolated,
not matrix
glazou: In wiki WebKit says they can't change to the preferred way anyway
smfr: Could, but would prefer not to
dbaron: I was originally asking the spec to change back to what it used
to say
dbaron: Also worried in general that this spec changes too much in ways
that are incompatible with Web content
dbaron: Afraid might have to come back 3 months and have to request revert
of changes
dbaron: But can't say sooner than 3 months
Krit: Can you be more specific?
dbaron: There's a lot of content using this
dbaron: They stuff the result of any prefixed/unprefixed values into the
same variable and use it the same way
dbaron: prefixes isn't getting us anything here
smfr: Risk of interpolating transforms is in cases where we used to not
do convert then decompose, cases where we would now if we change
the spec
smfr: The spec is going away from using matrix interpolation, which is
a good thing
dbaron: Yes, worried about changing things *to* matrix interpolation
Krit: If I got feedback on specific parts that needed to change, I
changed it, that's all.
dbaron: It was specified when I implemented it. If it's not anynmore,
someone deleted it
smfr: notion of primitives and derived [...]
<sylvaing> I am also worried about making incompatible changes at this point
smfr: e.g. translateX() will interpolate with translate()
smfr: WebKit didn't implement that
Krit: [...]
Florian: I'm not very up to speed on how this behaves, but do completely
agree with dbaron
<dbaron> Gecko implemented that a few weeks ago, but we haven't shipped
it yet.
<sylvaing> at a minimum testcases showing some level of interop are
warranted
<sylvaing> (or lack thereof)
Florian: Used too much to be changed without trouble
Florian: Need to document things, but not change suboptimal behavior
smfr: But whose implementation do we pick? Webkit, Gecko, Opera, IE?
sylvaing: Need to write some test cases to figure that out
Krit: These changes were made several months ago,
Krit: even translateX() and translate(), was something not specified
before, just said "transform function of he same type".
Had to address, what does "same type" even mean
Krit: So we say "transform function with the same name"
Krit: This is different from editors' decision.
Krit: I'm fine with changing everything to match transform names
Krit: Still think it's useful for translate functions to interpolate
Krit: e.g. you have translate() and translateX()
Krit: with your interpretation we need to decompose to a matrix
Krit: whereas I would prefer a numeric interpolation
smfr: I agree, that's better
smfr: I think that's safe, because in the direction of less matrix
interpolation
Krit: Same issue with scaleX()
<krit> http://dev.w3.org/csswg/css3-transforms/#transform-primitives
Krit: Things that are affected are scale(), translate(), translate3d()
and scale3d()
Krit: Not sure that's implemented by browsers, I don't think so
Krit: But from our pov seems useful
smfr: Seems unlikely that these changes break content
smfr: one thing that happens when you fall into matrix interpolation
is that you lose rotations greater than 360 deg
smfr: So if someone has a high deg rotation (e.g. 760deg) and has one
of these functions, you fall into matrix interpolation
smfr: might be ppl doing that now
Krit: second request, you said you'd like to interpolate between
rotate3d along same axis?
Krit: So rotations around same axis, would like to interpolate.
smfr: WebKit will interpolate between rotateZ() and rotate()
smfr: And for rotate3d() will check if axes match, otherwise
go to matrix path
smfr: That's just for that one function.
smfr: I believe it will fill due to transform individually in the list
if there are rotate3D()s in corresponding places even if axes are
different
dbaron is fine with that
Krit: Everything else, implementers requested it. So should be ok.
Florian: In general I would like to see test cases for these, to check
if we are picking the interoperable solution
Florian: If there is a difference, we need to figure out whether we
want good or compatible
Krit: We don't have a format for animation tests
Florian: These are used a lot out there, so we can't break compatibility
fantasai: Can always write a manual test
fantasai: That's good enough to see what browsers are doing for purpose
of speccing it
<dbaron> It's really easy to write script tests for interpolation by
using a negative transition-delay.
some question of how to write testcases
CSS2.1
------
<glazou> https://lists.w3.org/Archives/Member/w3c-css-wg/2012JulSep/0090.html
https://lists.w3.org/Archives/Member/w3c-css-wg/2012JulSep/0101.html
Anton: First one is follow-up on adding concept of formatting contexts
Anton: Rossen wanted it clearer when a box establishes an inline
formatting context
https://www.w3.org/Bugs/Public/show_bug.cgi?id=17121#c2
https://www.w3.org/Bugs/Public/show_bug.cgi?id=17121#c5
https://www.w3.org/Bugs/Public/show_bug.cgi?id=17122#c1
https://www.w3.org/Bugs/Public/show_bug.cgi?id=15686#c2
fantasai: Those edits all look good to me
Anton: proposal to satisfy Rossen is
https://www.w3.org/Bugs/Public/show_bug.cgi?id=17121#c5
Anton: This was what was implied in the text before, now just explicitly
stating it
Rossen: Change sounds good to me
<stearns> looks good to me
RESOLVED: Accept edits listed above
Item B
Anton: We raised issue that there was no interop on whether overflow
affects the table wrapper box or the table box
Anton: Agreed to implement whatever is most widely implemented
https://www.w3.org/Bugs/Public/show_bug.cgi?id=17121#c5
<antonp> https://www.w3.org/Bugs/Public/show_bug.cgi?id=17505#c6
Anton: Answer was some UAs are using the table box (Gecko and Trident)
whereas WebKit and Opera 12 seem to apply to wrapper box but
are doing something weird
Anton: Which one resolve to?
fantasai: height applies to table box, so makes sense for overflow to
also apply to table box
dbaron: What values of overflow apply to the table box?
Anton: Didn't investigate that one. Personally tested overflow: hidden
Florian: We'll align with whatever sensible behavior we agree on
fantasai: Do we want to resolve that 'overflow' applies to the table box,
and later figure out whether 'overflow: scroll' applies?
dbaron: I'm reading the spec, and the spec says overflow doesn't apply
to tables
Anton: We have bugs on that, we know that is kind-of wrong.
Anton: In reality it does apply to tables, it's a question of which box
it applies to.
Anton: The formatting context edits will fix the Applies to line.
Anton: But first we have to resolve on is the table box or table wrapper box
Florian: Test results sound good enough reason to say apply to table box
Florian: Is anyone disagreeing?
Bert: Don't see how it would affect table
fantasai: could have a fixed-height div inside a cell, that has overflowing
content
Anton: Question is where do we truncate it, or where do we put the scroll bar
Bert: Isn't it easiest to say it doesn't apply?
glazou: I'm still not hearing any important change or removal on this issue...
glazou: Do we need more time?
dbaron: I'm trying to figure out why we do anything for overflow on tables
dbaron: I haven't found the code yet
dbaron: I'm concerned about saying that overflow applies to tables
dbaron: Not sure anyone applies values other than 'hidden' to tables
<sylvaing> +1
Anton: The spec used to say it applied to tables, but during the terminology
fixes, it accidentally got removed
Anton: Separate question of whether we want that or not
Florian: Not exactly excited for 'overflow: paged' applying to tables
dbaron: Found list of where we support 'overflow: hidden' but not other
overflow values --
dbaron: table, table cell, svg:svg, svg:foreignObject
Florian: Is anyone interested in other values on table?
Florian: Or should we just spec that only 'hidden' applies
glazou: suggest deferring to next week
Arronei offers to help Anton work on testcases
<stearns> antonp: I have a couple questions on your item [C] we didn't
get to today
<stearns> antonp: added my questions to
https://www.w3.org/Bugs/Public/show_bug.cgi?id=18346
CSS3 Text
---------
fantasai: Thinking about publishing WD soon
fantasai: Would like people to review
fantasai: Also thinking about splitting it, with text decoration parts
in separate module
fantasai: It's a very long module
szilles: where would parts common to both go?
fantasai: There aren't really any
Florian: I'm in favor of shorter modules, if you don't mind the overhead.
glazou: Everyone, please add agenda items to F2F wiki
Meeting closed.
Received on Thursday, 2 August 2012 22:47:24 UTC