- From: Dael Jackson <daelcss@gmail.com>
- Date: Fri, 2 Jan 2015 09:52:53 -0500
- To: www-style@w3.org
Selectors 4
-----------
- RESOLVED: unprefix :dir and :lang
- The current goal with selectors 4 is to separate the unstable
bits out and put them in level 5 so that the spec can make its
way through CR.
Fragmentation
-------------
- The remaining issue of how to handle containers with no break
opportunity was agreed to be no data loss for all container
types.
- RESOLVED: Publish a new WD of Fragmentation and give 6 weeks for
feedback before CR
Transforms
----------
- smfr's proposal for a new "3D rendering context" concept and
Robert O'Callahan's counter-proposal were discussed with a
focus on the 'preserve-3D' property and how much memory would
need to be allocated for smfr's proposal.
- A point of particular concern was what the author's expectation
is for when 2D and 3D elements would intersect when the 3D
item is rotated.
- There was discussion of inheriting transform-style.
- Those interested in Transforms will look over smfr's results and
discuss further.
==== FULL MINUTES BELOW ======
Scribe: dael
Selectors 4
===========
dbaron: I stuck this on the agenda because I want to get to some
things. At some point we should stop adding features and
advance it?
fantasai: I think I want to trim it to the things that will go to
CR when I have time. Make a cut and put everything else
in level 5. But that was my goal last year, so I don't
know if it will happen this year.
fantasai: I would be happy to take a resolution that :dir should
be unprefixed.
glazou: So to do that, does the WG think it's stable enough to do
it and second are all implementors okay?
glazou: So objections to it being stable?
fantasai: :dir and :lang are quite stable, the syntax is obvious,
and it's well-defined and already implemented.
SimonSapin: Do you think the complex language matching is ready?
fantasai: We're just pointing to it. I think Microsoft implements
that.
glazou: There were bugs in browser implementations about :lang
where one rendering language wasn't parsing more than one
dash.
glazou: It was a bit back. Make sure it was fixed.
glazou: Second question, implementors, you okay with unprefixed
:dir?
RESOLVED: unprefix :dir and :lang
florian: Do we have a test suite?
fantasai: I think Mozilla does.
florian: It would be good to share so people who were prefixed get
it right.
<ArronEi> There are very few test cases
<ArronEi> I will put the selectors 4 on my list
<ArronEi> ... for more cases
glazou: Anything else on Selectors 4? Test suite? Very few cases,
can we have more?
fantasai: Mozilla implemented so I'm sure they have a bunch of
test cases. I'm not sure where.
dino: Has there ever been a proposal for an OM API to be able to
set a pseudo-class on something? Like if you want to set the
initial-letter on a div.
TabAtkins: That's a pseudo-element.
glazou: So astearns and I suggested an API a way to create
programmatical psuedo-elements. I'm not sure it got
consensus, but I think it should happen.
florian: On this topic it doesn't look like the test stash from
Opera will help. I went through the repo and they're
barely there.
glazou: It would be good to have more tests.
glazou: Anything else on Selectors 4 dbaron ?
dbaron: That's it. We have a bunch of JS scripts that would need
to be rewritten, but they're straightforward.
Fragmentation
=============
<astearns> issue in this section:
http://dev.w3.org/csswg/css-break/#possible-breaks
Rossen: fantasai and I spent time cleaning up. We think we figured
out the outstanding issues and cleaning up the language.
fantasai: There's one issue open, let me pull it up.
dbaron: What's the next level?
fantasai: I think we need to republish as a WD, ask for review, go
to CR
Unfragmentable Objects
----------------------
fantasai: We say that if you have something you can't fragment,
you can fragment anywhere.
fantasai: For example with inline blocks, there's no break
opportunity possible within a line box
fantasai: You have an inline block on a line box, it happens to be
1 1/2 pages. You can't fit it on one page. We have
language that says if you're printing and have a thing
that doesn't have breaks and will not fit, you can break
whereever you want so the content doesn't disappear.
fantasai: The issue was, do we want this for other fragmentainers
such as Regions and multi-column?
fantasai: The default is no data loss for printing. For regions
and multi-column you might be able to scroll to see it
another way, but it's probably easier from
implementations to only have one way to fragment so we
were thinking for this level we should be consistent.
fantasai: That was our proposal for closing this. Is there a
different perspective?
dbaron: I'm fine with it, though I don't think slightly different
printing rules is that big a deal.
astearns: We need something saying what happens with other
fragmentainers and the printing models is a good
starting default. If we need something else we can add.
florian: Given that the proposal is do what you need to to make it
fit, we can check again later.
florian: It gives room to play around.
fantasai: So we'll close as apply to all fragmentainers. I think
that's all the fragmentation issues. Anything else let
us know. We'd like a resolution to publish a new WD with
6 weeks for review and then publish CR
RESOLVED: Since unfragmentable elements must be sliced to avoid
dataloss when printing, this behavior applies to all
types of framentatation.
Feature Set
-----------
dbaron: What's in the draft for new features?
<dbaron> ... as opposed to just specifying things better?
fantasai: We added the break-before and break-after property. We
have new values for forced break: always and any. We have
added the recto/verso values.
fantasai: 'always' forces a break through all the levels, so if you
have a region in a pagination etc you break through all
the things.
fantasai: We also have some values for regions spec things in
addition to column and page spec. They're going to be at
risk because it depends on where the regions spec goes.
I think that's it for new features.
Floats and Fragmentation
------------------------
Bert: A float is a fragmentainer?
fantasai: It's not.
fantasai: Unless it's a region.
Bert: Yeah. I was wondering if it's a useful case to include
fantasai: Technically a line box is a fragmentainer, but we put it
out of scope.
Bert: I can imagine someone doing a three column layout and
wanting a break mid-float.
astearns: Unless there's somewhere else for the content to go.
Rossen: You can make a region inside a float.
Rossen: If you have a region inside your float, sure you can have
three floats and call your content through there. Then
you'd be fragment context in a region in a float.
Bert: So I can page break in a void, but I can't use page-break
for any inside a float. So it would break over two pages,
but I don't have full control as to where. I can suppress a
break, but not force a break.
Bert: Seems asymmetric. I can do that with a region, I assume, but
not a float.
Bert: Sounded like the extra keyword of any would do it.
Bert: I have to think more about that. I'm wondering why float
isn't a fragmentainer.
fantasai: Because it doesn't cause fragmentionation. A
fragmentainer is a page, column, or region
Rossen: It's what happens inside, not outside.
Bert: A page break can occur mid-float.
Rossen: It's the content inside a float
fantasai: If you force a page-break inside a float, the
fragmentainer what's important is the page, not the
float. You can do a page-break inside a float. We define
how that works, but the page isn't a fragmentainer, it's
a containing block.
Bert: The float has a flow.
Rossen: Just like a table cell.
fantasai: It doesn't make it a fragementainer, just a containing
block.
Bert: It would still be useful to indicate where in the float I
want to break it.
fantasai: Use page-break.
florian: You don't want floats to break across a page. That's not
what we're doing, you can't split the float in half
without splitting the page in half. Floats don't break
without being in the page.
Bert: If you break before always, any content after the float is
on the current page.
fantasai: The effect of the page-break is only on the parallel
flow.
Bert: So it is for a float. So fragmentainer isn't the word I was
looking for.
Bert: OKay. That's what I wanted.
fantasai: Alright.
Publication Plan
----------------
Rossen: Publish a WD of fragmentation and give 6 weeks for
feedback before CR?
<bkardell> +1
glazou: Objections?
RESOLVED: Publish a new WD of Fragmentation and give 6 weeks for
feedback before CR
glazou: I have to leave for the AC meeting.
plinss: Transforms next?
Transforms
==========
smfr: I recently updated the ED of transforms to contain new text
for the description rendering of 3D transforms
smfr: This section on transform rendering is rewritten.
smfr: The first part is 2D transforms which we're clear on. 3D is
the new part.
smfr: Initially it talks about perspective. 6.1.2 describes how 3D
transform elements are rendered, how they interweave and
intersect with non-transformed elements. This was unclear
before so this is making it good enough to implement.
florian: Was it unclear or unintentionally ambiguous?
smfr: Unclear. I added a 3D rendering context. Analogous to CSS
stacking. It's a set of elements inside of which the 3
transformed elements are altered and can intersect, but are
then flattened into a plane, just as stacking is flattened
smfr: The way I spec'ed it here I mirrored the behavior of
stacking context in that an element with z-index of -1 will
go behind the content and other descendants.
smfr: Let me show you pictures. This is on the wiki and I have a
link from transforms as the first issue.
<smfr> https://wiki.csswg.org/spec/intersection-of-transformed-and-untransformed-elements
smfr: If you look at the blue box and compare to pale blue box,
you'll see it's behind and that's the CSS2.1 order
smfr: Now an element with a negative z-translate will go behind
and a positive will go in front.
smfr: This is the rendering the spec property where the order is
the backgrounds and borders order. Where the z = 0 plane
it's the standard rendering. On top of that is the positive
translated content.
smfr: This is the ideal behavior that the spec describes.
smfr: A consequence is it's possible to intersect translated with
the untranslated element.
smfr: One of the issues is that this spec requires UA to basically
render the root at two planes so it can do intersections.
smfr: The problem is it could force UAs to allocate twice as much
memory for some elements, so I have some concerns, but it is
basically the ideal behavior.
smfr: On the ML Robert O'Callahan proposed an alternative where
translate z-1 is on top and if you rotate it wouldn't
intersect. It's a bit more special case, but would allow
browsers not to allocate twice as much memory.
smfr: One consequence is what happens...let me go back to the spec
smfr: The issue we described is issue 3.
smfr: There's more subtle ones about UA implementation details and
if you intersect z=0 planes sometimes.
smfr: krit asked if this is flattening. In the spec we have 3
values for the transform-style property.
smfr: There's a new 'auto' which is the default. It means ignore
this for the purpose of computing 3D
smfr: 'flat' is make it flattening and it's a 3D rendering context
ancestor.
smfr: 'preserve-3D' is the special one where We allow descendants
to live in the same 3D space.
smfr: So the default is auto which lets them live in the same
space and maybe intersect.
smfr: There's things that required flattening, like clipping,
opacity. But default transform and perspective also cause
flattening. With transforms people want to build a 3D
hierarchy. If an element has a transform the author can
override the flattening.
smfr: The role of transform-style is controlling if transforms in
perspective cause flattening. The root flattens by default
which is simple.
smfr: The previous had wording as to if elements belongs to 3D
context, now it says every element belongs, like stacking.
smfr: The main issue to discuss is the one I showed you because
that influences...before I can write test cases
smfr: Robert proposed the second.
krit: What's the reasoning?
smfr: Be efficient for UA.
vollick: So it's possible to have a bunch of 3D sorting at the
same time.
smfr: You do it in the 3D rendering context you belong to. It has
access to 3D rendering context. That happens no matter which
model.
smfr: One impact of Robert's model is position:fixed won't
intersect 3D transformed items. So a position:fixed would be
like it's in the z=0 frame. I think that's a downside of
this model.
smfr: It would be possible to have a combination, it's not
impossible, it just is in some configurations.
MaRakow: Can you talk about how the new values would be used. If I
have an item with preserve-3D?
smfr: That was a mis-nomer. Preserve prevents flatting, not
creates it. They would probably set preserve-3D to flat,
though that would likely be the default. It's only used if
you want to override the default.
MaRakow: So every element would have auto except the root of the
scene?
smfr: Preserve-3D would only be used on transformed elements that
want to live in the same 3D space.
MaRakow: I'm trying to figure out how it's different from
inheritance.
smfr: It's been suggested transform should inherit. I didn't do
that because it would cause flattening in places we don't.
MaRakow: What's an example?
smfr: webkit if you have a perspective element and then a div, in
most cases transform respects perspective.
MaRakow: Is the middle div already transform-style: flat?
smfr: It's more like auto.
smfr: I think we may be willing to make it inherited. It
simplifies it.
MaRakow: That seems like a more existing concept as opposed to the
children behavior.
MaRakow: Going back to z-index, I think the negative z-index would
be a pain point.
smfr: So you favor Robert's behavior?
krit: There's interoperability for that.
smfr: It has weaknesses. If it had a 2D transform it wouldn't
interweave with a 3D. The spec would have to have special
language saying it pops to the front. We would have to
actively prevent interweaving.
MaRakow: The 3D rendering context is gone?
smfr: It's there, but morphed into an example.
MaRakow: Because they're in the same 3D rendering context you have
to have the 3D?
smfr: In this example everything is in the same context. I guess
the natural is by mirroring the left, but the one on the
right is Robert's, where anything with 3D pops to the front.
I think it's weird because anything that's 2D isn't part of
that set of depth
plinss: Also if you're 3D into the z-plane you'd expect it to be
behind. I accept it's easier to implement, but is it
rational? Does it give the expected behavior?
MaRakow: What seems odd to me is the scenario between the text and
background where it's splitting.
smfr: But you have to implement that.
MaRakow: I wouldn't say we enjoy that.
florian: TabAtkins, any thoughts from google?
vollick: I have a preference to the proposal from smfr.
krit: That proposal is more what users would expect if they
understand z-index.
smfr: We may have to do implementation experiments and come back.
krit: So does he object to your model?
smfr: He agreed with my comment where it would force implementors
to output more memory.
smfr: Maybe implementations can be smart and know if they won't
intersect.
smfr: I guess with animations it's hard.
MaRakow: Does this do that much if everything is in the same 3D
rendering context?
smfr: It's hard to know compatibility risk because implementations
are different. For webkit I intend to only do this for un-
prefixed, but other browsers don't have that luxury.
krit: We created a lot of tests to observe behavior and for many
tests, each browser was completely different. Current
behaviors can't align.
MaRakow: Previous design was such that it required you to declare
here's where the content is. I'm hesitant to give that
aspect up because it makes it easier to think of 3D and
makes it more backage.
smfr: It's easy in the current but existing content might have
issues. Making transform-style inherit might solve those.
MaRakow: In the new model you might have to wrap in a container
div.
smfr: The perspective property calls it flatting too so you end up
with three contexts. I don't think compatibility risk is too
bad.
MaRakow: I'd like to explore inheritance more.
smfr: Okay.
smfr: Other feedback?
Bert: It's complex. I've given tutorials, but perspective is weird.
What I never succeed at explaining is transform-style. You
try it and it doesn't work the expected way.
smfr: That's because existing implementation isn't consistent. The
new spec is more specific and the scope is limited.
Bert: Why do I need it?
smfr: Hierarchies of elements with 3D elements. You often do
siblings and you don't need transform style. If you want a
descendant of a face of a cube to have its own transform you
need it.
smfr: If you think of it like CSS Stacking, a transform is like
z-index: 0 - it causes flattening, but you can override with
preserve-3D.
Bert: So if you take a cube and then make it rotate, the cube
disappears.
smfr: You'd want preserve-3D on the container. There's subtlety,
it's about making an element not flatten. It allows its
descendants to share the 3D space it lives in.
smfr: There's a lot of content about preserve-3D for perspective,
but you only need it on descendants.
smfr: You don't need preserve-3D on the root of a 3d scene.
plinss: If I have a minor component and I want it to participate
and it has a random ancestor, I need to set the preserve
on the ancestor, not the child. I get technically why, but
as an author you may want the other way around.
smfr: We have the opacity property that forces stacking because
the way it's spec'ed. You enter the descendants opaquely.
Preserve-3D is render with the opacity and then combine. We
don't have that for opacity, but that's the equivalent.
plinss: That's the way it should have worked, but the other way is
cheaper.
MaRakow: From the author perspective, I think they're used to it
being 2D and when you're in 3D you're asking to flatten
at a certain point.
smfr: In the new approach, sibling transforms will intersect. I
think it's the correct behavior. It's a change, but I found
it hard to write text to formalize the other behavior.
MaRakow: I think that's true for members of the same scene from an
author perspective. I think it makes sense for those to
intersect.
MaRakow: What's weirder is the cases where they intend to isolate
and it happens to be that it's near other content that
they thought of as 2D, but now it intersects.
smfr: So you're concerned about intersection with?
MaRakow: I think the author doesn't think of the non-3D section
being part of the transform.
smfr: So you'd prefer the second?
MaRakow: I think they should be capable of intersecting, but
that's not the default expectation.
smfr: I think the choice between the two of if you get depth
sorting by default, the pro is it's more like z-index and
more consistent of a default, but it's more resource
requiring and may have unexpected intersections. Also 2D
transforms don't interact in the same way as 3D.
smfr: In our implementation some descendant with something special
will start intersecting and we'll have to turn it off in a
funny way.
MaRakow: I don't have a strong opinion, but if the feedback is
"I'm not sure which", I think we should avoid the
intersection.
smfr: I think the feedback will go away.
smfr: Other comments?
krit: In this case you spec on the container itself. I think I
would expect it to intersect the text by default.
plinss: It seems like a reasonable default. I think you should let
the author opt, but it makes sense.
smfr: I think flippers and stuff will still work as expected.
krit: You're unsure if an author thinks it's better to have
intersection?
MaRakow: I think the main thing is as an author I don't expect
everything in my page to participate in 3D.
krit: In this case?
MaRakow: I'm not sure. I have to go figure out.
smfr: We've seen people put perspective on the body, but mostly
they want a 3D scene.
MaRakow: It's hard to think about it in terms of test cases
because I'm not sure about more active applications. Have
you guys implemented this?
smfr: I've done part. The transform-style: auto value, but not the
intersection.
MaRakow: Did you get feedback?
smfr: Great.
plinss: So are you looking for a resolution?
smfr: Looking for implementor and author feedback.
krit: MaRakow, do you want to look at it again?
MaRakow: Sure. I'd like to see what your results are.
plinss: More transforms?
plinss: Everything else folks wanted in the afternoon.
plinss: What about animations?
Rossen: sylvaing wanted that.
smfr: I think we wanted to do that at 3pm.
fantasai: Text?
Received on Friday, 2 January 2015 14:53:21 UTC