Gervase Markham wrote:
>
> > > Regarding Matthew's earlier comments, which I can't find, it would be
> > > _very_ _bad_ to use XHTML and serve it as text/html - without
> > > enforcing the well-formedness constraint on XHTML from the very start,
> > > you are throwing away the world's best chance to have a HTML-esque
> > > format which is zero-cruft, and can be understood by lightweight
> > > parsers which don't need to deal with broken code.
> > >...
> >
> > I don't believe that for a moment. And the reason I don't believe it is
> > that XHTML 1.0 Transitional (which is what I propose we use) exists at
> > all. XHTML Transitional wouldn't exist, if XHTML hadn't been intended to
> > be served to clients which only understand text/html.
>
> What _benefits_ are there in using XHTML over HTML 4.01 Strict? I'm not
> going to post Henri's opinion here a third time, but I do agree with it -
> using XHTML without enforcing well-formedness at the browser is just
> asking for trouble.
>
> I remember reading, in a bug I think, that they had a big argument about
> this on the W3C list. I am pretty sure that the conclusion was XHTML as
> text/xml only, and HTML as text/html, but I'm not certain. dbaron (among
> others) would know.
>
> > > > 6) We need to settle on filesystem layout and URI layouts. Some have
> > > > been suggested, I'm not aware of anything we should be working to.
> > > > It's make our minds up time.
> > >
> > > Again, this problem goes away if we use a content management system.
> >
> > No, it doesn't. We need to minimize linkrot whether or not we use a
> > content management system. A content management system might make it
> > easy to keep links on our own site up to date, but it will do nothing to
> > update links to mozilla.org which reside on other people's Web sites and
> > bookmark lists.
>
> If we use a content management system, there's no such thing as a
> filesystem layout. Therefore there's no argument as to what it should be.
> The only thing is the navigation layout (see below.)
Even if we use a content management system, there will still be a
hierarchy in the URI layout. Whether there is a filesystem matching
the URIs or a database below that is irrelevant; you link to the URI,
not the physical file.
> > > More important is the navigational layout, which is a separate thing
> > > which keeps getting conflated with the filesystem layout and even the
> > > URI layout.
> >
> > To mazimize usability, the URI structure should match the navigational
> > structure as much as possible.
>
> But the navigational structure won't be a tree. At least, I would have
> thought it wouldn't be - the problems we've had deciding where things live
> are symptoms of the fact that, navigationally, some things live in two or
> more places.
The navigational structure is a web, more or less. But a good web--
an /organized/ web--has strong spokes for filaments to attach to,
and those spokes are the URI hierarchy. They maintain organization,
provide a well-defined path for navigation, and can be oriented to
when lost.
