Tapestry
  1. Tapestry
  2. TAPESTRY-1552

@Any divs with no body content render <div /> shorthand form

    Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 4.1.2
    • Component/s: None
    • Labels:
      None

      Description

      Here's a short bugzilla discussion between me and my UI engineer...

      The following line:
      <div class="photo_frame" title="ognl:'invite ' + invitee.username" jwcid="@Any"></div>

      outputs the following code in "view source" using Firefox 1.5.0.12.
      <div title="invite jkassis" class="photo_frame" id="Any_1" />

      The problem is with the way the div is terminated. For Firefox to function
      properly, divs need to be terminated like so <div contents></div> and not <div
      contents />

      It tends to generate very hard to track down browser rendering bugs.

      I can't give you any more guidance about why this is happening or where else it
      may be happening right now, but please check it out when you get a chance.

      ------- Comment #1 From Jeremy Kassis 2007-06-05 16:44 [reply] -------

      (In reply to comment #0)
      > The following line:
      > <div class="photo_frame" title="ognl:'invite ' + invitee.username"
      > jwcid="@Any"></div>
      This source looks OK. Only thing remarkable about it is that it is an @Any
      component with no body content. Tapestry may by trying try to save characters
      by rendering it in the shorthand form.

      Not much I can do about this but put an   in there. Thankfully, this kind
      of code (a <div> with no body content) shouldn't happen too frequently.

      ------- Comment #2 From Erik Burns 2007-06-05 16:57 [reply] -------

      yeah, that fixed it. before we close it though... do you want to mail howard
      or the tapestry mailing list about this? If his code DOES truncate divs to
      save space, it's a pretty big Tapestry bug since truncated divs don't render
      properly on Firefox 1.0 or 1.5. I also seem to remember a few other browser
      choke on that, possibly Opera. It would help us and other developers if the
      Tapestry framework didn't do this type of thing.

      Anyways, log it with the Tapestry list or don't. Your   hack fixed the
      problem (for now).

        Activity

        Hide
        Andreas Andreou added a comment -

        At least i am aware of this - it's the reason why DropdownDatePicker and family render
        <div ...> </div> (notice the space between the tags, no need for  )

        Now, it's not Tapestry's fault - we correctly render both opening and closing tags

        It's Mozilla's xml parser that automatically does such a change when treating an xml document (and
        that's what the ajax response is).

        A similar issue occurs with textarea's and FF but we specifically handle this case by postprocessing
        the response.

        But, let me describe an alternative solution that should handle this.

        In tacos 4.0.x, due to some bugs in IE with several html entities( i think ´ and such)
        in ajax responses, we changed the way html is included in the response...
        instead of it being an xml node, it's now a CDATA and (of the top of my head) i can only
        see benefits for this.

        no textarea, or empty divs transformations, no valid html but invalid xml issues (think <br>),
        no need to transform the xml node to string... in fact i dont remember if we need that part as
        an xml node at all !

        PS I'm noty even the inventor of the CDATA idea - i think it originated from Viktor

        Show
        Andreas Andreou added a comment - At least i am aware of this - it's the reason why DropdownDatePicker and family render <div ...> </div> (notice the space between the tags, no need for  ) Now, it's not Tapestry's fault - we correctly render both opening and closing tags It's Mozilla's xml parser that automatically does such a change when treating an xml document (and that's what the ajax response is). A similar issue occurs with textarea's and FF but we specifically handle this case by postprocessing the response. But, let me describe an alternative solution that should handle this. In tacos 4.0.x, due to some bugs in IE with several html entities( i think ´ and such) in ajax responses, we changed the way html is included in the response... instead of it being an xml node, it's now a CDATA and (of the top of my head) i can only see benefits for this. no textarea, or empty divs transformations, no valid html but invalid xml issues (think <br>), no need to transform the xml node to string... in fact i dont remember if we need that part as an xml node at all ! PS I'm noty even the inventor of the CDATA idea - i think it originated from Viktor

          People

          • Assignee:
            Jesse Kuhnert
            Reporter:
            Jeremy F. Kassis
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development