Re: MarkUp Validator's new clothes

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

olivier Thereaux <ot@w3.org> wrote:

>I am not aware of these past problems, so please detail.

All pages had an inline navbar; with some pages having the full set and others
a stripped down number to, among other things, make it easier to update. Every
time a link changed you needed to change it in every .html file as well as in
the /check code. You can guess how often a link got left out in one or more
.html files or in /check when a change was made.

Note that the relevance is as a cautionary tale about making pages irregular
- -- every exception is a potential for getting tripped up -- not as a barrier
to implementing irregular navigation. The Includes structure makes this a
fairly straightforward matter to implement (as you note below).


>Now that most internal navigation is handled by the main horizontal bar,
>the righthand bar is mostly limited to external links. I have a hard
>time seeing how this would cause a lot of navigation troubles or out of
>sync links.

Separate issue. Yea or Nay on the right-hand navbar is a question of whether
all pages should have a consistent look, with consistent navigation and
header/footer; or whether the symmetry can be traded off against... Well, I
must admit I don't really see what nuking the right-hand navbar will actually
gain you, but... "Something". :-)


>I agree that it would be a problem if some pages had the menu and others
>would not, but in case only ONE (homepage) had the menu and others no,
>this is just trivial to do with our current head/main/foot structure.

Well, IMO, in that case you can just as well move them to a separate "links"
page (and then pretty much just delete them out of hand as nobody checks links
pages). The n+1 rule applies here; either you have it everywhere or you have
it nowhere, because "if n then why not n+1".


>And besides, I'm sure that nuking the righthand bar would also solve our
>CSS "guillotine" glitch. (call me lazy...)

*Harumph*

Call me anal, but I prefer to actually fix bugs instead of hiding them! :-)


>>>Well, the markup validator gives it as a link if valid, in the field
>>>to revalidate if not. I suppose consistency wouldn't hurt, though.
>>Please note that this design is in direct response to a feature request
>>that the URL be available and *editable* in the result page to support
>>Revalidate with an altered URL.
>
>I have nothing against the editable URI, I was suggesting adding a link
>to the page itself.

Ok, I obviously am not understanding this. Elaborate?

Are we not talking about the URL of the page just Validated in the validation
results page? That's the only place we spit out an URL inside a form field
AFAIK.


>>the original layout made the Valid/Invalid status too difficult to
>>discern at a glance.
>
>Wild idea: use the fact that our top banner image is in B&W and use
>different stylesheets for  results:invalid. That would allow a much
>smaller size of text (still necessary I think), along with the Error
>number maybe (was that what the old design had?)

Ditto. What do you have in mind?


- -- 
"A plague o' both your houses! I am sped." - Mercutio, kinsman to the Prince.
                   See Project Gutenberg <URL:http://promo.net/pg/> for more.

-----BEGIN PGP SIGNATURE-----
Version: PGP SDK 3.0.3

iQA/AwUBQIi8AqPyPrIkdfXsEQJUZgCfREk6bSxp/0Ds7p8vexq1YUV0k0oAoNfR
g0zSaFHrqTtftkJAQpL6IAd+
=8LPa
-----END PGP SIGNATURE-----

Received on Friday, 23 April 2004 02:52:07 UTC