Where's the HTML and where's the structure?

**Charles Moir** · 06 March 2009, 01:23 AM

Well said cursor.

**covoxer** · 06 March 2009, 05:45 AM

You guys don't stop writing even when I sleep, eh?

Answers shall follow.

**covoxer** · 06 March 2009, 06:11 AM

Originally Posted by Hexen53

For me, I would rather they can manage by themselves - perhaps another reason why XWD is not so suitable in these circumstances.

You think they can't edit your design in WD and upload when needed? Is it more complex than HTML editors?

Originally Posted by Hexen53

As for structure, how about a discography page for the band?
<h1>Satan's Kittens - Discography</h1>

<h2>Album 1 - Black Metal Psychos</h2>
<p>Recorded 1999 at Hell Studios</p>
<ul>
<li>Track1 - Crap overdose</li>
<li>More Crap</li>
</ul>

<h2>7" Single - We Are Sorry</h2>
<p>Recorded 2000 at Kitten Central</p>
<ul>
<li>Track1 - Love overdose</li>
<li>More Love</li>
</ul>

This part has applied structure in code. But it does'n describe how this will look. It is somwhere else, in stylesheet. So, actually, this example of yours can easily look as plain, not structured and not formatted text for the user. Of couse, noone uses such css, but this is exactly what I say - user don't see this structure directly, he don't read source and he can't know there's <h1> or <li>. He only see what's rendered by the browser. And this particular piece of html does not explicitly describe how this will be rendered.
But if you provide the stylesheet along with this code, both will describe the outlook much better. But in result it is the same thing the WD does, only WD do it directly, without any intermediate syntax elements. It just doesn't need it to simplify html coding process. So actually, it is even more efficient form the technical point of view.

**covoxer** · 06 March 2009, 06:28 AM

Originally Posted by Hexen53

Zoom into your page 500% (some people may need it) and where is your design?

And where will be any other design with text scalling set to 500%? How nice will it be to still fit all the 3 columns of text on screen if every one of them fits a word or two in line? With dynamic layout and text scaling, you'll avoid horizontal scrolling, but you'll get more of vertical scrolling, and unpredictably looking design. The static design will not change. To grasp the overal look and layout, people can zoom out and then zoom in to the area of interest to reed the text. This quite natural process.

Often visually impaired users will just want the text in a very large font, in their preferred colours - structure helps.

Well, if you don't mind losing the layout, you still can override how the page is rendered for example in Opera.

Two or three times I have come under criticism for providing pdfs on my organization's website as visually impaired users find them harder to work with than Word docs - even though you can zoom in 1000s of times in a pdf!

And this is another question. The accessibility means that constrained people can read information, it does not require it to be of highest level of comfort. If someone really needs to create sites that are not only readable but also easily and comfortably readable by visually impaired readers, he can create special copy of the site for them. This is only really working solution. And many do this, you can find text version of the site on many sites. You can even provide it in downloadable form in any format you like. Anyway, the nice graphical design, with many columns and blocks of text, with all redundant decorations, images and other design elements is hard to read by impaired people regardless of it's internal structure.

**covoxer** · 06 March 2009, 07:13 AM

Originally Posted by remi

I'm sure you will see a lot of complaints over the next weeks because of that, after the first euphoria has ended. We're trying to explain John (covoxer) and Charles, that they should not ignore the well known ideas behind semantic HTML and Web accessibility.

Remi, there are always complaints whatever you release. I have never seen software that users had no complaints to it. Of course there will be complaints regarding code generated by WD. But if we wouldn't produce this code, there would be much more complaints form users regarding wrong text positioning and why their designs fall apart in browser. Currently, we can't avoid both, so we are trying to avoid the most critical one. I'm sure you understand.

BTW Even though the WD code is still static and such, if you look at it and compare it to code produced by XXP4, you may notice that there are quite a few improvements, including some changes that we were discussing with you after XXP4 release. Remember?

