Loading ...
Sorry, an error occurred while loading the content.

YUI 2.5.1 wants PERFECT HTML, and other 2.5.1 comments...

Expand Messages
  • bretlevy
    Just a note that might help others along the way... I have been debugging several new issues with a very large complicated web app I developed using YUI 2.5.1.
    Message 1 of 3 , Mar 31, 2008
    • 0 Attachment
      Just a note that might help others along the way...

      I have been debugging several new issues with a very large
      complicated web app I developed using YUI 2.5.1. I started the
      application development with an early 2x version YUI (2.3.0 or
      earlier). Each update of YUI has been fairly painless except the
      2.4.1 version that brought along the IE memory problem (kudos to the
      team for fixing it right away and getting 2.4.1 out quickly).

      2.5.1 has been a unique experience. Several problems have surfaced,
      and I have been able to work around all of them (with much community
      help, of course), so if anyone else has these troubles, here are
      the "fixes":

      1. Several YUI elements failed to work or display properly (calendar,
      for example) -- I found that I had a <div> nesting error that seems
      to have caused no problem until now (no browser or YUI problems).
      However, in YUI 2.5.1, it simply would not display the calendar (just
      a transparent grid would show up where the calendar should be), but
      the rest of the page, including all my Panels, worked and looked
      fine. ERGO, make sure your html is perfect. If like me, much of
      your page is generated by a server-side scripted framework, take the
      OUTPUT of a page (view source in browser) and save that as a plain
      HTML page and post to a test area of your site and use the W3C
      validator to find your errors.

      2. Menubars that are not statically placed will get a 10-
      pixel "buffer" in front of them causing them to move to the right
      slightly. I actually fixed this by doing something bad -- I set the
      x position in my config block like this; x:"0px". The team tells me
      I really shouldn't have done that, but it does fix the problem. The
      CORRECT solution is to statically position the menubar.

      3. Pre-251, YAHOO.widget.DataTable.initializeTable() took an argument
      which was (optionally) the new data to load into the table. 251
      eliminates that parameter, and initializeTable no longer will rebuild
      the table with new data (after it is called, the table will be
      empty). Use Yahoo.widget.DataTable.getRecordSet().replaceRecords
      (oData) instead.

      4. After doing table work (like in the example above), you need to
      call the render method of the table object. This was not necessary
      (at least for the actions I was performing) before.

      5. There appears to be some (additional) sensitivity to the order of
      the loaded css and js files. Pre-251, things that worked just
      displayed blank pages under 251. After using the wonderful YUI
      configurator tool, I was able to figure out why my YUI configurator
      (I use a custom PHP class as part of my framework to set the proper
      includes for each page based on what is needed by the page)
      was "wrong". Either use their configuration tool to get the exact
      correct includes, or make sure that your logic maintains a compatible
      ordering. I was able to see this problem in Firefox's error console
      where a YUI message was telling me that a required dependency wasn't
      loaded.

      6. Table scrolling in 2.5.1 may not meet your expectations. If you
      have a particularly large data set (more than 20-30) items, and/or
      each data set is more complex than a few simple fields, you may get
      very undesirable results when building a scrolling table (that is, a
      table with fixed headers). My test with approximately 400 rows of
      data in a TYPE_JSARRAY data source took 90 seconds (or so) to
      render. Based on input from the team, I added a renderLoopSize, but
      that DOUBLED the render time! The net affect is that the background
      code is doing way too much work (in my case) to render the table and
      figure out the fixed header. If your table has fixed column widths,
      you MAY NOT be penalized (as much or at all). Please test! Your
      results may vary. Batteries not included.

      There may have been a few other minor issues.

      On the plus side, 251 seems much more responsive to me under normal
      use. Some elements have been cleaned up nicely (colorpicker for
      example seems particularly buttoned up -- it had some loose edges
      before). There are also a great deal more options with many of the
      elements, such as the paginator functions and the added calendar
      controls).

      I am so trusting of it and the team at this point that I have
      switched to the "min" versions of the js files! That means no more
      debugging even if I wanted to!!!! ;-)

      Good luck all,

      ~~bret
    • alexhusic
      Hi Bret, first of all, thank you very much for the entry which pinpointed a problem I couldn t solve: menu dynamically positioned always sitting a dozen
      Message 2 of 3 , Sep 29, 2008
      • 0 Attachment
        Hi Bret,

        first of all, thank you very much for the entry which pinpointed a
        problem I couldn't solve: menu dynamically positioned
        always "sitting" a dozen pixels away from the left browser edge. I
        have tried your solution, but my menu simply disappears. I believe
        you used cofig property x:"opx", or is it x:"0px"? I've tried both,
        always with the same result - disappearing menu. I would have
        positioned the menu statically, but than it always comes up on top of
        all the other elements and I actually need it to be below a 20px high
        green banner line. If you have any pointers that could help me, I'd
        be grateful.

        Best regards

        Alex



        --- In ydn-javascript@yahoogroups.com, "bretlevy" <bret@...> wrote:
        >
        >
        > Just a note that might help others along the way...
        >
        > I have been debugging several new issues with a very large
        > complicated web app I developed using YUI 2.5.1. I started the
        > application development with an early 2x version YUI (2.3.0 or
        > earlier). Each update of YUI has been fairly painless except the
        > 2.4.1 version that brought along the IE memory problem (kudos to
        the
        > team for fixing it right away and getting 2.4.1 out quickly).
        >
        > 2.5.1 has been a unique experience. Several problems have
        surfaced,
        > and I have been able to work around all of them (with much
        community
        > help, of course), so if anyone else has these troubles, here are
        > the "fixes":
        >
        > 1. Several YUI elements failed to work or display properly
        (calendar,
        > for example) -- I found that I had a <div> nesting error that seems
        > to have caused no problem until now (no browser or YUI problems).
        > However, in YUI 2.5.1, it simply would not display the calendar
        (just
        > a transparent grid would show up where the calendar should be), but
        > the rest of the page, including all my Panels, worked and looked
        > fine. ERGO, make sure your html is perfect. If like me, much of
        > your page is generated by a server-side scripted framework, take
        the
        > OUTPUT of a page (view source in browser) and save that as a plain
        > HTML page and post to a test area of your site and use the W3C
        > validator to find your errors.
        >
        > 2. Menubars that are not statically placed will get a 10-
        > pixel "buffer" in front of them causing them to move to the right
        > slightly. I actually fixed this by doing something bad -- I set
        the
        > x position in my config block like this; x:"0px". The team tells
        me
        > I really shouldn't have done that, but it does fix the problem.
        The
        > CORRECT solution is to statically position the menubar.
        >
        > 3. Pre-251, YAHOO.widget.DataTable.initializeTable() took an
        argument
        > which was (optionally) the new data to load into the table. 251
        > eliminates that parameter, and initializeTable no longer will
        rebuild
        > the table with new data (after it is called, the table will be
        > empty). Use Yahoo.widget.DataTable.getRecordSet().replaceRecords
        > (oData) instead.
        >
        > 4. After doing table work (like in the example above), you need to
        > call the render method of the table object. This was not necessary
        > (at least for the actions I was performing) before.
        >
        > 5. There appears to be some (additional) sensitivity to the order
        of
        > the loaded css and js files. Pre-251, things that worked just
        > displayed blank pages under 251. After using the wonderful YUI
        > configurator tool, I was able to figure out why my YUI configurator
        > (I use a custom PHP class as part of my framework to set the proper
        > includes for each page based on what is needed by the page)
        > was "wrong". Either use their configuration tool to get the exact
        > correct includes, or make sure that your logic maintains a
        compatible
        > ordering. I was able to see this problem in Firefox's error
        console
        > where a YUI message was telling me that a required dependency
        wasn't
        > loaded.
        >
        > 6. Table scrolling in 2.5.1 may not meet your expectations. If you
        > have a particularly large data set (more than 20-30) items, and/or
        > each data set is more complex than a few simple fields, you may get
        > very undesirable results when building a scrolling table (that is,
        a
        > table with fixed headers). My test with approximately 400 rows of
        > data in a TYPE_JSARRAY data source took 90 seconds (or so) to
        > render. Based on input from the team, I added a renderLoopSize,
        but
        > that DOUBLED the render time! The net affect is that the
        background
        > code is doing way too much work (in my case) to render the table
        and
        > figure out the fixed header. If your table has fixed column
        widths,
        > you MAY NOT be penalized (as much or at all). Please test! Your
        > results may vary. Batteries not included.
        >
        > There may have been a few other minor issues.
        >
        > On the plus side, 251 seems much more responsive to me under normal
        > use. Some elements have been cleaned up nicely (colorpicker for
        > example seems particularly buttoned up -- it had some loose edges
        > before). There are also a great deal more options with many of the
        > elements, such as the paginator functions and the added calendar
        > controls).
        >
        > I am so trusting of it and the team at this point that I have
        > switched to the "min" versions of the js files! That means no more
        > debugging even if I wanted to!!!! ;-)
        >
        > Good luck all,
        >
        > ~~bret
        >
      • bretlevy
        Just put the div right in the document flow (below the banner) and it should work. Make the div look like this: blah, blah, blah
        Message 3 of 3 , Sep 29, 2008
        • 0 Attachment
          Just put the div right in the document flow (below the banner) and it
          should work. Make the div look like this:

          <body>
          <div id="banner"> blah, blah, blah </div>
          <div id="menudiv" style="position:static;"></div>

          And make sure you render your menu into the menudiv.

          Your menu should appear below the "banner" as in my site(s). See:

          http://corp.bluelinkdirect.com

          (You won't be able to login or do anything, but you can see the menu
          bar below the banner...)


          ~~bret




          --- In ydn-javascript@yahoogroups.com, "alexhusic" <alexhusic@...>
          wrote:
          >
          > Hi Bret,
          >
          > first of all, thank you very much for the entry which pinpointed a
          > problem I couldn't solve: menu dynamically positioned
          > always "sitting" a dozen pixels away from the left browser edge. I
          > have tried your solution, but my menu simply disappears. I believe
          > you used cofig property x:"opx", or is it x:"0px"? I've tried both,
          > always with the same result - disappearing menu. I would have
          > positioned the menu statically, but than it always comes up on top
          of
          > all the other elements and I actually need it to be below a 20px
          high
          > green banner line. If you have any pointers that could help me, I'd
          > be grateful.
          >
          > Best regards
          >
          > Alex
          >
          >
          >
          > --- In ydn-javascript@yahoogroups.com, "bretlevy" <bret@> wrote:
          > >
          > >
          > > Just a note that might help others along the way...
          > >
          > > I have been debugging several new issues with a very large
          > > complicated web app I developed using YUI 2.5.1. I started the
          > > application development with an early 2x version YUI (2.3.0 or
          > > earlier). Each update of YUI has been fairly painless except the
          > > 2.4.1 version that brought along the IE memory problem (kudos to
          > the
          > > team for fixing it right away and getting 2.4.1 out quickly).
          > >
          > > 2.5.1 has been a unique experience. Several problems have
          > surfaced,
          > > and I have been able to work around all of them (with much
          > community
          > > help, of course), so if anyone else has these troubles, here are
          > > the "fixes":
          > >
          > > 1. Several YUI elements failed to work or display properly
          > (calendar,
          > > for example) -- I found that I had a <div> nesting error that
          seems
          > > to have caused no problem until now (no browser or YUI
          problems).
          > > However, in YUI 2.5.1, it simply would not display the calendar
          > (just
          > > a transparent grid would show up where the calendar should be),
          but
          > > the rest of the page, including all my Panels, worked and looked
          > > fine. ERGO, make sure your html is perfect. If like me, much of
          > > your page is generated by a server-side scripted framework, take
          > the
          > > OUTPUT of a page (view source in browser) and save that as a
          plain
          > > HTML page and post to a test area of your site and use the W3C
          > > validator to find your errors.
          > >
          > > 2. Menubars that are not statically placed will get a 10-
          > > pixel "buffer" in front of them causing them to move to the right
          > > slightly. I actually fixed this by doing something bad -- I set
          > the
          > > x position in my config block like this; x:"0px". The team tells
          > me
          > > I really shouldn't have done that, but it does fix the problem.
          > The
          > > CORRECT solution is to statically position the menubar.
          > >
          > > 3. Pre-251, YAHOO.widget.DataTable.initializeTable() took an
          > argument
          > > which was (optionally) the new data to load into the table. 251
          > > eliminates that parameter, and initializeTable no longer will
          > rebuild
          > > the table with new data (after it is called, the table will be
          > > empty). Use Yahoo.widget.DataTable.getRecordSet().replaceRecords
          > > (oData) instead.
          > >
          > > 4. After doing table work (like in the example above), you need
          to
          > > call the render method of the table object. This was not
          necessary
          > > (at least for the actions I was performing) before.
          > >
          > > 5. There appears to be some (additional) sensitivity to the order
          > of
          > > the loaded css and js files. Pre-251, things that worked just
          > > displayed blank pages under 251. After using the wonderful YUI
          > > configurator tool, I was able to figure out why my YUI
          configurator
          > > (I use a custom PHP class as part of my framework to set the
          proper
          > > includes for each page based on what is needed by the page)
          > > was "wrong". Either use their configuration tool to get the
          exact
          > > correct includes, or make sure that your logic maintains a
          > compatible
          > > ordering. I was able to see this problem in Firefox's error
          > console
          > > where a YUI message was telling me that a required dependency
          > wasn't
          > > loaded.
          > >
          > > 6. Table scrolling in 2.5.1 may not meet your expectations. If
          you
          > > have a particularly large data set (more than 20-30) items,
          and/or
          > > each data set is more complex than a few simple fields, you may
          get
          > > very undesirable results when building a scrolling table (that
          is,
          > a
          > > table with fixed headers). My test with approximately 400 rows
          of
          > > data in a TYPE_JSARRAY data source took 90 seconds (or so) to
          > > render. Based on input from the team, I added a renderLoopSize,
          > but
          > > that DOUBLED the render time! The net affect is that the
          > background
          > > code is doing way too much work (in my case) to render the table
          > and
          > > figure out the fixed header. If your table has fixed column
          > widths,
          > > you MAY NOT be penalized (as much or at all). Please test! Your
          > > results may vary. Batteries not included.
          > >
          > > There may have been a few other minor issues.
          > >
          > > On the plus side, 251 seems much more responsive to me under
          normal
          > > use. Some elements have been cleaned up nicely (colorpicker for
          > > example seems particularly buttoned up -- it had some loose edges
          > > before). There are also a great deal more options with many of
          the
          > > elements, such as the paginator functions and the added calendar
          > > controls).
          > >
          > > I am so trusting of it and the team at this point that I have
          > > switched to the "min" versions of the js files! That means no
          more
          > > debugging even if I wanted to!!!! ;-)
          > >
          > > Good luck all,
          > >
          > > ~~bret
          > >
          >
        Your message has been successfully submitted and would be delivered to recipients shortly.