Forum OpenACS Improvement Proposals (TIPs): TIP #8 (Approved): Modification of default-master.adp structure.

Collapse
1: TIP #8 (Approved): Modification of default-master.adp structure.
Posted by Andrei Popov on 08/23/03 06:31 PM 
    TIP: 8
  Title: Modification of default-master.adp structure.
Version: 0.1d
Authors: Andrei Popov (andrei::at::ceesaxp::dot::org)
  State: Draft
   Type: Process
   Vote: 
Created: Saturday, August 23, 2003
-------------------------------------------------------

Abstract

To make OpenACS more standards-compliant it should move away from using tables as a layout engine. The first small step in this direction would be to modify default-master.adp to explicitly state master/slave DIVs.

Rationale

OpenACS-HEAD advertises itself (in default installation, based on content of default-master.adp) as <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">. Anybody attempting to validate even the front page of default installation will immediately discover that resulting document does not validate against the a.m. DOCTYPE.

While making OpenACS as compliant with current Web Standards is beyond the purpose of this TIP, it is suggested that several small changes could lay the foundation to future modifications of the core make it compliant.

One of the problems one faces trying to abolish TABLE-based design in favor of a DIV-based is correct positioning of resulting elements. Mixing DIV'ed and not DIV'ed content within the same page results in a complete mess. However, by wrapping portions of default-master in separate DIVs and assigning a sensible positioning CSS to them eliminates this problem.

Proposed Modifications

default-master.adp should be modified to include thre wrapper DIVs ID'ed as: master-top, slave, master-bottom. Using ID atribute of DIV tag is proposed in order to enforce uniqueness of an element.

In order to ensure correct positioning of resulting DIVs, it is then suggested to embed CSS block within default-master (via LINK), that defines properties of a.m. DIVs.

A sample default-master.adp could, therefore, look thusly:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
       "http://www.w3.org/TR/html4/loose.dtd">
  <html>
    <head>
      <title>@title@</title>
      @header_stuff@
      <style type="text/css">
        #master-top {
        }
        #master-bottom {
          float:left;
        }
        #slave {
        }
      </style>
    </head>
    <body<multiple name=attribute>@attribute.key@="@attribute.value@"</multiple>>

      <div id="master-top">
        <include src="login-status" />
        <if @body_start_include@ not nil>
          <include src="@body_start_include@" />
        </if>
        <h1>@title@</h1>
        @context_bar@
        <hr />
      </div>

      <div id="slave">
        <slave />
      </div>

      <div id="master-bottom">
        <hr />
        <address><a href="mailto:@signatory@">@signatory@</a></address>
        @ds_link@
      </div>
    </body>
  </html>
Collapse
2: Re: TIP #8 (Proposed): Modification of default-master.adp structure. (response to 1)
Posted by Torben Brosten on 08/24/03 12:17 AM
I think the idea of using div tags is sound. However the idea should be carried further.

"Using ID attribute of DIV tag is proposed in order to enforce uniqueness of an element."

Why force uniqueness of use when using the DIV Class attribute allows any reuse of formatting elsewhere on the page?  One goal in publishing is to create an elegant set of publishing styles that are re-usable as much as possible for consistency.

If the requirement of uniqueness is to prevent redefining label definitions when importing css rules from other sites et cetera, perhaps more unique labels should be used. For example, use oacs-master-top, oacs-slave, oacs-master-bottom instead of master-top, slave, master-bottom.

This is also a good time to consider using alternates to master/slave[1] for primary/secondary etc. since changes are being made anyway, and CSS is less engineering and more "soft" technology related, and apt to be discussed openly in the greater environment of humanity where the interpretation of  master/slave may not be as clearly understood by non-engineers. And sensitivity to using alternates can easily help reduce the potential of creating/increasing tension such as when creating opportunities in situtations where oppressed labor has been an issue.

Also, consider reducing the popular, yet inaccurate, visual orientation of pages at the pre-browser interpretation levels (when for example, the page is interpreted sometimes by a voicesynthesizer and vertical orientation is imaginary). Maybe the styles should be called: oacs-primary-first, oacs-secondary, oacs-primary-last to emphasize that not all interpretation is visual.

1. https://openacs.org/forums/message-view?message_id=111883

Collapse
3: Re: TIP #8 (Proposed): Modification of default-master.adp structure. (response to 1)
Posted by Torben Brosten on 08/24/03 02:13 AM
Another reason to use first-last instead of top-bottom references:

In i18n (an OpenACS project goal), when using UTF-8 or greater, some writing directions are top-to-bottom (vertical rendering) as well as right-to-left and left-to-right. With vertical rendering, the semantics top-bottom inaccurately reflect the page positions (left side, right side). Using first-last or begin-end etc. more accurately describe the template "position" and avoids confusion.

