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

[covoxer]

Well, it looks like it's a time to talk about concepts. So the straight answer to the question: "Where's the HTML and where's the structure?" is "Somewhere inside a black box which you should not care about."
Do you also ask where is the "PostScript code" when you create graphics? I don't think so. Our approach is to eliminate the need of designer to see or alter any code at all. And to stop him worry about how it looks. After all, what's important is - how you design it, and how users see it. Why should designers or users care about how it is processed by their hardware/software? This is a problem of the programmers.
As I say, this is a concept. We feel that html is mature enough to close it's childhood page and get rid of manual editing. Most information types has grown through this stage - first raster images were coded manually on per pixel basis but no one does this today, first formatted text was coded manually (quite similar to html), but no one does this today, PostScript was edited manually but none does it today...
Yes, there is a strong dominating trend that html has and is supposed to be created manually (or near so). There even a lot of "guidelines" and "rules of thumb" mostly created by the mature, highly experienced html coders. But then again - this all is like advices on how is it better to write your RTF or LaTeX well formatted book using a plain text editor. As soon as you get Word, you don't need them any more.
The WD is a first step in this direction.

[covoxer]

Now some comments.

So far as I can see there is no easy way to insert basic HTML - paragraphs <p>, headings <h1>, <h2> etc and where are the bulleted lists <ul> and <ol>?
Aside from the obvious use of bulleted lists they are also a means of structuring navigation menus. XWD is the only web tool I have seen that does not have the familiar toolbar button to add a bulleted list.
Headings are used to give levels of importance to the text and should, if done properly, give the document a structure. When I look at the code for any of the template pages, all the text is split into DIVs - not headings, sentences or paragraphs, just snippets of text. When a human looks at that web page the structure is obvious but for Google and screen readers there is nothing in the HTML to indicate the structure of the document!

When you read a hard printed book, how do you denote structure? There are no hidden tags. The Google, of course need hints, but what for? The rating of your site is mostly determined not on the structure of your html but on the relations from other sites.
After all, the final goal of site creation is to make reader see what we want him to see. He will not open document source to find out that this particular line of text is marked as a header right? So only outlook has a meaning.

What about tables? Okay they get bad press but that is because they have been misused for years, as a method of structuring and designing a web page rather than for their original purpose of providing a means to layout tabular data. Tables have tags to denote titles and headings, giving structure and meaning to tabular content - how is this to be achieved correctly in XWD

There's no need in table if you can place anything anywhere. Well, the tables implementation in editor (like in Word) is useful to simplify creation of large regular tables, but why should anyone care how this is represented within the html as long as reader see exactly what you want him to see?

It is possible to use placeholders to insert HTML but it seems strange that it is easier to insert rotated text in a fancy box and see the end result as you edit than it is to insert a simple bulleted list or heading that has to be previewed to see the end result.

Exactly! It is "strange" because of the habits you have. You need bullet? Draw one! Just like we all learn from the childhood. If you want to see something - draw it! That simple. You can do it easily in WD, but as you want to add similar shape somewhere else with different purpose, it's still just as simple in WD, but a lot of pain in html coding approach. After all, the bullets are just automation of one of the hard cases. While drawing software is an automation for all possible cases.

It is considered good practice to keep the formatting of a document separate from the document content. CSS should be in an external style sheet and inline styles should be avoided.

That's right - this is one of those rules of thumb useful for hand coding. But if do not hand code this becomes completely meaningless. Just like a source tab formatting of the RTF when you use Word to edit it.

There are accessibility issues with the use of fixed font sizes.

This is partly true. Mostly for old browsers that do font scaling. New browsers zoom entire page which is a real solution of the accessibility problem. The font scaling is a relict form times of Mosaic when computers were simply too slow, and browser software to primitive to be able to scale graphics.
Besides, taking this approach, all printed materials have much more accessibility issues.

The HTML is not easy to read and

Because it is created for browsing, not for reading.

harks back to the bad old days of Frontpage.

This is not true. We produce W3C compliant XHTML code. It's quality is actually higher then most sites you have out there, including many large ones.

I am concerned about the non-standard method of coding the web pages.

WD is not a tool for coding web pages, but for designing them.
If you want to enjoy the process of coding - you have to use other tools.

[Spinny]

I sense a religious war brewing...

[MikeM]

It is really simple to sort this, design and build the site exactly how you want it, QUICKLY, save it and open it up again in DW or EWeb to do any tweaks you fancy. This works perfectly.

[dogbertbh]

Just like we all learn from the childhood. If you want to see something - draw it! That simple.

THIS is what I like about the whole process.

I can't code, but that doesn't mean I'm not creative enough to draw.

[Hexen53]

