Bug 267700 – <br> tags are incorrectly effected by *{position:absolute;}

• Status: RESOLVED
• Resolution: INVALID
• Component: Layout and Rendering

[[e-mail]]

Created attachment 469444 [details]
Screenshot of <br> being ignored as it's now absolute and on it's own layer essentially

As of updating to IPADOS 17.2 , when using *{position:absolute;} the <br> tag's display type, contrary to the behaviour of other browsers/previous versions of Safari, is now also changed to absolute.

I've had to use br{position:relative;} as a workaround; yet, as a line-break is usually the logical equivalent to \n, it's a little annoying.

[alan]

Thank you for reporting this issue.
This new behavior is considered a progression and it is inline with the CSS spec as discussed here https://github.com/w3c/csswg-drafts/issues/5749 (Firefox has been behaving like this for quite some time)

[[e-mail]]

(In reply to zalan from comment #1)
> Thank you for reporting this issue.
> This new behavior is considered a progression and it is inline with the CSS
> spec as discussed here https://github.com/w3c/csswg-drafts/issues/5749
> (Firefox has been behaving like this for quite some time)

Well, although I may not agree with the reasoning behind this new behaviour, I do appreciate you getting back to me.  

There needs to be a reliable analogue to \n, and it feels like someone didn't think this through.

It would be nice to see a usecase where this new behaviour makes sense? It is not a container element and cannot have children, and thus, logically, seems it is only meant to modify relatively.

But, again, thank you for letting me know/getting back to me.

[alan]

(In reply to [e-mail] from comment #2)
> (In reply to zalan from comment #1)
> > Thank you for reporting this issue.
> > This new behavior is considered a progression and it is inline with the CSS
> > spec as discussed here https://github.com/w3c/csswg-drafts/issues/5749
> > (Firefox has been behaving like this for quite some time)
> 
> Well, although I may not agree with the reasoning behind this new behaviour,
> I do appreciate you getting back to me.  
> 
> There needs to be a reliable analogue to \n, and it feels like someone
> didn't think this through.
> 
> It would be nice to see a usecase where this new behaviour makes sense? It
I don't think there's a such a use case. This change was carried out simply to align the implementation with the relevant CSS spec i.e. when an inline level element gains out-of-flow positioning, it should stop affecting the neighboring in-flow content. Whether having such forced line break makes sense, I am not sure. You could argue that instead of blockification we should apply inlinification (or rather ignore blockification) on forced line break inline level boxes and let them always be in-flow. If you feel strongly about it, you should open an issue at https://github.com/w3c/csswg-drafts/issues.
I am going to close this bug for now (works as expected).

[Radar WebKit Bug Importer]

<rdar://problem/121599131>