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.
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:
- The creation of extra containers when they wouldn't be necessary if I were hand coding the page.
- The output code is not always XHTML valid. Sometimes the export engine creates duplicate id's for the auto generated "colwrap" containers.
- The CSS files, even for simple layouts, are thousands of lines long.
- There is no notion of "class grouping". If you name items the same, FW export appends numeric values to make them all unique ids.
- 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.