2 Replies Latest reply on Dec 17, 2009 10:42 AM by endertech

    How to Eliminate Annoying "colwrap" Divs


      So, as promising as the CSS export feature of Fireworks CS4 seems to be, we here at EnderTech are still finding ourselves having to do a lot of  work to fix its XHTML & CSS output so that templates meet our standard for XHTML quality and semantic clarity.


      My primary annoyance (at the moment), is that FW likes to create all these automated divs with ID's like "colwrap", and I can't figure out the logic behind their creation... so that I can avoid it by following some FW best practices.


      If anyone knows of FW best practices so that only divs I intend to create are created, please enlighten me!


      Here is what I've determined so far:


      1) If you create a simple set of non-overlapping containers (rectangles) on the canvas and then export, you'll get a good looking XHTML document with logical divs named as you'd expect.


      2) If you then add one sub-container rectangle inside one of your primary containers and then export, again, you'll get a good looking XHTML document with a hierarchical div structure as you'd expect.


      3) If you then add a second sub-container rectangle inside your primary container and adjacent to your previous sub-container and then export, all of a sudden you get all these "colwrap" divs surrounding your containers.


      WHY?!?! How to avoid?


      I've attached a simple PNG file with two pages to demonstrate. Simply export the two pages and compare the HTML.

        • 1. Re: How to Eliminate Annoying "colwrap" Divs
          Linda Nicholls Level 4

          Don't expect Fireworks markup to be as sophisticated as Dreamweaver's. It was designed for creating web graphics. The code it produces is meant to be used for prototypes rather than fully developed web pages.

          • 2. Re: How to Eliminate Annoying "colwrap" Divs
            endertech Level 1

            Hi Linda.


            Thanks for the response!


            Ya, I can see that, but clearly the FW dev team is working towards a more robust export mechanism that outputs quality XHTML / CSS.... so I figure they might as well just go the whole mile.


            I'm sure there are all sorts of technical difficulties involved in calculating relative positions of divs, especially considering the flexibility FW gives you in design... but nevertheless... from a purely logical perspective, I'm sure there is a way to avoid the creation of extra containers that the user did not intend.


            My current complaints with the export mechanism are:


            1. The creation of extra containers when they wouldn't be necessary if I were hand coding the page.
            2. The output code is not always XHTML valid. Sometimes the export engine creates duplicate id's for the auto generated "colwrap" containers.
            3. The CSS files, even for simple layouts, are thousands of lines long.
              1. There is no notion of "class grouping". If you name items the same, FW export appends numeric values to make them all unique ids.
              2. It would be ideal for the system to identify objects that have the same name, identify any similarities between those objects, and then put all those similarities in a single CSS class identifier, while putting the DIFFERENCES in their own ID identifiers.


            At any rate, FW is still great for rapid prototyping... but it will be excellent, when I don't have to spend hours refactoring its CSS / XHTML output. As it is... I think we will just end up avoiding that feature and building our XHTML & CSS by hand.... as we've done for years.


            So really, this new feature isn't buying us more time... which was my hope.