352276 - Make /seamonkey/ validate and meets style guidelines and markup guidelines

Status: RESOLVED FIXED

(www.mozilla.org :: General, defect)

Description

[Gérard Talbot]

Robert,

Since you are webpages maintainer of seamonkey directory and since you expressed the request of being explained changes in advance in a bugfile...

http://www.mozilla.org/projects/seamonkey/brownbag.html (3 errors; no doctype decl; 13 errors with strict DTD)

http://www.mozilla.org/projects/seamonkey/news.html (1 error; no width and height defined for images; no rel used for intra-project navigation, so no site navigation toolbar usable; no relative referencing of links;

http://www.mozilla.org/contribute/writing/guidelines#linking
"Use relative links whenever practical."

http://www.mozilla.org/contribute/writing/guidelines#linking
"Anchors should not be empty."

Defining image width and height helps speed up rendering as the browser knows how much space to allocate a particular area (image placeholder) while parsing and rendering the page. Otherwise, the browser has to wait until the graphic is loaded before it knows where to put anything below or to the right of the graphic. The browser may need to rearrange the page as the images are downloaded. When it does, the visitor sees a reflow, a shift in the page layout. It's generally widely acknowledged among expert web authors, book authors that defining width and height attributes of image is the correct thing to do.

http://www.mozilla.org/projects/seamonkey/milestones/50m5plan.html (49 errors, 23 warnings with a transitional DTD; 54 errors with a strict DTD; lots of  ) Maybe this document should be removed.

http://www.mozilla.org/projects/seamonkey/milestones/50m6plan.html (48 errors, 23 warnings with a transitional DTD; 47 errors with a strict DTD; 257 &nbsp; 90 <br>; maybe this document should be removed.

http://www.mozilla.org/projects/seamonkey/milestones/index.html (53 errors with a transitional DTD; 99 errors with a strict DTD; lots of <br>, &nbsp; <font>, bgcolor, nosave (!), deeply nested lists, etc. Maybe this document should be removed.

http://www.mozilla.org/projects/seamonkey/release-notes/index.html (21 errors with a transitional DTD; 24 errors with a strict DTD)

http://www.mozilla.org/projects/seamonkey/milestones/m3.html (5 errors with a transitional DTD; 8 errors with a strict DTD). This document looks like an informal, internal document. Maybe this document should be removed.

http://www.mozilla.org/projects/seamonkey/milestones/neck-sched.html Maybe this document should be removed.

http://www.mozilla.org/projects/seamonkey/milestones/progress-2-beta.html (107 errors) Maybe this document should be removed.

http://www.mozilla.org/projects/seamonkey/release-notes/m3portnotes.html Maybe this document should be removed.
http://www.mozilla.org/projects/seamonkey/release-notes/m4.html Maybe this document should be removed.
http://www.mozilla.org/projects/seamonkey/release-notes/m5.html Maybe this document should be removed.
http://www.mozilla.org/projects/seamonkey/release-notes/m6.html Maybe this document should be removed.
http://www.mozilla.org/projects/seamonkey/release-notes/m7.html Maybe this document should be removed.
http://www.mozilla.org/projects/seamonkey/release-notes/m8-5.html Maybe this document should be removed.
http://www.mozilla.org/projects/seamonkey/release-notes/m8.html Maybe this document should be removed.
http://www.mozilla.org/projects/seamonkey/release-notes/m9.html Maybe this document should be removed.
http://www.mozilla.org/projects/seamonkey/release-notes/m12.html (46 errors, 12 warnings) Maybe this document should be removed.
http://www.mozilla.org/projects/seamonkey/release-notes/M15-detail.html (27 errors with a transitional DTD; 100 errors with a strict DTD; document even uses invalid characters; )

http://www.mozilla.org/projects/seamonkey/release-notes/rnguide.html Maybe this document should be removed.

http://www.mozilla.org/projects/seamonkey/releases/1.0a.html (2 errors;
<div style="border: 1px solid rgb(255, 153, 153); margin: 1em 0; padding: 4px; background-color: rgb(255, 255, 153);">
is it possible that there might be an already defined class in content.css or in cavendish/content.css which could be used instead of an inline style for that warning section? Just asking.

This is how the document styles dt: with an embedding <strong>.
<dt id="linux-i686"><strong>Linux (x86)</strong>
Now, this is how the stylesheet http://www.mozilla.org/css/base/content.css
styles dt:
	dt {
		font-weight: bold;
	}

http://www.mozilla.org/projects/seamonkey/releases/seamonkey1.0a/README.html
http://www.mozilla.org/projects/seamonkey/releases/seamonkey1.0a/changelog.html
http://www.mozilla.org/projects/seamonkey/releases/seamonkey1.0a/installation.html
http://www.mozilla.org/projects/seamonkey/releases/seamonkey1.0a/known-issues.html
http://www.mozilla.org/projects/seamonkey/releases/seamonkey1.0b/README.html
http://www.mozilla.org/projects/seamonkey/releases/seamonkey1.0b/changelog.html
http://www.mozilla.org/projects/seamonkey/releases/seamonkey1.0b/installation.html
http://www.mozilla.org/projects/seamonkey/releases/seamonkey1.0b/known-issues.html
http://www.mozilla.org/projects/seamonkey/releases/seamonkey1.0/README.html
http://www.mozilla.org/projects/seamonkey/releases/seamonkey1.0/changelog.html
http://www.mozilla.org/projects/seamonkey/releases/seamonkey1.0/installation.html
http://www.mozilla.org/projects/seamonkey/releases/1.0b.html (see the comments on 1.0a.html for the exact same issues)
http://www.mozilla.org/projects/seamonkey/reports/ns6b2analysis.html (empty!)
http://www.mozilla.org/projects/seamonkey/rules/shipping-rules.html (humor)
http://www.mozilla.org/projects/seamonkey/rules/tree-hints.html (7 years old document!)

Comment 1

[Gérard Talbot]

Another point. Usage of <link rel="..." ...> and <meta>-data is formally encouraged at mozilla.org Documentation Style Guide

http://www.mozilla.org/contribute/writing/guidelines#meta

