You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tapestry.apache.org by "Howard M. Lewis Ship (Closed) (JIRA)" <ji...@apache.org> on 2011/10/18 01:01:11 UTC
[jira] [Closed] (TAP5-1048) Support for IE conditional stylesheets
will need changes to DocumentLinkerImpl
[ 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