My arguments are not about whether it is better to be able to code by hand or use a WYSISYG app. Whichever method you use there will be an HTML page, full of code. My argument is about the lack of HTML and structure in WXD pages.

The W3C develop the HTML language and they determine what the vocabulary is and how it should be used. They give us ways to identify headings, bullets, tabular data etc. The tags are there for good reason.

XWD has done away with the vocabulary of HTML and just uses positioning divs and fixed font sizes. So, why is that a problem?

I stated earlier that most people would be able to determine headings, bullet points, structure etc of a web page just by looking at it and that has been pointed out again in a few other posts. However, there are many people who can't look at a web page - no matter how big the font is. Blind and seriously visually impaired people use screen reading software to help them get content from the web - screen reading software actually reads the HTML content of the web page, not the screen itself - see the link below as to why we need to have headings, bulleted lists etc and why structure is important.

http://www.webcredible.co.uk/user-fr...-readers.shtml

It is also worth mentioning that in many cases it is a legal requirement to make websites accessible - see the RNIB site http://www.rnib.org.uk/xpedio/groups...legalcase.hcsp

MikeM - I tried exporting and then editing in EW2 but I won't be doing that again

Covoxer - You make a lot of good points but why should I have to draw my own bullets when HTML provides nestable ordered and unordered lists with definable bullet characters, including images? Xara make a point of avoiding bullets in their software - you can't DTP them either!

• Bulleted lists
• are great
• and even
• this editor supports them!

as easy as

1. one
2. two
3. three

Ron

[Charles Moir]

No one argues that having automatic bullet or numbered lists would be a worthwhile addition. It's on the wish-list. It will get done at some point.

But I'd argue that the point about HTML structure is not valid. The tags only exist because back-along you created websites by hand, hacking the HTML and the only way to add a heading (or something as simple as italic) was by adding embedded tag commands. They only exist through a dint of history. It was the exactly same with old word processors, before they went WYSIWYG. Same with DTP programs, but how many people use TeX now? WYSIWYG design tools have made the whole manual mark-up redundant.

There is no value in having HTML 'structure'. Search engines do not use it - they care only about the text (some people mistakenly believe, and spread the myth, that is matters to search engines - it does not). All they care about is that text. By all accounts Google doesn't even look at very specific metadata, the keywords metatag, so they are not going to pay attention to <H1>. There is no value in the 'vocabulary of HTML' as you put it.

So in fact as and when we implement easy bullet lists we probably will not do it with the <li> tag even, but our own way so that designers have accurate, predictable, WYSIWYG lists. I can see little value in using the <li> when what people really care about is that the lists looks right, and exactly as they intend on all browsers.

As to the 'accessibility' point this is mute point as all mainstream browsers have moved to full page zoom where everything on the page zooms (like in Xara). This is a better solution for everyone, blind or not, because then everything gets bigger in proportion and you can zoom into graphics, photos and text. And designers are happy because their page remains completely intact as intended, just bigger.

So the only browser that do not implement full page zoom (Chrome and Safari) are switching to it real soon now. Problem solved.

[remi]

As to the 'accessibility' point this is mute point as all mainstream browsers have moved to full page zoom where everything on the page zooms (like in Xara). This is a better solution for everyone, blind or not, because then everything gets bigger in proportion and you can zoom into graphics, photos and text. And designers are happy because their page remains completely intact as intended, just bigger.

Ron (Hexen33) was talking about blind people. Blind people will not zoom (they are not able to interprete your generated DIV tag soap, if they zoom in or out, because they are blind).

Remi

[nickydude]

I thought that was a bit of an odd paragraph. 'As long as you can zoom right in, blind people should be ok.' http://www3.b92.net/ipb_images/style...efault/huh.gif

[covoxer]

Some good points Ron. Especially regarding accessibility. It's true that there are blind people that use voice readers browsing html. But it's not true that simply adding headers or bullets automatically makes a page perfectly readable by them. It much more depends on the amount of text on the page and number of text blocks. It also depends on the content of the text. It may be explicit and independent of the page layout and graphics or hard to understand. The alt text for images is also important here. So, generally, if you want to produce accessible page (I don't mean technical term but real one), you have to work hard on the correct design in the first place.
As a result, accessible pages are usually not attractive for visual browsing as design is hampered with necessary constraints.
On the other hand, even technically accessible pages are not always easy to understand using text browser. So the best approach is to develop separate versions of the site for text and graphical browsing. You can do both in WD.
Another aspect is that all printed literature (books, manuals, newspapers, magazines e.t.c.) are completely unaccessible by this criteria, since they can't be read by the blind without help of someone else. And in reality, the only really working solution in any conditions is let someone to read the text aloud and explain what's there.