comment: My use of "popular" in the previous message is relative to current Western practices. Chinese is currently the most popular language on the planet. The template labeling could become a major issue if a small segment of the population fluent in Chinese start using OpenACS --a scalable solution for large online communities. Let's prepare for it ahead of time, eh? ;)

Collapse
4: Re: TIP #8 (Proposed): Modification of default-master.adp structure. (response to 2)
Posted by Andrei Popov on 08/24/03 11:14 AM

Torben,

Intention here was to create a front-matter/main-matter/end-matter structure for a rendered page, where frontmatter is your heading, navigation bar, logos, etc. This is followed by mainmatter that wraps whatever is slave's content. In the end you have the (surprise) end-matter that holds the footer of the page.

In this case uniqueness needs to be stressed -- there should be only zero or one instance of each portion in a single page, otherwise laying the page out in an arbitrary user agent may become ambiguous (e.g. if you have several front-matters -- which should go first?).

This is intended for the page master -- reusable class descriptors could also be setup to provide "precanned" styles for various other parts of the site, but this is beyond the scope of this TIP. I think it relates more to #5.

Naming of styles in the suggested default-master.adp is, obviously, just that -- a suggestion. If decided they could be anything other than that -- we can call them even __OACS_DEFAULT_MASTER_HEADER_DONT_TOUCH_OR_IT_WILL_BITE__ or whatever else...

Collapse
5: Re: TIP #8 (Proposed): Modification of default-master.adp structure. (response to 3)
Posted by Andrei Popov on 08/24/03 11:26 AM
In i18n (an OpenACS project goal), when using UTF-8 or greater, some writing directions are top-to-bottom (vertical rendering) as well as right-to-left and left-to-right. With vertical rendering, the semantics top-bottom inaccurately reflect the page positions (left side, right side). Using first-last or begin-end etc. more accurately describe the template "position" and avoids confusion.

I may be mistaken, but Japanese and Chinese newspapers are still rendered in a more or less similar to western manner, i.e. they look like:

S O M E   H E A D E R S T U F F
--------------------------------
s i o
t n r
o   d
r t e
i t r
e b .
s
--------------------------------

and not

S | s o
O | t r
M | o d
E | r e
  | i r
H | e .
E | s
A |
D | i
E | n
R |
  | t
S | t
T | b
U |
F |
F |
Collapse
6: Re: TIP #8 (Proposed): Modification of default-master.adp structure. (response to 1)
Posted by Jun Yamog on 08/24/03 06:20 PM
Hi,

I will help a little.  Since I already have a current working template form adp.  In case this tip pushes through, I can give a pure css form template.

Take note that graceful degradation is something I suggest.  So its likely a few tables will still be needed.  So in may case I have to change my template a bit.

Collapse
7: Re: TIP #8 (Proposed): Modification of default-master.adp structure. (response to 6)
Posted by Andrei Popov on 08/24/03 08:59 PM

I also have a DIV'ed ad_form template -- much cleaner than tabled one (although I have not yet de-TABLEd all of th widgets, i.e. all the date stuff would still render as a bunch of cells). Once implemented, it is actually very easy to maintain, and a lot shorter/readable too...

The only problem I (thought I) have is the fact that one can't say: make this form DIV only as wide as form elements require, at least not in case when ad_form -section {} is used.

As for graceful degradation, the page does not get "cluttered", it simply gets unwound, with each DIV getting rendered sequentially. This is at least what happens in lynx. I'll try to resurrect NS4.7 and see what happens there.

Collapse
8: Re: TIP #8 (Proposed): Modification of default-master.adp structure. (response to 1)
Posted by Peter Marklund on 08/25/03 10:43 AM
My experience is that tables are easier to use and make for more predictable behaviour than divs across various browsers. Also, I'm not sure I understand the standards compliance argument as HTML tables validate fine with XHTML 1.1.
Collapse
9: Re: TIP #8 (Proposed): Modification of default-master.adp structure. (response to 8)
Posted by Andrei Popov on 08/25/03 12:23 PM
HTML tables validate fine with XHTML 1.1.

Just try validating and you will see. Besides, as you know, one is supposed to apply proper *structural* mark-ups. Using TABLE to achieve a particular layout for FORM elements is not correct, from standards point.

In fact, even in 4.0 FORM cannot contain a TABLE. You can have a FORM fully inside a TD/TH, but not a TABLE inside a FORM (just try http://validator.w3.org/).

Granted, ther is a certain amount of "unlearning" one needs to go through, but it is not really any more difficult:

http://alistapart.com/stories/practicalcss/

My DIV'ed standard.adp is only 70 lines, while default one is about 100, standard-lars.adp is even larger at 143 lines. While smaller, it is not any more cryptic:

Collapse
10: Re: TIP #8 (Proposed): Modification of default-master.adp structure. (response to 1)
Posted by Jun Yamog on 08/25/03 06:18 PM
Hi Peter,

Andrei is right.  My pure css is also a lot simpler.  Also move logical.  No "if" this then make a "tr" or "td", etc.  Also I think your comment of more predictable may not be that objective.  CSS should be more predictable, since its one of reason why we have CSS.  Needs unlearning, in fact even now I am still on trial and basis with css.  Hehehe.

The form I made,  the errors a summarized above.  And elements with errors are just now highlighted.  This is more logical and seems to be used by others too.  Also comes will nice icons too :)  You might think that that has nothing to do with css.  But it does, because all the layout and even the icons are on .css file only.  That means that I can change the style on the css only.

