Forum OpenACS Q&A: OpenACS home page CRASHES Netscape
Screenshot (Windows NT 4.0, Netscape 4.7)
Additional rant #1: The forum doesn't let me post <img src="http://www.vad1.com/oacs-20021112-crash-netscape-4_7.gif" width=774 height=402> saying it doesn't fit its notion of allowed tags.
Additional rant #2: Screenshot of posting this comment in IE 5.0. Note layout bugs.
Can't you just stop playing with fancy gadgets and concentrate on REAL usability?
width="690" from the forms/standard.adp (which no
doubt will break other things somewhere else).
Vadim, why don't you look at the html and tell me how you
think it should be changed (I would look at acs-templating/resources/forms/standard.adp as a start).
Looking at the page source, I can think that all the problems reside in STYLE="table-layout: fixed" thing. Unfortunately I have zero experience with css and still regard them as a gimmick, so the only suggestion I can offer is to get rid of any style, span, etc. tags.
Yes, I did change it in the live version.
Unfortunately I have zero experience with css and still regard them as a gimmickThat's pretty funny. It's good to know where you come down on this whole web standards thing. It's also a pretty misguided view but I can understand why you might think that if you are still using NN4.7
I think they are a good thing (as do most other people working on OpenACS), and I think we will gradually work our way to the point that most of templates shipped with openacs are stylesheet based.
Netscape 4.7 crashes due to a bug in the renderer.
That said, we did test the home page with Netscape 4.7, so we will have to do some more work to get it working.
We are not ignoring Netscape 4, but it does have quite a few bugs that will never be fixed. Also the people who are working on the site do not have every browser, so we do rely on reports from other users.
Using CSS makes maintaining a site wide style much easier. That is why it is used. Changing the style in one file is more efficient than changing hundreds of files.
Ok, I'd certainly accept that, as with HTML itself, its not a perfect model, but its rare that anything is. They are extremely useful, particularly when building larger sites, and sites where high level of dynamic, growing content are a feature.
They also offer a much simpler way to apply a certain level of automation/logic to the management of page format.
Having well designed and well managed style sheets as part of the core acs is a highly desirable thing. As ever, I'm sure great care and substantive thought will go into any such addition to the toolkit, as is most often the case here, and therefore I'm sure the benefits will be visible and universal.
Although I'd like to add that its not always the case the the 'lowest common denominator' approach is either wise or implicit, as you continually seem to suggest. Some companies, some indiviudals, some communities may genuinely find that the benefits of not appealing to all possible environments is outweighed by the possible negative aspects.
Take NN4.7. Lets face it... it was a *really* fussy and *really* inconsistent browser. Yes, you can do your best to cater for that browser and limit your resources, profitability and functionality if you want, but lets accept that whatever you do there are going to be thousands of sites that look shite in NN.7. Ultimately the user is going to change browser, rather than wait for a re-development of the entire internet.
It is important to cater for *choice* in terms of what your users can use as a browser, but it is not a question of a kind of moral obligation to support every browser under the sun. You provide the range of choice you feel acceptable to satisfy the majority of the community. I for one don't resent having had a 'push' to get off NN4.7 and discover the delights (and teeney footprint) of opera.
We'd be forgiven for having one or two little glitches on NN4.7, but we'd not get much thanks for a poor website on the most common of browsers...
I don't see that as defeatist, or poor design, its merely common sense and simple economics of organic processes
As a community we also decided to support NN4.7 as best we can. The fact that it crashes sometimes when given standard HTML isn't a bug in our site, it's a bug in NN4.7.
I suppose you'd like us to support Postgres 4.2 also?
However, a toolkit is used as a base for building hundreds very different sites and comminities, with different decisions behind each of them. This is what makes a difference. A toolkit must follow a reasonable 'lowest common denominator' approach. And, the home page is the face of the toolkit.
I played a bit with the source of home page. The vertical bars are missing either because Netscape doesn't support background GIFs with transparency or because of the file format (I used Photoshop 5.0 to save transparent GIFs). The bars appear if redone with no-transparency GIFs; this one is trivial to fix.
Now, the other layout issues are more difficult. The columns are made through the use of stylesheets. I have little idea how to debug that. Perhaps since older browsers don't support stylesheets, it's beter to make a table layout for the home page. Should I proceed with that?
With table layout, this bug wouldn't happen. First, the browser will redistribute the column width. When the longest words will be pushing all columns, a horizontal scroll bar will appear.
Seriously, it looks like virtually all big sites (e.g. yahoo, shashdot, amazon, cnn) use tables for multi-column layout, not css. It should be possible to replicate our home page design with tables. Does it make sense if I try this, what do you think?
If the site works for screens 800 pixels wide, I think we're OK.
It's common to have browser window that's not taking the whole screen. IE spawns non-maximized windows by default, and users may occasionally want to tile two windows side-by-side. We may occasionally have a long_non_breakable_word_in_the_columns (for example, a forum topic with some long variable name in it). Pages really should work gracefully at any window width. Finally, what about possible portable devices with small screens, we don't want to support them? It looks like the layout falling apart at smaller widths is an expected behaviour of this css layout, no? It better be fixed either by changing css or by switching to using a table for column layout. I like tables as they seem to be more robust if a bit inflexible from programmer's standpoint. I can try to make it if you think this won't break some overall concept.
Very often non-web-savy people critizise web frontends (they are allowed to do!) and not using any technology that lies around to support them and is called "standard" would be a shame.
Maybe the current discussion is just a natural consequence of the style and layout change / efforts. Also it's ok that Vadim originally notified the community that NN4.7 crashes. But, imho, supporting WebTV, Konqueror, Netscape, Mozilla, IE, Opera, and of course, Lynx (both, the one with and without color and frame support, of course), maybe WML, Users that life in the 640x480 world (256 colors) ... that is really the job of the people deploying the toolkit in a real project.
my 5 cent.
OpenACS team - great job with the new website!
As you are aware, NN4.7 is a great canary (to mix metaphors) for sorting out fault tolerant html and css. Canaries used to be used in mining expeditions to indicate the presence of toxic gases before others are affected. NN4.7 breaks easily with "toxic" code and works fairly well with fault tolerant code, making it a great canary for testing fault tolerance against a growing list of browsers and browsing applications.
To get NN4.7 working, turn off the CSS rendering in the Preferences area. Yes, the pure html work isn't quite settled either, but NN4.7 should not crash.
An html/css fix was already submitted before the revisions went live. Priorities to fixing and documenting existing code took priority over fixing the html/css --the site functions on a developing environment afterall.