[ 
https://issues.apache.org/jira/browse/TAP5-1048?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andy Blower updated TAP5-1048:
------------------------------

    Attachment: TAP5-1048-patch.txt

This does fix the problem, but it's not the most satisfactory solution. Without 
changing the Node/Raw/Element classes I couldn't see another way to fix it.

> 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.

Reply via email to