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

RESOLVED WONTFIX

Status

()

Core
CSS Parsing and Computation
P5
enhancement
RESOLVED WONTFIX
17 years ago
3 years ago

People

(Reporter: drapeau, Unassigned)

Tracking

({qawanted})

Trunk
qawanted
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [Hixie-PF])

Attachments

(2 attachments, 1 obsolete attachment)

(Reporter)

Description

17 years ago
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

Comment 2

16 years ago
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
Created attachment 58370 [details]
First testcase without PI and with XHTML style

Comment 5

16 years ago
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.

Comment 6

16 years ago
... 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.

Comment 7

15 years ago
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.
Created attachment 93761 [details]
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?

Comment 17

14 years ago
Created attachment 116597 [details]
One more (test case)

Comment 18

14 years ago
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.

Comment 22

14 years ago
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.

Comment 24

14 years ago
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 → ---

Updated

13 years ago
Attachment #58370 - Attachment is obsolete: true

Updated

13 years ago
Severity: normal → enhancement

Updated

13 years ago
Whiteboard: [Hixie-PF] [have workaround] WONTFIX? NEED WG CLARIFICATION → [Hixie-PF]

Comment 30

13 years ago
*** Bug 253676 has been marked as a duplicate of this bug. ***

Comment 31

13 years ago
*** 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.

Updated

13 years ago
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.

Updated

12 years ago
No longer blocks: 275196
Assignee: dbaron → nobody
QA Contact: ian → style-system

Updated

9 years ago
Duplicate of this bug: 411807
I think this should just be WONTFIX.  Objections?
Priority: -- → P5
Sounds good to me.
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.