So we are not ignoring this aspect, we just can't radically sacrifice the main concept to it, and as a result produce one more semi-WYSIWYG-wannabe, html authoring tool, which are numerous out there these days.

**covoxer** · 06 March 2009, 07:14 AM

Originally Posted by remi

The point is, you shouldn't export such a div tag soup like the current one for the users of your software.

Well, for the most users it is expected that they shall never look into that code. Fr others, who use WD for prototyping, it's mostly irrelevant since they create the resulting product from the scratch. Yet there is still a small number of users who may want to export html and the tweak it in html editor. For them, we implemented easily readable layout of the html code. Even not experienced users are able to locate elements of interest in exported html. The soup you are talking about is a great exaggeration. There are div per every text line and that's it. No soup. No spaghetti. Text blocks are clearly visible and locatable in the notepad, never mind the syntax highlighting editor.
But there's no way to easily tweak static html into dynamic. And the problem is far not in the soup of divs. The absolute positioning of all elements (graphics) will make it a nightmare except for very primitive basic designs. So no one should really try to tweak WD exported html this way.

Furthermore Xara Web Designer customers shouldn't need to use "placeholders", in order to get simple HTML.

Well, actually we would be glad to remove the placeholder feature altogether, would there be any other way for users to work with snippets. But there's none. Everything is represented as a part of html code, so we had to provide a way to use that part of code. Why placeholder? Simply - this is the only way to place that code where you want on a page. Since all the other design is absolutely positioned, you cant just enter code into <body>, it will overlap with design. Besides, why should anyone manually calculate and enter position of his snippet into the code if we can do it visually for him?
Of course you don't believe me from the coders point (I know, I'm a coder myself

), but placeholder approach is much more intuitive and easier to learn and use correctly by not experienced users.

Why do you think your absolute positioned HTML is the only way to let it look exactly how I want it in different browsers?

We don't think, we know it. Because we have tried all the other ways. In the early versions of the html filter for XXP4, the text was exported as a single div, with paragraphs in <p>. But we had to abandon it because it was not acceptable.

I say, please try it harder the next time

No way to try harder. We alredy did it very hard. As a result, we had to redesign the text export completely because it was a dead end street. There's no way to get precise positioning of the text withot making it as explicit as we do. The problem is not that Xara render text differently from browsers, the problem is that every browser does it differently. It is possible to get close to wysiwyg, but this is acceptable only with small and simple text. The longer the column is, the more you get not what you see. I shall not explain all the dirty details here, but most of the text layout options are implemented very unsatisfactory in all browsers (Safari is a nice exception as it does text rendering much better than all others that use windows text engine, but still is not perfect). There is W3C specification, of course. But reading carefully you'll find that most of the text related features are documented loosely, so that the result is allowed to be browser specific. In other word, strictly speaking, W3C HTML specification is not WYSIWYG. So, of course, following non wysiwyg coding guidelines is not a best way to achieve wysiwyg result, is it?

same styles in a stylesheet, instead of repeating them in the HTML markup.

This makes no sense while the styles concept is absent in editor. But it is in whish list I believe.

**Markku** · 06 March 2009, 08:37 AM

Just want to express my support for the approach Xara dev's have taken in developing XWD.

For my work XWD works perfectly. I do web UI wireframes, visual design and prototypes and I expect the html to work wysiwyg. Easily, predictably, and without too much effort to avoiding html errors.

I have tried other visual html tools like Serif WebPlus and I am using Adobe Fireworks. Neither of them produces code that the coders in my company would accept and neither of them produces wysiwyg html that I would accept.

The only way to produce coder compliant html code is to do it manually, or with the help of html editors like dreambeaver or expression web. I work with UI coders that are always holding their noses up for anything that is not done according to all possible web requirements. There is no point in trying to please them. Let them have their job!

For guys like me or for "ordinary" people making their own web sites XWD is the ideal solution. Fast, easy and wysiwyg.

Keep it up Xara! You are doing it right.

**remi** · 06 March 2009, 01:50 PM