Last Comment Bug 61675 - Can't link XML document to embedded stylesheet (Support <?xml-stylesheet href="#local" type="text/css" ?>)
: Can't link XML document to embedded stylesheet (Support <?xml-stylesheet href...
Status: RESOLVED WONTFIX
[Hixie-PF]
: qawanted
Product: Core
Classification: Components
Component: CSS Parsing and Computation (show other bugs)
: Trunk
: All All
: P5 enhancement with 7 votes (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
:
: Jet Villegas (:jet)
Mentors:
: 193924 253676 267161 411807 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2000-11-30 18:12 PST by drapeau
Modified: 2014-06-03 09:46 PDT (History)
20 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
First testcase without PI and with XHTML style (1.21 KB, text/xml)
2001-11-19 10:30 PST, Heikki Toivonen (remove -bugzilla when emailing directly)
no flags Details
real testcase (571 bytes, text/xml)
2002-08-02 14:37 PDT, Heikki Toivonen (remove -bugzilla when emailing directly)
no flags Details
One more (test case) (807 bytes, text/xml)
2003-03-07 16:47 PST, Stanimir Stamenkov
no flags Details

Description drapeau 2000-11-30 18:12:04 PST
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
Comment 1 Hixie (not reading bugmail) 2001-02-12 16:25:36 PST
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...
Comment 2 Pierre Saslawsky 2001-11-18 17:36:02 PST
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.
Comment 3 Heikki Toivonen (remove -bugzilla when emailing directly) 2001-11-19 10:29:18 PST
-> 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.
Comment 4 Heikki Toivonen (remove -bugzilla when emailing directly) 2001-11-19 10:30:22 PST
Created attachment 58370 [details]
First testcase without PI and with XHTML style
Comment 5 Pierre Saslawsky 2001-11-19 15:43:11 PST
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 Pierre Saslawsky 2001-11-19 15:47:01 PST
... 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 Merrick Schincariol 2002-08-02 13:59:46 PDT
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.
Comment 8 Heikki Toivonen (remove -bugzilla when emailing directly) 2002-08-02 14:37:07 PDT
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.
Comment 9 Hixie (not reading bugmail) 2002-11-08 04:18:30 PST
What happens if the target element contains other elements? :-)
Comment 10 Hixie (not reading bugmail) 2003-02-18 14:47:14 PST
Oh, bz? :-)
Comment 11 Hixie (not reading bugmail) 2003-02-18 14:48:12 PST
*** Bug 193924 has been marked as a duplicate of this bug. ***
Comment 12 Boris Zbarsky [:bz] (still a bit busy) 2003-02-18 15:04:27 PST
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. 
Comment 13 David Baron :dbaron: ⌚️UTC-10 2003-02-18 17:52:05 PST
What standard describes this behavior?
Comment 14 Boris Zbarsky [:bz] (still a bit busy) 2003-02-18 19:15:42 PST
None, that I have found.  There is a very vague informative note
at http://www.w3.org/Style/styling-XML#Embedded 
Comment 15 Hixie (not reading bugmail) 2003-02-19 16:21:16 PST
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.
Comment 16 Boris Zbarsky [:bz] (still a bit busy) 2003-02-19 18:39:03 PST
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 Stanimir Stamenkov 2003-03-07 16:47:51 PST
Created attachment 116597 [details]
One more (test case)
Comment 18 Stanimir Stamenkov 2003-03-07 16:59:41 PST
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.
Comment 19 Boris Zbarsky [:bz] (still a bit busy) 2003-04-01 21:17:46 PST
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>
Comment 20 Hixie (not reading bugmail) 2003-04-02 05:20:07 PST
Which WG, exactly?
Comment 21 Boris Zbarsky [:bz] (still a bit busy) 2003-04-02 06:30:05 PST
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 Anne (:annevk) 2003-10-24 23:59:59 PDT
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.
Comment 23 Boris Zbarsky [:bz] (still a bit busy) 2003-10-25 00:55:14 PDT
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 Anne (:annevk) 2003-10-25 04:28:31 PDT
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.
Comment 25 Hixie (not reading bugmail) 2003-10-25 05:24:58 PDT
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...
Comment 26 Boris Zbarsky [:bz] (still a bit busy) 2003-10-25 09:58:23 PDT
> 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.
Comment 27 Hixie (not reading bugmail) 2003-10-25 10:07:20 PDT
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.
Comment 28 Hixie (not reading bugmail) 2003-10-25 10:11:51 PDT
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
Comment 29 Boris Zbarsky [:bz] (still a bit busy) 2004-01-06 16:23:56 PST
No plans to work on this any time in the foreseeable future, so to default owner.
Comment 30 Anne (:annevk) 2004-07-30 22:35:06 PDT
*** Bug 253676 has been marked as a duplicate of this bug. ***
Comment 31 Anne (:annevk) 2004-11-05 10:19:05 PST
*** Bug 267161 has been marked as a duplicate of this bug. ***
Comment 32 Henri Sivonen (:hsivonen) 2005-01-03 12:44:39 PST
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 }
  
Comment 33 Boris Zbarsky [:bz] (still a bit busy) 2005-01-03 12:49:23 PST
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.
Comment 34 Hixie (not reading bugmail) 2005-01-06 04:58:47 PST
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).
Comment 35 Boris Zbarsky [:bz] (still a bit busy) 2005-01-06 10:18:37 PST
>   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.  ;)
Comment 36 Hixie (not reading bugmail) 2005-01-06 10:25:30 PST
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.
Comment 37 Philip Chee 2008-01-10 17:36:11 PST
*** Bug 411807 has been marked as a duplicate of this bug. ***
Comment 38 David Baron :dbaron: ⌚️UTC-10 2011-11-15 12:53:18 PST
I think this should just be WONTFIX.  Objections?
Comment 39 Boris Zbarsky [:bz] (still a bit busy) 2011-11-15 20:24:35 PST
Sounds good to me.

Note You need to log in before you can comment on or make changes to this bug.