Its nice and spiffy.  But I think the best benefit is clean html.  Also adp and html code can be done without breaking the tag nesting.  How many times have we seen a if putting out the other pair of a tag.  "if" is a tag too.  So therefore it should logically not break the nesting.

BUT I am not saying we go pure css.  My opinion is to move to that direction and just have older browser degrade their display.  Even to the point of still using some simple table for layout.

Isn't this tip and Don's other tip is almost similar?

Collapse
11: Re: TIP #8 (Proposed): Modification of default-master.adp structure. (response to 1)
Posted by Jade Rubick on 08/25/03 07:29 PM
</ul>

I think this is a really good idea. I've been moving away from using TABLEs for layout. There are tradeoffs, definitely, and I still use tables for many things, but I think this overall the tradeoffs are really worth it.

I agree that we should not name them according to TOP and BOTTOM.

Collapse
12: Re: TIP #8 (Proposed): Modification of default-master.adp structure. (response to 1)
Posted by Lars Pind on 08/26/03 11:33 AM
So this is the TIP forum, meaning there should be a vote.

Should we vote on the TIP as proposed above, or do you want to close this one and create a new TIP with the proposal which should be voted on?

/Lars

Collapse
13: Re: TIP #8 (Proposed): Modification of default-master.adp structure. (response to 12)
Posted by Jade Rubick on 09/08/03 07:47 PM
Andrei, could you suggest a revised proposal, with the changes suggested above?
Collapse
14: Re: TIP #8 (Proposed): Modification of default-master.adp structure. (response to 1)
Posted by Andrei Popov on 09/09/03 03:58 PM
Jade, I'd gladly do, but I don't really see much in terms of proposed changes:

* Master/slave debacle seemed to end up with "there is no point in doing that."  It is always completely beyond the point of this TIP.  If community so chooses to rename the two, the change can be done at any point of time later.

* First/last vs. top/bottom or left/right -- how about master-header/master-footer?  Or should we borrow from LaTeX for front/main/end matter?

* ID vs. CLASS -- as I indicate in this case ID *must* be used, as with CLASS desired result (a distinct separation of navigation section vs. content vs. footer).

* Lastly -- Don's tip on is not exactly the same.  These can be implemented completely separately.  In both cases there is no immediate impact on the rest of the toolkit.
Collapse
15: Re: TIP #8 (Proposed): Modification of default-master.adp structure. (response to 1)
Posted by Jade Rubick on 09/10/03 07:33 PM
Seems good to me? Any comments from the OCT?
Collapse
16: Re: TIP #8 (Proposed): Modification of default-master.adp structure. (response to 15)
Posted by Jeff Davis on 12/04/03 03:07 PM
This has been marked proposed for a while and I think we will do something like this for 5.1 (possibly not exactly this but something similiar) so I will mark it approved and when the actual code goes in on 5.1 will summarize here.
Collapse
17: Re: TIP #8 (Proposed): Modification of default-master.adp structure. (response to 16)
Posted by Andrei Popov on 12/18/03 10:00 AM
Wow, I've lost all hope :)
Collapse
18: Re: TIP #8 (Proposed): Modification of default-master.adp structure. (response to 17)
Posted by Joel Aufrecht on 02/02/04 12:03 PM
I would like to mark this one Resubmit, because:
1) the current master structure has changed, possibly rendering the original proposal obsolete
2) It's not clear to me if the original proposal was modified by all the comments.

Andrei, could you look at the structure in 5.0.0 and re-formulate your proposal as needed?

Collapse
19: Re: TIP #8 (Proposed): Modification of default-master.adp structure. (response to 18)
Posted by Andrei Popov on 02/10/04 10:50 AM
Will do shortly.  Shall I leave the TIP number intact?
Collapse
20: Re: TIP #8 (Proposed): Modification of default-master.adp structure. (response to 19)
Posted by Joel Aufrecht on 02/10/04 11:51 AM
yes please.  See also https://openacs.org/doc/openacs-5-0-0/how-do-I.html for the currently existing docs on the 5.0.0 template defaults.
Collapse
21: Re: TIP #8 (Approved for 5.1): Modification of default-master.adp structure. (response to 1)
Posted by Andrei Popov on 03/16/04 06:30 PM
Joel,

Looking at a recent checkout of HEAD, this does not seem to be very critical anymore.  I might suggest a few non-TIP enhancements to the collection of default/blank/master templates, but otherwise I think this TIP can rest in peace.