- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Wed, 20 Jun 2012 13:59:56 -0700
- To: "www-style@w3.org" <www-style@w3.org>
Summary:
- RESOLVED: Proposed edits to CSS2.1 accepted pending dbaron's review
and acceptance:
http://wiki.csswg.org/topics/overflow-formatting-context
- RESOLVED: order affects painting order
- Discussed handling of replaced elements as flex items; fantasai
to summarize discussion for resolution next week
http://wiki.csswg.org/topics/css3-flexbox-flexbox-replaced-children
- Discussed how to handle background-attachment: fixed; in transformed
elements; vendors to investigate their implementations
- RESOLVED: add recto/verso values to (page-)break-before/after in css3-break
====== Full minutes below ======
Present:
Rossen Atanassov
David Baron (late)
Arron Eicholz
Elika Etemad
Simon Fraser
Sylvain Galineau
Daniel Glazman
Koji Ishii
John Jansen
Brad Kemper
Peter Linss
Divya Manian
Alex Mogilevsky
Anton Prowse
Florian Rivoal
Dirk Schulze
<RRSAgent> logging to http://www.w3.org/2012/06/20-css-irc
Scribe: fantasai
Administrative
--------------
plinss: additions to agenda?
smfr: transforms and fixed backgrounds
florian: at bottom of agenda, leftovers from f2f, some have been
addressed and should be removed
fantasai: an issue on counter style case-sensitivity
CSS2.1
------
http://wiki.csswg.org/topics/overflow-formatting-context
plinss: everyone had an action item to review this
antonp: So, this is an issue about introducing a new term "formatting
context" which will cover things like BFC but also be used to
cover things like "flexbox FC" and "table FC"
<glazou> #antonp { speech-rate: slower; }
antonp: It came up in the Flexbox spec, because its children are not
formatted as blocks
antonp: Realized it would be useful to have a term simply "formatting
context"
* sylvaing once again, antonp makes me question whether digital really
is faster than analog
antonp: would solve problem in specs currently, e.g. for overflow it
should apply to a wider class of items than just block formatting
contexts
antonp: similar issue with containing block
antonp: answer here is an element that establishes a formatting context,
not just a block formatting context
antonp: this also speaks to some bugs we have on 2.1
antonp: related to the fact that currently we have problems with
definitions of overflow and containing block because they do
forget to handle tables
antonp: These edits would fix those bugs and give us a nice editorial
hook for future specs
florian: after reading what was written and listening to what was said,
I think the logic makes sense
florian: I don't feel comfortable enough that I know enough details
to be sure this all works
florian: I therefore hesitate to vote for it
fantasai: I think these edits are correct (I wrote some of them).
Would like to hear from dbaron too though
arronei: I think these changes are fine, but wondering why we're editing
2.1 here
arronei: 2.1 isn't completely clear here, but it's not obviously wrong
arronei: why not just start a CSS3 spec
fantasai: Our current specs depend on 2.1 right now, not on non-existent
or early-draft specs
plinss: I'm also concerned about editing 2.1, but also see the problem
with not having equivalent text in level 3
proposal - resolve pending dbaron's approval
Rossen: Is this going to have any changes to the behavior of tables?
Or is it just editorial?
antonp: When there was a lot of rewriting of blocks and boxes and things,
there were some thing that were broken as part of that
antonp: e.g. overflow used to apply to tables, but doesn't as a result
of that
antonp: basically the edit there is taking the spec back to what it was
supposed to be saying
antonp: we can fix those two bugs by being very explicit, and just say
exactly which boxes are affected
antonp: but the primary motivation for using this term is that CSS3 specs
need to use it
antonp: since it's useful to 2.1 and 3, better to make these edits
Rossen: just concerned about introducing any implementation changes to 2.1
sylvaing: the question is, do we need to change testcases. If yes, then
we need to take a closer look at this
sylvaing: If there are testcases, should be part of the proposal
antonp: I believe there are testcases, part of the reason these bugs were
filed was because they didn't match the testcases
<sylvaing> bringing the spec in line with the test suite is fine imo
http://test.csswg.org/shepherd/testcase/overflow-applies-to-013/
RESOLVED: Proposal accepted pending dbaron's review and acceptance
Flexbox
-------
fantasai: First issue is, does the order property have an effect on the
z-order/ painting order
fantasai: do you follow document order when painting, or do you follow
the order-modified order
alexmog: also tab-order
fantasai: that's a separate question
fantasai: tab-order and speech order affect a11y. Probably order shouldn't
affect speech order; part of the point is to affect the visual
order without affecting the logical order used for linear
rendering
smfr: From implementation perspective, would prefer if flex order didn't
affect painting order
alexmog: I think these are related, if we make tab-order change, then
z-order should also change
alexmog: from accessibility pov, whole point of changing order is that
you don't change your tree, you only change little bit in cells,
it looks like the order is different
alexmog: tab dialogs, one item's bring to front
alexmog: you still read stuff in original source order
smfr: if you have flex order affect painting order, the author puts in
z-index, what happens?
smfr: what stacking context are you using to paint the flex items
smfr: can items interleave with flex items
fantasai: z-index still works as usual
fantasai: but if z-index has same number or auto, you use document order
fantasai: question is, does 'order' affect the document order fallback
for painting, or do you just you straight-up document order
alexmog: the last time we discussed this, a couple years ago, we concluded
at that point that reordering is a major enough change that
everything looks as if it really was in a different order, and
it makes sense to actually render in this new order
+dbaron
alexmog: nobody could come up with use cases where it's important to
preserve source order for painting
alexmog: if there is any overlap of items, if it is ever intentional,
painting order that matches order in flexbox would make sense
fantasai: IIRC, webkit prefers painting order to be affected; for Mozilla,
we can go either way, but I think simplifies our implementation
somewhat
alexmog: IE reorders by order, and it does simplify implementation
smfr: if webkit impl is ok with it, then fine with me
antonp: [...]
antonp: if you make 3-column layout, you probably want each column to be
stacking context anyway, would use z-index anyway
florian: I think I'm hearing most people wanting painting order following
order
plinss: Yes, though I'm hearing some concerns about tab-order
fantasai would like to tackle that as a separate issue, since it affects
other things
Rossen: do we have a similar thing for grid?
alexmog: Discussed in grid, in grid there is no order, everything is
explicitly placed into its slot
alexmog: no sequence in grid, so not applicable there
alexmog: if at some point order is universally applicable, then it should
be treated same way wherever it's applicable
plinss: proposal is for order to affect painting order. Any objections?
RESOLVED: order affects painting order
http://wiki.csswg.org/topics/css3-flexbox-flexbox-replaced-children
http://www.w3.org/TR/2012/WD-css3-flexbox-20120612/#flex-items
fantasai: Current spec text goes with Proposal A, based on Hamburg
discussions
fantasai: proposal A can be recast in terms of proposal B at a later point
alexmog: I would prefer to revert to the old wording
alexmog: Someone said it's a problem with replaced elements vs. non-replaced
elements having different styling during loading
alexmog: whatever browser does this cannot pass Acid2
...
florian: for me that's not the motivation
florian: we're doing this because these elements have the wrong display
type
florian: for other things the user can change the display type to whatever
they want
florian: Proposal B lets you opt out
fantasai clarifies that Alex is asking for previous WD's behavior, not A vs B
dbaron: what happens if an element is replaced due to CSS3 'content'
property?
alexmog: the same (follow the rules for whether 'width' and 'height' apply)
florian: I like proposal B best
florian: I would not like to be stuck with Proposal A forever
florian: what Alex is saying sounds suboptimal to me but is acceptable
alexmog: I can live with any of those, just seems inconsistent that
replaced inline elements have special behavior that's already
defined an known
alexmog: and object fallback depends on those
fantasai: One complication here is that Mozilla falls back to inline
when <img> elements don't load, but some other browsers treat
them as inline-block
fantasai: whereas I believe some other impls don't
fantasai: so you'll get different results
some questions on what is the correct behavior
<dbaron> I don't see anything in html5 saying img should be anything
other than display:inline when there's no resource
<dbaron> same for canvas
antonp: I think it make sense for these elements to have special behavior
plinss: have 3 proposals on table, not hearing consensus
florian: To me Proposal A is only acceptable because we can later switch
to B
florian: To me it doesn't make sense to have A in the list because what
I want is B
fantasai: I think I'd like to summarize the situation and resolve when
Tab's back
fantasai: Anything else to add to summary?
florian: Does anyone disagree that B is better than A
antonp: I think A should be followed by B, but not sure it should be
instantly
florian: concerned that we might be stuck with A if it takes too long
to do B
fantasai: don't think we'll get stuck with A, B just has A implemented
as ua.css rules
fantasai: Have a bigger problem that might get stuck with flex items
returning 'display: block' and can't change to returning
'display: flex-item'
alexmog: if A or B, would rather do B
alexmog: yet another thing to do would be to treat any element that is
a direct child of flexbox as a flex items
alexmog: from all use cases we have, anonymous text in flexbox is not
a use case
alexmog: just do something to not lose content when it's there
alexmog: could just have any element, e.g. <b> or <i>, be a flex item
alexmog: you'd get weird results if you have formatted text in a flexbox,
but that's not a use case
ACTION: fantasai summarize discussion
Background Attachment and Transforms
------------------------------------
<plinss> https://www.w3.org/Bugs/Public/show_bug.cgi?id=17521
<smfr> http://www.w3.org/TR/css3-transforms/
smfr: In CSS transforms spec there's a sentence that says
smfr: [quotes spec]
smfr: and there's a note that this behaves like a porthole -- you see
the background through the porthole
smfr: this kindof makes sense for 2D transforms, but for 3D it's
extremely hard to implement
smfr: Making that element behave like a porthole where you see an
untransformed background
<smfr> https://www.w3.org/Bugs/Public/show_bug.cgi?id=17521
smfr: one possible amendment to the spec would be to say that
background-attached: fixed affected by transform is treated
like scroll
fantasai: Would it make sense to have the fixed background be transformed
with the rest of the element? Rather than just ignoring fixedness
florian: would make sense, why would you do that as an author?
smfr: Your suggestion is tricky because how you render that background
before applying that transformed
smfr: so, you render the element as if screen-aligned, then transform
smfr: not sure what left/top offset you'd use
smfr: when you scroll page you'll have this shifting of that background
krit: background should transform with the element
smfr: dbaron gave us some history, that bg-attach fixed was only intended
for the root element.
smfr: sortof crept into applying to other elements
smfr: any other implementers with feedback? IE?
<dbaron> I'm sure Gecko does something, but I don't know what, and it's
hard to work out what's hard off the top of my head.
arronei: Not sure, have to look that up and check
florian: I don't know for Opera
smfr: maybe get action items from other vendors to investigate
florian: from our POV, probably too early to tell
sylvaing: pretty sure we don't do porthole thing, but I'll check what we do
krit: are there test files?
ACTION: smfr make a testcase
<trackbot> Created ACTION-477
ACTION: florian ask Opera wrt background-attachment:fixed and transforms
<trackbot> Created ACTION-478
ACTION: dbaron check Gecko wrt background-attachment:fixed and transforms
<trackbot> Created ACTION-479
ACTION: sylvaing check wrt background-attachment:fixed and transforms
<trackbot> Created ACTION-480
plinss: should also give some thought to what the right thing to do is
bradk: Sounds like if the bg was large enough, and coordinates ok,
could have portal effect look good
deferred to next week
page-break: recto/verso
-----------------------
fantasai summarizes
http://lists.w3.org/Archives/Public/www-style/2012Jun/0443.html
glazou: These will be easy to understand in Europe
plinss: these are industry standard terms going back ages
http://en.wikipedia.org/wiki/Recto_and_verso
florian: sounds good to me
RESOLVED: add recto/verso values to (page-)break-before/after
in css3-break
Meeting closed.
Received on Wednesday, 20 June 2012 21:00:28 UTC