Closed Bug 66585 Opened 24 years ago Closed 21 years ago

"\A" escape sequence in the 'content' property doesn't render as newline.

Categories

(Core :: CSS Parsing and Computation, defect)

x86
All
defect
Not set
normal

Tracking

()

RESOLVED DUPLICATE of bug 17646
mozilla0.9.5

People

(Reporter: val, Assigned: pierre)

References

Details

(Keywords: css2, testcase)

Attachments

(3 files)

From Bugzilla Helper:
User-Agent: Mozilla/4.6 [en-gb]C-CCK-MCD NetscapeOnline.co.uk  (Win98; I)
BuildID:    2001012020

'A string cannot directly contain a newline. To include a newline in a string, 
use the escape "\A" (hexadecimal A is the line feed character in Unicode, but 
represents the generic notion of "newline" in CSS). See the 'content' property 
for an example.' (CSS2 4.3.10 Strings)

However, the "\A" escape sequence in the 'content' property of the :before and 
:after pseudo-elements seems to be ignored.


Reproducible: Always
Steps to Reproduce:
The attachment contains the example style from CSS2 12.2 The 'content' property:

H1:before {
      display: block;
      text-align: center;
      content: "chapter\A hoofdstuk\A chapitre"
}

with HTML:

<H1>Heading...</H1>


Actual Results:  Notice that the 'content' is rendered with the words "chapter", 
"hoofdstuk" and "chapitre" all on the same line.


Expected Results:  They should appear on consecutive lines.
Wouldn't you need to also set white-space:pre to get things like \A to render?  I 

think \A puts a newline character in the text, but after that the text is laid 

out the way any text with a newline would be and the whitespace (including 

newlines) is collapsed into just spaces.

QA Contact: chrisd → ian
That certainly works, but note what CSS2 section 12.2 (The 'content' property) 
says:

"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."

Surely that means it shouldn't be treated as collapsible whitespace.
Val, you are quite right (the referenced section of the spec is
http://www.w3.org/TR/REC-CSS2/generate.html#content).  I am seeing the problem
on Linux build 2001-01-29-06, so os->all and status->new.

Adding some keywords.
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Windows 98 → All
does this implies that in CSS2 content is always white-space:pre ? Or is it
:before and :after that has white-space:pre by default?
Currently, white-space doesn't apply to :before and :after, but it is assumed
that white-space: pre has been applied. I have proposed that this be changed in
the CSS3 spec so that white-space applies.

We could fix this bug by adding

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

...to html.css, but I'm not sure if we want to.
It can't be fixed that way because:
- whitespace characters other than '\A' would be affected too (spaces, tabs...)
- '\A' characters in generated content should not be affected by the 'white-
space' property (http://www.w3.org/TR/REC-CSS2/text.html#propdef-white-space)
Like I said, there is a proposal on the table that would change this.
Whiteboard: WG
With the current spec, we can collapse spaces and still generate newlines in the 
generated content as if we had a <br>.  I don't know whether the WG will give up 
this feature.

Marc, Ian: please review.
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla1.0
Attached patch patch 1.0Splinter Review
Attached file testcase 1.0
I think this would introduce a weird new behavior only because someone writing
the spec didn't say exactly what they meant to say.  I think we should discuss
this in the WG before changing our behavior.
The spec is very clear, both in:
  http://www.w3.org/TR/REC-CSS2/text.html#propdef-white-space
and:
  http://www.w3.org/TR/REC-CSS2/generate.html#content

The issue was debated in the WG last year and Bert and Hakon didn't seem inclined 
at all to change the meaning of "\a" in generated content.  It gives a simple 
definition of BR and allows to do things that would not be possible otherwise 
(see testcase 1.0).
  http://lists.w3.org/Archives/Member/w3c-css-wg/2000JulSep/0083.html
  http://lists.w3.org/Archives/Member/w3c-css-wg/2000JulSep/0082.html
and
  http://lists.w3.org/Archives/Member/w3c-css-wg/2000OctDec/0175.html

Ian's proposal covered 3 points:
1) should white-space apply to all elements, inline and block?
2) should white-space apply to generated content?
3) should newline characters collapse in generated content?

#1 was more or less agreed on. 
#2 is what the spec says already, including exceptions related to newlines in 
generated content. 
#3 was refused by the other folks, do you want to bring it back on the table?
Oh, never mind then.  I just hate to see ugly hacks like this go in just because
the spec defines things in a way that's difficult to implement simply.
> With the current spec, we can collapse spaces and still generate newlines in 
> the generated content as if we had a <br>.  I don't know whether the WG will 
> give up this feature.

