Henri Sivonen wrote:
> In article <[EMAIL PROTECTED]>, James Green <[EMAIL PROTECTED]> wrote:
[ snip ]
>> 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.
I would for one.
>> 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.
I suspect this needs to be an opt-in thing. If people want to use
Editor, they can, but pages will sent straight back to the author if the
document contains problems with non-compliant HTML/CSS or layout issues.
The author would then be encouraged to check for validity before
submitting documents.
> 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.
I believe I am a member of the fourth group.
> 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!
Agreed.
>> 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.
Depends on what exactly 4.x decides to spit out at us.
[ snip ]
>> 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.
Not Transitional? Why not XHTML?
> * 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?
> * Don't use <dl> or <blockquote> for indenting.
Why? They're perfectly valid and work for creating structural documents.
> * Use <code> for code
> * Use <em> and <strong> for emphasis
Which? Why not state one or the other? Perhaps <em> for italics and
<strong> for bold?
> * Use heading tags for headings. Don't use <b> for headings.
Good, but what levels? Perhaps h1 is a little too large, so h2 or h3?
> * Use <ol> and <ul> for lists
> * Put paragraph in <p> elements
Of course, and let's not forget to close such things (very often <p> is
without it's </p>).
> * Avoid <pre>
I would hope that <pre> wasn't neccessary in too many cases anyway.
> * Avoid <i> and <b>
Why? They may be deprecated but many authors find them a) quick and b)
backwardly-compatible. I don't mind losing them entirely provided the
alternative is sane and well-supported.
> 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. 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'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? Who authors it in what software?
> I am not saying that we should use XML.
But it should be explored.
>> 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 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. If they wanted to put
things in where the template would take them out, what happens?
James Green
