IBM®
Skip to main content
    Country/region select      Terms of use
 
 
   
     Home      Products      Services & solutions      Support & downloads      My account     

developerWorks  >  Lotus  >  Forums & community  >  Best Practice Makes Perfect

Best Practice Makes Perfect

A collaboration with Domino developers about how to do it and how to get it right in Domino

This is a survey for developers -- please add a comment to respond.

CSS in a Notes client doesn't work exactly like CSS in a browser. Making them exactly the same is a lot of work and unlikely to occur. What I'm wondering is, based on your experience out there in the field, which differences are the most inconvenient for creating applications? Where do you need to add style/class information that you can't do it now?

Likewise for HTML in the Notes client, are there any little changes we could make in how it renders, that would make a big difference for what you are able to accomplish in your forms?

Andre Guirard | 3 May 2007 09:08:00 AM ET | Plymouth, MN, USA | Comments (15)


 Comments

1) Sure
Nathan T. Freeman | 5/3/2007 9:52:30 AM

Domino 8 already generates SPAN & DIV tags for every change in a text run and for every Pardef. Giving us CSS controls associated with those would go a LONG way.

Selecting an arbitrary group of cells in a table and setting HTML controls on all of them at once would help enormously.

Generally, though, I would discourage you from giving us CSS controls, and simply improve the rendering of Notes style controls into CSS automatically. There are a dozen ways to do this already, and some of them are already being done in Domino 8. Frankly, simply letting us access some of that generated CSS that we'll have in 8 will probably keep a lot of developers happy for a while.

2) Need Web Tools in Designer
Roland Reddekop | 5/3/2007 11:02:02 AM

I find I am using external tools quite a bit when doing CSS in Notes (Topstyle). I am constantly editing a CSS file, refreshing it into the NSF, then previewing in my browser. I can do it pretty fast, but there are lots of wasted mouseclicks to do something simple. Assuming Designer gets incorporated into the Eclipse framework eventually, It would be convenient to have some form of CSS editor with an instant view of how your Notes form would be affected in a view. No idea how you do that, but its better than my current trial and error method which feels like I am driving the square peg of Web Development into the round hole of Notes/Domino development.

3) I would like...
Frantisek Kossuth | 5/3/2007 11:04:16 AM

CSS support for:

links/hotspots in forms/RT

views/view columns

action bar/actions

at least attributes for: font, size, color, border

4) HTML Web Tools also
Ron Kats | 5/3/2007 2:29:14 PM

Besides an CSS editor an HTML editor would be nice too.

I've not yet tested it in Notes8, but in R6x converting a table to HTML (by Notes) doesnot work fine. It puts the HTMl code inside the table itself.

Pardon my poor english..

5) Documentation
Rob McDonagh | 5/3/2007 3:10:38 PM

More than support for specific elements in CSS, I'd like to see complete documentation of what is and is not available. The same holds true for HTML and Javascript support in the client. At this point, we don't bother trying to use ANY web techniques in client apps because we can't predict what will or will not work correctly.

Of course, if I knew what doesn't work, I'd immediately start begging and pleading for various items. heh.

The only specific items I know don't work (and wish did) are DHTML visibility switching at the table (row, TD) element level at least. And fieldsets would be very handy. I know I can mimic those things with native Notes constructs, but I don't want to maintain two sets of UI code.

6) Stylesheets id’s for view tables
Karsten Lehmann | 5/3/2007 3:55:19 PM

Don't know if this is better in R8, but in views the surrounding table tag does not have a stylesheet id. So you need some JavaScript/DOM e.g. to expand the table to 100% width of the screen.

An ID would be great - and even better a clean and modern lazy loading JavaScript implementation of views on the web.

7) Simple support for the H1..Hn tags in notes.
Peter Herrmann | 5/3/2007 7:36:57 PM

I would like my Notes users to be able to set the properties on some text such that it is H1, H2 etc. This would be rendered properly when outputted in Notes and HTML. I am aware that you can create a special notes RT style called Heading1 and apply that to the text but that's a kludge and not easy for users.

8) choice to turn off text rendering altogether
Tom Franks | 5/4/2007 8:16:20 AM

I'd love an option to turn off text rendering altogther...perhaps a check box on on the form design properties. If I checked it, ALL i want is the passthru + text, with no attempts by Notes to render it.

Of course this would have to apply to the RT fields as well.

