[ https://issues.apache.org/jira/browse/TAP5-1048?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12843670#action_12843670 ]
Howard M. Lewis Ship commented on TAP5-1048: -------------------------------------------- My intention is to extend the new JavascriptSupport interface (adding in 5.2) with new options to support these kinds of issues, along with new annotations (@ImportJavascriptLibrary to replace @IncludeJavascriptLibrary) to make it easier to control ordering. > Support for IE conditional stylesheets will need changes to DocumentLinkerImpl > ------------------------------------------------------------------------------ > > Key: TAP5-1048 > URL: https://issues.apache.org/jira/browse/TAP5-1048 > Project: Tapestry 5 > Issue Type: Bug > Components: tapestry-core > Affects Versions: 5.1.0.5 > Reporter: Andy Blower > Priority: Minor > Attachments: TAP5-1048-patch.txt > > > I'm having the issue described in TAP5-56, and although it's fairly easily > solved using a component (see: http://markmail.org/message/aidg4w223t5yaass) > or some other way, this is still not sufficient. The problem is in the > ordering of the stylesheets in the final rendered HTML output. The > addStylesheetsToHead() method of DocumentLinkerImpl adds the included > stylesheets and then moves them before any stylesheet links already in the > dom. This fails if one of the existing stylesheet links is a conditional one, > as findExistingElement() doesn't find the comment. > I've tried modifying the service, but because comments are Raw node, it's > difficult to put a bunch of Element nodes before one in the DOM. The only way > I could think of is included as a patch - findExistingElement() can return > the previous Element which can then have the link element nodes placed after > rather than before. This works, but is not very satisfactory. > I can't use this anyway because overriding that T5 DocumentLinkerImpl is > fragile and breaks in some of our environments. I spent several hours > aliasing and overriding this 'service' before I realised that DocumentLinker > is not actually a service! It's in the internal.services package, but isn't > actually a service - it's instantiated directly. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.