Re: Implementation of Inset Box Shadow on image elements

Brian Manthos wrote:
>
> That's a pretty fundamental change.

So was Brad's proposal to alter border-image, but we took it
because it was a really good idea.

Note that while the rest of the features in the module have gone
to CR, 'box-shadow' is in its first Last Call for Comments phase.
It is an appropriate time for Divya to be bringing this up.

> Unless I'm misremembering, this would be the first instance of
> "render on top of content" for the any of the terms in the module
> {border, background, border-image, box-shadow}.
>
> Do you really want to open up that can of worms *now*?

I'm thinking we might.

> Off the top...
> - all existing implementations are rendered non-interoperable
>   with spec-based implementations

True. This is why we have prefixes until things go to CR.

> - are the border geometries still relevant when we're talking
>   about nested child content?

Nothing should change wrt geometry.

> - what happens with absolutely positioned children?

See z-index. Otherwise no effect.

> - should it react to text flow (/orientation) of the content?

The same way as before. No changes.

> - how does z-index come into play?

As I mentioned, it should be painted immediately below z-index: 1,
so that authors can pop things out of the shadow with 'z-index'.

> - do we need to create a new stacking context?

No.

> - what do we do about blurry text in the box-shadow region?

The text isn't blurry, the shadow is.

> If you really want this capability, you need a new property --
> "content-overshadow" -- likely in a different "adornments on
> top of the content of an element" module if you want it done
> right.

I don't think that is necessary.

~fantasai

Received on Tuesday, 27 July 2010 19:36:29 UTC