I don't think we disagree on most of your points. I've never suggested
vocabularies. And granted there are stylistic elements that have crept
days), which I'm of course not recommending you use.
identified: headings, paragraphs, lists etc. And of course its greatest
strength is that it is widely understood by all types of user agents. So
outline of the document by inspecting the heading levels. All sorts of
does not provide.
much* information in the pipeline. Surely there's no advantage to
Anyway, gotta get off my soapbox and back to work. ;-) I won't spend more
time on this thread.
We must agree to differ - a pet peeve of mine is that people use HTML
as a data structure language rather than as a page mark up language
(cf TeX) :-) . HTML has absolutely nothing to do with data
structuring - it (with CSS) only determines what goes where on a
page. We are trying to use a language which is neither XML
(structural) or PostScript (true page mark up) which is why it needs
XML and CSS.
The problem is that while HTML undoubtedly has some structural
information such as paras, headings, lists etc., these are about the
only ones it has. It also mixes in pure style constructs such as
italic (which tell you nothing about the structure and why they are
italic).
To be really useful we need to have extra structural tags in the HTML
such as author, date, version, footnote, inline note, citation ... -
the list is obviously not insubstantial depending on the structure
you are representing. Since HTML is not extendable (that was why XML
was done) we have a problem. Not until XML + sensible style sheets
are used instead of HTML will there be a solution that satisfies both
of us.
This is why Cocoon is so important - it is all a question of
information flow (or some might say, entropy). I can take too much
information (in XML) and deliver it in a variety of formats (HTML,
PDF etc) by losing information that I do not want. But I cannot go
the other way around. For example start with HTML or PDF and produce
XML that is the structure that the author intended. Although by
clever use of classes etc. you might end up with sufficient XML
granularity to achieve this, butI believe that this is against the
spirit of the whole thing.
So, the question is, does it matter about divs and spans? I believe
not because I would not dream of taking HTML and try and do something
useful with it (screen scrapping for example) other than displaying
it on a browser. If required to interpret the data it is best to
deliver it in a form that is amenable to this: raw or processed XML.
btw I did look at Firefox output with no style and it looked fine. I
agree you could not see the headings (they looked like paras) but it
certainly was not unreadable. I would totally agree with you if I had
used positional information for the flow, rather than simple vertical
stacking. Previous sites that I used Cocoon for always had a facility
to output the data for a variety of browsers including Lynx which is
styleless.
Ultimately it is all a question of how you view HTML. There probably
is no "correct" answer to this (cf the big-endian, little-endian holy
wars of processor and bus design in the 1980s). Let us hope that XML
comes sooner rather than later to the Web. My opinion is that since
we are using HTML as page markup it does not really matter using divs
and spans, because we get very little other benefit from using <p>
and <h1> etc. However it is not something I would stake my life on.
It is all a m,atter of personal preference I guess.
Thanks for the appreciation of the software though.
- Hugh
On 7 Aug 2006, at 16:45, Jason Johnston wrote:
<t:p>Paloose is a simplified (much simplified) version of ... </t:p>
There is nothing here that indicates the final look (obviously). The
relevant template
<xsl:template match="t:p" mode="inline-text">
<xsl:element name="div">
<xsl:attribute name="class">normalPara</xsl:attribute>
<xsl:apply-templates mode="inline-text"/>
</xsl:element>
</xsl:template>
translates this into a simple HTML div
<div class="normalPara">Paloose is a simplified (much simplified)
version of ... </div>
Argh! This is a particular pet peeve of mine.
HTML provides the <p>
element specifically for marking up paragraphs.
By using a <div>
you've
removed any semantic meaning from the markup! It might as well not be
HTML at all. You can apply the same CSS styles to any HTML
element, so
why not use something that carries a well-known semantic meaning
that can
be interpreted equally well by non-visual means, and that has a useful
default styling for when your CSS isn't applied? Same goes for
headings:
<h1>, <h2>, etc. are much more appropriate than divs with special
classes.
I always find it a good exercise when building a site to view it
without
any CSS applied (in Firefox: View->Page Style->No Style), and if I can
still clearly see the structure of the page's content (heading
hierarchy,
paragraphs, lists, etc.) then it's good. If on the other hand all the
paragraphs and headings run together without any visual clues to their
meaning (as happens with the Paloose site!) then I've probably got
some
work to do.
Sorry to get off-topic, just hate to see <div> and <span> over-used in
place of perfectly good semantic HTML.
Nice software though! I look forward to giving it a try. :-)
--Jason
---------------------------------------------------------------------
=================================
Dr H.S. Field-Richards
MIEE MIEEE CEng BSc PhD
www.hopvine-music.com
