RT CSS Overhaul (ATTENTION W3M AND IE USERS)]

RT Developers
1

[Chris, how does this seem to you?]

I’ve spoken to our web accessibility expert and he has the following
comments:

Gecko: Lose the position: fixed; stuff. It’s still a nightmare to
use. Use position: absolute; instead. (Will also better work in IE)

Make it work at reasonable resolutions - I’m running at 831px wide
and it doesn’t fit.

Get rid of the font sizes set in px - they won’t rescale in IE, and
not particularly well in anything else. Use caution with font sizes
<100% (80% is likely to be unreadable in some situations, 90%
should be okay but not for paragraphs of text)

Opera: The horizontal scrolling doesn’t happen, the stuff that
would generate a horizontal scrollbar just goes off the right of
the screen. (Opera is available for Linux for testing)

IE6/Win: I can’t see the login box. This suggests that the rest of
the stylesheet will be badly messed up too. (After using the
keyboard navigation and a bit of guesswork, managed to log in
anyway. The top half of the layout is in pieces, the main area and
footer is okay but is also about a screen height down the page…

(A single windows box isn’t that expensive for testing and can have
IE 5, 5.5 and 6 co-installed on it. Trying to debug IE CSS layout
via second-hand reports of what looks wrong is near-impossible and
will take weeks.)

IE 5 on the Mac is likely to have similar problems due to position:
fixed.

W3M/Lynx: Page fails to display. Problem caused by <!–[if lt IE
7]> in the , which Lynx, and indeed anything else (other than
IE), will interpret as an unclosed comment. I don’t know why
Gecko/KHTML don’t interpret this as an unclosed comment, probably
a bug in their parsers.

Anything: The close buttons on the various bits of the homepage are
Javascript dependent. Ideally they should do something server-side
to hide those bits, but you should use JS to write the close buttons
out so that non-JS browsers don’t see them.

Andrew Stribblehill
Systems programmer, IT Service

2

Hi,
I took a quick look with Mac OSX/IE5.2

On the default page, 'new ticket in ’ buttons are painted
above the QuickSearch box. This is the case as well with ticket
listings (buttons about between Header and ticket metadata). The
buttons do not scroll with page content.

Regards,
Harald

3

Hi,
I took a quick look with Mac OSX/IE5.2

On the default page, ‘new ticket in ’ buttons are painted
above the QuickSearch box. This is the case as well with ticket
listings (buttons about between Header and ticket metadata). The
buttons do not scroll with page content.

Mac IE has borribly broken CSS support and is unmaintained by the
vendor and isn’t likely to be something that we support.

4

Unfortunately, your accessibility guru’s comments beat a number of CSS
fixes I made for IE.

[Chris, how does this seem to you?]

I’ve spoken to our web accessibility expert and he has the following
comments:

Gecko: Lose the position: fixed; stuff. It’s still a nightmare to
use. Use position: absolute; instead. (Will also better work in IE)

Other users have expressed a very strong preference the other way. (For
IE, I implemented a fallback to absolute positioning.

Make it work at reasonable resolutions - I’m running at 831px wide
and it doesn’t fit.

On what browser and what pages? There’s a known issue with fit on IE at
the moment.

Get rid of the font sizes set in px - they won’t rescale in IE, and
not particularly well in anything else.

nod This update goes a long way to doing that from the previous
version where almost everything was absolutely set.

Use caution with font sizes
<100% (80% is likely to be unreadable in some situations, 90%
should be okay but not for paragraphs of text)

What’s recommended for doing smaller labels?

Opera: The horizontal scrolling doesn’t happen, the stuff that
would generate a horizontal scrollbar just goes off the right of
the screen. (Opera is available for Linux for testing)

IE6/Win: I can’t see the login box. This suggests that the rest of
the stylesheet will be badly messed up too. (After using the
keyboard navigation and a bit of guesswork, managed to log in
anyway. The top half of the layout is in pieces, the main area and
footer is okay but is also about a screen height down the page…

This should all be significantly better now.

(A single windows box isn’t that expensive for testing and can have
IE 5, 5.5 and 6 co-installed on it. Trying to debug IE CSS layout
via second-hand reports of what looks wrong is near-impossible and
will take weeks.)

It was more a matter of “not easily availabe on my laptop while hacking”

IE 5 on the Mac is likely to have similar problems due to position:
fixed.

IE5 on the mac is an ugly, broken hack was officially discontinued by
its vendor several years ago.

W3M/Lynx: Page fails to display. Problem caused by <!–[if lt IE
7]> in the , which Lynx, and indeed anything else (other than
IE), will interpret as an unclosed comment. I don’t know why
Gecko/KHTML don’t interpret this as an unclosed comment, probably
a bug in their parsers.

You caught us in the middle of attempting to fix a number of the IE
issues with /IE7/. That didn’t work and has
been removed.

Anything: The close buttons on the various bits of the homepage are
Javascript dependent. Ideally they should do something server-side
to hide those bits, but you should use JS to write the close buttons
out so that non-JS browsers don’t see them.

nod

5

And after another day of beating my head against the CSS-brick wall, I
don’t think this is going to happen for RT 3.4. It was sort of wishful
thinking that it would, but the state of CSS layout engines is still a
bit too varied and broken to roll out what I’ve got anytime terribly
soon.

I’ve committed the CSS work to
/bps-public/rt/branches/PLATANO-EXPERIMENTAL-CSS, a sub-branch of the
platano (will likely be 3.5 or 4.0) development branch. Patches (and
additional style sheets are welcome)

Jesse

6

But we could get some better CSS class and id properties
in 3.4 along with a stylesheet for printing!On Thu, Oct 07, 2004 at 05:06:24PM -0400, Jesse Vincent wrote:

And after another day of beating my head against the CSS-brick wall, I
don’t think this is going to happen for RT 3.4. It was sort of wishful
thinking that it would, but the state of CSS layout engines is still a
bit too varied and broken to roll out what I’ve got anytime terribly
soon.

I’ve committed the CSS work to
/bps-public/rt/branches/PLATANO-EXPERIMENTAL-CSS, a sub-branch of the
platano (will likely be 3.5 or 4.0) development branch. Patches (and
additional style sheets are welcome)

Jesse

Rt-devel mailing list
Rt-devel@lists.bestpractical.com
The rt-devel Archives

7

Hi Jesse,

I just checked out what’s currently running on rt3.fsck.com as of this
moment, and I really like it. In both w3m and Firefox, I no longer have
to scroll sideways to see the home page or most of Jumbo. (This is w3m
in an 80-column xterm, and Firefox in a 1024x768 window but with tabs
down the side, which cuts it to about 900 wide.)

Of all of the web sites and web-based tools (incuding Bugzilla) that I
commonly use day-to-day, RT is the only one which has this sideways
scrolling problem. This almost turned me off of RT when I first saw it;
only after I dug deeper into features did I decide to switch us from
Bugilla. I’ve already spent a total of around 15 hours messing with the
3.2 stylesheet and templates; still not happy, still don’t use the web
interface except when I absolutely have to. This will be a problem with
other users – I’ve hacked at REST to get it to do what I want; other
people won’t be able to do that. (I’ve fixed some REST date-field bugs
and added an XML full-ticket-and-history dump template; I owe you code.)

Compared to 3.2-RELEASE, what you have up there right now is a much
better layout – the font size mix is much prettier, the lack of
horizontal scrolling is enough to make the difference between me wanting
to use the web interface at all or not. One major way I can see to make
it better would be to get rid of the horizontally stacked boxes; people
are used to vertical scrolling in all browsers; horizontal is just
strange. Another big bang for the buck would be to allow users to set
Jumbo as the default, to reduce number of mouse clicks to make a
single-field change (or is that in there and I just haven’t found it?)

My own vote would be to prioritize ease-of-use on common browsers.
Follow Google’s lead; simple, clean, minimal is the best way to get to
portable. CSS is anything but that. Do the fixes that clean up font
sizes and remove fixed-width elements, release some of this in 3.3, take
it in bite sizes.

Wonderful tool, great customizeability, I’m glad I found RT.

SteveOn Thu, Oct 07, 2004 at 05:06:24PM -0400, Jesse Vincent wrote:

And after another day of beating my head against the CSS-brick wall, I
don’t think this is going to happen for RT 3.4. It was sort of wishful
thinking that it would, but the state of CSS layout engines is still a
bit too varied and broken to roll out what I’ve got anytime terribly
soon.

I’ve committed the CSS work to
/bps-public/rt/branches/PLATANO-EXPERIMENTAL-CSS, a sub-branch of the
platano (will likely be 3.5 or 4.0) development branch. Patches (and
additional style sheets are welcome)

Jesse

Rt-devel mailing list
Rt-devel@lists.bestpractical.com
The rt-devel Archives

Stephen G. Traugott (KG6HDQ)
UNIX/Linux Infrastructure Architect, TerraLuna LLC
stevegt@TerraLuna.Org
http://www.stevegt.com – http://Infrastructures.Org

8

Hi Jesse,

I just checked out what’s currently running on rt3.fsck.com as of this
moment, and I really like it. In both w3m and Firefox, I no longer have
to scroll sideways to see the home page or most of Jumbo. (This is w3m
in an 80-column xterm, and Firefox in a 1024x768 window but with tabs
down the side, which cuts it to about 900 wide.)

So, I think that’s fixable without the extensive hackery in that version
of the app. (I’ll note also that it’s wider than RT 3.2 on some
browsers :confused:

interface except when I absolutely have to. This will be a problem with
other users – I’ve hacked at REST to get it to do what I want; other
people won’t be able to do that. (I’ve fixed some REST date-field bugs
and added an XML full-ticket-and-history dump template; I owe you code.)

I’d like the date fixes as soon as you can manage.

For XML, I’d love to hear what you think of the RT::Atom addon, which
gets you much more comprehensive XML support.

Compared to 3.2-RELEASE, what you have up there right now is a much
better layout – the font size mix is much prettier, the lack of
horizontal scrolling is enough to make the difference between me wanting
to use the web interface at all or not. One major way I can see to make
it better would be to get rid of the horizontally stacked boxes; people
are used to vertical scrolling in all browsers; horizontal is just
strange.

I’m glad you like the new stuff. It’s the direction we’re headed in. But
RT 3.4 is a couple bug fixes away from a beta release and I’m not
prepared to destabilize it as much as a major UI overhaul.

My own vote would be to prioritize ease-of-use on common browsers.

Well, the priority is being functional in just about everything. and
that includes on my phone. After that, pretty and easy on common
browsers. And I can tell you that the current “CSS Preview” is not
pretty on modern IE, which is pretty damn common among RT’s userbase.

Follow Google’s lead; simple, clean, minimal is the best way to get to
portable. CSS is anything but that.

CSS is all about being minimal and portable in your markup.
Tables and inline styling make portability much, much harder.

Best,
Jesse
9

Well, the priority is being functional in just about everything. and
that includes on my phone. After that, pretty and easy on common

Just so you know, the current rt3.fsck.com works on the hiptop phone,
which isn’t a great browser for this sort of format.

A

Andrew Sullivan | ajs@crankycanuck.ca
I remember when computers were frustrating because they did exactly what
you told them to. That actually seems sort of quaint now.
–J.D. Baldwin