- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Tue, 04 Feb 2014 01:15:55 -0800
- To: "www-style@w3.org" <www-style@w3.org>
Reversed Lists
--------------
- RESOLVED: keep counter-reset magic for <ol reversed> lists in level 3
Transforms
----------
- Discussed Simon Fraser's proposal for 'transform-style: auto' to make
transform flatting make more sense by default. Details will be posted
to www-style for discussion.
Display Module
--------------
- RESOLVED: Add fantasai's run-in model to Display Model, with
clarifications / fixes needed to solve bzbarsky's issues
http://lists.w3.org/Archives/Public/www-style/2012Jul/0450.html
- Discussed various clarifications that are needed in the spec.
- RESOLVED: FPWD Display Module
====== Full minutes below ======
Reversed Lists
--------------
tab: the lists module correctly handles HTML list rendering
tab: except for the reverse attribute which counts backwards
tab: if you look at the list module right now the style sheet resets
the counter to some magic thing so we can't express this
tab: so do we keep it magic or do we have a way to represent the number
of children of an element
<TabAtkins> http://dev.w3.org/csswg/css-lists/#ua-stylesheet
simonsapin: right now this is a non-normative stylesheet so we could
consider this magic for now
dbaron: i think we should address this eventually but this is not a
priority right now. and the way we do address it should not
just be some hack like counting the number of children
dbaron: though it's possible html defines it as...
simonsapin: html specifies to count the number of <li>
plinss: and does the display value impact the count?
fantasai: HTML has a preshint-level rule that sets counter-reset
on the list element to the number of <li> in the list
<SimonSapin> http://www.whatwg.org/specs/web-apps/current-work/multipage/grouping-content.html#attr-ol-reversed
<dbaron> it sounds like <ol reversed><li><li value="20"><li></ol>
gives 3, 20, 19, which isn't quite expected...
<dbaron> I'd rather have had a mechanism that gave 21, 20, 1
<fantasai> dbaron, that doesn't make any sense to me
<dbaron> reversed means "works the normal way but counts in the other
direction"
<glazou> it is expected because reversing a list is only setting
start a counter-increment: -1
RESOLVED: keep counter-reset magic for <ol reversed> lists in level 3
<fantasai> dbaron: hm, fair enough. I interpreted it as "count downwards",
which I suppose matches the attr name less
<fantasai> dbaron, I think counting downwards is easier to conceptualize
as counters, though
<SimonSapin> dbaron, I don’t think any behavior makes sense in that example
Transforms
----------
smfr: previously i tried to clarify a couple of areas
smfr: i would like to revise the current text slightly
smfr: there would be a small behavior change but current interop is good
smfr: 1) how preserve-3d works 2) what elements in the document cause
flattening to happen are the two topics
<shows testcase>
two elements with 3d transforms applied to them
no preserve-3d
two siblings
these elements intersect with each other but not their parent
smfr: today the spec says this is just a painting effect
smfr: in webkit we do support intersection. i would like this to be the
right behavior because it simplifies the explanation of preserve-3d
<next test>
smfr: in this new model, if you wanted to prevent intersection you would
need the parent to force flattening with transform-style:flat
smfr: the next question is when does a transformed element intersect with
its parent?
<shows test where preserve-3d is applied to the parent>
smfr: intersection is where there is little interop
ACTION smfr Share transform testcases with the group
<trackbot> Created ACTION-611
tab: so webkit make the siblings intersect in their own space then flatten
smfr: the spec currently explains it using '3d rendering context'
established by preserve-3d
smfr: it says such elements can intersect with each other based on
z-depth (not document z-index)
smfr: so sometimes elements are a 3d rendering context, otherwise
they're not
smfr: instead I'd like to say that every element is in a 3d rendering
context but sometimes it's only one element deep
smfr: similar to stacking contexts
dbaron: I thought I understood until we compared to stacking contexts...
smfr: today you're sometimes in a 3d rendering context, sometimes you're not
smfr: whereas with css contexts, all elements belong to a stacking context
dbaron: the default with stacking contexts is to not make a new one;
it sounds like with 3d rendering contexts the default would
be to make a new one?
smfr: I think I'm proposing to change that also
smfr: now I'm considering that transform-style:flat creates a 3d rendering
context
smfr: preserve-3d extends this context through the element
smfr: I'm proposing to transform-style: auto as an initial value instead
of the current 'flat'
smfr: if you have two elements with 3d transforms; parent has preserve-3d.
its ancestor is flat
smfr: the spec is ambiguous as to how/whether elements inserted above
those child elements can cause flattening
dbaron: the spec says this is containing-block based
smfr: right. so it wasn't clear whether stacking contexts or containing
blocks were involved
smfr: the reason for 'auto' makes the determination of 3d rendering
context unambiguous
smfr: some things cause flattening like opacity, filters….if an element
has a 2d or 3d transforms and transform-style:auto then it should
be flattened
dbaron: I'm trying to understand how this works with the various
z-ordering rules that require various things to interleave
dbaron: before this only things that established a stacking context
could be preserve-3d
dbaron: if you don't establish a stacking context things can interleave
dbaron: I'm not sure what this means in this new model
smfr: the spec would have to say that the root has transform-style:flat
smfr: in the new model, the root creates a 3d rendering context
smfr: ...
smfr: transform--style:flat establishes a 3d rendering context; you
render the 3d transform descendants, including intersections...
smfr: then you composite those above the untransformed parents...
dbaron: suppose the root has another child with a z-index
dbaron: so you flatten all the 3d stuff and render it with infinite
z-index in that stacking context?
smfr: I think so
smfr: when you have neg z-index, it renders behind…in this model,
3d descendants don't intersect with the plane of what creates
the 3d rendering context....
smfr: I don't think there is a way that z-index can trump the 3d
rendering contexts
dbaron: I agree
dbaron: it would be great to have a write-up of this
smfr: I have one in draft form, with test cases
dirk: this fixes a lot of issues we currently have in the spec
dbaron: I think the intersection of this with stacking contexts sounds OK
dbaron: what this means is that in the default case, if you specify a
3d transform on one thing in the doc and nothing else, then
this thing is above everything in the document
smfr: yes
dbaron: it seems kind of reasonable. but is it web compatible?
dbaron: I'd like to hear from our transform experts...
dbaron: I'm worried about compat but compat is also messy right now
in this area
smfr: I think this model helps explain perspective as well i.e. it
doesn't cross 3d rendering context boundaries
dirk: I agree we want more people to check out the proposal
dirk: over email
dbaron: yes
smfr: I will send the proposal to www-style
plinss: I'm a bit about the interaction with z-index...
plinss: could we rationalize the two models?
Bert wonders whether flattening is necessary
dbaron, smfr, dirk: a bunch of things require it
Bert: it is hard to explain transform-style
smfr: this will help explain it.
chris: you'll be able to say it's like stacking contexts!
ACTION smfr to send update to mailing list
<trackbot> Created ACTION-612
smfr: based on feedback I'll update the ED
smfr, dirk: no other issues to discuss
<krit> http://dev.w3.org/csswg/css-transforms/#issues-index
Display Module Revisited
------------------------
Scribe: fantasai
<TabAtkins> http://lists.w3.org/Archives/Public/www-style/2012Jul/0450.html
TabAtkins: Wanted to discuss fantasai's run-in model, and whether
to integrate it into Display module
TabAtkins summarizes the model
(see mail above)
foo <runin>bar</runin>
creates a block boundary between foo and bar
TabAtkins: It's a remarkably simple model, and solves every problem
we've had with run-ins, I believe.
* liam thinks the mail looks sane and helpful
fantasai: bz did raise some issues, but solveable by defining things
more precisely
dbaron: Any interesting things wrt placeholders inside run-in?
dbaron: The whether things run in is purely computable at box-tree
generation time? No layout effect at all?
TabAtkins: Yes
TabAtkins: Some box-tree mangling, but no layout
SteveZ: So inline, but create a new block if needed
TabAtkins: or merge into next block if needed
RESOLVED: Add fantasai's run-in model to Display Model, with
clarifications / fixes needed to solve bzbarsky's issues
TabAtkins: Also, I would like to publish FPWD
http://dev.w3.org/csswg/css-display-3/
SimonSapin: Where does run-in fit into this module?
TabAtkins: It's a display-outside value, like inline-level
SimonSapin: Doesn't affect display-inside?
TabAtkins: Not at all
dbaron asks for clarification on how the shorthand handles omitted values
ACTION TabAtkins clarify how omitted values are handled for display
shorthand (and other shorthands he might've forgotten
to handle)
<trackbot> Created ACTION-613
SimonSapin: What are longhands for 'display'?
fantasai: display-inside, display-outside, display-decoration
TabAtkins: Yes, need to specify that they get reset
dbaron: display shorthand should be more clear about what happens with
values listed twice
dbaron: e.g. flex is both a value for 'display' and also 'display-inside',
how is it interpreted
TabAtkins: Yes, I can be much clearer about that
florian: Does this model make sense for authors and others who don't
have a deep mental model of how this all works?
TabAtkins: The main motivation is to separate out display: none, the
rest is just making things easier
dbaron: I'm ok with publishing
RESOLVED: FPWD Display Module
SimonSapin: display-inside: auto;, says some cases element acts as normal.
Should also specify what is the computed value
<TabAtkins> (the computed value is still "auto")
<br type=lunch>
<smfr> hi leaverou!
<leaverou> hi smfr !!
<smfr> leaverou: we were talking about a 9-piece image function yday
<smfr> leaverou: not much support, and a call for use cases
<smfr> leaverou: so if you have use cases, could you share them somehow?
<leaverou> smfr: you mean for 9 slice scaling?
<ChrisL> call for use cases that aren't borders
<smfr> leaverou: right
<leaverou> hmm I think I've come across some, but can't remember them
off the top of my head right now :/
<smfr> main comment on things like button backgrounds was "why can't you
use user border image?"
<leaverou> what about masking?
<leaverou> like, if you were able to 9-slice-scale any image, you could
use it for masking too
<leaverou> which you can't flexibly do with border-image
<smfr> this came up in the context of masking
<smfr> do we remove mask-box in favor of some mythical future image
slicing function
<leaverou> that doesn't seem very wise when we already have implementations
of mask-box
<leaverou> we can always have the image slicing function in addition
<TabAtkins> leaverou: Main issue with using it for masking is that you
need the "outset" ability that border-image has, but that's
nonsense for normal images.
<TabAtkins> Because normal images don't extend outside of their bounds.
Received on Tuesday, 4 February 2014 09:16:25 UTC