Closed Bug 17646 Opened 25 years ago Closed 21 years ago

"\A" in generated content does not break lines

Categories

(Core :: Layout, defect, P3)

Product:
Core
Component:
Layout
Platform:
x86
Windows 98
Type:
defect

Tracking

()

Status:
RESOLVED INVALID

People

(Reporter: ian, Assigned: troy)

References

(
URL
)

Details

(Keywords: css2, Whiteboard: semi-compliant CSS2 fix suggested (py8ieh:awaiting CSS3 draft / WG)) 

The "\00000A" character (line feed) in CSS generated content should cause
a line break in the rendering, regardless of the value of white-space.

For example:

   span:before { content: "Hello \A World"; }

   <p> Well <span> People </p>

...should render as:

   Well Hello
   World People

...but currently renders all on one line.

See section 16.6 of the CSS2 spec, where keywords for 'white-space' are defined:

# normal
#     This value directs user agents to collapse sequences of whitespace, and
#     break lines as necessary to fill line boxes. Additional line breaks may
#     be created by occurrences of "\A" in generated content (e.g., for the
#     BR element in HTML).

Simple test case:
   http://www.bath.ac.uk/%7Epy8ieh/internet/projects/mozilla/gcnewline.html

Complex test case: See the first test of the "special content" section of:
   http://www.bath.ac.uk/%7Epy8ieh/internet/eviltests/content/1.html
Status: NEW → RESOLVED
Closed: 25 years ago
Resolution: --- → WONTFIX
I would have marked it INVALID, but then you would have reopened it and then I
would have closed it again marking it INVALID :-)

Peter and I went explicitly went over this. Even though the spec doesn't say so,
you need to mark it as preformatted. You can mark the :before rule itself so
there's no impact on any other elements

Peter's rational for this, and I agree, is that \a has no effect in regular text
unless it's preformatted so why should generated content be different?

If we were to implement what you ask for we would have to force the text to be
preformatted anyway. Either that or change the text frame code to know about
this special behavior and that seems wrong
Whiteboard: semi-compliant fix suggested
Troy -- the spec doesn't "not say so", it actually says the _exact_opposite_!

It specifically says, as I quoted above, that "additional line breaks may be
created by occurrences of "\A" in generated content" when 'white-space' is
set to 'normal'.

This is repeated again in section 12.2:
# Authors may include newlines in the generated content by writing the "\A"
# escape sequence in one of the strings after the 'content' property. This
# inserts a forced line break, similar to the BR element in HTML.

An easy fix for this would be to add the following to ua.css:

   *:before, *:after { white-space: pre; }

...except that this would result in sequences of white-space not being
collapsed. At the very least you should do this.

A better solution would be to introduce an additional value for 'white-space',
namely '-moz-collapse-whitespace' or somesuch, which collapses white-space like
with 'normal' but honours line breaks like with 'pre'. This is effectively the
exact behaviour that the spec wants. You could then say:

   *:before, *:after { white-space: -moz-collapse-whitespace; }

...which would be spec compliant except for when some dufus (like, say, me with
my webstandards project hat on) sets 'white-space' explicitly to 'normal'...

I'll let you reopen it... ;-)
I know what the spec says. Peter's opinion was that the spec is wrong and
inconsistent with how \n is treated elsewhere.

We will not change ua.css to automatically make :before and :after preformatted.

And I'm opposed to adding yet another white space option. We already have a moz
wrap formatted option that leads performatted text wrap. The block and text code
is already way too confusing

The spec needs to be clarified to indicate the \a only works if the :before or
:after says it is preformatted
QA Contact: petersen → chrisd
Troy: Well, I'll let you try to convice the WG.

David: You mentioned that you were keeping a list for the Samurai review.
If you are still doing this, this would be one thing to add to it...
Ian - my list hasn't been touched since June.  I suspect it's mostly useless
now.  Why don't you start another one?

I think the messy issues in this bug all derive from the many ambiguities about
whitespace in the processing of markup.  I've never been happy about whitespace
issues in general, and I don't think it's possible to comply with any standard
without breaking compliance with another, because nobody understands what's
supposed to happen...
Peter and I convinced the W3 style committee that it's busted the way it is
now. There will not be an errata update for CSS2, but the CSS3 spec will clarify
it so that it states that \A only has an effect if it is preformatted text or
the new (to CSS3) style for preformatted wrapped text
Status: RESOLVED → VERIFIED
Assume from comments, this is a WONTFIX. Verifying as so. Please reopen if I am
incorrect.
Whiteboard: semi-compliant fix suggested → semi-compliant CSS2 fix suggested (py8ieh:awaiting CSS3 draft)
Okiedokie. I'll wait for the CSS3 "Generated content, numbering and lists"
draft before complaining again. ;-)
Keywords: css2
Migrating from {css2} to css2 keyword. The {css1}, {css2}, {css3} and {css-moz}
radars should now be considered deprecated in favour of keywords.
I am *really* sorry about the spam...
Whiteboard: semi-compliant CSS2 fix suggested (py8ieh:awaiting CSS3 draft) → semi-compliant CSS2 fix suggested (py8ieh:awaiting CSS3 draft / WG)
*** Bug 56956 has been marked as a duplicate of this bug. ***
*** Bug 113358 has been marked as a duplicate of this bug. ***
*** Bug 168333 has been marked as a duplicate of this bug. ***
*** Bug 66585 has been marked as a duplicate of this bug. ***
*** Bug 225884 has been marked as a duplicate of this bug. ***
Per CSS 2.1, this is actually INVALID, not WONTFIX...
Status: VERIFIED → REOPENED
Resolution: WONTFIX → ---
->INVALID
Status: REOPENED → RESOLVED
Closed: 25 years ago → 21 years ago
Resolution: --- → INVALID
*** Bug 225781 has been marked as a duplicate of this bug. ***
Summary: {css2} "\A" in generated content does not break lines → "\A" in generated content does not break lines
*** Bug 235552 has been marked as a duplicate of this bug. ***
*** Bug 250420 has been marked as a duplicate of this bug. ***
*** Bug 251834 has been marked as a duplicate of this bug. ***
You need to log in before you can comment on or make changes to this bug.