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

Howard M. Lewis Ship closed TAP5-1048.
--------------------------------------

    Resolution: Invalid
      Assignee: Howard M. Lewis Ship

This was subsequently addressed with new and improved APIs in 5.2.
                
> 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
>            Assignee: Howard M. Lewis Ship
>            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.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Reply via email to