<link rel="..." ...> when properly used, can help, can assist users with Site Navigation toolbar as it helps intra-page navigation, inter-page navigation and, finally, intra-project navigation.

Comment 2

[Robert Kaiser]

image height/widths:
yes, I'm lazy, I should probably do this.

<link rel="foo"> is probably a good idea, <a rel="foo"> isn't of much use though, esp. when the same rel="foo" already has been defined in a <link> on the same page already.

It would probably be a good idea to define a class for that inline-style div somewhere, perhaps in a new css file, I'll think about that.

The <dt><strong>foo</strong> may be redundant, but I actually prefer to keep it, as we are safe in case the style gets changed some time.

No relative links in news.html entries (and only there) is intentional, as we want to be able to copy&paste those entires to several news sites (mozine etc.) without needing to change the links from relative to absolute.

What's the problem in releases/ documents though? "Only" validation errors?

I'll go on and work on those docs, I have some local changes to some of those here, as another release is nearing which may have conflicting changes to stuff needed to do in this bug (one reason why I don't like others doing major changes to the files without my OK).
HTML validation problems will be fixed by me any time when I get pointed to any that creep in, of course :)

I don't care about brownbag, milestones/, release-notes/, reports/, rules/ though, as all of those are old files from the old days that are only kept for historical reference. Those are not pert of the current SeaMonkey project and therefore are not maintained by me. Talk to mozilla.org owner(s) for what to do about them before touching them though.

Comment 3

[Gérard Talbot]

> <a rel="foo"> isn't of much use
> though, esp. when the same rel="foo" already has been defined in a <link> on
> the same page already.

*If* <link rel="foo"> has already been defined, <a rel="foo"> won't be of much additional use. It could maybe be useful to style rel="foo" links though.

> It would probably be a good idea to define a class for that inline-style div
> somewhere, perhaps in a new css file, I'll think about that.

There is already 5 stylesheets defined, to be fetched and loaded for many mozilla.org webpages, and these stylesheets have many css rules, classes defined. Creating a 6th css file is not what I would recommend.
How about using <div class="key-point"> instead?

> The <dt><strong>foo</strong> may be redundant, but I actually prefer to keep
> it, as we are safe in case the style gets changed some time.

I do not understand. You see the duplication, the redundancy and you want to keep it just in case... If we followed your logic, then we would duplicate all already declared css rules in content.css and/or
in cavendish/content.css just in case these change. It's not how a stylesheet is supposed to work for a large and community-driven website, you know...

> No relative links in news.html entries (and only there) is intentional, as we
> want to be able to copy&paste those entires to several news sites (mozine etc.)
> without needing to change the links from relative to absolute.

Fair enough :) I was not aware of this.

> What's the problem in releases/ documents though? "Only" validation errors?

Yes, a few validation errors. You may want to check the following points too because they occur often:
- Example of empty anchor: <h2><a name="linux_install"></a>Installation Instructions</h2>
found in seamonkey1.0a/installation.html
- All links in seamonkey1.0a/changelog.html are redirected from http://bugzilla.mozilla.org/...
to
https://bugzilla.mozilla.org/...
- You use 
<tt class="filename"> or
<tt> or
<tt><em>
etc.. for identifying filenames. <tt> is generally discouraged
"In most cases, use of a phrase element such as CODE, SAMP, or KBD is more appropriate since these elements express the meaning of the text more clearly."
http://www.htmlhelp.com/reference/html40/fontstyle/tt.html
<tt class="filename"> will be resolved into <tt> in the mentioned page: there is no class="filename" for tt element defined in http://www.mozilla.org/css/base/content.css ; only for <code>.

	code.filename {
		font-style: italic;
		white-space: nowrap;
	}

Maybe samp.filename and kbd.filename should be defined. <shrug> 
Right now, the most suitable recommendation (and better semantic choice) at 
http://www.mozilla.org/contribute/writing/markup#computers
is <code class="filename">

> HTML validation problems will be fixed by me any time when I get pointed 
> to any that creep in, of course :)

I use HTML Tidy 0.8.3 extension (true SGML validation, just like w3c validator) from Marc Gueury on Fx 1.5.0.6; as soon as I load a page, I see if the page validates and, if not, how many errors and warnings. And it involves less than a sec. M. Gueury claims 1/100 of a sec. for parsing time.

Cheers, Gérard

Comment 4

[Robert Kaiser]

