7516 - [Content sink] XML ignores HTML:LINK tags

Status: VERIFIED FIXED

(Core :: Layout, defect, P3)

Description

[Chris Waterson]

To reproduce,

1. Install attached test cases, style.xml & style.css onto your hard drive.

2. Run viewer and load style.xml.

Expected behavior: HTML:LINK tag is honored and style.css is loaded; this would
cause "hello, world" text to appear in red.

Actual behavior: LINK tag is ignored.

Note that I am assigning this bug to the LAYOUT component, because the
nsHTMLLinkElement implementation makes assumptions about being in an HTML
document.

Also note that the XML in the test case is written to work around bug 4924;
specifically, each of the HTML attributes are explicitly qualified to be in the
HTML namespace. This may break when Nisheeth fixes 4924.

Comment 1

[Chris Waterson]

Attachment: style.xml

Comment 2

[Chris Waterson]

Attachment: style.css

Comment 3

[rickg]

Nisheeth - -this one's for you

Comment 4

[Chris Waterson]

Note that this is NOT a problem with the XML parser: it is a problem with the
implementation of the HTML LINK element.

Comment 5

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

When the stylesheet is loaded, to which elements will it apply?  Only the ones
in the namespace with an HTML-ish name, or to elements in all namespaces?  What
if html:link isn't in html:head?

Comment 6

[Nisheeth Ranjan]

The HTML content sink handles the LINK tag specially.  This code does not get
called from the XML content sink, hence the bug.  There are other bugs of a
similar nature that will all get fixed once we factor code correctly for the
HTML/XML/XUL/RDF content sinks.

Ccing Vidur, and David and setting milestone to M9...  I'll chip in with Vidur,
Chris, and David to get this done.

Comment 7

[Nisheeth Ranjan]

Oops.  Forgot to accept this bug...

Comment 8

[vidur (gone)]

Yup. Part of the factoring is moving out some of the code in the HTML content
sink to the specific content elements (necessary, anyway, for dynamic content
additions via the DOM). This will fix the HTML:LINK issue as well.

Comment 9

[Hixie (not reading bugmail)]

*** Bug 7835 has been marked as a duplicate of this bug. ***

Comment 10

[Hixie (not reading bugmail)]

*** Bug 7835 has been marked as a duplicate of this bug. ***

Comment 11

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

See peterl's comments in bug 7835.  You might want to ask him what should happen
here.

Comment 12

[Nisheeth Ranjan]

Adding Peter Linss to the cc list.  Peter, do you have any update on the comment
you made on bug 7835?

Comment 13

[Peter Linss]

Since one of the intents of XHTML is to be able to create a document which can
be served as *either* HTML (text/html) or XML (text/xml), supporting the
html:link tag is going to be important in XHTML after all. (because PIs will NOT
work if the document is severd as "text/html")

It's probably a good idea to set the default namespace in a stylesheet linked
via html:link to "html". I have provided a default namespace param to the CSS
loader for this purpose (use UNKNOWN if there is no default, not NONE).

This also implies that we should fully support <html:style> tags as well. They
should also set the default namespace within the stylesheet to "html".

Comment 14

[David Hyatt]

We should make sure to do this in the XUL content sink as well.

Comment 15

[Peter Linss]

Most of this code should really live in the content objects themselves,
therefore the XUL sink won't have to worry about it (neither should the XML
sink).

For any other issues that remain (that don't logically go in the content code),
we should consider factoring the content sink code out into a generic sink that
can have specific content handlers plugged in on a per namespace basis.

Comment 16

[Nisheeth Ranjan]

The content sink cleanup work is probably going to happen in M10.  Moving this
bug accordingly.

Comment 17

[Nisheeth Ranjan]

Moving content sink code factoring related bugs to M12.

Comment 18

[Nisheeth Ranjan]

The content sink code factoring has been postponed to post beta.  Moving related
bugs out to M15.

Comment 19

[Nisheeth Ranjan]

Moving bugs out by one milestone...

Comment 20

[Nisheeth Ranjan]

Moving XML/HTML content sink factoring related bugs out to M17...

Comment 21

[Nisheeth Ranjan]

Nominating for beta 3...

Comment 22

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Now that I think about it (and as Peter mentioned on bug 7835):

If it's acceptable to link a stylesheet this way in a pure XHTML XML document, 
should it be acceptable in a document with mixed XML vocabularies?  If so, 
authors would start using it to link (or embed) stylesheets into XML documents 
that otherwise have nothing to do with HTML.  This would force anyone who 
implemented any displayable XML vocabulary for use on the Web to understand 
HTML's style an link elements.  Is that a good thing?  Should we fix this bug?

Comment 23

[Dane Weber]

Re: Peter (via David) and his questioning of whether to fix linked style sheets 
in XHTML

The 'link' element is an HTML entity, and therefore one that is to be carried 
over from HTML into XHTML. It is only valid in an XML document when XHTML is 
one of its XML vocabularies. Also, as 'link' is an HTML entity, I believe it 
should only apply to HTML elements, although I doubt it would hurt to let it 
handle other XML elements if XHTML is within the vocabulary of the document.

Also, 'link' is necessary for XHTML support. If there is not enough time to 
fully implement XHTML, XHTML documents should be handled as HTML only. 
Without 'link', the XHTML support would be broken, not simply lacking.

Comment 24

[Peter Trudelle]

->future, per ekrock

Comment 25

[ekrock's old account (dead)]

Marking [nsbeta3-]. There's no commitment to any XHTML support in the first 
release of Gecko/N6, let alone full support. It is possible to link CSS style 
sheets into an XHTML document already using an XML processing instruction, so it 
will be possible to create new XHTML content that links in CSS style sheets in 
this way.

Obviously, the lack of support for HTML:LINK will be a nuisance for those who 
wish to migrate existing HTML content forward to XHTML. However, we have done no 
analysis to assess the overall feasibility of HTML --> XHTML content migration; 
there may be many other blocking issues there as well; we don't know, we don't 
have the time to do the analysis, and we don't have the time to fix other bugs 
anyway. Hence Future.

Comment 26

[Christopher Hoess (gone)]

Looks like this got fixed somehow (probably in changes to the style system).
Marking as such.

Comment 27

[Heikki Toivonen (remove -bugzilla when emailing directly)]

Verified. The testcase is not totally correct, though (XHTML attributes should
have no namespace prefix, maybe something else as well).