In article <[EMAIL PROTECTED]>, James Green <[EMAIL PROTECTED]>
wrote:
> Henri Sivonen wrote:
> > Disapproving Word or FrontPage wouldn't likely be a big deal. However,
> > the policy wrt. 4.x Composer might be. I think output from 4.x Composer
> > is suitable for putting on www.mozilla.org unedited.
>
> Depends on what exactly 4.x decides to spit out at us.
I think it is safe to say that no page output from 4.x Composer
validates without editing. Even if everything else happens to be
correct, the doctype is bogus.
> > The instructions can be made very simple:
> > * Use HTML 4.01 Strict.
>
> Not Transitional?
I'm assuming we want to do site-wide styling. Transitional is more
complicated. Are there parts of Transitional that are needed in you
opinion?
> Why not XHTML?
I addressed this in another post.
> > * Let the server add the style sheet.
>
> What if the author was putting up a page for general mozilla testing and
> wanted to use a stylesheet file containing a large number of complex
> rules for his suite?
Test suites are different. These draft guidelines were for documents
that aren't test cases.
> > * Don't use <dl> or <blockquote> for indenting.
>
> Why? They're perfectly valid and work for creating structural documents.
<dl> is a definition list. <blockquote> is intended for quotations. It
is OK to use them for these purposes, but neither of these elements
should be used as a general indentation tag like they are currently used
on www.mozilla.org.
> > * Use <em> and <strong> for emphasis
>
> Which? Why not state one or the other? Perhaps <em> for italics and
> <strong> for bold?
No. :-) <em> for usual emphasis and <strong> for stronger emphasis.
> > * Use heading tags for headings. Don't use <b> for headings.
>
> Good, but what levels?
<h1> one time per document. Levels 2 and 3 as necessary. If one feels
like using levels 4 through 6, it might be a good idea to reconsider the
structure of the document. If levels 4 through 6 feel necessary after
reconsideration, it is OK (IMO) to use them in a long document.
> Perhaps h1 is a little too large, so h2 or h3?
You are not thinking in terms of structure. The size is a style issue
and should be resolved in a site-wide style sheet.
> > * Put paragraph in <p> elements
>
> Of course, and let's not forget to close such things (very often <p> is
> without it's </p>).
Yes, Nav 4.x and some human readers (like me) want that.
>
> > * Avoid <i> and <b>
>
> Why?
Because they encode presentation instead of meaning.
> They may be deprecated
They aren't.
> b) backwardly-compatible.
<em> and <strong> are supported widely enough.
> > And one a bit difficult point
> > * Use Unicode quotes, dashes and apostrophes instead of ASCII
> > surrogates
> > such as: ``, '', ", -- and '.
>
> These may turn into gibberish in some browers.
They work in Netscape Communicator 4.6 for Mac, IE 5 for Mac and
Mozilla. (Mac and Solaris tested, but I think it is safe to say they
work in Mozilla on all platforms. On Unix platforms they are all
readable, but some characters are degraded to ASCII surrogates due to
font issues.). I think they work in IE 5.x for Windows, but I am not
100% sure right now.
They are used in this document for example:
http://www.hut.fi/~hsivonen/doctype.html
> But if we're looking for a way of 'encouraging' people to upgrade to
> Netscape 6 or Mozilla (both these two *do* support unicode characters
> in pages properly, right?) then you're on the right road.
I was thinking more in terms of typographical correctness, but I don't
think we need to support browsers that are too old to support those
characters.
> >> I'm not sure XML server software is advanced and mature enough to
> >> provide the basic facilities needed yet.
> >
> > The same kind of automated Web site build process could be used, but in
> > addition to wrapping, XML files would be checked for well-formednedd
> > using expat from within Perl and then a simple regexp find-and-replace
> > could transform the document.
>
> What exactly do we put in XML?
If I understood Braden's suggestion correctly, we'd put in the document
structure using aliases of HTML tags.
> Who authors it in what software?
I think people who write documentation would write author it in their
favorite text editor.
> >> Web databases require web front ends.
> >
> > A database other than CVS is not needed for using XML.
>
> Hmm, are you talking about the XML functionality I've seen in examples
> that talk about retrieving a data source and formatting it? If so, would
> that be a server-side process?
I meant that instead of just wrapping HTML from CVS, a conversion from
XML to HTML would happen first.
> >> I see no reason not to use a set of templates that have blank spaces
> >> for
> >> content, and have people fill them in using Editor, then we take the
> >> content and bung it into cvs,
> >
> > I don't like that approach. I think that (like now) HTML files
> > shouldn't
> > contain the template part, but the template should be inseted
> > automatically. This way the template can be updated in one place.
>
> Depends on what flexibility the authours require.
There are NOWRAP exclusion files.
> If they wanted to put things in where the template would take them
> out, what happens?
The way the template curretly works, the original attributes of the
<html> and <body> tags are lost, but that's about it.
--
Henri Sivonen
[EMAIL PROTECTED]
http://www.clinet.fi/~henris/
