W3C home > Mailing lists > Public > www-style@w3.org > December 2014

RE: [css-transforms] Publish new WD?

From: Matt Rakow <marakow@microsoft.com>
Date: Wed, 3 Dec 2014 01:19:43 +0000
To: Dirk Schulze <dschulze@adobe.com>, w3c-css-wg <w3c-css-wg@w3.org>, www-style list <www-style@w3.org>
Message-ID: <BLUPR03MB135AFD98360A36799393E1FAD7B0@BLUPR03MB135.namprd03.prod.outlook.com>
Hi Dirk,

I reviewed your latest edits in more detail.  A few high-level points of feedback and then some minor details.

I'm glad to see a more detailed description of 3D Rendering Contexts, but the proposed definition is extremely difficult to understand as worded.  I think that for the most part the intent is to simply define the Webkit/Blink behavior (where untransformed elements that don't set a transform-style don't interrupt a 3d rendering context), but otherwise leave behavior unchanged as compared to the previous version.  Is that a correct interpretation of the intent of this edit?  If so, I'm also worried that this has unintentionally introduced a behavior change that sibling "preserve-3d" elements with a "flat" parent will now intermingle (as illustrated by Example 7).  We should avoid this behavior change, since existing content considers the uppermost element with "preserve-3d" to be the isolated root of the scene, not its parent with "flat".  This behavior is already interoperable across implementations.

Regardless of behavior, I think we should re-word this passage.  For example, the initial statement sounds counterintuitive on its face: "A 3D rendering context is established by an element which has a used value for transform-style of "flat"."  There are also some terms that should be defined explicitly, including "grouping" and "flattening".  As I mentioned at TPAC I also think this method of describing the functionality is counterintuitive to web developers, who think in terms of "here's the subtree with my 3d content" rather than "here's the node where we can safely render into an intermediate texture".  I'm happy to spend some time on a proposal for language here.

I'd also like to continue the discussion regarding inheritance vs. a new "auto" value.  I'll consider some more examples per Simon's most recent mail and get back to you.

With regards to the new rendering algorithm, I'm opposed to splitting the content from the border and background (A and B in your algorithm).  Even though it aligns with the behavior specified for stacking contexts and z-index, I don't consider that behavior desirable from either an implementor or web developer perspective.  Aside from the memory cost, I'd wager that 99% of web developers who use negative z-index today aren't trying to position an element between the background and content.  My preference is to render the backgrounds, border, box decorations, as well as the content and untransformed descendents into a single plane at z=0, allowing it to fully intersect with other transformed content.

A few minor (I think) notes:
6.1.2 -- example 7 -- the HTML of this example doesn't include the lorem text.  Can you please add it in explicitly?  I also think it's missing a width/height definition on the div elements.
6.1.2 -- typo "suppling" should be "supplying"
6.1.4 -- As currently written, the second iteration of the loop will have current element == ancestor block, resulting in incorrect behavior when it reaches step #4.2.  I think this is fixed by striking step #3, and move step #4.4 to the beginning of the loop.

My preference would be to hold off on publishing a new draft until we can at least:
-Resolve the behavior change for sibling "preserve-3d" elements
-Clarify the wording for 3d rendering context
-Close on the issue of whether non-transformed content can be intersected independently of the background/border


-----Original Message-----
From: Dirk Schulze [mailto:dschulze@adobe.com] 
Sent: Tuesday, November 25, 2014 12:05 AM
To: w3c-css-wg; www-style list
Subject: [css-transforms] Publish new WD?


I think a new WD for CSS Transforms is overdue. The last publication was a year ago and we have had a lot of spec fixes and a new CSS property 'transform-box' since then. The only part that may be controversial are the changes to 'transform-style'[1]. We did not get to a conclusion about the changes at the last F2F.

Does someone object to publishing a new WD?


[1] http://dev.w3.org/csswg/css-transforms/#transform-style-property
Received on Wednesday, 3 December 2014 01:20:15 UTC

This archive was generated by hypermail 2.4.0 : Monday, 23 January 2023 02:14:46 UTC