Braden McDaniel wrote:
> In article <[EMAIL PROTECTED]>, "Gervase Markham"
> <[EMAIL PROTECTED]> wrote:
>
>
>>>> We could have rules for high-profile pages, perhaps, but we would
>>>> have to define high-profile.
>>>
>>> Why only high-profile? What legitimate excuse is there for any HTML
>>> page on mozilla.org to be invalid?
>>
>> Because there are 5 of us and 16,000 of them :-) Are you volunteering to
>> fix all 16,000?
>
>
> I'm volunteering to help, but I'm not going to fight a losing battle. If
> the proper controls are in place, all 16,000 (or damn near it) will
> eventually be corrected.
I'm with Braden on this one. We *will* get them all validated and
correct, it will just need to be a prioritised task over time (top 30
pages first, then top 60, etc.)
I would be *very* hesitent about helping out knowing that bad html was
going live. If it f***s up in people's browser, we show them the light,
otherwise they should get a clean, fast loading and attractive page that
gives them the information they want.
The only problem is deciding which standards to adhere to, not in terms
of XML or this or that, but what versions. I could suggest using just
HTML 4.01 and CSS 2, but why not go for XHTML and CSS 2 now?
> You aren't going to cure the disease with a few
> band-aid patches. New sores will just open up and fester. There *is* a
> cure. It might be bitter to some at first, but it's an acquired taste.
> You know it's good for you. ;-)
Indeed. Not going to be an overnight "fix this script and all pages will
valiate" but it will get done providing we maintain good progress.
And yes I am volunteering, I know cvs adequately, use Apache and PHP (a
little perl) and need a bigger hard disk *sigh*.
>> OK, fair enough. _I_ _consider_ only those to be worth making the effort
>> to fix. If other people want to fix other ones, that's cool :-)
Hence the need for prioritisation... But people should expect a
"standards-compliant browser" to have a standards-compliant homepge...
>>>> And we probably wouldn't want to - part of the point of this exercise
>>>> is to lower the barrier to entry for people wanting to contribute.
>>>
>>> Requiring valid HTML pages is too high a barrier to entry for
>>> contributing to a Web site???
>>
>> Yes :-)
To a point.
It depends largely on who is writing the pages. If they're all
Mozilla/Netscape people savvy with these issues then they should all be
using Mozilla/Editor or text/editor and be capable of checking validity
before committing. If however we get individuals coming along then we
need to do more work.
Either way, the owner module should always validate and if neccessary
fix problems with submitted pages before it goes live, imho. Sure I can
help out in this respect and I'm sure I'm not the only one willing to
take on such work.
> Then this effort is bound to be ineffective. We'll still have crap when
> it's done, it will just be different crap. That is a waste of time.
Agreed. We Need To Make A Difference.
>> Well, it depends how you validate them (as in, as what sort of
>> HTML.)
> The document contains that information. You simply validate them.
Are we talking in terms of HTML 3.2 v. 4.01 or which validation software
to use?
>> Also, if we are going to encourage people to use Mozilla
>> Composer, what happens if it produces stuff that doesn't pass.
You use Bugzilla and while you await a patch you fix the page.
> Then it gets rejected and significant bugs in Mozilla Composer are
> highlighted. I don't see the downside.
Or you could reject the page and have the author fix it themselves... I
like it :)
>>>> I think it's good enough that the high-profile pages validate
>>>> correctly. There is no way we can check and fix all 16,000 of them!
I find it hard to believe that mozilla.org has 16,000 pages. If it does,
it needs a diet. 16,000 pages is unmanagable without a database.
>>> Not all at once. But the proper controls can both keep the problem from
>>> getting any worse, and ensure that the number of invalid pages on the
>>> site goes only down, never up.
>>
>> I agree. But that's a different point entirely.
> I don't think it is, because I don't think this effort is worthwhile if
> those controls aren't considered a prerequisite.
Indeed.
I don't mind the idea of using XML in fact, but we'd need to re-write
the site all at once (probably) before going live.
James Green
