Closed Bug 222151 Opened 22 years ago Closed 22 years ago

New site needs testers

Categories

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

Product:
www.mozilla.org
Component:
General
Platform:
x86
Windows XP
Type:
defect
Priority:
Not set
Severity:
blocker

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: bart, Assigned: bugs)

Details

Ben will recruit testers for the site, including James Russell <Kovu401@netscape.net>
over to ben. kerz can you help too?
Assignee: endico → bugs
I've pulled but don't see anything on the branch yet.
volenteering byner to help too. branch is MOZILLA_ORG_BRANCH on the website content tree
Yeah, there's no new content on the branch yet. Ben/Chris, can you comment here when there is?
just checked in to the branch.
OK, walking through it, the link from decision one back to us seems to be broken. Reproduce, go to http://support.decisionone.com/mozilla/mozilla_help_main.htm then click the mozilla logo in the upper left corner, it goes to http://support.decisionone.com/mozilla/www.mozilla.org for me, dunno if they just forgot the http:// part or if it's supposed to redirect.
/mozilla-org/output/README-style.html /mozilla-org/output/README-cvs.html Title text bleeds into authors names.
/mozilla-org/output/cvs.html Scroll to Mac Classic instructions, font gets really small in places.
rafael to file bug and track dec1 problems
<kerz> ./press/mozilla1.0.html is pretty small <kerz> same with ./press/open-source-security.html
/tinderbox.html - seems like there is a general problem with nested lists getting smaller and smaller.
Old page, I know, but it shows a problem with TT tags being really small. Search for nsbeta3 to see it. /roadmap/roadmap-25-Sep-2000.html
Need to remove this line from /releases/ at the top. "We make binary versions of Mozilla available for testing purposes only! We provide no end user support."
Need to remove this line from /releases/ at the top. "We make binary versions of Mozilla available for testing purposes only! We provide no end user support."
kerz are the font size problems that your uncovering related to http://bugzilla.mozilla.org/show_bug.cgi?id=222205 ???
Juan.Trevino@DecisionOne.com Issues sent to Juan. He'll fix in the morning. * The mozila icon in left hand corner should point to: http://www.mozilla.org. * TheYour One Source for Technology Support! link is broken * The Technology Support in Your Home! link is broken * In the top nav About Mozilla should link to: http://www.mozilla.org/about.html
chris: could be, if there was a set size, rather than a relative one, they would likely not grow smaller the more nested they are. There seems like there are a few different problems tho, the nested lists growing smaller (cvs.html, tinderbox.html), the <tt> tag causing extremely small text (/roadmap/roadmap-25-Sep-2000.html) and the <pre> tag also causing very small text (/press/mozilla1.0.html, /press/open-source-security.html).
<code> also seems to be causing smaller text. Just about everywhere I've seen fixed-width text it has been smaller than the surrounding text.
Another good example of the nested problem along with the various fixed-width tags problem is /build/release-checklist.html. Lots of tiny fonts on this page.
Adding dave so he can see it.
Updated style sheet has been sent to Dawn Endico for upload that should address fixed-width and list-cascading issues.
The updated stylesheet checkin wiped out a bunch of prior changes to the stylesheet. code, etc., causing smaller text probably would be fixed by bug 222205. Once you use a font size that's not relative to the parent font size (e.g., 'small', which we shouldn't be using), we stop using the hacks we have to balance the size of monospace fonts using a separate pref. I don't see why you want any rule like: li > li, li > li > li { font-size: 120%; } It either suggests that there's just a bug somewhere else in the stylesheet, or it doesn't do anything. I suspect the latter (and that removing the rule that shrank the font size on p, li, dd, and dt fixed this problem completely).
(Either that or you intentionally moved a 'text-decoration' rule that I put where I did for a reason -- in the hopes that we'll stop specifying text-decoration entirely for most links.)
David, simply put, I have no access to the system. I have to modify my local copy and get Dawn to upload. No one has enabled me to do anything differently. I agree that the li > li etc. is unnecessary, my mistake. That should be deleted. My change involved removing 'font-size: 92%' on all li and dd items, which has made it to the live .css file. If you want to remove the li > li bit, feel free. The problem is solved without that. If your changes have been overwritten, I'm sorry. Your comments in bug #222205 and now this one suggesting I have impure and sneaky motives, or that I don't understand the issues, makes me want to stop contributing. Please tone it down. Regarding text-underlining specifically: a lot of discussion has occured, and Bart, Rafael, Dawn and I decided text-decoration would be set to none for all links. I haven't changed anything specifically, and if you are, why?
Sneaky motives? I didn't mean to suggest anything like that. It's just that your walking in and trying to change the standards and accessibility policy of a project that I've been working on for five years, in some cases in ways that I strongly disagree with, make *me* want to stop contributing.
Someone, dawn I guess, checked in changes without running cvs diff, and noticing conflicts or stompage, and merging. While I'm sure everyone's intentions are good, checking in blindly must stop. I propose that dbaron review changes before they get checked in by dawn. /be
Then what we have here is a communication problem, because I never saw any documentation on the accessibility policy of the site. Not your fault, but, well - not mine either. What's the URL?
I'm not talking about a written accessibility policy. I'm talking about being accessible. Though there is http://mozilla.org/README-style.html . Overriding a bunch of user preferences (font size, link underlining) causes problems for some users. While these changes may even be appropriate for the front page, I don't think they're appropriate for the vast majority of the existing content on the site.
Group: Marketing Private
marking fixed
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED
Product: mozilla.org → Websites
Component: www.mozilla.org → General
Product: Websites → www.mozilla.org
You need to log in before you can comment on or make changes to this bug.