169334 - reenable generated content for floated and positioned replaced elements

Status: RESOLVED INVALID

(Core :: CSS Parsing and Computation, defect, P4)

Description

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Depending on what the CSS WG decides, we might want to reenable generated
content for floated and positioned elements, which was removed by the fix for
bug 141054.  It would need to be more clearly defined how it should work,
though, either by saying that the :before and :after go around the placeholder
(which would be somewhat of a pain for us to implement), or by saying what
things such as 'height' and 'width' should mean (which would also be hard for us
to implement).

See also bug 137430 for one of the bugs related to implementing it by placing it
around the placeholder.

Comment 1

[Hixie (not reading bugmail)]

current CSS3 proposal is that replaced elements have no :before/:after.

Comment 2

[Sekundes]

any chance to fix it during 1.7 timeframe?

Comment 3

[Boris Zbarsky [:bzbarsky]]

Jiu, what exactly would constitute this being fixed?

Ian, even in normal flow?  That's not what CSS2.1 says (it claims that these
apply to elements and gives no restrictions) and not what browsers implement at
this point....  Unless you guys take action pretty quickly (and it may already
be too late) it'll be a de-facto standard to sorta-maybe-support generated
content on replaced elements, in ways that break as soon as you do anything
interesting with it.

Comment 4

[Hixie (not reading bugmail)]

Yes, even in flow: the 'content' property, if set to a url() that causes the
element to become a replaced element, would replace _all_ the contents of the
element, including the :before and :after contents.

However, I can see that it would be useful in certain cases for inline replaced
content to have :before and :after become siblings of the element... seems like
a slippery slope though. Also seems odd that you'd be inheriting from something
that you are supposed to be a sibling of.

Comment 5

[Boris Zbarsky [:bzbarsky]]

I know the arguments for _not_ doing it. The problem, as I said, is that UAs
_do_ do it and that authors expect it (thanks to the wonderful example in the
CSS2 spec, in no small part).

Comment 6

[Hixie (not reading bugmail)]

So what are you looking for me to say?

Comment 7

[Boris Zbarsky [:bzbarsky]]

I'll send some mail to www-style, I guess.  Sorry for mixing up fora.

Comment 8

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Attachment: remove generated content for all replaced elements (checked in to trunk, 2004-02-19 10:04 -0800)

Comment 9

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 141469 [details] [diff] [review]
remove generated content for all replaced elements (checked in to trunk, 2004-02-19 10:04 -0800)

Yeah, this would work.	r+sr=bzbarsky on the code, but I'd sorta like to figure
out the following things:

1)  What does khtml do?
2)  What does Opera do?
3)  What exactly is the plan with CSS3?  Ian's mail to www-style is not nearly
as sure as his comments here.

I'm getting a little tired of being jerked around by internally inconsistent
specs that can't make up their mind...

Comment 10

[Hixie (not reading bugmail)]

What I said here is totally consistent with what I said in www-style. I
specifically said in comment 1 above "the _current_ proposal". And that was
several months ago. And when I replied (comment 4), I pointed out that I was
aware that that proposal may need changes.

Look, I can't avoid "jerking you around" when things are still in draft stage.
CSS2.1 doesn't mention it because it hasn't been decided yet. CSS2 was full of
errors and that's what we've been spending the last few years trying to fix.

What spec is internally inconsistent? What spec keeps changing its mind?

Based on http://junkyard.damowmow.com/112, Opera converts an <img> which has
:before into an inline element then puts the image inside that inline and the
contents of the :before before the image inside the inline. We consider that a
low priority bug.

Comment 11

[Boris Zbarsky [:bzbarsky]]

The inconsistent spec is the latest edition of the CSS spec that's actually a
recommendation -- CSS2.  I know it's full of errors.  I'm also pretty much fed
up with anything related to CSS as a result of all the time wasted cleaning up
these errors now.

Sounds to me like Opera and Mozilla are interoperable on this stuff at the
moment, at least in the easy case.  So naturally, if we remove support for it,
given that CSS2.1 doesn't say either way, people will treat that as a bug.  Of
course Opera is in the same situation.  Unless we remove it together.

Comment 12

[Boris Zbarsky [:bzbarsky]]

Oh, what does Opera do if the image is display:block?  Or if it's
positioned/floated (as per this bug)?

Comment 13

[Hixie (not reading bugmail)]

> CSS2. I know it's full of errors. I'm also pretty much fed up with anything 
> related to CSS as a result of all the time wasted cleaning up these errors

You're not the only one having to deal with this.


> Oh, what does Opera do if the image is display:block?  Or if it's
> positioned/floated (as per this bug)?

For this demo: http://junkyard.damowmow.com/112
Opera does this: http://junkyard.damowmow.com/113


Incidentally, if authors expect this, them the CSS3 specs should probably give
it to them. I welcome implementation experience on how exactly it should work.
(When CSS3 Generated Content first came out, I got implementation feedback
saying that "we will never implement this", which is one of the reasons I am now
looking at alternative solutions.) How do you _want_ this to work? Does what I
described in www-style make sense, or is Opera's rendering better? Or is a fifth
option preferable to all of these?

Comment 14

[Hixie (not reading bugmail)]

(And Safari 1.1 doesn't put generated content on replaced elements at all.)

Comment 15

[Boris Zbarsky [:bzbarsky]]

> Opera does this: http://junkyard.damowmow.com/113

I see.  So it really makes the <img> not be a replaced element and sticks an
image inside... fun.

> Incidentally, if authors expect this, them the CSS3 specs should probably give
> it to them.

OK.  Note that authors only expect it because of the CSS2 example.  :(

> How do you _want_ this to work?

I don't.  ;)  In my opinion, generated content as described in the spec makes no
sense on replaced content and I see no way to make it make sense without total
wackiness like "some of the properties apply to the element's box and some apply
to some random box that we make up (which is what Opera, and to a lesser extent
Mozilla, seem to do)".  Of course we already have a similar situation with
tables.... (eg opacity on a table applies to the body and the caption but border
only applies to the body).  Note the hundreds of lines of code that have to deal
with this for tables, though.

> Does what I described in www-style make sense

Not to me, but not in the way you ask.  It relies on a far more in-depth
understanding of the CSS3 Generated Content model (and in particular of how
::outside works) than I have or am likely to gain any time in the next year.

Comment 16

[Hixie (not reading bugmail)]

> I see.  So it really makes the <img> not be a replaced element and sticks an
> image inside... fun.

That's what I said. ;-)


> I don't.  ;)  In my opinion, generated content as described in the spec makes 
> no sense on replaced content and I see no way to make it make sense without 
> total wackiness like "...". [...] Note the hundreds of lines of code that have
> to deal with this for tables, though.

Ok, so the Opera rendering is out. The version I suggested in www-style (much
closer to Mozilla's current rendering) seems to be easier then. Basically, I am
proposing that :before become siblings to the replaced content elements instead
of children of the replaced content elements. When the image is taken out of
flow, they would be left in the flow.

Comment 17

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

I'm going to say this is invalid unless a spec clearly says otherwise and says
how it should work.