- From: Simon Fraser <smfr@me.com>
- Date: Mon, 11 Apr 2011 12:04:41 -0700
- To: Alan Gresley <alan@css-class.com>
- Cc: fantasai <fantasai.lists@inkedblade.net>, Boris Zbarsky <bzbarsky@mit.edu>, Andrew Fedoniouk <news@terrainformatica.com>, Andrew Fedoniouk <andrew.fedoniouk@live.com>, www-style list <www-style@w3.org>
On Apr 11, 2011, at 11:36 AM, Alan Gresley wrote: > On 12/04/2011 3:36 AM, fantasai wrote: >> On 04/11/2011 08:54 AM, Simon Fraser wrote: >>> >>> My proposal is to not have z-index applied to transformed elements. > > > Please bare in mind that there are two things. The first is a 'stacking context' (some referred to as a stacking or painting layer) [1] and the second is a 'z-index or new stacking context' with a value that is not 'auto' [2]. Here are some details. > > > | <integer> > | This integer is the stack level of the generated box in the > | current stacking context. The box also establishes a new > | stacking context. > > > | auto > | The stack level of the generated box in the current stacking > | context is '0'. The box does not establish a new stacking > | context unless it is the root element. I am aware of stacking level vs. stacking context. My proposal is to make transforms behave like opacity: they create stacking context, but the z-index property does not apply to them (unless they are also positioned). > > >>> I'll work >>> with Ted to propose some new wording for the spec. >> >> If you apply "position: relative" to the element, will z-index then apply? >> >> ~fantasai > > > Opera, IE9 and Firefox are already painting the transforms as if they already had 'position relative' in respect to painting layer. If transforms cause a default behavior of 'position relative' then this would establish a new containing block. Do we want this? > > This is similar to the issue we faced a few years ago with box-shadow and text-shadow. Source order alone (normal painting behavior) was adopted as the spec for box-shadow and text-shadow. I think that we should step wisely with this. > > Here is a test case that shows how transforms are painted above a float when transitioning. Before and after the transition has taken place, the float is painted higher. > > > http://css-class.com/test/temp/transform-transition-painting.htm This testcase has the same behavior in WebKit and Firefox now, so I'm not sure what the problem is. It has the same behavior if you add opacity on the hover state; this is just normal painting order stuff. Simon
Received on Monday, 11 April 2011 19:05:11 UTC