OK, index.html, news.html, and releases/*.html should be fixed now.
I introduced a SeaMonkey-specific stylesheet, this will be merged with a site-wide stylesheet when we move to our own site with bug 350250 and followups.

The warning box wouldn't fit as a .key-note as that one would be too soft for this box. It may fit for the other box usually below it, maybe I'll revisit that later, for now I've done my own class for those.

Intra-project navigation now follows the .snav-Model by being nice CSS. This doesn't look as good in IE6, but it's overall better style and still not too ugly on that non-compliant browser.

Your <a rel="foo"> argument with styling is interesting, but I decided to go without that for now, it's not too hard to add later on. a <link> tag is added though.

The <strong> "duplication" is because we also use <strong> for the platform in the "contributed" section, and this gurantees us better those will stay consistent even if the <dt> styling rules would change.

I'll go over the release notes documents once the rest of our documents are OK. Most problems we had esp. there were imported by copying from old Mozilla Suite relnotes, so expect to find lots of that stuff when you might look through those in your cleanup process...

I have to remark the only validator I really care about if the offical W3C one, everything else is considered only a helper for me, and given how many documents I already have ruined through the tidy tool, I have a certain resistance to everything connected with it (not that it really was its fault though, the fault was that it's just a generic tool and no human specifically trained by me)...
That said, I probably wouldn't use a FF extension anyways, as that may require me to use FF ;-)

Comment 5

[Gérard Talbot]

Robert, 

in comment #1, I wrote you that <meta>-data is formally encouraged in mozilla.org Documentation Style Guide. The next day and 3 days later, you deliberately removed <meta>-data already carefully edited in releases/index.html and in several other releases/* documents. Would you care to explain why you did this, obviously on purpose?

Comment 6

[Gérard Talbot]

> I introduced a SeaMonkey-specific stylesheet, 

You've added a 6th stylesheet; 14 css rules with 46 css declarations. Robert, was that really necessary? That was not requested nor expected, you know. If all mozilla.org projects would do that, add another stylesheet, it would for sure defeat the purpose of sharing and only using a common base of stylesheets (with all its related and known advantages).
Not to mention to defeat the purpose of writing style guidelines and markup guidelines for a community-driven website.
Also, by increasing the number of stylesheets and css rules, the complexity level increases and so will the risks of differentiated rendered layouts due to browser incompatibilities: that's unavoidable. For ex., line-height property, :before and :after pseudo-classes are overall not that well supported.
Maintenance can become an issue too: there is such a thing as over-use/inflation of css rules, css classes and stylesheets ("classitis" and "Divitis" are known expressions on this phenomenon). One fundamental advantage of use of CSS compared to traditional "tag-soup" coding is that CSS is supposed to make website maintenance easier, not more difficult.

I would agree with you that mozilla.org projects managers would benefit from being able to use an intra-project navigation class declared into the current stylesheets... that is if you ever open a bugfile, as suggested by fantasai in such cases in the intro of 
http://www.mozilla.org/contribute/writing/markup

CC fantasai added

Comment 7

[Robert Kaiser]

1) I couldn't find anywhere that mozilla.org enforces, encourages or wishes those useless, dumb (sorry, that's my opinion) Dublin Core meta tags in their documents (yes, I'm starting to think when you are maintaining them, I can't consider them "our" but only "their" any more). So much for comment #5.

2) The extra stylesheet is mainly for the reason that SeaMonkey documents will probably leave www.mozilla.org "soon" as a result of bug 350250 and I don't want to introduce new styles on the whole www.m.o site when they will probably get unused again in a not too long timeframe (that's esp. about the styles for the mainpage and releases pages). And it seemed like a good idea to not declare that stuff in <style> areas in the documents but a better maintainable extra CSS file.

3) :before and :after are used in the main mozilla.org stylesheets. Even if some popular borwsers don't support them, we're using them for formatting several boxes and even the snav class globally. So I see no reason why I can't do something very similar to snav (and you'll see that I even used the snav class itself where it was applicable).
And if our browsers perform better than some non-standards-compliant competitor, so be it (as long as the pages are usable and looking good enough on that competitor's software and we adhere to standards and good coding practice).
(BTW, same goes for HTML4-conforming #id navigation.)

4) I don't see any "classitis" and "divitis" in the documents I changed. That is, I don't see more than on other mozilla.org documents. And that said, the style guilde explicitely tells that inline style is unwanted and every styling should be done via classes or IDs, so a certain amount of classes is simply necessary.

5) I am maintaining those pages belonging to the "new" SeaMonkey project, and therefore I (together with the SeaMonkey Council) will decide on what should be done with those pages. As long as they conform to mozilla.org page writing guidelines and validate with the official W3C validator as HTML4 strict, I believe I have some freedom in my decisions about those pages and can even veto the opinion of some random contributor who comes along and wants to change them.
Please understand me correctly, I'm happy about input and ideas for improvements, I'm happy to be pointed at arising problems and bugs, but again, I am maintaining those pages, and I intend to continue to do that.

Comment 8

[Gérard Talbot]

> 1) I couldn't find anywhere that mozilla.org enforces, encourages or wishes
> those useless, dumb (sorry, that's my opinion) Dublin Core meta tags in their
> documents

Where do you see that you have (or had) to remove <meta>-tags ?
"Add meta description to help indexing. The description text should be an abstract of the page. If you're adding a keywords tag as well, pick keywords that you would use if you forgot the URI and were searching for the page, not just any remotely relevant word that comes to mind."
http://www.mozilla.org/contribute/writing/guidelines#meta
Why have you removed <meta>-tags right after I told you in this bugfile that adding meta tag was formally encouraged? You can't claim ignorance here...

Dublin Core is most likely the best metadata system; it has the best chance (mostly because of its bibliographical system) of being used in the future for searching purposes. You don't seem to care about any <meta>-data anyways, whatever their relative (inherent) merits might be.

>
> 2) The extra stylesheet is mainly for the reason that SeaMonkey documents will
> probably leave www.mozilla.org "soon" as a result of bug 350250 and I don't
> want to introduce new styles on the whole www.m.o site when they will probably
> get unused again in a not too long timeframe (that's esp. about the styles for
> the mainpage and releases pages). And it seemed like a good idea to not declare
> that stuff in <style> areas in the documents but a better maintainable extra
> CSS file.

A 6th stylesheet is clearly not the path projects managers or webpage project managers should take, and that, for many reasons: that is clearly not the best recommendable way to deal with style issues or styling needs in a community-driven large website.
If you're no longer hosted on mozilla.org, then do whatever it pleases you. There is an importantissimo difference in what I'm saying here.


>
> 3) :before and :after are used in the main mozilla.org stylesheets. Even if
> some popular borwsers don't support them, we're using them for formatting
> several boxes and even the snav class globally.

What if there is a simple, standard way to avoid :first-child, :before and :after? Maybe that snav class is also unneedlessly complex too, not degrading so easily...

> So I see no reason why I can't
> do something very similar to snav (and you'll see that I even used the snav
> class itself where it was applicable).

Hear me up, Robert. This is what you do in all releases/* pages:

<ul class="pnav">
 <li><a href="../">SeaMonkey Project</a></li>
 <li>Releases</li>
</ul>

and then you have 6, that's right, 6 css rules (some complex) for that pnav class coming from a 6th stylesheet:

ul.pnav { /* project navigation */
  list-style-type: none;
  margin: 0 0 1em 0;
  padding: 0;
}
ul.pnav > li {
  margin: 0;
  padding: 0;
}
ul.pnav > li {
  display: inline;
}
ul.pnav > li:before {
  content: " > ";
}
ul.pnav > li:first-child:before {
  content: "";
}

and many browsers which do not implement Site Navigation toolbar do not at the same time support :first-child, :before, :after, on top of all this!

Now, try the following as a fully self-sufficient, complete, perfectly-degradable replacement:

<p><a href="../">SeaMonkey Project</a> &gt; Releases</p>

It will work in all browsers I can think of, even Lynx 2.85. No extra stylesheet. No complex css rules. Not even a single css declaration.


> And if our browsers perform better than some non-standards-compliant
> competitor, so be it (as long as the pages are usable and looking good enough
> on that competitor's software and we adhere to standards and good coding
> practice).
> (BTW, same goes for HTML4-conforming #id navigation.)

"Use <a name="anchor-name">.  Linking to an ID isn't supported in many browsers."
http://www.mozilla.org/contribute/writing/guidelines#linking

I did not decide that anchor-naming policy but then I think it makes sense not to alienate unneedlessly the browsers which may not support or do not support intra-page navigation thanks to id. You'll reach more browsers and web-aware applications with name attribute: so why would you want to choose deliberately a coding practice that restricts more, that contraints navigation more, that excludes more?
Access to content and navigation functionality are top priorities at WAI and in WCAG documents.


> 4) I don't see any "classitis" and "divitis" in the documents I changed.

There is already a lot of classes available, declared and defined in
css/base/content.css: 94 css rules, 223 css declarations
css/cavendish/content.css: 75 css rules, 200 css declarations
css/base/template.css: 19 css rules, 41 css declarations
css/cavendish/template.css: 41 css rules, 154 css declarations
and there are 2 documents explaining what the defined classes do. (Maybe people don't bother reading+exploring these 2 documents and 4 stylesheets because they overwhelm them).
Your 6th stylesheet brings more classes, more css rules, more css declarations and your code brought more wrapping div: no one can seriously claim otherwise.

Eg: you do
<div class="redirect-user">
  A newer version of SeaMonkey is available. For more information about what's
  new and to download the latest version, go to the <a href="./">Releases</a>
  page.
</div>

What's wrong with/what would be so incorrect if you go with:
<p class="important"> <!-- or even class="remark" -->
  A newer version of SeaMonkey is available. For more information about what's
  new and to download the latest version, go to the <a href="./">Releases</a>
  page.
</p>

> That
> is, I don't see more than on other mozilla.org documents.

The other mozilla.org documents are *_not_* necessarly the example to follow; on the other hand, the markup guidelines and style guidelines have guidelines to follow along with examples that a project webpage maintainer can use.

> And that said, the
> style guilde explicitely tells that inline style is unwanted and every styling
> should be done via classes or IDs, so a certain amount of classes is simply
> necessary.

Well, this is where you took the path of creating a 6th stylesheet with 14 css rules, 46 css declarations. OTOH,
"if you find yourself needing presentational markup or CSS, check here first—maybe what you're looking for is already defined. (If it's not, then maybe it should be. If you think your style rules would be useful for other authors, file a bug report against"
is what was clearly mentioned at
http://www.mozilla.org/contribute/writing/markup
I am repeating myself.


>
> 5) I am maintaining those pages belonging to the "new" SeaMonkey project, and
> therefore I (together with the SeaMonkey Council) will decide on what should be
> done with those pages.
> As long as they conform to mozilla.org page writing
> guidelines and validate with the official W3C validator as HTML4 strict,

And they did not. Definitely not always. And they involved new pages which failed to conform to several of those guidelines. 

There would not be so many m.o. webpages (9,000 listed in 2 attachments in bug 151557) failing validation and failing to meet large parts of markup|style guidelines if a policy on new webpages say, in year 2000, had been implemented and followed/agreed on.

> I
> believe I have some freedom in my decisions about those pages and can even veto
> the opinion of some random contributor who comes along and wants to change
> them.
> Please understand me correctly, I'm happy about input and ideas for
> improvements, I'm happy to be pointed at arising problems and bugs, but again,
> I am maintaining those pages, and I intend to continue to do that.

What about mozilla.org markup|style guidelines then? What about your removal of <meta>-data then? What about reducing css complexity while improving webpage degradability and accessibility?

Is the project whose webpages you maintain still part of a convergence to meet those guidelines? or something outside mozilla.org which does not have to comply with any mozilla.org markup|style guidelines?

Comment 9

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

(In reply to comment #8)
> "Use <a name="anchor-name">.  Linking to an ID isn't supported in many
> browsers."
> http://www.mozilla.org/contribute/writing/guidelines#linking

That's out of date, from back when people cared about Netscape 4.x.  It should be removed.

Comment 10

[Robert Kaiser]

Gérard, I think I have answered everything but one thing you did refer to before, so I don't feel I need any more reply to that. You just seem to not want to understand me. And the one thing I wouldn't be able to rectify my position otherwise is the one dbaron just referred to as being outdated.

Just one note about meta tags: The guidelines never talk about Dublin Core, with which I claim you are/were adding useless, not easy maintainable (esp. change times) and redundant (title) information. I'm not opposed to "normal" HTML meta tags (description, keywords) but very much to Dublin Core meta tags where they are not needed.

The pnav class is closely modeled after the snav class, and correctly identifies this navigation part as list, which it is in reality, not another text paragraph as before and in your example. That actually help accessibility, if you like it or not.

That said, I don't see much more than ranting any more in your comments, and I'll stand by my decision to maintain our documents myself, which I will do.

Comment 11

[fantasai]

Woah, please calm down both of you! Robert, the style guide is my domain; if there's a problem with its rules, you can always email me, and I'll either update it or explain why it is the way it is.

Gérard, Robert's right, the style guide makes no mention of Dublin Core. It suggests using meta 'description' (which I believe is used by some search engines in presenting results, if not in calculating them), and gives some hints on picking good 'keywords' if the author decides to go that route. Dublin Core is overkill for this website.

I've updated the style guide to recommend 'id' anchors except in certain circumstances. http://www.mozilla.org/contribute/writing/guidelines#linking Let me know what you think.

I think your .redirect-user should be .important, but I also think your styling is prettier than the current default we have for .important -- so I'd like to copy your rules into the site-wide style sheet, if you don't mind, and then you can switch to class="important".

.release-general should probably be .key-point

> The <strong> "duplication" is because we also use <strong> for the platform
> in the "contributed" section, and this gurantees us better those will stay
> consistent even if the <dt> styling rules would change.

Why don't you use <dt> for both sections? <dt>OS/2<dd> is much better markup than <p id="os2"><strong>OS/2:</strong><br> anyway, and then they'd be guaranteed to be even more consistent because you'd drop the colon. ;)

.pnav is a perfect example of a class that should be available site-wide. Breadcrumb navigation is generally useful, and I'm surprised we don't already have rules for it somewhere. That said, I would use Gérard's markup, not an unordered list. It degrades much better, but it also better reflects what the navigation is saying. It's not an unordered list of items (like .snav is). It's ordered, and it represents a path. The greater-than sign should be in the markup; it's a fairly accurate way of stating the hierarchical relationship amongst the linked pages. I'd code the breadcrumbs like this:
  <p><a href="../">SeaMonkey Project</a> &gt; <strong>Releases</strong></p>
with e.g. class="crumbs" on the <p>.
If that's acceptable to you, Robert, I will add that to the markup guide / css
and you can adapt your markup accordingly.

Robert, Gérard has given (and I hope will continue to give) a lot of useful advice for improving these pages. He's taken on a very frustrating task in trying to clean up the entire website, so please cut him some slack, for my sake. Gérard, thank you for pulling me in when you did. I hope we can all get along constructively now, as I don't see anything left to argue about here anymore. :)

Comment 12

[Robert Kaiser]

fantasai:
OK, what you say about using .important and using our style for the global .important sounds good to me.
Using .key-point would probably be correct for the other box, I just fear that the rounded .key-point box and the rectangular .important box clash with each other, that's why I didn't use .key-point in the first place.

Your argument about <string> and <dt> is very good, I see Gérard and me both looked at it the wrong way and I buy it :)

The .pnav/breadcrumbs case is more difficult though: While I agree it's no unordered list, it still a list (a hierachical/ordered one) in my eyes and should be marked up as such for acessibilty and correctness reasons, IMHO. That's what I realized when seeing the snav class mentioned in the style guide and that was the reason for me to switch from simple markup as you proposed to that list class at all. You convinced me though that it should be a <ol> and not a <ul> ;-)

For the general case, I know that Gérard is doing good work for bringing mozilla.org pages up to speed, the vast majority of which is unmaintained anyways. In the case of pages that are actively maintained (like those), I object to just changing them all over the place without prior notice, which he did in the beginning. It's much better to file bugs against those actively maintained pages and tell the maintainers how they should improve the pages, as that helps everyone a lot more by teaching the maintainers about their errors - at least that was the case for me, and I did rework quite a lot on those pages and will do some additional changes because of our current discussion.
What led to my recent angry comment was that he insisted on changes and asked again about things I already had explained, some even more than once. And that does not help anyone. As you see in this comment here, I'll happily buy good arguments, but I don't feel I need to reply to reiterations of "but I want Dublin Core" when they have no arguments attached...
That said, despite the inconvenience he caused me at times, I'm happy Gérard brought up those topics as I've already improved SeaMonkey pages quite a bit following that and I'll improve them even further according to the outcome of those discussions.

Comment 13

[Robert Kaiser]

Attachment: change to global .important class

fantasai, this is the change for the global .important class. I'd like the actual change to be OKed before I change global rules ;-)
Not yet sure how much I like the larger font set there on the SeqaMonkey pages, but I guess I'll need to swallow that.
And yes, I pulled in an unrelated comment fix I spotted when looking into the file.

Comment 14

[Gérard Talbot]

> For the general case, I know that Gérard is doing good work for bringing
> mozilla.org pages up to speed, the vast majority of which is unmaintained
> anyways.

This issue is important to address. This issue is not just related to your project webpage maintenance. You said 

"I don't care about brownbag, milestones/, release-notes/, reports/, rules/
though, as all of those are old files from the old days that are only kept for
historical reference. Those are not pert of the current SeaMonkey project and
therefore are not maintained by me."

What's the best, future-promoting way to deal with old, outdated webpages? If the current policy is to ignore old, outdated webpages, to leave them where they are, then with time, the number of unmaintained m.o. webpages increases and does not decrease. This is possibly the attitude/policy taken by a lot of project managers and/or project webpage maintainers. Out of 9,000 webpages, there is quite possibly more than half of them which are unmaintained like that.

Who should deal with these webpages? This issue should be discussed. 
Robert, you have a double-standard here: either you are maintainer of *_all_* of the webpages in the seamonkey directory or you are not. This is furthermore true since you have repeatedly insisted in this very bugfile that you are/want to be the absolute king of these seamonkey project webpages. You even mentioned in an email that I should not upgrade the very webpages that you say shouldn't be maintained by you in this bugfile! <shrug>
Unmaintained project webpages won't suddenly become maintained without some kind of an involvement. Unmanaged, outdated webpages won't become managed without an involvement coming from somewhere, someone.
My answer is the project manager or the project webpage maintainer (if there is one and an active one) should address/deal with these issues. Otherwise the bug assignee to such issue should.

What should be done? Deletion, removal or archiving (into .zip files or not) in some sort of "graveyard documentation" directory. Otherwise upgrade and maintenance of the webpages. There is nothing complicated here.

> In the case of pages that are actively maintained (like those), I
> object to just changing them all over the place without prior notice, which he
> did in the beginning. 

Well, I did send you an email last year on this.

> It's much better to file bugs 

Yes, you have a point on that. I have started to file bugfiles systematically for this purpose. But it's not just for validation (bug 151557) purposes: it should also involved markup guidelines and style guidelines ... while we are addressing coding practices.


> against those actively
> maintained pages 

I do/can not know beforehand which webpages are maintained. I do/can not know in advance who is project webpage maintainer (if there is such a person). I couldn't find any active+updated list on project webpage maintainer on m.o.
Last modified date and Document History (CVS log) file are not per se necessarly clear or trustworthy on these matters. Having authored a webpage does not necessarly indicate project webpage maintenance nor even just that there is a project webpage maintainer.

