Done for XML PI's, HTMLLinkElement still to be done.

Does this need to be nsbeta2 or can we drop for FCS?

This could be very useful, but IMO not absolutely critical for FCS, I think we'll get this more or less for free once bug 7515is fixed. nominating for beta2

This is not mandatory for beta2.

Tracking bug, futuring...

Taking QA Contact on all open or unverified DOM Style bugs...

Nominating this bug for nsbeta1 on behalf of gerardok@netscape.com.

This seems to work for HTML Link elements and STYLE elements, but fails for META elements. Since this means it mainly works, removing nsbeta1 nomination.

So what needs to be done here?

IE displays the h1 as red. I *believe* Mozilla should too... I think this is related to bug #7515, but that's marked as VERIFIED/FIXED and, to judge by this test case - it isn't :( I really don't like seeing IE do something better than Mozilla :,-( Sorry I don't know enough about Mozilla to help debug it. J.

The reason my code didn't work is because the base uri of dynamically generated html is not the same as the base uri of the generating page. Should it be?

Good question. Radha? What does NS4 do?

Based on what jrgm has said in comment #11, when a wyciwyg url is loaded normally, the generating document is not set as the base url. However this is done if a wyciwyg url is loaded from history. I looked into making the generating url as the base url for all types of loads, instead of just for history loads. But there are some issues with it in docshell. I think it can be worked out. But I haven't seen a compelling reason to do it.

What would you consider a "compelling reason"? I might be able to supply one...

I may consider a "loss of data" or a top 100 site rendering failure as a compelling reason.

Shame, I've got no way to offer you something that serious. I do have a work around. I'd rather not have too, but I can't add anymore reasoning. Sorry to have bothered you! J.

Radha, could you at least outline the issues that docshell has with setting the base URI to the generating URI? Just so those who feel that this being a bug is compelling enough a reason to fix it can actually do so.

Just as a quick note, I think I've seen at least 2 or 3 bug reports caused by this "no compelling reason to fix it" bug.. I agree with Christopher; some details on the technical issues would be nice.

The only issue I'm aware of is that this fails for <meta> elements that link in stylesheets.

Hixie, this seems to work just fine to me....

The issues in docshell relate to how pages are loaded and added to Session History . Search for "OriginalURI" in docshell and look through the flow of control before a page is sent to necko in DoChannelLoad() and after the onStartRequest response from necko comes, from OnLoadingSite() to OnNewURI() and eventually to SetCurrentURI(). When original url is set different from the actual loaded url, nsDocShell::mCurrentURI will end up with a different value than what it has actually loaded. This could lead to a slew of other problems when subsequent urls are loaded and when user navigates through history to and from this wyciwyg url.

bz: but does that <meta> element support LinkStyle?

May as well take this... Let's have a separate bug for the wyciwyg discussion, ok, since there's work left to do here on the original problem...

This needs to be fixed in order to ensure correct ordering of sheets linked via <meta> elements. Though I'm not quite sure, to be truthful, whether such sheets should be treated exactly like ones linked via the header (that is, come before all <link> and <style> sheets). Thoughts?

I don't think that <meta> should act like <link>. <meta> should do the exact same thing as adding the same header, that is IMHO the most logical behaviour. I don't see any reason why <meta> should be as convinient and featurefull as <link> unless if we absolutly have to do it. WRT what should happen when you remove a <meta>. I don't really have a strong oppinion either way. Should removing a <meta http-equiv="Refresh"> halt a pending refresh? What about removing a <meta http-equiv="Content-Type">?

I'm of the opinion that <meta http-equiv="Link"> should work exactly the same way as <link>. The insertion point should depend on the point in the HTTP stream where the stylesheet is mentioned. <meta> should also be fully dynamically editable, just like <link>. This doesn't remove any of the functionality available to the author, indeed it adds more functionality.

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

OK. Could we decide on something here, please? Either we wontfix it, or we fix it, but just having it sit here is silly. Personally, I'm for making <meta> elements support nsIDOMLinkStyle and nsIStyleSheetLinkingElement. I don't see any major problems this would cause. I think ordering in document order would be more intuitive than ordering all the <meta> sheets first. And that's the only possible issue I see with just fixing this bug. Are there any others?

IMHO a <meta http-equiv> should work *exactly* as adding the same http-header, meaning that any linked stylesheets would be ordered as if the link came from a http-header. Personally I think this is makes a lot of sense, although i'm aware that i'm looking at it from a fairly technical point of view. I'm also afraid that if we start adding interfaces to <meta> we will end up overloading it a lot with time. And remember that if we give it those interfaces it will have to have them even for elements like <meta name="keywords" content="rubber ducks">. Giving functionality based on an attribute-value makes for a lot of mess (look at the code for <input>), so let's avoid it if we can. That said, I won't go screaming in dispair if this is implemented anyway. I'm just of the oppinion that we're better off without it :)

Yeah... the issue with interface proliferation is the same as with <link> -- it just kinda sucks. :(

Note that per the current HTML5 draft, <meta http-equiv="Link"> sounds like it should do absolutely nothing.

https://bugzilla.mozilla.org/show_bug.cgi?id=1472046 Move all DOM bugs that haven't been updated in more than 3 years and has no one currently assigned to P5. If you have questions, please contact :mdaly.