javaserverfaces-spec-public
  1. javaserverfaces-spec-public
  2. JAVASERVERFACES_SPEC_PUBLIC-974

Add support for conditional comments to h:outputStylesheet and h:outputScript (add condition attribute)

    Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Minor Minor
    • Resolution: Won't Fix
    • Affects Version/s: 2.0, 2.1
    • Fix Version/s: None
    • Component/s: Resources
    • Labels:
      None
    • Status Whiteboard:
      Hide

      size_medium importance_medium

      Show
      size_medium importance_medium

      Description

      Conditional comments at wikipedia: http://en.wikipedia.org/wiki/Conditional_comment

      Example:

      <!--[if IE 6]>
      <link rel="stylesheet" type="text/css" href="style.css" />
      <![endif]-->

      This is currently not easy to achieve with facelets, because <!-- --> comments are normally stripped and JSF componentes inside comments also do not (really) work. However, working with styling frameworks, you have to use this quite heavily in order to support a variety of browsers.

      Thus I'd suggest to add a "condition" attribute to h:outputStylesheet and h:outputScript, which, if set, renders the conditional comment containing the value of the attribtue around the <link> or <script>.

      Example:

      <h:outputStylesheet name="style.css" condition="IE 6" />

      renders

      <!--[if IE 6]>
      <link rel="stylesheet" type="text/css" href="style.css" />
      <![endif]-->

        Activity

        Hide
        lamine_ba added a comment - - edited

        What I hate the most is to start from scratch. Do you think that I'll loose my time to create my own facelets template? No, the web is full of templates even they are not facelets templates. It is just a matter of transformation and the job is done.
        What is the probability to download a template without this inside?
        <!--[if IE 6]>
        <link rel="stylesheet" type="text/css" href="style.css" />
        <![endif]-
        Very low because web designers use this quite heavily in order to support a variety of browsers. This feature is quite interesting for my multi-templating system if I want to reuse the free joomla templates out there (http://www.gelono.com/free-joomla-1.5-templates.html).

        Show
        lamine_ba added a comment - - edited What I hate the most is to start from scratch. Do you think that I'll loose my time to create my own facelets template? No, the web is full of templates even they are not facelets templates. It is just a matter of transformation and the job is done. What is the probability to download a template without this inside? <!-- [if IE 6] > <link rel="stylesheet" type="text/css" href="style.css" /> <! [endif] - Very low because web designers use this quite heavily in order to support a variety of browsers. This feature is quite interesting for my multi-templating system if I want to reuse the free joomla templates out there ( http://www.gelono.com/free-joomla-1.5-templates.html ).
        Hide
        120430 added a comment -

        I don't think this should added to outputStylesheet and outputScript. A own component for conditional comments would be more useful.

        Show
        120430 added a comment - I don't think this should added to outputStylesheet and outputScript. A own component for conditional comments would be more useful.
        Hide
        Jakob Korherr added a comment -

        I don't think that a own component is really necessary here.

        Another idea would be to add the "condition" attribute to h:panelGroup, then you could do something like this:

        <h:panelGroup condition="lte IE 6">
        <h:outputScript .... />
        </h:panelGroup>

        Show
        Jakob Korherr added a comment - I don't think that a own component is really necessary here. Another idea would be to add the "condition" attribute to h:panelGroup, then you could do something like this: <h:panelGroup condition="lte IE 6"> <h:outputScript .... /> </h:panelGroup>
        Hide
        120430 added a comment -

        Why not:

        <ui:comment condition="... >
        <h:outputScript .... />
        </ui:comment>

        this would be clear for someone who knows conditional comments.

        Show
        120430 added a comment - Why not: <ui:comment condition="... > <h:outputScript .... /> </ui:comment> this would be clear for someone who knows conditional comments.
        Hide
        i_oss added a comment -

        But what if on uses resource relocation and moves the script from the body to the head, this would either mean, that the ui:comment would stay at place and the condition would be "lost" or that the relocation would have to check if it was in a condition and move that condition too. Both ways would be unintuitive.

        Show
        i_oss added a comment - But what if on uses resource relocation and moves the script from the body to the head, this would either mean, that the ui:comment would stay at place and the condition would be "lost" or that the relocation would have to check if it was in a condition and move that condition too. Both ways would be unintuitive.
        Hide
        Jakob Korherr added a comment -

        That's true! Thus I still prefer the first proposal: adding the condition attribute to h:outputStylesheet and h:outputScript!

        Show
        Jakob Korherr added a comment - That's true! Thus I still prefer the first proposal: adding the condition attribute to h:outputStylesheet and h:outputScript!
        Hide
        Ed Burns added a comment -

        size_small importance_medium

        Show
        Ed Burns added a comment - size_small importance_medium
        Hide
        i_oss added a comment -

        I gave it another thought or two, so I'd like to put an alternative solution ( with additional usecases ) up for discussion .

        <f:relocate target="~head" at="end" rendered="…">
        <!--[if IE7]>
        <style>..</style>
        <![endif]-->
        </f:relocate>

        Here is an example compcomp with further usecases:

        <cc:interface>
        <cc:attribute name="statusId" required="false"/>
        <cc:attribute name="serviceBean" required="true"/>
        </cc:interfaces>

        <cc:implementation>

        Some content
        <h:form id="LoginForm">

        </h:form>
        Some content (the disclaimer will be relocated in front of this content)

        <f:relocate target="#

        {cc.clientId}" at="after">
        <!--[if IE7]>
        <script>…;fixMyWidget('##{cc.clientId}

        ');…</script>
        <![endif]-->
        </f:relocate>
        <f:relocate target="~body" at="end" rendered="#

        {myHelper.once('mywidget.link.fix.for.ie6')}

        ">
        <!--[if IE6]>
        <script src="/s/mywidget.fix.code.js"></script>
        <script>fixIe6('.widget a');</script>
        <![endif]-->
        </f:relocate>

        <f:relocate target="#

        {cc.attrs.statusId}

        " rendered="!empty cc.attrs.statusId and not empty cc.attrs.serviceBean.lastLogin">
        <em>Last Login: #

        {cc.attrs.serviceBean.lastLogin}

        </em>
        </f:relocate>

        </cc:implementation>


        Usingpage:
        <my:loginFrom id="LoginComp" statusId="LoginStatus" service="#

        {…}

        ">
        <f:relocate target=".:LoginForm" at="after">
        <div class="disclaimer">Bla bla bla</div>
        </f:relocate>
        </my:loginForm>

        If we can come up with a good target/location selector "language", this could be used to create compcomps that even provide data to the using page, and also provide a way to customize compontents (as in the example above).
        I am still not sure, if this isn't just "too" much…

        Show
        i_oss added a comment - I gave it another thought or two, so I'd like to put an alternative solution ( with additional usecases ) up for discussion . <f:relocate target="~head" at="end" rendered="…"> <!-- [if IE7] > <style>..</style> <! [endif] --> </f:relocate> Here is an example compcomp with further usecases: <cc:interface> <cc:attribute name="statusId" required="false"/> <cc:attribute name="serviceBean" required="true"/> </cc:interfaces> <cc:implementation> Some content <h:form id="LoginForm"> … </h:form> Some content (the disclaimer will be relocated in front of this content) <f:relocate target="# {cc.clientId}" at="after"> <!-- [if IE7] > <script>…;fixMyWidget('##{cc.clientId} ');…</script> <! [endif] --> </f:relocate> <f:relocate target="~body" at="end" rendered="# {myHelper.once('mywidget.link.fix.for.ie6')} "> <!-- [if IE6] > <script src="/s/mywidget.fix.code.js"></script> <script>fixIe6('.widget a');</script> <! [endif] --> </f:relocate> <f:relocate target="# {cc.attrs.statusId} " rendered="!empty cc.attrs.statusId and not empty cc.attrs.serviceBean.lastLogin"> <em>Last Login: # {cc.attrs.serviceBean.lastLogin} </em> </f:relocate> </cc:implementation> — Usingpage: <my:loginFrom id="LoginComp" statusId="LoginStatus" service="# {…} "> <f:relocate target=".:LoginForm" at="after"> <div class="disclaimer">Bla bla bla</div> </f:relocate> </my:loginForm> If we can come up with a good target/location selector "language", this could be used to create compcomps that even provide data to the using page, and also provide a way to customize compontents (as in the example above). I am still not sure, if this isn't just "too" much…
        Hide
        Jakob Korherr added a comment -

        Hmm, this might be a bit over-engineered, don't you think?

        My initial idea was just a minor improvement of the current resource inclusion system.

        Show
        Jakob Korherr added a comment - Hmm, this might be a bit over-engineered, don't you think? My initial idea was just a minor improvement of the current resource inclusion system.
        Hide
        i_oss added a comment -

        For this specific usecase it is "over- engineered" I totally agree, as I said "..."too" much" ... (but my solution is not only meant for conditional comments, but for usage in compcomps, flexible templating, etc. This is probably not the correct issue to add this)

        So with regards to conditional comments only, I don't like the idea of adding such an attribute to any component (neither for scripts nor for styles).

        Show
        i_oss added a comment - For this specific usecase it is "over- engineered" I totally agree, as I said "..."too" much" ... (but my solution is not only meant for conditional comments, but for usage in compcomps, flexible templating, etc. This is probably not the correct issue to add this) So with regards to conditional comments only, I don't like the idea of adding such an attribute to any component (neither for scripts nor for styles).
        Hide
        Udo Schnurpfeil added a comment -

        Why not:

        <h:comment condition="..." target="...">
        <h:outputScript .... />
        </h:comment>

        Advantages in my opinion:

        • h: instead of ui: because it is a HTML feature, not a output independent feature.
        • easy to understand.
        • can be used with any other tags e. g. use <video> tag in HTML5 browsers and an special player tag in an other.
        • no need to change existing tags.
        Show
        Udo Schnurpfeil added a comment - Why not: <h:comment condition="..." target="..."> <h:outputScript .... /> </h:comment> Advantages in my opinion: h: instead of ui: because it is a HTML feature, not a output independent feature. easy to understand. can be used with any other tags e. g. use <video> tag in HTML5 browsers and an special player tag in an other. no need to change existing tags.
        Hide
        Udo Schnurpfeil added a comment -

        An alternative for resources:

        The basic problem behind this resolution is that we want to have different resources for different browsers.
        I suggest to enhance the resource management to cover this issue.

        In short: resources should know for which browsers they are. If you have e.g. 2 files:

        • standard/style.css
        • ie6/style.css
          the tag
          <h:outputStylesheet name="style.css"/>
          should render one tag (if the browser is not ie6)
        • standard/style.css
          and two tags if the browser is ie6:
        • standard/style.css
        • ie6/style.css

        In the project Apache Tobago the resource mechanism works like this.

        This should be discussed in the resource management, of course. But when we have a simple to use <h:comment> (like my last comment) and a smart resource management, one can pick its preferred way.

        Show
        Udo Schnurpfeil added a comment - An alternative for resources: The basic problem behind this resolution is that we want to have different resources for different browsers. I suggest to enhance the resource management to cover this issue. In short: resources should know for which browsers they are. If you have e.g. 2 files: standard/style.css ie6/style.css the tag <h:outputStylesheet name="style.css"/> should render one tag (if the browser is not ie6) standard/style.css and two tags if the browser is ie6: standard/style.css ie6/style.css In the project Apache Tobago the resource mechanism works like this. This should be discussed in the resource management, of course. But when we have a simple to use <h:comment> (like my last comment) and a smart resource management, one can pick its preferred way.
        Hide
        i_oss added a comment -

        Probably should be, but as we are discussing it here:

        How would you know that the useragent is IE6 (or 7 or so), the only safe way to find out is conditional comments.
        I think a better way would be to make (as you proposed) outputStylesheet or Script aware of IE* resources and just have it add conditional comments automatically for the additional resources no matter what useragent jsf thinks you have. How to do so, is part of the resource-management issues.

        Concerning h:comment: h: agreed!
        But I personally! still don't like the idea of having a condition and target attribute on a comment tag, I really think there should be a general (and easy) way to relocate component(-sub-trees) of any kind. (With the extended usage of meta (chrome plugin, iphone-settings, ...) we also need to be able to add this tag to the head, and probably be able to discover/remove them => h:meta anyone?)

        Show
        i_oss added a comment - Probably should be, but as we are discussing it here: How would you know that the useragent is IE6 (or 7 or so), the only safe way to find out is conditional comments. I think a better way would be to make (as you proposed) outputStylesheet or Script aware of IE* resources and just have it add conditional comments automatically for the additional resources no matter what useragent jsf thinks you have. How to do so, is part of the resource-management issues. Concerning h:comment: h: agreed! But I personally! still don't like the idea of having a condition and target attribute on a comment tag, I really think there should be a general (and easy) way to relocate component(-sub-trees) of any kind. (With the extended usage of meta (chrome plugin, iphone-settings, ...) we also need to be able to add this tag to the head, and probably be able to discover/remove them => h:meta anyone?)
        Hide
        Ed Burns added a comment -

        Out of scope for 2.3.

        Show
        Ed Burns added a comment - Out of scope for 2.3.
        Hide
        Manfred Riem added a comment -

        Closing resolved issue out

        Show
        Manfred Riem added a comment - Closing resolved issue out

          People

          • Assignee:
            Unassigned
            Reporter:
            Jakob Korherr
          • Votes:
            7 Vote for this issue
            Watchers:
            5 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: