Convert xml style sheets to link elements in browser.xhtml
Categories
(Firefox :: General, task, P3)
Tracking
()
People
(Reporter: bdahl, Unassigned)
References
Details
To continue the "htmlification" of browser.xhtml we should move <?xml-stylesheet.. to <link> in the <head>.
There is special handling of XML style sheets in the prototype cache that may also need to support CSS in link elements.
|
||
Comment 1•5 years ago
|
||
Do you know if there is a meta tracking bug for html-ification?
|
Reporter | |
Updated•5 years ago
|
|
||
Comment 2•5 years ago
|
||
(In reply to Brendan Dahl [:bdahl] from comment #0)
To continue the "htmlification" of browser.xhtml we should move
<?xml-stylesheet..to<link>in the<head>.There is special handling of XML style sheets in the prototype cache that may also need to support CSS in link elements.
What's the goal here? Just familiarity for people who authored HTML? Other perf benefits? Afaik we're not going to stop serving browser.xhtml as XML, so from that perspective this seems unnecessary.
|
||
Comment 3•5 years ago
|
||
(In reply to Brendan Dahl [:bdahl] from comment #0)
There is special handling of XML style sheets in the prototype cache that may also need to support CSS in link elements.
Last time I checked the primary style sheet cache (which has a large perf impact) works for both types of sheets - and is even working for link tags injected later, like in Shadow DOM.
|
|
||
Comment 4•5 years ago
|
||
(In reply to Dão Gottwald [::dao] (PTO till Nov 13) from comment #2)
(In reply to Brendan Dahl [:bdahl] from comment #0)
To continue the "htmlification" of browser.xhtml we should move
<?xml-stylesheet..to<link>in the<head>.There is special handling of XML style sheets in the prototype cache that may also need to support CSS in link elements.
What's the goal here? Just familiarity for people who authored HTML? Other perf benefits?
Unless if there's a particular benefit to PIs (which this bug is intending to help us figure out) we should do what most people are familiar with. We also have .html docs in tree and it's good to be consistent. For example, Bug 1582786 is a case where injecting PIs from JS into a non-XML html document caused a problem.
Afaik we're not going to stop serving browser.xhtml as XML, so from that perspective this seems unnecessary.
Correct.
|
||
Comment 5•5 years ago
|
||
Bugbug thinks this bug should belong to this component, but please revert this change in case of error.
|
||
Updated•5 years ago
|
|
||
Comment 6•3 years ago
|
||
Just curious, is there any reason we would want to continue serving this as xhtml instead of html?
|
||
Comment 7•1 year ago
|
||
(In reply to Jared Hirsch [:jhirsch] (he/him) (Needinfo please) from comment #6)
Just curious, is there any reason we would want to continue serving this as xhtml instead of html?
A number of reasons. See 1858003.
|
|
||
Comment 8•1 year ago
|
||
We need to do this more generally than just for browser.xhtml so lets close this in favour of the more general bug.
Description
•