> and tell the maintainers how they should improve the pages, 

I agree with you that an how-to-do+explainations approach has more future, is more fruitful than what people may perceive as an agressive, hostile take-over. Getting them involved, empowering them with/thanks to the guidelines is constructive and fruitful for everyone. I am claiming that all my changes were listed, descrived and explained. And I claim that a lot of people do make changes, modifications, tweaks, etc.. in a lot of webpages hosted on m.o. without being formally, officially a webpage project maintainer.

as
> that helps everyone a lot more by teaching the maintainers about their errors

I wanted and want to adopt that approach. This bugfile shows there is a limit to this approach. People have different perspective, different background, different depth of experience, different depth of understanding semantic, markup, stylesheet, etc.
Eventually, people like yourself, Robert, have to understand that m.o. webpages are community-driven webpages which must comply with basic, general community-driven guidelines, goals, etc. You have mentioned "Seamonkey council" and "Seamonkey style" but those are not defined anywhere in a document and certainly not meeting m.o. style guidelines as far as I'm concerned.

 -
> at least that was the case for me, and I did rework quite a lot on those pages
> and will do some additional changes because of our current discussion.

How much discussion, typing arguments, do you reasonably expect from people like me? How much discussion is reasonable to you? There is a limit to your receptivity on all these issues, obviously. E.g.: if you couldn't understand/agree with my reasoning on pnav class, - and you still believe it should be a list with 5 css rules - then 
someone else should invite you to read for yourself what accessibility expert propose for that very same and precise matter. I can not and will not search for you.

> What led to my recent angry comment was that he insisted on changes and asked
> again about things I already had explained, some even more than once. And that
> does not help anyone. As you see in this comment here, I'll happily buy good
> arguments, but I don't feel I need to reply to reiterations of "but I want
> Dublin Core" when they have no arguments attached...

I explained my changes. I explained the dangers, pitfalls, problems and blatant inconsequences of bringing a 6th stylesheet into any/all m.o. project. And I failed in convincing you to remove that and to adopt a different policy.
 
You removed <meta>-data - yes Dublin Core scheme-based (what's soooo awful about Dublin Core to begin with?) - *_after_* I told you in this bugfile about the formal encouragement to use meta-data. You couldn't tolerate those meta-tags: I explained Dublin Core scheme have more future and are better. You did not even replace these meta-data in all those webpages! So you can't claim to support meta data.
There was no need to remove them. And if Dublin Core was making you so sick, why didn't you just replace them with the type/scheme of meta-data you preferred?

> That said, despite the inconvenience he caused me at times, 

When you refer to "talbotism impact" in the CVS logs - and you did that in several fles after this bugfile was created - you went into a personal mode. All of that was uncalled, unjustified, undeserved, non-professional and should be discouraged. You've made it an ethic/etiquette issue. Robert, I was definitely (before and then) trying to work with you, not against you, not despite you.

In review-and-flags.html
"I used HandCoder 0.3.4 from KompoZer 0.77 to fix the nested lists and to reformat the code indentation of the deeply nested lists."
"2006-09-12 05:35 make reviews and flags document fit SeaMonkey style again after talbotism impact"

I fixed validation markup errors specifically related to the nested lists thanks to a tool, a reliable, totally non-subjective tool. The code re-indentation for that deeply nested lists was welcomed, was needed to understand (recognize visually) the intricated nesting, was created by HandCoder. Doing some kind of indentation for nested lists helps maintenance. Obvious! Code re-indentation (horizontal and vertical) can be customized in HandCoder to whatever your code indentation tastes may be.

> I'm happy Gérard
> brought up those topics as I've already improved SeaMonkey pages quite a bit
> following that and I'll improve them even further according to the outcome of
> those discussions.

When you reply to my emails, please stop trash-talk with vocabulary like "shit", "crap", "dumb", "stupid", etc.. None of this is necessary, best, useful or acceptable.

Comment 15

[Robert Kaiser]

I won't reply to any messages in that matter that don't directly concern work on pages I actively maintain (i.e. did check-ins to in the last year) and don't contain constructive arguments for improvements.

And if an official maintainer of mozilla.org steps up and tells me all documents inside projects/seamonkey/ have to be maintained by the current SeaMonkey project or deleted, I'll happily delete old release note and brownbag videos as I don't intend to touch them in any other way.

A bug report like this should contain constructive comments for the matter it is about, all general discussion should go into groups/lists, and I will stick with that policy.

Comment 16

[Reed Loden [:reed]]

(In reply to comment #15)

> And if an official maintainer of mozilla.org steps up and tells me all
> documents inside projects/seamonkey/ have to be maintained by the current
> SeaMonkey project or deleted, I'll happily delete old release note and brownbag
> videos as I don't intend to touch them in any other way.

We have official maintainers? Hah!

Comment 17

[fantasai]

Comment on attachment 239889 [details] [diff] [review]
change to global .important class

I'd shift these rules to cavendish/content.css rather than base/content.css. Also, please use 'background' instead of 'background-color' (this makes sure it resets any images that might've cascaded through) and use #XXXXXX form, which is better supported. Also set 'color: black' as well. I agree the text seems a bit large.. maybe add a rule 'font-size: 1.1em'? That should increase the size, but not as much. (Tweak the number as you like.)

Comment 18

[fantasai]

Gérard, that's enough, please. I've already said Dublin Core is overkill here. It's not really helping anybody: it doesn't help searching, cvs already tracks all our changes and dates for them, and authorship should be listed visibly in the page, not invisibly in metadata. Tantek Çelik, who is working on improving metadata use on the web through microformats.org, would tell you that good metadata is visible by design and invisible metadata is useless on the Web. Robert is within his rights to delete those tags;  he's maintaining those pages, and they are just getting in his way.

There are a lot of old, unmaintained pages on mozilla.org, and yes, most of them are out of line with the style guide. I would prefer that we focus our efforts on improving new content and old but maintained content, however. Robert (and many other page maintainers, for that matter) have a lot of other important tasks to work on and can't be expected to clean up pages that are there only for archival purposes anyway. I'm sure if you or someone else volunteered to make the markup/validation changes, they would give you the go-ahead.

I know that you and Robert have had some heated discussion about coding style, but you have also done some useful, constructive work together as well. Robert has, as he said, learned a lot about better coding style, and the seamonkey pages are no doubt in better shape than ever. So please, let's put aside the history of angry comments and build instead on the useful things you have accomplished together.

Robert, Gérard has a good point that it is very difficult to figure out who the maintainer of a given page is on mozilla.org. Can you sign your name to the seamonkey pages as the maintainer? You can list it at the bottom (in an <address>), if you'd rather, but I think it's a good idea to make it easy to identify/contact the page maintainer.

About the breadcrumbs,
  http://www.webaim.org/discussion/mail_message.php?id=8982

Comment 19

[Reed Loden [:reed]]

fantasai: Did you mean to mark this bug as fixed? You denied review on the patch...

Comment 20

[Gérard Talbot]

> Dublin Core is overkill here.
> It's not really helping anybody: it doesn't help searching, 

If you don't include meta data aimed at/for searching, listing keywords, description, contributors, etc.., then - of course - it won't help searching, indexing, bibliographical indexing, etc.

> cvs already tracks
> all our changes and dates for them, and authorship should be listed visibly in
> the page, not invisibly in metadata. 

What's wrong with doing both? I never removed authorship visibly listed in a page. Why not make the document self-documented, self-independent (therefore more migratable), self-logical both from a reader and from an author perspective? If one wants to increase the scope and potential reach of a document, then one would use <meta>-data in that way, regardless of scheme used.

> metadata is visible by design and invisible metadata is useless on the Web.

Search indexing engines do read/parse the metadata edited in the <head> section.

> Robert is within his rights to delete those tags;  he's maintaining those
> pages, and they are just getting in his way.

He did not replace the meta-data: he remove them.
The origin of most of the problems I had with Robert came from unclear communication, blatant incoherences and undefined procedures. Robert wrote this in
http://www.mozilla.org/projects/seamonkey/start/

{
Docs and Website
    The website is currently being totally rewritten, and any help would be greatly appreciated. SeaMonkey could also do with all sorts of documentation - see the Mozilla Documentation Project.
}

Over here and elsewhere, he is much more constraining, rigid and restrictive.
The following chunks come from Robert's email dated September 11, 2006:

"
Me: > Well, there is the
> 
> mozilla.org Documentation Style Guide
> http://www.mozilla.org/contribute/writing/guidelines

Robert: Our pages are not documentation, so I don't care much about that one.
"

"
Me: > and the
> mozilla.org Markup Reference
> http://www.mozilla.org/contribute/writing/markup
> 
> I thought you knew about these documents!

Robert: Umm, I actually did not know about them, sorry.
"

"Robert: they [Dublin Core meta-data] add useless crap to documents. Leave them out of projects/seamonkey. and don't ever dare to edit anything within the 
seamonkeyprject-org cvs module that is not reviewed by the SeaMonkey web 
page maintainer.

Robert: >> I'll probably revert those when I find time.
> 
Me: > Why would you want to do that? Please elaborate.

Robert: Because I am the maintainer of those pages, and I want to be informed of 
any characters that is changes in them.
"


> 
> There are a lot of old, unmaintained pages on mozilla.org, and yes, most of
> them are out of line with the style guide. I would prefer that we focus our
> efforts on improving new content and old but maintained content, however.
> Robert (and many other page maintainers, for that matter) have a lot of other
> important tasks to work on and can't be expected to clean up pages that are
> there only for archival purposes anyway. 

If Robert says he does not maintain page "x", then why does he need to revert changes done by others?

> I'm sure if you or someone else
> volunteered to make the markup/validation changes, they would give you the
> go-ahead.


It's counter-productive having to send an email, then wait, then open up a bugfile, then wait, etc.. just to get the permission to fix 2, 3 or 4 validation markup errors in a document.

> I know that you and Robert have had some heated discussion about coding style,
> but you have also done some useful, constructive work together as well. 


The "talbotism" remark had no reason to be.

 
> Robert, Gérard has a good point that it is very difficult to figure out who the
> maintainer of a given page is on mozilla.org. Can you sign your name to the
> seamonkey pages as the maintainer? You can list it at the bottom (in an
> <address>), if you'd rather, but I think it's a good idea to make it easy to
> identify/contact the page maintainer.

The "Docs and Website" seamonkey/start/ description needs to be clarified too. From the beginning, I never wanted to work against Robert (or any author), never wanted to work despite Robert. I created this bugfile, you know. Several aspects of the problems (maintenance, collaboration, style|markup guidelines documents) I underlined in this bugfile happen in lots of other project webpages.

> 
> About the breadcrumbs,
>   http://www.webaim.org/discussion/mail_message.php?id=8982

Mark Pilgrim, accessify.com, Peter-Paul Koch and several others use 
<p id="breadcrumbs"><a href="[path/filename.html]">Webpage name</a> &gt; Current page</p>
They don't use 5 css rules for a list. Robert, are we all wrong??

Comment 21

[fantasai]

Reed: No, I didn't mean to close the bug; thanks.

Gérard: Discussion of a) mozilla.org's meta tag policy and b) problems in your
working relationship with Robert are both out of scope for this bug. If you want
to talk about a), open a new bug about it and give a good, clear explanation of your rationale. If you want to discuss b), then write a coherent private email to me listing your grievances and CC KaiRo and the three of us can discuss it without polluting this bug report further.

Note that while fixing minor validation problems shouldn't require page maintainer's permission, doing a major revamp on the markup is often hard to follow, and changing indentation and wrapping especially wreaks havoc on the CVS history (because it's kinda dumb about whitespace like that). Changes like that, even if they don't affect the text at all, are very disconcerting to the page maintainer because they aren't sure what happened and if anything significant has changed.

Comment 22

[Robert Kaiser]

(In reply to comment #18)
> Gérard, that's enough, please. I've already said Dublin Core is overkill here.
> It's not really helping anybody: it doesn't help searching, cvs already tracks
> all our changes and dates for them, and authorship should be listed visibly in
> the page, not invisibly in metadata. Tantek Çelik, who is working on improving
> metadata use on the web through microformats.org, would tell you that good
> metadata is visible by design and invisible metadata is useless on the Web.
> Robert is within his rights to delete those tags;  he's maintaining those
> pages, and they are just getting in his way.
> 
> There are a lot of old, unmaintained pages on mozilla.org, and yes, most of
> them are out of line with the style guide. I would prefer that we focus our
> efforts on improving new content and old but maintained content, however.
> Robert (and many other page maintainers, for that matter) have a lot of other
> important tasks to work on and can't be expected to clean up pages that are
> there only for archival purposes anyway. I'm sure if you or someone else
> volunteered to make the markup/validation changes, they would give you the
> go-ahead.
> 
> I know that you and Robert have had some heated discussion about coding style,
> but you have also done some useful, constructive work together as well. Robert
> has, as he said, learned a lot about better coding style, and the seamonkey
> pages are no doubt in better shape than ever. So please, let's put aside the
> history of angry comments and build instead on the useful things you have
> accomplished together.
> 
> Robert, Gérard has a good point that it is very difficult to figure out who the
> maintainer of a given page is on mozilla.org. Can you sign your name to the
> seamonkey pages as the maintainer? You can list it at the bottom (in an
> <address>), if you'd rather, but I think it's a good idea to make it easy to
> identify/contact the page maintainer.
> 
> About the breadcrumbs,
>   http://www.webaim.org/discussion/mail_message.php?id=8982

Those are good arguments. I'm not completely convinced yet, but I understand those. I especially like the last paragraph:
"So much of accessibility is understanding the issues, choosing from
multiple 'good' options, and doing what you think is best. It's certainly
subject to opinion, but this is what my opinion on this would be."

That's quite often the real problem, and it's also here. And the biggest problem is probably the reason why I introduced breadcrumbs at all, which is that we have too much other navigation already on the page that still doesn't point to the main SeaMonkey page anywhere.
And then there's the general breadcrumbs problem that they represent a hierachical path but there are no HTML elements for representing such a path, so one needs to improvise. I still think the list markup looks cleaner than the straight paragraph markup, but I understand the problems.

About the "important" class: You mean, the whole class rules for that one should be moved to cavendish? Should I attach another patch or just move over those rules and apply the requested changes?

For the page maintainer stuff, adding the following blurb at the end of every page should be OK, right?
<address>Page maintainer: Robert Kaiser (KaiRo) &lt;<a href="mailto:[e-mail]">[e-mail]</a>&gt;</address>

Comment 23

[fantasai]

For .important, just add your rules to cavendish/content.css; they will cascade
over the uglier rules in base/content.css.

For the blurb, I'd go with either
  <address>Maintained by <a href="mailto:[e-mail]">Robert Kaiser
  (KaiRo)</a></address>
or just
  <address><a href="mailto:[e-mail]">Robert Kaiser (KaiRo)</a></address>

Comment 24

[Robert Kaiser]

fantasai:
Thanks, I'll do that. About the text size of .important - I risked inconsitency of a few releases pages and did previews, which size do you like better:
1em - http://www-stage.mozilla.org/projects/seamonkey/releases/1.0.1.html
1.1em - http://www-stage.mozilla.org/projects/seamonkey/releases/1.0.html
1.15em - http://www-stage.mozilla.org/projects/seamonkey/releases/1.1a.html
1.2em looks as big as the original "larger" style that we already said is too big.

Looks like the only thing we have not completely resolved yet are the breadcrumbs...

Comment 25

[fantasai]

Heya Robert,
1.1em and 1.15em both look fine to me. Your call.
One thing I would do, though, is increase the padding to something closer to the value you have in your blue box--but specify it in ems, so it scales with the font during text zoom, etc.

For the breadcrumb navigation-- I added a .crumbs class to the markup guide
  http://www.mozilla.org/contribute/writing/markup#crumbs
Ideally the mozilla.org build system would take care of hierarchical navigation, like it did on devmo's old CVS system.. but, anyway, let me know what you think. :)

Comment 26

[Robert Kaiser]

Attachment: add cavendish .important class, remove top border from .crumbs

OK, here's another iteration of my proposed changes to global mozilla.org style sheets:
1) add new extended .important definitions in cavendish
2) if p.crumbs is the topmost content element, remove its top border (like we're already doing it for headers)
3) slight comment typo correction in base/content.css

If those changes are OK with you, I'll check them in this way.
If you want to see how the changes look, I've already applied them to http://www-stage.mozilla.org/projects/seamonkey/releases/1.1b.html through the seamonkey style sheet (from which I'll remove those styles after that checkin, of course)

Comment 27

[fantasai]

Comment on attachment 245000 [details] [diff] [review]
add cavendish .important class, remove top border from .crumbs

Looks good to me. :) Thanks for making the fix.

Comment 28

[Robert Kaiser]

OK; this is checked in now, along with all changes for the SeaMonkey releases pages. I'll update the rest of the SeaMonkey project pages to fit the new style soon, and then close this bug.

I'm still a bit nervous about adding my email address to all pages, as I don't want users to mail me about every other SeaMonkey problem, thinking I "maintain SeaMonkey"... but we'll see, I can always remove those <address> tags and use HTML comments instead, if needed.

Comment 29

[Robert Kaiser]

OK, I checked in changes to all relnote pages now to add breadcrumbs and make the <head> fit with what we have everywhere else. That should complete my rework of all pages of the new SeaMonkey project (as I said, I won't touch historical docs that were there before 2005), and I'll mark this bug as fixed now.

I didn't make sure that all relnote pages (projects/seamonkey/releases/seamonkey*/*.html) validate, that's already a big number of pages, too big to spend my time checking all of them. If you find any bugs and/or validation errors there, please ideally file a bug against Chris Thomas ([e-mail]) and me CCed - for all other pages of the SeaMonkey project, against me.
But please do individual bugs for specific issues, catch-all bugs are always hard to tick off in the to-do list and mark fixed.

Thanks to everyone who pointed out how we can improve our pages and who provided me with the needed help to really get this fixed.