They won't need to, since the same proposal (and others) introduce new keywords
to the 'white-space' property, in particular one which does exactly what you
describe.


> please review.

I am strongly against fixing this until we have a consensus from the working 
group. The proposal I have mentioned had the strong backing of other WG members
and I think it would be unfortunate for us to change our behaviour at a time
where an existing implementation may be used as proof of concept.

If you really want to fix this, I would suggest fixing two birds with one stone
(as it were) by introducing a new keyword for 'white-space', say for instance 
'-moz-collapse-nowrap', which would be the behaviour described in CSS2 for
generated content. That way at least we don't remove functionality, and we pave
the way to easily implementing the feature in CSS3 if and when it is accepted.
I have no opinion in particular except, as a general rule, that we can't always 
wait for CSS3 to be finalized before implementing CSS2.  I simply looked at the 
responses from the 2 editors of the CSS2 spec who were standing behind what was 
published and these were the last messages on that topic, 9 months ago.  In the 
meanwhile, the property was confirmed in its current description as part the 
Mobile profile and the only other mentions of evolution for CSS3 that I found 
were to split the functionality into 3 or 4 additional properties (white-space-
treatment, white-space-collapse, etc...).  If you want to propose a new keyword 
for the current property, please go ahead, we certainly can wait a bit more.  
Keep in mind however that it might not fit with what was debated more recently, 
and that the discussions I'm referring too are 2 months old and seemed far from 
beeing over.  Overall, it was for me a case of "better fix it now than later".
Target Milestone: mozilla1.0 → Future
3 comments :

  1. the spec is as it is and we can't bet on an hypothetical change done on
     an hypothetical date. Pierre has a patch for support for "\A" in content
     property that fills a gap in our CSS 2 support. That's not
     hypothetical at all.

  2. I need basic "\A" support for AllTags mode in Composer and I need it _now_.
     Typically, the test case attached by Pierre should be rendered as expected. 

  3. if you want to see what web authors do with such a feature, you'd better
     give them... I mean that w/o users' feedback, it might be hard to ever get
     something correct.
Maybe we can give Ian a few days (let's say next Monday) to see if the WG likes 
the idea of changing the behavior of white-space in generated content.  Given the 
responses last year and the new orientations this year, I doubt there will be an 
agreement but if some folks want to do so, it is now or never because there isn't 
any implementation yet, afaik.

His other suggestion is an additional keyword that describes the current behavior 
of white-space in generated content. Note, though, that this behavior cannot be 
described with just one additional keyword, we need two: "normal-with-newlines" 
and "nowrap-with-newlines".

Three choices here...
- If the WG accepts to change the behavior, the fix is potentially very simple (1 
line in html.css).
- If the WG accepts to extend the current property and add 2 keywords, we do it.
- If the discussion goes towards defining 3 or 4 new properties, we check in the 
attached patch and wait until things settle down.
It seems another member of the working group has issues with 'white-space', as
the subject has been added to the F2F agenda without me having to say anything.
Whiteboard: WG → WG (Seattle F2F)
It's a good thing.  Try with Daniel to come back from the meeting with decisions 
or clear orientations so we don't block the Editor guys much longer.

The minutes that mention the new properties are here (members only, sorry)
 http://lists.w3.org/Archives/Member/w3c-css-wg/2001AprJun/0191.html
(Note, BTW, that Michel recently sent an updated proposal to the w3c-css-wg list
regarding the white-space stuff in CSS3's test module.)
*** Bug 98906 has been marked as a duplicate of this bug. ***
Marc/DBaron: can I checkin my "patch 1.0" which, even though ugly as sin, has the 
merit to be standard-compliant, to unblock the editor and to fix this bug and the 
one that was marked dup?  And then I'll open a new bug to implement Michel's 
proposal once it's finalized.
Target Milestone: Future → mozilla0.9.5
This was discussed at the F2F and an errata has been (or will be) added saying
that 'white-space' applies to all elements, including ::before and ::after.

Ergo, this bug is not INVALID. Marking as such.
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → INVALID
Whiteboard: WG (Seattle F2F)
Verified invalid.  I made sure white-space:pre is honored within :before content.
Status: RESOLVED → VERIFIED
er. s/not INVALID/now INVALID/. Sorry about that.
.
Status: VERIFIED → REOPENED
Resolution: INVALID → ---
.

*** This bug has been marked as a duplicate of 17646 ***
Status: REOPENED → RESOLVED
Closed: 23 years ago21 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.