In article <[EMAIL PROTECTED]>, James Green <[EMAIL PROTECTED]> wrote:
> Simon P. Lucy wrote:
>
> > At 14:29 12/12/2000 +0200, Henri Sivonen wrote:
> >> 2) The structure of the documents (HTML)
> >>
> >> I have taken a loog at the source of a number of pages at
> >> www.mozilla.org. Sadly, the rule seems to be that they are almost
> >> entirely presentational and lacking stylable structure. To put it
> >> bluntly, Mozilla itself is among the best in terms of standards
> >> compliance, but the documents at www.mozilla.org are, in general,
> >> bad HTML.
>
> One might say that we could fix that by making sure Editor created fully
> compliant pages, but how do ensure all pages are created in Editor?
Some people would scream if we said they couldn't use their favorite
text editor.
> Personally, I find a simple text editor sufficient, although human error
> is sometimes a problem too.
A validator helps.
> I would suggest we try to keep with Editor...
There are (the way I see it) three issues with Editor
1) The whitespace handling is broken. I expect this to be fixed in the
short term.
2) Superfluous <br> tags. I expect this to be fixed sooner or later.
3) Currently there is no Right Thing enforcement.
This last one is going to be controversial. Some people might argue that
Right Thing enforcement is patronizing and shouldn't be implemented at
all since it restricts the users' Right to the Freedom of doing the
Wrong Thing. Others might argue that doing the Right Thing should be
enforced at all times. A third group might argue that Right Thing
enforcement should be an opt-in preference. A fourth group might argue
that Right Thing enforcement should be enabled by default, but there
should be a pref for opting out.
A person who wants to produce good documents but does not want to read
the specs needs expects that software does the Right Thing. If the
burden is put on the user, an essential part of the usefulness of using
a specialized editor in comparison to a text editor is lost!
> However whether we should accept pages created by, for example, Word97
> or FrontPage, is something that could turn into a political hot potato.
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.
> >> Straight-forward mozilla.org HTML guidelines could be written in
> >> order
> >> to promote standards-compliance and site-wide stylability. However,
> >> this would only work if people used the right kind of tools.
>
> And read and agreed to to guideless, and tested the results. In short,
> authors need to be given the simplest of instructions.
The instructions can be made very simple:
* Use HTML 4.01 Strict.
* Let the server add the style sheet.
* Don't use <dl> or <blockquote> for indenting.
* Use <code> for code
* Use <em> and <strong> for emphasis
* Use heading tags for headings. Don't use <b> for headings.
* Use <ol> and <ul> for lists
* Put paragraph in <p> elements
* Avoid <pre>
* Avoid <i> and <b>
And one a bit difficult point
* Use Unicode quotes, dashes and apostrophes instead of ASCII surrogates
such as: ``, '', ", -- and '.
That's about it. Very simple. Very easy.
> 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.
I am not saying that we should use XML.
> Web databases require web front ends.
A database other than CVS is not needed for using XML.
> 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.
--
Henri Sivonen
[EMAIL PROTECTED]
http://www.clinet.fi/~henris/
