Closed Bug 61675 Opened 24 years ago Closed 13 years ago

Can't link XML document to embedded stylesheet (Support <?xml-stylesheet href="#local" type="text/css" ?>)

Categories

(Core :: CSS Parsing and Computation, enhancement, P5)

Product:
Core
Component:
CSS Parsing and Computation
Type:
enhancement

Tracking

()

Status:
RESOLVED WONTFIX

People

(Reporter: drapeau, Unassigned)

References

Details

(Keywords: qawanted, Whiteboard: [Hixie-PF])

Attachments

(2 files, 1 obsolete file)

real testcase
571 bytes, text/xml
Details
One more (test case)
807 bytes, text/xml
Details
Quoting from a bug report I got from Allan Jacobs of Sun. The bug report below includes two test cases. The first line of an in-line CSS style sheet is ignored by Netscape 6. Here is a test case: Use NS 6 to display the following XML and all is well. <?xml-stylesheet type="text/css" href="#docstyle"?> <!-- MidnightRain.xml --> <document> <style id="docstyle"> junk {display:none;} style {display:none;} head {display:block;} title {display:block;font-size:24pt;} author {display:block;font-size:18pt;} email {display:none;} body {display:block;font-size:10pt;} note {display:block;} para {display:block;font-size:11pt;} document {background-color:white;} </style> <head> <title>Midnight Rain</title> <author>Kurt Cagle</author> <email>cagle@olywa.net</email> </head> <body> <note>From the first chapter of Midnight Rain, by Kurt Cagle</note> <para>The rain spat against the apartment's window pane, torrential cwfor this part of Los Angeles, though Gina would not have much noticed it at home. The rain straddled the boundary between being the life blessing touch that this valley so seldom received and the caustic depressed state that lately so made up her soul.</para> <para>"Rain, Rain, Go Away ..." she sang listlessly, though as she doodled over the script that Stan had sent, Gina secretly relished the rain, as indulgent as the black mood she wore around herself.</para> </body> </document> Remove the line junk {display:none;} from the <style> node. Redisplay. The <style> block will now be visible. It should not be visible. Change the style node to <style id="docstyle"> document {background-color:white;} style {display:none;} head {display:block;} title {display:block;font-size:24pt;} author {display:block;font-size:18pt;} email {display:none;} body {display:block;font-size:10pt;} note {display:block;} para {display:block;font-size:11pt;} junk {display:none;} </style> and redisplay. The background color will be gray, even though it should be white. The first line of an in-line CSS style sheet is ignored by Netscape 6. Here is a test case: Use NS 6 to display the following XML and all is well. <?xml-stylesheet type="text/css" href="#docstyle"?> <!-- MidnightRain.xml --> <document> <style id="docstyle"> junk {display:none;} style {display:none;} head {display:block;} title {display:block;font-size:24pt;} author {display:block;font-size:18pt;} email {display:none;} body {display:block;font-size:10pt;} note {display:block;} para {display:block;font-size:11pt;} document {background-color:white;} </style> <head> <title>Midnight Rain</title> <author>Kurt Cagle</author> <email>cagle@olywa.net</email> </head> <body> <note>From the first chapter of Midnight Rain, by Kurt Cagle</note> <para>The rain spat against the apartment's window pane, torrential cwfor this part of Los Angeles, though Gina would not have much noticed it at home. The rain straddled the boundary between being the life blessing touch that this valley so seldom received and the caustic depressed state that lately so made up her soul.</para> <para>"Rain, Rain, Go Away ..." she sang listlessly, though as she doodled over the script that Stan had sent, Gina secretly relished the rain, as indulgent as the black mood she wore around herself.</para> </body> </document> Remove the line junk {display:none;} from the <style> node. Redisplay. The <style> block will now be visible. It should not be visible. Change the style node to <style id="docstyle"> document {background-color:white;} style {display:none;} head {display:block;} title {display:block;font-size:24pt;} author {display:block;font-size:18pt;} email {display:none;} body {display:block;font-size:10pt;} note {display:block;} para {display:block;font-size:11pt;} junk {display:none;} </style> and redisplay. The background color will be gray, even though it should be white
Netscape's standard compliance QA team reorganised itself once again, so taking remaining non-tables style bugs. Sorry about the spam. I tried to get this done directly at the database level, but apparently that is "not easy because of the shadow db", "plus it screws up the audit trail", so no can do...
QA Contact: chrisd → ian
The problem is that we don't support associating embedded stylesheets to XML documents through a fragment identifier in the URI (see the second "NOTE" in http://www.w3.org/TR/xml-stylesheet). In the testcases above, the following line causes the entire XML document to be passed to the CSS parser. <?xml-stylesheet type="text/css" href="#docstyle"?> Then the parser does what it can to find parsable rules and it causes it to miss the first declaration (which is the correct behavior per CSS specifications). Changed summary line from "First line of an inline style sheet is ignored" to "Can't link XML document to embedded stylesheet". Reassigned to Parser, but maybe it should go to XML.
Assignee: pierre → harishd
Component: Style System → Parser
QA Contact: ian → moied
Summary: First line of an inline style sheet is ignored → Can't link XML document to embedded stylesheet
-> XML There are easy workarounds: use inline XHTML style (no need for the xml-stylesheet PI) or external style. Will attach a workaround example using XHTML style. Futuring.
Component: Parser → XML
Priority: P3 → --
Whiteboard: [have workaround]
Target Milestone: --- → Future
heikki: this is not a complete workaround as it does not allow you to embed several stylesheets, define them as default/alternate or enable/disable them, all within a single document.
... but note that I don't contest the Future milestone. The feature is not supported by IE either, AFAICT, and there is still the possibility to link external stylesheets.
Looks like this bug was fixed as part of the work done in bug 70882. Embedded stylesheets now work, although you need to use the XHTML namespace for the style element in order to activate the id attribute. The issue of multiple and/or alternate stylesheets appears to be covered in bug 126841.
Attached file real testcase —
This is not yet fixed. It works in XHTML because the style element is applied anyway, regardless of the PI or id.
What happens if the target element contains other elements? :-)
Oh, bz? :-)
Assignee: harishd → bzbarsky
Component: XML → Style System
OS: Solaris → All
QA Contact: moied → ian
Hardware: Sun → All
Summary: Can't link XML document to embedded stylesheet → Can't link XML document to embedded stylesheet (Support <?xml-stylesheet href="#local" type="text/css" ?>)
Whiteboard: [have workaround] → [Hixie-PF] [have workaround]
*** Bug 193924 has been marked as a duplicate of this bug. ***
Sigh. Copying comments from bug 193924: We _could_ add support for this via the XML sink; it'd have to notice such PIs and stash them away or something and then when the element with the matching ID comes along it could kick off the sheet load.... It'd mean sheets suddenly loading after part of your document has loaded, of course, but I suppose that's what you want if you're doing this fragment business. More interestingly, the example being cited (at http://www.w3.org/Style/styling-XML#Embedded when I wrote the comment, but it applies equally to every single example in this bug) is totally broken because the sheet is not inside a CDATA section and will thus get parsed into real text nodes (and worse yet, '<' and '>' chars in it will be parsed as tags and such). I have a gut feeling that as currently presented this behavior is a really bad idea, and I will not implement anything along these lines unless I get convinced otherwise. So if you want this please come up with technical answers to comment 9 and this comment.
Priority: -- → P5
Whiteboard: [Hixie-PF] [have workaround] → [Hixie-PF] [have workaround] WONTFIX?
What standard describes this behavior?
None, that I have found. There is a very vague informative note at http://www.w3.org/Style/styling-XML#Embedded
It is defined in: http://www.w3.org/TR/xml-stylesheet/ ...specifically: # NOTE: Since the value of the href attribute is a URI reference, it may be a # relative URI and it may contain a fragment identifier. In particular the URI # reference may contain only a fragment identifier. Such a URI reference is a # reference to a part of the document containing the xml-stylesheet processing # instruction (see [RFC2396]). The consequence is that the xml-stylesheet # processing instruction allows style sheets to be embedded in the same document # as the xml-stylesheet processing instruction.
So if I have: <?xml-stylesheet type="text/css" href="foo.xml#bar"?> Then the UA is supposed to load foo.xml, parse it as _XML_ and then feed the contents of the element with ID "bar" to the CSS parser?
Attached file One more (test case) —
The spec says that if the 'href' contains only fragment identifier this should be embedded style data. When there is specified 'href="foo.xml#bar"' there could not be told which type the "foo.xml" file is without querying it but if it is only a fragment identifier it is already known this is a XML document and what exactly is this fragment in it. So I think at least embedded style sheets should be handled correctly - 'href="foo.xml#bar"' is not embedded at least if it is not reference to the same document as the processed one.
This needs WG clarification. For example, what is the expected treatment of the following case: <?xml-stylesheet href="#linkToMe" type="text/css"?> <foo id="linkToMe"> <bar> a { color: red } a:before { content: "<div> text </div>" } </bar> <![CDATA[ b { color: green } ]]> </foo>
Keywords: qawanted
Whiteboard: [Hixie-PF] [have workaround] WONTFIX? → [Hixie-PF] [have workaround] WONTFIX? NEED WG CLARIFICATION
Which WG, exactly?
http://www.w3.org/TR/xml-stylesheet/ doesn't seem to belong to any useful WG (if you know who's in charge of it, please feel free to request clarification from them). But http://www.w3.org/Style/styling-XML#Embedded is most certainly the CSS WG, and if they're going to advertise this, I think they'd better define how it should be interoperably implemented. Alternately, they could change that text to a note saying that this is undefined at present. And then I will wontfix this bug, pending a spec that's actually a spec. Because as things stand, this stuff looks to me like no one bothered to think about it while writing about it.
RE: comment 19. Shouldn't that be treated like: <style type="text/csS"> <span> a { color: red } a:before { content: "<div> text </div>" } </span> <![CDATA[ b { color: green } ]]> </style> IMO, this should be supported by Mozilla, since you can have all your style sheets in a single file (one for screen, one for print and so on), without using the @media rule. Besides that you can also add additional comments in that file and covert the whole thing with XSLT.
The markup in comment 19 is treated in totally different ways in XHTML and HTML (aka tag-soup). See http://www.w3.org/TR/xhtml1/#h-4.8 (in particular "As a result, < and & will be treated as the start of markup"). You should really try to see what happens when you use a <style> element like that in XHTML... the results are quite poor. There's a reason that XHTML recommends not using <style> elements.
What I meant was that the way that Mozilla handles this invalid nesting now in XHTML should be the same in XML documents. I don't understand why this needs furthur clarification. It is invalid (and should therefore be treated as such), since you would expect that the CSS/"other style language" is directly inside the CDATA comment of the element with the ID attribute applied on it.
As I understand it the way we do it in XHTML is totally broken (we don't create the right DOM). So copying it is probably not ideal...
> since you would expect that the CSS/"other style language" is directly inside > the CDATA comment Why? I see no mention of CDATA anywhere on http://www.w3.org/Style/styling-XML#Embedded and I can see people making the argument that it should not be needed... Basically, I am not willing to waste my time implementing something that's so poorly specified that it's clear to me that that spec will be changed. I've done it before, and the end result is that you have to redo it when the spec _is_ finally changed. If I thought the functionality was useful enough to do twice, I would. But I don't.
For the record, I actually have an action item open to make a proposal to define this. I just haven't had time to do it yet.
BTW, those of you who think this is important enough that I should prioritise that action item over others should let me know by e-mail. There are things you can do to help this happen faster. ian@hixie.ch
No plans to work on this any time in the foreseeable future, so to default owner.
Assignee: bz-vacation → dbaron
Priority: P5 → --
Target Milestone: Future → ---
Attachment #58370 - Attachment is obsolete: true
Severity: normal → enhancement
Whiteboard: [Hixie-PF] [have workaround] WONTFIX? NEED WG CLARIFICATION → [Hixie-PF]
*** Bug 253676 has been marked as a duplicate of this bug. ***
*** Bug 267161 has been marked as a duplicate of this bug. ***
Re: comment #19: I think the natural way is that the style sheet should be the concatenation of the data in the CharacterData descendants of the designated style element when traversed in the document order. That would yield: a { color: red } a:before { content: " text " } b { color: green }
Whereas I think it would make more sense to assume anything that has any non-text and non-CDATA nodes in there is in error and simply ignore it... But both approaches have their merits, which is why I'd like to see an actual specification proposed.
Blocks: 275196
The W3C CSS and XML Core WGs are supposed to be discussing this this year. Anne and I made a test suite that made certain assumptions about what should happen. The idea was basically: An XML Stylesheet PI, if it uses a fragment identifier, must link to elements in the local document. If an XML Stylesheet PI points to the same document using a fragment identifier, and that document is an XML document, and there is an element for that fragment identifier, and the given type="" on the PI is acceptable as a styling language (if not provided, the document's MIME type is used instead), then that element is used for styling. If the type is text/css, then the immediate children of the element that are text nodes or CDATA nodes are concatenated, and all other children ignored. If the type is an XML type (or if the type attribute is omitted) then the namespace and tagname of the target element decides processing (XSLT, if the element is xsl:stylesheet). In CSS, the elements are inserted into the cascade at the point of reference (the PI) not the point of definition (the element). Links with fragment identifiers pointing to other documents only work if the target document is a stylesheet in a language that can be referenced by fragment identifier, it doesn't cause the referenced element to be taken out and parsed using the given MIME type. @import and XHTML <link> elements, etc, don't get any of the magic processing either, so they can't be used to link to elements in external XML files or even elements in the same file. (i.e. this processing is specific to the PI, not to the stylesheet loader) The tests are at: http://www.hixie.ch/tests/adhoc/xml/styling/pi/internal/ However, all of this could change based on (a) implementation experience, and (b) dicussion between the CSSWG and the XML Core WG. If you agree with the above definitions I encourage you to implement them, as that will yield significant weight to the proposal. If you disagree, I recommend that you propose an alternative model that I can comment upon. I'm not at all tied to the proposal above. I'm tempted to just propose that none of this should work at all (i.e. no special casing for linking to the same document with a fragment identifier).
> An XML Stylesheet PI, if it uses a fragment identifier, must > link to elements in the local document. So it's not just treated as a URI? That will be rather annoying to implement.... Though I guess base issues are not a problem here anyway, so a bare fragment identifier will always resolve to the current document, huh? > Links with fragment identifiers pointing to other documents > only work if the target document is a stylesheet in a language > that can be referenced by fragment identifier It's not clear to me what this means. Frankly, I'm perfectly fine with the "not working at all" approach. ;)
The idea is if it's a link into the current document, you handle it specially (the type="" pseudo-attribute overrides the real type, and the contents of the element in question are used instead of the entire document), but if it's a link to an XML document in general, then you handle it normally (as we do now). We could change it a bit to be defined in terms of "if the URI starts with a #" or something like that to make it even easier. > Frankly, I'm perfectly fine with the "not working at all" approach. ;) Me too. It's quite possible we'll end up there eventually, but at the moments the specs suggest otherwise.
No longer blocks: 275196
Assignee: dbaron → nobody
QA Contact: ian → style-system
I think this should just be WONTFIX. Objections?
Priority: -- → P5
Sounds good to me.
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: