152104 - Add markup styles to persistent-style.css

Status: VERIFIED FIXED

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

Description

[fantasai]

Add style rules to persistent-style.css so that the classes defined 
in moz.zope.org's Markup Guide become useful on mozilla.org. This will allow us 
to check documents with cleaned-up markup into mozilla.org without losing any 
styling.

Comment 1

[fantasai]

*** Bug 152103 has been marked as a duplicate of this bug. ***

Comment 2

[fantasai]

Attachment: new persistent-style.css

I can't access cvs-mirror's docs, so I could get a cvs diff.
Tested in NS4, Mozilla, and IE5. The rules are simple, so I don't anticipate a
problem.

Comment 3

[fantasai]

Gerv-- what do I need to do to get this checked in?

Comment 4

[Gervase Markham [:gerv]]

Are you certain this isn't going to adversely affect the look of current
mozilla.org content? 

Does every page need the entire style sheet - is there any way of only having it
for the pages which need it?

I'm not certain I have permissions to change that file...

Gerv

Comment 5

[fantasai]

> Are you certain this isn't going to adversely affect the look of current
> mozilla.org content?

I didn't drop anything, and other than the <p> and header stuff (which you can
delete, if you wish) everything that's added uses a class selector--this means
the rules won't be applied unless the author explicitly assigns the class. I'm
quite sure this won't adversely affect current mozilla.org content.
If you want, you can ask Hixie to look it over.

> Does every page need the entire style sheet - is there any way of only having
> it for the pages which need it?

You /could/ separate the Markup Styles into a separate file and ask authors to 
explicitly link that... (Does the wrapper keep <link>s?)
Why would you want to? The stylesheet's not included in the page; it's linked, 
so it will only be downloaded once anyway.

If the styles are included by default, then authors are more likely to use them 
instead of creating their own. We want this; it ensures consistency, it 
encourages semantic markup, and it gathers style expertise so we have higher 
quality in our styling.*

* Example: In <pre class="programlisting">, the use of a border works around an 
NS4 bug on block backgrounds, and the "display: table" suggested by Bernd 
ensures that the background stretches with the content instead of letting only 
the text overflow.

Comment 6

[Gervase Markham [:gerv]]

Just checked - I don't have permission to alter this file. CCing endico.

Gerv

Comment 7

[fantasai]

Attachment: patch

Comment 8

[Dawn Endico]

where's the guide for using these styles? lets add a link to it as a comment to
the patch. or add short comments to the patch itself if it doesn't bloat the 
css file too much. (for some value of 'too much')

Comment 9

[fantasai]

Attachment: new patch

Added Markup Guide's URI and made also a few other slight changes.
Ready for review/checkin.

Comment 10

[Daniel Wang]

maybe we should add
  td p:first-child { margin-top: 0 }
  td img { display: block; }
  td p img, td li img, td div img { display: inline }

not required now, but would come in handy should we switch to HTML-strict in the
future.

I am not a fan of the .important class. It does not fit well with the current
layout.
I think it should have border-width = border-width of the left navigation pane. The
background-color should be dropped. The border color should be either orange or
black
to be consistant with the banner theme. If we change the banner, the color
should also
be changed accordingly. Also, "font-size: larger;" should be dropped from the patch.

see
  http://www.mozilla.org/newlayout/bugathon.html
and
  http://www.geocities.com/stolenclover/backstage/mozilla-org/docs/mdp/FAQ.html
for alternative working examples

Fantasai, before we go with this, can you browse around mozilla.org and find
pages with
custom styles? We need to know what's causing authors grief so we can minimize
CSS hacking.

Comment 11

[fantasai]

Attachment: persistent-style.css

New version.

Comment 12

[fantasai]

The .important class is for things like the box at the top of
  http://www.mozilla.org/community.html
The coloring is meant to catch one's attention.

Anyway, I'll file a separate bug for making it pretty. This one's just for the
basics.

What's the process for getting changes to persistent-style.css?
I've posted to n.p.m.documentation for review. Bob Clary looked at it; his
comments have been accounted for. It validates. Anything else?

Comment 13

[Gervase Markham [:gerv]]

> What's the process for getting changes to persistent-style.css?

Contact me :-) But things have changed somewhat with the new front page (which
is going to be converted into a wrapper.)

Gerv

Comment 14

[Daniel Wang]

Gerv, I like the new front page, but please get someone to change the orange
footer. The wraper should be neutral (white, black, & gray)

And it is possible to preview the wrapper before it goes live? and possibility
of customisable nav bar (to have something like that of
http://www.geocities.com/stolenclover/backstage/mozilla-org/docs/mdp/)?

Comment 15

[fantasai]

> But things have changed somewhat with the new front page (which
> is going to be converted into a wrapper.)

The styles here are as unthemed as it gets. Basic colors, if any.
I want to get the style guide in (bug 44741), and it relies on the existance of
these classes, in some form or another. We can theme it to match the new design
later.

Comment 16

[Gervase Markham [:gerv]]

CCing ben, who is looking after the new front page. Ben: comment 14 might be of
interest.

Gerv

Comment 17

[fantasai]

All right, Gerv. I'm formally requesting a review. For *this* bug. From *you*.
If you're the wrong person, then tell me who to ask. If you're the right person
but won't grant approval, then tell me why.

Comment 18

[Ben Goodger (use ben at mozilla dot org for email)]

Doesn't look like there's any impact here on the front page. Is the orange left
bar to be used as part of the site-wide wrapper, or is its use here in the left
menu a one-off?

Comment 19

[Daniel Wang]

oh, you were talking about my design (took me a while to figure out what you
were talking about). What I'm suggesting is allowing for custom navigation bar.
The aim is to convert the entire site into a how-to-contribute tutorial (the
current site design is just too confusing for new contributors).

Comment 20

[Gervase Markham [:gerv]]

Asa says:

"I'll gladly check it in if it doesn't break anything. Has someone tested this
to see that there's no adverse affect on all of our most important pages? I'd
like to see a statement from someone that says "I've checked and this doesn't
break/alter any of the top 100 or so pages at mozilla.org." or something like that."

Gerv

Comment 21

[Daniel Wang]

test result w/ Mozilla 1.5 nightly and MSIE 5.0/win98:

pass community.html
pass quality/beginning-duplicate-finding.html
pass quality/bug-writing-guidelines.html
pass quality/
FAIL quality/help/
pass MPL/boilerplate-1.1.html
pass MPL/
pass cvs.html
pass projects/firebird/why/
pass projects/camino/
pass get-involved.html
pass build.html
pass catalog/
pass roadmap.html
pass source.html
pass start/
pass hacking/win32.html

quality/help/ fails on MSIE 5.0

also, no MSIE 5.0, all visited colours are red (purple in Mozilla)

Comment 22

[fantasai]

Attachment: persistent-style.css

Thanks very much for the testing, Daniel. I fixed the visited link color
problem. (It was a mistyped selector.) I tested /quality/help in IE5.5, but
didn't see any problem. Could you attach a screenshot or something?

Gerv -- is there a list of these 100 files somewhere? Or should I just check
through the first two levels of mozilla.org's hierarchy?

Also, I was wondering if I should change .incorrect-example to .wrong-example
--
anyone have a preference?

Comment 23

[Gervase Markham [:gerv]]

fantasai: I don't think Asa had a literal 100 files in mind. Just checking the
top two levels and key pages would be more than enough, I'm sure.

Gerv

Comment 24

[Daniel Wang]

pass hacking/reviewers.html
pass hacking/mozilla-style-guide.html *
pass hacking/portable-cpp.html
pass hacking/code-review-faq.html 
pass hacking/
pass unix/customizing.html
pass build/distribution.html
pass build/faq.html
pass build/mac.html
pass build/unix.html
pass releases/
pass releases/mozilla1.4/
pass releases/mozilla1.4/known-issues.html
pass releases/mozilla1.4/installation.html **

I checked again, quality/help/ now works in MSIE5.0
That's 29 files of what I think are the important ones

* The stylesheet has <code> on light background. On this page, the style works
well because code stands out in normal text. One slight problem: the page uses a
(custom) heavier gray bg color for code block.

** Color distortion. When you have two class="important" together, the red
border appear to be pink.

Also,
<code> has light gray bg and no-line-break, 
<kbd> has light gray bg
<samp> has no background color.

Pages on mozilla.org don't use <code>, <tt>, <pre>, etc. consistently. will this
be a problem?

Comment 25

[fantasai]

> Pages on mozilla.org don't use <code>, <tt>, <pre>, etc. consistently. will this
> be a problem?

It's already a problem. :) We're trying to create a solution.
<tt> is discouraged.

Having <code>, <kbd>, etc. look different will (I hope) encourage authors to use
them more consistently because the differences will become more evident. And
right now, the pages are coded with custom styles, so it all looks haphazard anyway.

Comment 26

[fantasai]

note: Need to redo this to fit with the redesign.

Comment 27

[Daniel Wang]

yesterday my sis asked me what me-tsu-say means. I said I have no idea. Then she
spelled "m i s u s e" ... ;-D

Anyway, can we have .alt1 and .alt2 classes, to make reading of some words
easier, e.g. <alt1>multi</alt1>media, <alt1>mis</alt1>use ? Of course that
doesn't help with "kon-science", except maybe con<alt1>si</alt1>ence?

Comment 28

[fantasai]

Still need to make it pretty, but it's officially /done/.