Re: [WSG] Google and HTML5
On 1/26/06, Miika Mäkinen [EMAIL PROTECTED] wrote: Christian, that was my point... small atleast *sounds* presentational (thought it could indicate text that is less important) and that was why I wasn't happy to see it's included in HTML5... http://whatwg.org/specs/web-apps/current-work/#the-small Perhaps re-read the description of small in the WebApps spec. The point is that they've specified a meaning for it. In 'HTML5' (or whatever it eventually gets called), small means something and is differentiable from other text in the page. small may sound presentational because that's what it is in HTML4. But in HTML5 it refers to 'the small print' of a document, which is an entirely different use of text from a standard paragraph. What the WHATWG are doing which I think is clever, is they're reusing existing, meaningless presentational elements where they can. If I remember correctly, i has been re-specified too. As for the new elements: header, footer and so forth: It's all about separating _documents_ into component parts. There's nothing presentational about them: You have headers on letters, official documents and all sorts, thus there's now an element to identify that section of a document. Same for a footer. Consider the detail in which you can describe computer code in HTML: code, var, samp, kbd… huge descriptive power for technical publishing. But there's nothing like the same level of detail available non-technical documents. Most of these new HTML5 elements are designed to make HTML a richer language for the things the web is used for: Namely publishing documents within the frame of a larger website. article allows you to identify the primary page content from the site 'frame'. Useful for print stylesheets and generic richness, *very* useful for search engines (it means that you can avoid indexing unrelated content like advertising and navigation). Lots of examples. Could go on for hours, but this is probably plenty long enough! G'night, Ben
RE: [WSG] Google and HTML5
small may sound presentational because that's what it is in HTML4. But in HTML5 it refers to 'the small print' of a document, which is an entirely different use of text from a standard paragraph. The problem with that is that it *does* sound presentational and that people will just assume that it's the kind of tag to use to make small text, rather than use it in the framework it's intended to be used in. What the WHATWG are doing which I think is clever, is they're reusing existing, meaningless presentational elements where they can. If I remember correctly, i has been re-specified too. Quite the contrary, it's asking for problems. Between people who aren't aware that the specification change, browsers lagging behind, and WYSIWYG editor still using the deprecated elements in their previous meaning, we'll end up with a bigger mess than we find ourselves in now. How long have i and b been deprecated? Why are some editors still using it? Do you *really* think that a re-specification will catch on? Don't' get me wrong, I'm glad to see action on those fronts, but I'm not sure that using existing elements and re-defining them is the brightest approach. YMMV :) Nic ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help **
Re: [WSG] Google and HTML5
Nic wrote: What the WHATWG are doing which I think is clever, is they're reusing existing, meaningless presentational elements where they can. If I remember correctly, i has been re-specified too. Quite the contrary, it's asking for problems. Yes, I agree. Reusing presentational elements for semantic purposes is a mistake and has been criticised on the whatwg mailing list several times. How long have i and b been deprecated? They're not deprecated. Why are some editors still using it? Because they target authors that still think presentationally about their documents, rather than those that think semantically. Do you *really* think that a re-specification will catch on? No, it won't for presentational elements. However, the refined definitions for the more semantic elements will probably stand more chance. -- Lachlan Hunt http://lachy.id.au/ ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help **
RE: [WSG] Google and HTML5
How long have i and b been deprecated? They're not deprecated. Well, I'll be darned! I've been using em and strong for so long I'd come to believe i and b were deprecated... Thanks Lachlan, for setting me straight. I still won't use them though ;) rantAnd on a side rant, could people who are out of the office go NOMAIL from the list, It's getting VERY tiresome to get all those I'm out of the office mails... /rant Cheers Nic ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help **
Re: [WSG] Google and HTML5
On 1/28/06, Ben Ward [EMAIL PROTECTED] wrote:
It's all
about separating _documents_ into component parts. There's nothing
presentational about them: You have headers on letters, official
documents and all sorts, thus there's now an element to identify that
section of a document. Same for a footer.
The question is, where do we stop? And how long do we wait for all
these new tags to be introduced? So we have header, footer,
small, m, i, dfn, samp, var, sup, sub, kbd, etc.
etc. etc. Are we eventually going to have a whole repository of
available tags? Will this get to the point where few web developers
will actually be able to remember what all the tags are? And if you
think about it, these tags are still not enough to convey all the
potential meanings that content may have.
I think the W3C realized that a long time ago, and I think WhatWG will
go at this for a couple more years and say, hey, this html thing just
can't define everything, we need a technology that can support
applications, one that allows developers to define their own
information, and we need to make ways to define standards for using
existing elements, and they'll realize that this kind of
extensibility is available in xml, and they'll make a new technology,
called HTXML, and they'll start working on 1.0, while the W3C is
celebrating the formalizing of XHTML 2.0 and it's correct support in
Internet Explorer 8.
Let's face it, HTML5 is just an attempt to make html work for web
applications, but W3C realized that to make html work for web
applications, it would be best to utilize xml, rather than trying to
rewrite the existing html spec.
But even if you don't buy that argument, take this view: presentation
and semantics should be separate. Why? Because this is the problem
with HTML5: the person building the layout/structure has to also be a
semantics expert. With the complexity of web applications, this is
just not reasonable. Building the structure for a solid layout
shouldn't be mixed with making the content semantic. Just look at how
complicated this gets:
header/header
navigation/navigation
article/article
footer/footer
If I want all four containers to have similar CSS, I have to do:
header, navigation, article, footer { same stuff here }
And I sure hope nobody decides to add a sidebar, then I have to add:
header, navigation, article, footer, sidebar { same stuff here }
Do you see where this goes? Now content, presentation, and semantics
are getting all wrapped up, and it becomes difficult to add, change,
remove. Even then, I still can't convey much information. Look at:
The genus inematoda/i has ugly species, especially when they are
viewed with ix-ray/i machines.
Not the best example, but you can see that the distinction between the
first i being a taxonomical definition and the second being a
technical term is not made.
If you want to see what a proper separation of semantics and
presentation looks like, it's:
div title=header/div
div title=navigation/div
div title=article/div
div title=footer/div
where id, class, rel, etc. could be used in place of title, and
section could be used instead of div. Also consider:
The genus span title=taxonomynematoda/span has ugly species,
especially when they are viewed with span
title=technicalx-ray/span machines.
Whatever we use, the point is that it's easy to go into an already
constructed HTML4 or XHTML document and add semantics to it (when the
presentation and semantics are separate), without having to mess much
with the CSS [1], or wait for tags to be introduced. This kind of
thing isn't supported by machines yet, but I would much rather prefer
to see support for attribute-defined semantics [2], than trying to
modify/add presentational elements that are semantic.
Excuse the long e-mail, and especially excuse me if I'm off on
anything here, I'm not an XML expert. I hope that I've managed to
explain my point (xml is better than html, semantics belong in
attributes) without butchering any facts.
[1] Especially considering we can do this:
http://www.w3.org/TR/CSS21/selector.html#attribute-selectors
which makes it easy to style all divs / spans with the same title.
[2] Just peruse all the examples at http://www.microformats.org/wiki/
and imagine trying to make an html tag for every single one.
--
--
Christian Montoya
christianmontoya.com ... rdpdesign.com ... cssliquid.com
**
The discussion list for http://webstandardsgroup.org/
See http://webstandardsgroup.org/mail/guidelines.cfm
for some hints on posting to the list getting help
**
Re: [WSG] Google and HTML5
Christian Montoya wrote:
I think the W3C realized that a long time ago, and I think WhatWG will
go at this for a couple more years and say, hey, this html thing just
can't define everything, we need a technology that can support
applications, one that allows developers to define their own
information, and we need to make ways to define standards for using
existing elements, and they'll realize that this kind of
extensibility is available in xml, and they'll make a new technology,
called HTXML, and they'll start working on 1.0, while the W3C is
celebrating the formalizing of XHTML 2.0 and it's correct support in
Internet Explorer 8.
IE8 will not support XHTML 2.0. It may support XHTML 1.0, possibly 1.1
as well, but definately not 2.0. In fact, I guarantee that there will
be browsers supporting new HTML5 features long before XHTML 2 is on the
road map.
Let's face it, HTML5 is just an attempt to make html work for web
applications,
It is in fact a lot more than that. While web applications are a major
use case, it's also an attempt to document and standardise the buggy
browser behaviour that we currently are and will always be stuck with in
the hopes on increasing interoperability, particularly with relation to
error handling; refine the semantics of existing elements and introduce
semantics that we have been waiting a long time for.
But even if you don't buy that argument, take this view: presentation
and semantics should be separate. Why? Because this is the problem
with HTML5: the person building the layout/structure has to also be a
semantics expert. With the complexity of web applications, this is
just not reasonable. Building the structure for a solid layout
shouldn't be mixed with making the content semantic. Just look at how
complicated this gets:
header/header
navigation/navigation
article/article
footer/footer
How is that at all complicated? It actually simplifies the markup a
great deal by removing several use-cases for div – a semantically
meaningless element.
If I want all four containers to have similar CSS, I have to do:
header, navigation, article, footer { same stuff here }
div title=header/div
div title=navigation/div
div title=article/div
div title=footer/div
where id, class, rel, etc. could be used in place of title, and
section could be used instead of div. Also consider:
Any time a div is the answer, there's a hole in HTML. -- Ian Hickson
Well, for that, you could use
div { same stuff here }
But, then you'd have to deal with all the other (ab)uses of div in your
document. Otherwise, you'd just have to give them IDs or classes and
style them like this:
#header, #navigation, #article, #footer { same stuff here }
Which, by your logic, is somehow better than using a semantically
defined element!?
Whatever we use, the point is that it's easy to go into an already
constructed HTML4 or XHTML document and add semantics to it (when the
presentation and semantics are separate), without having to mess much
with the CSS [1], or wait for tags to be introduced. This kind of
thing isn't supported by machines yet, but I would much rather prefer
to see support for attribute-defined semantics [2], than trying to
modify/add presentational elements that are semantic.
...
[2] Just peruse all the examples at http://www.microformats.org/wiki/
and imagine trying to make an html tag for every single one.
While it is good to reuse and refine the meanings of existing markup
where possible, and in fact Hixie would wholeheartedly agree with you on
that point:
(See the glossary example here, for instance)
http://ln.hixie.ch/?start=1129948617count=1
The use of attributes for semantics is not always a good idea. If it
were, we'd have documents like this:
!DOCTYPE div -//W3C//DTD DIV 1.0//EN
div
div class=head
div class=titleHeading/div
/div
div class=article
div class=headingDiv-Mania/div
div class=paragraphIt's great to use
span class=codediv/code and span class=codespan/span
for everything/div
div class=noteThis could be considered a joke, if it were not
for this kind of crap actually being used! Instead, consider
it a reality check./div
/div
div class=nav
diva href=#Foo/a/div
diva href=#Bar/a/div
diva href=#Baz/a/div
!-- If only div or span had an href attribute! --
/div
/div
If you prefer to mark up like that, then by all means, go for it. But
for those of us that actually like to put semantics in our documents,
we'll use the elements with formally defined semantics that UAs can
actually do something useful with.
--
Lachlan Hunt
http://lachy.id.au/
**
The discussion list for http://webstandardsgroup.org/
See http://webstandardsgroup.org/mail/guidelines.cfm
for some hints on posting to the list getting help
**
Re: [WSG] Google and HTML5
Geoff Deering wrote: Do others feel there are *elements* of presentation creeping back into the structure? Absolutely, header and footer elements, to my mind, break the semantics of separating the presentation from content. Once you say this element represents the footer for the section it applies to surely you're suggesting the physical layout of the presentation? The idea of aside has more merit since it describes the weight of the content with respect to the rest of the page but doesn't suggest placement on the page. And I agree that the idea of a nav tag seems sound assuming you agree that navigation is inherent to the content. It looks like the draft has been prepared with a standard page layout strongly in mind (see: http://whatwg.org/specs/web-apps/current-work/#sectioning) and that may not lend itself well to media that we may not yet have invented to display/experience the content. Cheers Peter -- Peter Asquith http://www.wasabicube.com smime.p7s Description: S/MIME Cryptographic Signature
Re: [WSG] Google and HTML5
On 1/25/06, Geoff Pack [EMAIL PROTECTED] wrote: We could have: html head/head body header/header nav/nav article/article aside/aside footer/footer /body /html If you are going to make a tag for every element on the page you might as well just serve an xml document with a stylesheet. I assume everyone knows this can be done, yes? It's not like we are talking about something new. -- -- Christian Montoya christianmontoya.com ... rdpdesign.com ... cssliquid.com ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help **
Re: [WSG] Google and HTML5
More than headers and footers I was a bit worrried seeing an element named small in the list... though actually there might be idea in adding something that gives negative weight, like an opposites of em and strong unimportant or note maybe?On 1/26/06, Peter Asquith [EMAIL PROTECTED] wrote: Geoff Deering wrote: Do others feel there are *elements* of presentation creeping back into the structure?Absolutely, header and footer elements, to my mind, break thesemantics of separating the presentation from content. Once you saythis element represents the footer for the section it applies to surely you're suggesting the physical layout of the presentation?The idea of aside has more merit since it describes the weight ofthe content with respect to the rest of the page but doesn't suggest placement on the page. And I agree that the idea of a nav tag seemssound assuming you agree that navigation is inherent to the content.It looks like the draft has been prepared with a standard page layout strongly in mind (see:http://whatwg.org/specs/web-apps/current-work/#sectioning) and that maynot lend itself well to media that we may not yet have invented to display/experience the content.CheersPeter--Peter Asquithhttp://www.wasabicube.com
Re: [WSG] Google and HTML5
At 11:52 PM 1/25/2006, Geoff Deering wrote: header/header nav/nav article/article aside/aside footer/footer Do others feel there are *elements* of presentation creeping back into the structure? ... The second does this by the semantically defining the presentation structure. (IMHO) Geoff, You can certainly make a good argument that header and footer denote positional placement on the page -- header means at the beginning and footer means at the end -- but I don't see how nav, article, and aside convey presentation -- they individuate the various parts of the page and convey the semantic meaning of each, but communicate nothing about how they'll be presented. How does nav semantically define the presentation structure while table, ol, and h1 do not? Curiously, Paul ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help **
Re: [WSG] Google and HTML5
On 1/26/06, Miika Mäkinen [EMAIL PROTECTED] wrote: More than headers and footers I was a bit worrried seeing an element named small in the list... though actually there might be idea in adding something that gives negative weight, like an opposites of em and strong unimportant or note maybe? Miika, small is presentational markup, it makes the text smaller. No semantics as far as I know. It's also not new. -- -- Christian Montoya christianmontoya.com ... rdpdesign.com ... cssliquid.com ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help **
Re: [WSG] Google and HTML5
Christian, that was my point... small atleast *sounds* presentational (thought it could indicate text that is less important) and that was why I wasn't happy to see it's included in HTML5... http://whatwg.org/specs/web-apps/current-work/#the-smallOn 1/26/06, Christian Montoya [EMAIL PROTECTED] wrote:On 1/26/06, Miika Mäkinen [EMAIL PROTECTED] wrote: More than headers and footers I was a bit worrried seeing an element named small in the list... though actually there might be idea in adding something that gives negative weight, like an opposites of em and strong unimportant or note maybe?Miika, small is presentational markup, it makes the text smaller. Nosemantics as far as I know. It's also not new.Christian Montoya christianmontoya.com ... rdpdesign.com ... cssliquid.com** The discussion list forhttp://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help**
Re: [WSG] Google and HTML5
Peter Asquith wrote: Geoff Deering wrote: Do others feel there are *elements* of presentation creeping back into the structure? Absolutely, header and footer elements, to my mind, break the semantics of separating the presentation from content. Once you say this element represents the footer for the section it applies to surely you're suggesting the physical layout of the presentation? The idea of aside has more merit since it describes the weight of the content with respect to the rest of the page but doesn't suggest placement on the page. And I agree that the idea of a nav tag seems sound assuming you agree that navigation is inherent to the content. It looks like the draft has been prepared with a standard page layout strongly in mind (see: http://whatwg.org/specs/web-apps/current-work/#sectioning) and that may not lend itself well to media that we may not yet have invented to display/experience the content. Cheers Peter The logical extension of your argument is that we should never use h1..h6 either! Isn't it? Bob McClelland www.gwelanmor-internet.co.uk ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help **
Re: [WSG] Google and HTML5
Christian Montoya wrote: If you are going to make a tag for every element on the page you might as well just serve an xml document with a stylesheet. I assume everyone knows this can be done, yes? It's not like we are talking about something new. I'd be really interested in knowing how Christian : can you give a link to start me off? Thanks, Bob McClelland www.gwelanmor-internet.co.uk ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help **
Re: [WSG] Google and HTML5
Christian Montoya wrote: On 1/25/06, Geoff Pack [EMAIL PROTECTED] wrote: We could have: html head/head body header/header nav/nav article/article aside/aside footer/footer /body /html If you are going to make a tag for every element on the page you might as well just serve an xml document with a stylesheet. I assume everyone knows this can be done, yes? It's not like we are talking about something new. The problem with that approach is that generic XML, even with a stylesheet applied, doesn't have any formally defined semantics. It's not till the elements have been defined in a spec somewhere and implemented by UAs that they really become useful for anything more than just styling in a visual UA. Without formally defined semantics, you may as well just be using presentational HTML elements, which have precisely the same meaning: none at all! For example, with a nav element defined and implemented as a section of navigation, a UA could provide an easy way to either skip over it or skip to it, without relying on the author having to use skip links which would be good for screen readers. Likewise with the article element, which will usually contain the most interesting content on the page. -- Lachlan Hunt http://lachy.id.au/ ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help **
RE: [WSG] Google and HTML5
Christian Montoya wrote: On 1/25/06, Geoff Pack [EMAIL PROTECTED] wrote: We could have: html head/head body header/header nav/nav article/article aside/aside footer/footer /body /html If you are going to make a tag for every element on the page you might as well just serve an xml document with a stylesheet. I assume everyone knows this can be done, yes? It's not like we are talking about something new. Yeah, I know. The point is that these five elements are standardised in the Web Apps 1.0 Spec [HTML 5]. If you went down the XML route, you'd still need to write a spec or a DTD if you wanted your elements to become standardised. Geoff. ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help **
Re: [WSG] Google and HTML5
On 1/26/06, Designer [EMAIL PROTECTED] wrote: Christian Montoya wrote: If you are going to make a tag for every element on the page you might as well just serve an xml document with a stylesheet. I assume everyone knows this can be done, yes? It's not like we are talking about something new. I'd be really interested in knowing how Christian : can you give a link to start me off? Just one example, I know there are others: http://www.w3.org/Style/styling-XML -- -- Christian Montoya christianmontoya.com ... rdpdesign.com ... cssliquid.com ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help **
Re: [WSG] Google and HTML5
On 1/25/06, Brian Cummiskey [EMAIL PROTECTED] wrote: I just stumbled upon this: http://code.google.com/webstats/index.html Based on commonly used classes and such, they are suggesting new html markup. For example, they mention that footer is used a lot, and are thus suggesting a footertag/footer. http://whatwg.org/specs/web-apps/current-work/#the-footer Thoughts? My thought: they have no idea how hard it is to introduce a new tag. Then again, they would probably advocate dropping support for IE, but we have to be practical. -- -- Christian Montoya christianmontoya.com ... rdpdesign.com ... cssliquid.com ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help **
Re: [WSG] Google and HTML5
Christian Montoya wrote: On 1/25/06, Brian Cummiskey [EMAIL PROTECTED] wrote: For example, they mention that footer is used a lot, and are thus suggesting a footertag/footer. http://whatwg.org/specs/web-apps/current-work/#the-footer Thoughts? My thought: they have no idea how hard it is to introduce a new tag. What exactly is hard about introducing a new element? Browser vendors have done it with hundreds of proprietary extensions in the past. What's different about doing it now, especially now that these new elements are being standardised and will be implemented by several major browsers relatively soon? -- Lachlan Hunt http://lachy.id.au/ ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help **
Re: [WSG] Google and HTML5
On 1/25/06, Lachlan Hunt [EMAIL PROTECTED] wrote: Christian Montoya wrote: On 1/25/06, Brian Cummiskey [EMAIL PROTECTED] wrote: For example, they mention that footer is used a lot, and are thus suggesting a footertag/footer. http://whatwg.org/specs/web-apps/current-work/#the-footer Thoughts? My thought: they have no idea how hard it is to introduce a new tag. What exactly is hard about introducing a new element? Browser vendors have done it with hundreds of proprietary extensions in the past. What's different about doing it now, especially now that these new elements are being standardised and will be implemented by several major browsers relatively soon? These elements, well, how long were they around as proprietary elements? Years right? That sounds like a long time to me. Just look at how long we have waited for support for the object tag (still waiting for IE). We had a discussion a while back regarding addresses and the rel attribute and I think someone mentioned why it would be difficult to introduce an address tag. I'm pretty sure it's in the archives. Anyway, even when (if) a footer tag was finally approved and supported by all browsers, it would be a long time before many designers actually used it. What's wrong with div id=footer anyway? Nothing. -- -- Christian Montoya christianmontoya.com ... rdpdesign.com ... cssliquid.com ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help **
RE: [WSG] Google and HTML5
I like the idea of the nav and the aside elements: http://whatwg.org/specs/web-apps/current-work/#the-nav http://whatwg.org/specs/web-apps/current-work/#the-aside So instead of: html head/head body div id=header/div div id=nav/div div id=content/div div id=sidebar/div div id=footer/div /body /html We could have: html head/head body header/header nav/nav article/article aside/aside footer/footer /body /html Which is cleaner and more semantic. But it would take years to get it implemented by the browsers and to grow the installed base to the point where we can actually use it. Better to just standardise the id and class names - the web patterns / microformats approach. cheers, Geoff. Brian Cummiskey wrote: I just stumbled upon this: http://code.google.com/webstats/index.html Based on commonly used classes and such, they are suggesting new html markup. For example, they mention that footer is used a lot, and are thus suggesting a footertag/footer. http://whatwg.org/specs/web-apps/current-work/#the-footer Thoughts? ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help **
Re: [WSG] Google and HTML5
Geoff Pack wrote: I like the idea of the nav and the aside elements: http://whatwg.org/specs/web-apps/current-work/#the-nav http://whatwg.org/specs/web-apps/current-work/#the-aside So instead of: html head/head body div id=header/div div id=nav/div div id=content/div div id=sidebar/div div id=footer/div /body /html We could have: html head/head body header/header nav/nav article/article aside/aside footer/footer /body /html Which is cleaner and more semantic. But it would take years to get it implemented by the browsers and to grow the installed base to the point where we can actually use it. Better to just standardise the id and class names - the web patterns / microformats approach. cheers, Geoff. Do others feel there are *elements* of presentation creeping back into the structure? The first approach keeps the semantics of the document whilst providing handles to present the sections of the document. The second does this by the semantically defining the presentation structure. (IMHO) I'd prefer to see a direct jump into the xml world (which would drag the soupsayers into the standards world). Maybe it's time for a better semantic language. Regards Geoff Deering ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help **
