[Content sink] XML ignores HTML:LINK tags

VERIFIED FIXED in Future

Status

()

Core
Layout
P3
normal
VERIFIED FIXED
19 years ago
17 years ago

People

(Reporter: Chris Waterson, Assigned: Nisheeth Ranjan)

Tracking

({testcase})

Trunk
Future
testcase
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [nsbeta3-])

Attachments

(2 attachments)

(Reporter)

Description

19 years ago
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.
(Reporter)

Comment 1

19 years ago
Created attachment 326 [details]
style.xml
(Reporter)

Comment 2

19 years ago
Created attachment 327 [details]
style.css
(Reporter)

Updated

19 years ago
Blocks: 7517

Updated

19 years ago
Assignee: rickg → nisheeth

Comment 3

19 years ago
Nisheeth - -this one's for you
(Reporter)

Comment 4

19 years ago
Note that this is NOT a problem with the XML parser: it is a problem with the
implementation of the HTML LINK element.
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?
(Assignee)

Updated

19 years ago
Target Milestone: M9
(Assignee)

Comment 6

19 years ago
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.
(Assignee)

Updated

19 years ago
Status: NEW → ASSIGNED
(Assignee)

Comment 7

19 years ago
Oops.  Forgot to accept this bug...

Comment 8

19 years ago
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.
*** Bug 7835 has been marked as a duplicate of this bug. ***
*** Bug 7835 has been marked as a duplicate of this bug. ***

Updated

19 years ago
QA Contact: petersen → chrisd
(Assignee)

Updated

19 years ago
Summary: XML ignores HTML:LINK tags → [Content sink] XML ignores HTML:LINK tags
See peterl's comments in bug 7835.  You might want to ask him what should happen
here.
(Assignee)

Comment 12

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

Comment 13

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

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

Comment 15

19 years ago
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.
(Assignee)

Updated

19 years ago
Target Milestone: M9 → M10
(Assignee)

Comment 16

19 years ago
The content sink cleanup work is probably going to happen in M10.  Moving this
bug accordingly.
(Assignee)

Comment 17

19 years ago
Moving content sink code factoring related bugs to M12.
(Assignee)

Comment 18

19 years ago
The content sink code factoring has been postponed to post beta.  Moving related
bugs out to M15.
Depends on: 21771
(Assignee)

Comment 19

19 years ago
Moving bugs out by one milestone...
Target Milestone: M15 → M16
(Assignee)

Comment 20

19 years ago
Moving XML/HTML content sink factoring related bugs out to M17...
Target Milestone: M16 → M17
(Assignee)

Comment 21

18 years ago
Nominating for beta 3...
Keywords: nsbeta3
Target Milestone: M17 → M18
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

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

18 years ago
->future, per ekrock
Target Milestone: M18 → Future
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.
Whiteboard: [nsbeta3-]

Updated

18 years ago
QA Contact: chrisd → petersen

Updated

18 years ago
Keywords: testcase
Looks like this got fixed somehow (probably in changes to the style system).
Marking as such.
Status: ASSIGNED → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → FIXED
Verified. The testcase is not totally correct, though (XHTML attributes should
have no namespace prefix, maybe something else as well).
Status: RESOLVED → VERIFIED
No longer depends on: 21771
You need to log in before you can comment on or make changes to this bug.