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)
Tracking
()
mozilla0.9.5
People
(Reporter: val, Assigned: pierre)
References
Details
(Keywords: css2, testcase)
Attachments
(3 files)
351 bytes,
text/html
|
Details | |
3.44 KB,
patch
|
Details | Diff | Splinter Review | |
456 bytes,
text/html
|
Details |
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.
Comment 2•24 years ago
|
||
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.
Comment 4•24 years ago
|
||
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?
Comment 6•23 years ago
|
||
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.
Assignee | ||
Comment 7•23 years ago
|
||
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)
Comment 8•23 years ago
|
||
Like I said, there is a proposal on the table that would change this.
Whiteboard: WG
Assignee | ||
Comment 9•23 years ago
|
||
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
Assignee | ||
Comment 10•23 years ago
|
||
Assignee | ||
Comment 11•23 years ago
|
||
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.
Assignee | ||
Comment 13•23 years ago
|
||
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.
Comment 15•23 years ago
|
||
> 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.
Assignee | ||
Comment 16•23 years ago
|
||
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.
Assignee | ||
Comment 18•23 years ago
|
||
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.
Comment 19•23 years ago
|
||
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)
Assignee | ||
Comment 20•23 years ago
|
||
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
Comment 21•23 years ago
|
||
(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.)
Comment 22•23 years ago
|
||
*** Bug 98906 has been marked as a duplicate of this bug. ***
Assignee | ||
Comment 23•23 years ago
|
||
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
Comment 24•23 years ago
|
||
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)
Assignee | ||
Comment 25•23 years ago
|
||
Verified invalid. I made sure white-space:pre is honored within :before content.
Status: RESOLVED → VERIFIED
Comment 26•23 years ago
|
||
er. s/not INVALID/now INVALID/. Sorry about that.
Comment 28•21 years ago
|
||
. *** This bug has been marked as a duplicate of 17646 ***
Status: REOPENED → RESOLVED
Closed: 23 years ago → 21 years ago
Resolution: --- → DUPLICATE
You need to log in
before you can comment on or make changes to this bug.
Description
•