Simon P. Lucy wrote:
> At 14:29 12/12/2000 +0200, Henri Sivonen wrote:
>
>> I think there are five core issues:
>>
>> 1) The overall site structure
>>
>> We need a lot of brainstorming in this area.
Indeed. And speaking of someone who's had to dump an entire web cvs
module because of cvs's problems with deletion and moving of files,
let's make this a basic structure, rather than a complicated one.
>> 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?
Personally, I find a simple text editor sufficient, although human error
is sometimes a problem too.
>> I suspect that the misuse of HTML is due to use of "WYSIWYG" editors
>> that encourage the user to use <font> and <b> instead or real headers
>> and to overuse <blockquote>. (Most likely the culprit is 4.x Composer.)
This has been a serious problem with past and current products. I've not
tried Netscape 6/Mozilla's, but speaking as someone who saw what early
editions of Office 95/FrontPage did, they suck.
I would suggest we try to keep with Editor... I find many people simply
don't want to use a plaintext editor and it is reasonable for them to
want to use Editor. However whether we should accept pages created by,
for example, Word97 or FrontPage, is something that could turn into a
political hot potato.
>> 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. Where they fall
short, the people maintaining the web copy needs to fix the problems
before letting it go live.
> I think contributors should only be expected to contribute content, not
> style. Which is why the content should be held in a database (k, you
> could use an XML variant, the database could give you versioning as well
> though), and generated with whatever styling is decided upon.
I'm not sure XML server software is advanced and mature enough to
provide the basic facilities needed yet. XML isn't that old, and some
savvy friends of mine are still waiting for the next major version of
Cocoon to come along before really integrating it in their business.
Web databases require web front ends. Are we willing to devote the
resources neccessary to build such a thing? And how would it provide the
required flexibility?
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, and at the same time fix any compliance
issues.
> Submission then becomes a cycle of contribution/critique then insertion
> into the database at whereever in the heirarchy.
The problem with a database is that sometimes flexibility can be a
problem, and of course a front end is needed.
Just my thoughts,
James Green
