Closed
Bug 534071
Opened 15 years ago
Closed 15 years ago
CR ( ) is rendered as a new line
Categories
(Core :: Layout, defect, P2)
Core
Layout
Tracking
()
RESOLVED
FIXED
Tracking | Status | |
---|---|---|
blocking2.0 | --- | final+ |
People
(Reporter: egil, Assigned: hsivonen)
References
()
Details
Attachments
(3 files)
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; pl; rv:1.9.1.5) Gecko/20091102 Firefox/3.5.5 (.NET CLR 3.5.30729)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; pl; rv:1.9.1.5) Gecko/20091102 Firefox/3.5.5 (.NET CLR 3.5.30729)
There is a bug in rendering of HTML documents made from XML through XSL transform. This seems to happen because of new lines added as entities. I add those entities to have nicely formatted HTML output.
Reproducible: Always
Steps to Reproduce:
1.Create XSL for XML
2.Add table with <xsl:text> </xsl:text> inside a table
3.view XML in browser
Actual Results:
New line character adds extra vertical space.
Expected Results:
new line character shouldn't change the rendering (just chagne output XHTML)
Saved output renders correctly.
Comment 1•15 years ago
|
||
Is it adding a full extra new line as in Bug 197075?
Reporter | ||
Comment 2•15 years ago
|
||
(In reply to comment #1)
> Is it adding a full extra new line as in Bug 197075?
It does add an extra new line, but this is not the same. PREs should preserve whitespace characters, TABLEs should not.
The url shows you an example:
http://enux.pl/download/tmp/testxml/test.xml
Correct rendering would be:
http://enux.pl/download/tmp/testxml/test.html
(note test.html is exactly what is produced with XSL transform from test.xml)
Comment 3•15 years ago
|
||
Adding xhtml keyword.
The only difference I see is xml version is loaded in standards mode and the html version loads in quirks mode.
Keywords: xhtml
Reporter | ||
Comment 4•15 years ago
|
||
Standards mode is irrelevant. See:
http://enux.pl/download/tmp/testxml/test.xhtml
Comment 5•15 years ago
|
||
This isn't limited to XHTML, the HTML5 parser exposes the same behavior.
Status: UNCONFIRMED → NEW
Component: General → Layout
Ever confirmed: true
Keywords: xhtml
OS: Windows XP → All
Product: Firefox → Core
QA Contact: general → layout
Hardware: x86 → All
Summary: Bug in rendering (X)HTML document with XSL that contains new lines → CR ( ) is rendered as a new line
Version: unspecified → Trunk
Comment 6•15 years ago
|
||
Comment 7•15 years ago
|
||
This seems like correct behavior per http://www.w3.org/TR/CSS21/text.html#white-space-model (in particular, nothing in there says anything about transforming CR into space, and then the CR should be rendered.
If you think the behavior should be different in spite of you sticking technically invalid characters into the DOM (which is supposed to use LF throughout for newlines), please post a spec change suggestion describing your proposed change to www-style@w3.org.
Comment 8•15 years ago
|
||
And what about this one? I think the rule
> 1. Each tab (U+0009), carriage return (U+000D), or space (U+0020) character
> surrounding a linefeed (U+000A) character is removed if 'white-space' is
> set to 'normal', 'nowrap', or 'pre-line'.
applies here.
The spec also claims
> The CSS 'white-space' processing model assumes all newlines have been
> normalized to line feeds.
but I'm not sure if that's supposed to be normative.
(I do agree that it's silly to stick CRs in the DOM, though.)
Comment 9•15 years ago
|
||
> And what about this one? I think the rule
That applies for your second testcase, not the first one.
> but I'm not sure if that's supposed to be normative.
It is, yes. Generally, the only way to stick a CR into the DOM is to try really hard to put it in there.
Reporter | ||
Comment 10•15 years ago
|
||
(In reply to comment #7)
> This seems like correct behavior per
> http://www.w3.org/TR/CSS21/text.html#white-space-model (in particular, nothing
> in there says anything about transforming CR into space, and then the CR should
> be rendered.
First of all - this a CSS spec, XHTML spec refers to the XML spec which says:
"To simplify the tasks of applications, the XML processor MUST behave as if it normalized all line breaks in external parsed entities (including the document entity) on input, before parsing, by translating both the two-character sequence #xD #xA and any #xD that is not followed by #xA to a single #xA character." (see http://www.w3.org/TR/xml/#sec-line-ends)
And this should clarify that both of the characters MUST be treated identically and so Gecko seems to be a single engine that doesn't conform to the specification in this area.
Reporter | ||
Comment 11•15 years ago
|
||
To add to the above see white space definition and a note here:
http://www.w3.org/TR/xml/#sec-common-syn
Comment 12•15 years ago
|
||
We do perform newline normalization in various cases. I seem to recall that it's very purposefully NOT done for , but I'm not enough of an XML spec-lawyer to tell you why. I bet Henri is, though!
Assignee | ||
Comment 13•15 years ago
|
||
(In reply to comment #12)
> We do perform newline normalization in various cases. I seem to recall that
> it's very purposefully NOT done for , but I'm not enough of an XML
> spec-lawyer to tell you why. I bet Henri is, though!
http://www.w3.org/TR/xml/#AVNormalize step 3. first bullet point adds character references to the normalized value without further processing. Note that the usual XML line break normalization (http://www.w3.org/TR/xml/#sec-line-ends) has taken place before character references are expanded.
So it is correct behavior that in XML (even in attributes) puts a CR in the DOM.
(In reply to comment #9)
> > but I'm not sure if that's supposed to be normative.
>
> It is, yes. Generally, the only way to stick a CR into the DOM is to try
> really hard to put it in there.
Surely CSS needs to define the rendering of CR if it is possible to put a CR in the DOM even if it is hard.
Considering that http://www.w3.org/TR/CSS21/text.html#white-space-model step #1 mentions CR, I find it very odd that neither step #3 nor step #4 substep #1 mention CR.
Assignee | ||
Comment 14•15 years ago
|
||
See also attachment 438430 [details] from bug 557197.
Assignee | ||
Comment 15•15 years ago
|
||
I'll post to www-style about this.
Assignee: nobody → hsivonen
Status: NEW → ASSIGNED
Assignee | ||
Comment 16•15 years ago
|
||
Comment on attachment 444639 [details] [diff] [review]
Potential fix
In case the CSS WG's response doesn't make it in time for beta, does this approach look like something that could be landed? Or should CR be made more LF-like? Or something yet different?
Attachment #444639 -
Flags: feedback?(bzbarsky)
Assignee | ||
Updated•15 years ago
|
Priority: -- → P2
Assignee | ||
Comment 18•15 years ago
|
||
fantasai, can you guess what the probable outcome on this issue might be in the CSS WG or when the CSS WG might address this?
Assignee | ||
Updated•15 years ago
|
Attachment #444639 -
Flags: feedback?(bzbarsky) → review?(bzbarsky)
Updated•15 years ago
|
Attachment #444639 -
Flags: review?(bzbarsky) → review?(roc)
Comment 19•15 years ago
|
||
Comment on attachment 444639 [details] [diff] [review]
Potential fix
This is more roc's kettle of fish.
Comment on attachment 444639 [details] [diff] [review]
Potential fix
code looks OK. But it depends on what the WG says.
Attachment #444639 -
Flags: review?(roc) → review+
Comment 21•15 years ago
|
||
The probable outcome, if there is consistency among implementations, is to make the spec match what implementations do. If there is no consistency among implementations, then... I don't know. Btw, please tag subject lines with the spec (as described in the spec's Status section) when posting to www-style in the future.
Assignee | ||
Comment 22•15 years ago
|
||
Landed as http://hg.mozilla.org/mozilla-central/rev/3c4932e0058b to get a 1.9.3 blocker addressed.
Bug 565035 is needed as a follow-up. I'll also follow up to the WG.
Status: ASSIGNED → RESOLVED
Closed: 15 years ago
Flags: in-testsuite?
Resolution: --- → FIXED
Reporter | ||
Comment 23•15 years ago
|
||
(In reply to comment #21)
> The probable outcome, if there is consistency among implementations, is to make
> the spec match what implementations do. If there is no consistency among
> implementations, then... I don't know...
Latest Opera and Chrome/Safari displays this page as expected:
http://enux.pl/download/tmp/testxml/test.xml
I can check IE9 preview tomorrow if you are interested.
You need to log in
before you can comment on or make changes to this bug.
Description
•