300242 - Shouldn't it be possible to use position: absolute and position: fixed with ::before and ::after?

Status: RESOLVED DUPLICATE of bug 238072

(Core :: Layout: Positioned, defect)

Description

[lightsolphoenix]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.8) Gecko/20050511 Firefox/1.0.4
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.8) Gecko/20050511 Firefox/1.0+

I noticed that some other browsers (Opera and Safari) have no problems with
this, and double-checking the CSS 2.1 specification, there isn't any specific
wording against this.  In fact, CSS 2.1's spec says that ::before and ::after
are supposed to be treated like span tags in their parent element, which
suggests that giving the parent position: relative and ::before and ::after
position: absolute should cause it to work, just like if you were to make two
span tags position: absolute.

I checked it in both Firefox 1.0.4 and Deer Park Alpha (DP is closer, but it
still compresses the image incorrectly for some reason).

Reproducible: Always

Steps to Reproduce:
1.  Open Firefox.
2.  Surf to http://www.howtocreate.co.uk/wrongWithIE/eightpointbox.html .
3.  Note that the box is broken there; the CSS simply makes use of position:
absolute on ::before and ::after.

Actual Results:  
In Firefox 1.0, the ::before and ::after elements are actually expanded in size.
 In Deer Park, the elements aren't expanded, but they aren't treated correctly
either.

Expected Results:  
The software should have treated ::before and ::after as if they were span tags
and positioned them with respect to their parent tag, the p tag in this case.

Comment 1

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

It was prohibited in earlier versions of the specification.

I think this is a duplicate, but I couldn't find it quickly.

Comment 2

[Erik Fabert]

*** This bug has been marked as a duplicate of 238072 ***

Comment 3

[zug_treno]

(In reply to comment #1)
> It was prohibited in earlier versions of the specification.
> 
> I think this is a duplicate, but I couldn't find it quickly.

Maybe related to bug 227669 comment 1?