9) I’d rather have CSS classes for Domino generated HTML views
Gerald Mengisen | 5/4/2007 2:07:16 PM

My greatest wish in that department is that Notes views rendered on the web should have classes for the table rows (odd, even), categories, images (twisties), etc. no more font tags, and as Karsten @6 already requested, an ID for the table. Also the table tag should no longer have any attributes except for a class and and ID.

Just this week, I came across hand-coded HTML views at a client's site. Ironically, if they had been regular Notes views, I would have had an easier time to integrate them into portal with Portlet Factory and IIOP. (this was a web only Domino application)

Because the Notes client is so much richer than the web, one ends up writing a web and a Notes version of the application. Therefore, I don't see any benefit from CSS rendering in the Notes client. And since resources are limited, I'm hoping that the view HTML markup gets fixed instead :-)

10) For the notes client: Table styles & Action bars
Michelle O’Rorke | 5/4/2007 5:56:40 PM

Leaving aside the vast improvements needed in CSS support for Domino, in the Notes client itself my biggest need is to be able to globally change the style of action bars (views & forms), as well as table & cell styles: firstly border color & style, but cell color & background image also would be good.\

11) DOM support
Patrick Kwinten | 5/8/2007 2:25:43 AM

I rather have full DOM support in stead of full CSS support. Anyway I believe IE 7 still does not 100% support CSS2 and by the time CSS3 is supportted by most browsers we will be living on Mars.

12) Pieces of all of the above
Erik Brooks | 5/16/2007 3:04:06 PM

Ok, for the record - this blog gives you a very bad time if you forget the subject line. Last night I went to submit a comment and when I hit "submit", the response page said "Refused". Some input validation formula perhaps? Anyway, hitting "back" in the browser returned me to the submission page -- with my comment gone.

By the way Andre, I want to say that this sort of interaction is fantastic. You, Ed, Bob Balaban -- all of you are doing a great thing by running these blogs.

Here's my thoughts on this topic:

I echo Nathan's @1 comments regarding hooks into SPAN and DIVs in ND8 (though my understanding is that 8.0 still ships with <font> tags at the moment). I also echo his comment for focusing more on the rendering of existing Notes-style controls to CSS than giving us more programmatic CSS controls. But if you do want to make prorgammatic life easier, here goes...

MOST INCONVENIENT:

1. Lack of formulaic CSS Properties

If I want to dynamically change the background-color of a tablecell then I've got to create a CFD (Computed For Display) field that is marked as pass-thru HTML, and have it run a formula like ".mySpecialCell {background-color=@If(blah blah)". Cludgy.

1.5 Ditto Nathan's remarks (@1) about selecting and applying multiple CSS attributes to tablecells at once. Let us select multiple tablecells and then have the dialog work just like changing the inhieritance property of a script library.

2. A small change that would go a long way: Making the little boxes on the HTML properties tab double/triple their current height. E.g. the "style" box only accepts about 25 characters right now, and with CSS being as verbose as it is you can chew that up quick. Sometimes I end up copying/pasting a style string into a text editor to change it, then copy/paste it back in.

BONUS: This isn't directly CSS related, but @11 leads into it, and boy, is it inconvenient: Exposing a field to javascript.

To do it now requires computed text or CFD hacks combined with pass-thru HTML. Yes, there's [x] Generate HTML for all fields, but this poses potential security concerns and is ultra-spammy in many cases. What would be huge (and probably not to difficult to add, I'm guessing):

[x] Generate HTML for this field

13) My Two Cents
Bill Hanson | 6/28/2007 12:35:56 PM

Here is what I need:

(1) The ability to set the borders (including color) of a table or cell independently (client).

(2) Support for table and cell height and width (client).

(3) Support for action bars and buttons (client & web).

(4) Support for view properties such as background colors, row height and column width (client & web).

(5) Support for table and cell background images (client).

(6) The ability to apply an attribute to a range of selected cells (please!).

14) Sending HTML Tables
Joseph LeMay | 7/3/2007 11:33:46 AM

I was just trying to send an HTML newsletter, and the tables come out wrong for the recipient. The column widths come out all the same and all the text and images are centered, which is not the way it looked when I looked at the thing locally in IE.

 Add a Comment
Subject:
   
Name:
Comment:  (No HTML - Links will be converted if prefixed http://)
 
Remember Me?     Cancel

Search this blog 

Disclaimer 

    About IBM Privacy Contact