Part 1:
There is a really interesting debate going on at the moment on these forums over the structure of the code generated by Xara’s WD HTML export.

From the coder’s point of view, the tag soup HTML is not very useful if you want to edit the code or make use of it elsewhere. From the WYSIWYG point of view, the code structure is irrelevant and what is seen and experienced by the user at design time and in browsers is all that’s important.

Web Designer (WD) was designed to approach the creation of websites differently to the historical method of hand coding or editing HTML text; it was intended to allow maximally-precise WYSIWYG creation of websites using a graphical interface and without having to know or see any HTML code at all, thereby modernising and maturing the creation of websites and making it possible for the masses. The design is such that any edits to HTML are thus to be done in WD and not an HTML editor. This of course limits the HTML output to only what WD can support in this version.

It seems to ensure maximum WYSIWYG output, of many tried methods of HTML code structure, the one implemented produced the most similar results in browsers to what was seen in WD, thereby satisfying WYSIWYG criteria better. The code structure is very different from how it would look if hand coded and, as a consequence, is much less well formatted or layout-efficient, and is the primary cause for complaint by coders. Most modern websites are graphics dominated than text dominated; the additional overhead this different and less efficient HTML structure brings is very small in terms of what is measured at download time in such common graphics-dominated situations, with the time taken to download a typical HTML file being less than the time taken to download even the smallest single graphic image. Therefore this additional overhead is not a valid criticism of WD’s HTML code structure choice.

If the user is only ever to use WD to make graphics dominated websites (which applies to the majority of the target audience) then the internal HTML structure is completely and utterly irrelevant. Given that this is only what WD was designed for, the criticisms by coders about the HTML structure are completely invalid when placed in context. It seems as though coders are complaining about the code simply because it’s different and relatively inefficient (but immeasurably practically so at browse time), but totally failing to appreciate the situation—which is the new approach to website making within the limits of the goals of WD. I've seen no evidence that the code structure is in any way significantly worse than if coded by hand from an observer’s point of view when viewing the page in a browser.

Text heavy sites may be a different story however, it may be argued; the tag-soup overhead may increase substantially to increase HTML file sizes. But this is unlikely to be so significant as to cause browsing problems; my own website is extremely text heavy (tens of thousands of words—far bigger than most text heavy sites I’d bet, and only 10% complete) with pretty large HTML files as far as HTML file sizes go, yet the site loads very fluidly, confirming my point completely.

The hostility to the WD generated HTML seems to stem from the unique history of HTML; unlike say the analogue of not hand coding PDF document layout anymore (if at all), coding HTML has always had a set-in-stone approach of hacking HTML at a textual level. When such familiarity is subjected to (innovative) change whereby something familiar has to be relearned, such that there's an initial shred of effort required to get the same results until the new process is learned, there is bound to be resistance. But it’s also the apparent rape of the familiar ‘art’ of HTML hacking that coders seem to be having personal issues with, causing the furore, rather than there being any measurable substance to the criticisms. The code is different and less efficient (artistic), therefore it’s deemed bad, but this totally misses the point of the new approach, which is HTML editing entirely within WD without ever seeing code at all.

If WD’s code isn’t suitable for subsequent editing (going against the whole point of using WD to generate it), then don’t use WD to create the code—it’s so easy. Xara have even alluded to this by devoting a part of the marketing section of their website to the benefits WD can offer to ‘professional’ website makers (a.k.a. old fashioned died-in-the-wool code-head HTML hackers), by allowing working, dynamic mock-ups instead of static Photoshop mock-ups.