Bob Balaban's Blog

     
    alt

    Bob Balaban

     

    What if.....we didn’t use <font> tags in our HTML output anymore?

    Bob Balaban  May 17 2007 10:05:41 AM
    Greetings, Geeks!

    I am very pleased to introduce the first "guest blog" on my site. Please welcome my fellow IBM employee and fellow Geek, Mr. Mark Vincenzes!
    Mark is a long-time developer at IBM and a long-time member of the Web Server team. He is a particular expert on how we convert rich text in NSF data to HTML.

    Take it away, Mark!

    Hi all,
    In July 2006 I posted a note to the notes/domino forum concerning ideas on eliminating the use of the &lt;font&gt; tag in html generated by the domino web engine.    I presented several "alternative" HTML renderings and asked for comments.  I got some good feedback and continued to think about the problem.  It occurred to me that by adding a number of options I didn't have to pick one of the alternatives ahead of time, but leave it to the application developer do configure the html output the way she/he wants.
    The result design is described in the attachment below.  

    I did this work and a prototype implementation a while ago, but was negligent in posting a follow-up article.  Now with Bob Balaban's new blog it seems a good time to present this and get your feedback.    The drawback I see to it, and one of the reasons I was holding off posting it, is that there are a LOT of options (about 40) and it could be a bit daunting to figure out how to use them all.   I know some folks have asked for lots of control, but such control does come at a price.  I tried to name the options so that they would be easy group, and there is one "controlling option" (FontConversion)  that when you turn it on will enable the default set of other options, so if you are happy with the default set you only have one option.

    Note that these font options are part of the new $$HTMLOptions that we introduced in v8 for controlling html output..  You provide a text list of name=value pairs via a special $$HTMLOptions field on your form.
    There is a way to provide a server level set of options using a notes.ini, and a field level override by supplying $$HTMLOptions_fieldname for a specific field.  We are also looking at also providing web site and database level options.

    There is a lot in the write-up, but I'd like your comments.  Ways to consolidate options to make fewer options?  Different set of defaults?   Something I've forgotten?

    Thank you

    writeup2.html


    -mark vincenzes
    Comments

    1Fredrik Stöckel  05/17/2007 4:45:15 PM  What if.....we didn’t use <font> tags in our HTML output anymore?

    This looks like a very configurable and flexible solution. Will this solution allow the user to change to a/their preferred font-size? (The font-size setting in the browser).

    Most designers seem to use %/em as font-size units these days.

    2Jim Knight  05/17/2007 5:02:00 PM  What if.....we didn’t use <font> tags in our HTML output anymore?

    For converting rich text, I think it will be very hard to remove them without a convoluted solution. However, I would like these features on the form side.

    For example, I would love to have an option strip all <br>'s and <font>'s when publishing a form to the web and use my stylesheet to manage. Also, I wish the tables would spit out something more simple than what Domino does by default.

    Also, I was wondering if there is currently a way to publish as xhtml doctype and still use Notes fields without hardcoding the html? I saw at lotusphere that you can do a server wide doctype change now and there will be a setting in 8 for that but will that let you create a form in domino with fields and do an 'editdocument' or 'openform' after setting form to show as html without the error "Documents treated as HTML cannot be edited". Otherwise, I end up just using Domino as a placeholder and it makes things complicated for my clients to add new fields later to a form.

    Thanks for asking this question. I am a hardcore Domino web builder (check out acdivoca.org as an example) and I love to use as much core Domino functionality as possible (it makes it easier for clients to read my code for one thing).

    3Mark Vincenzes  05/17/2007 5:13:54 PM  What if.....we didn’t use <font> tags in our HTML output anymore?

    @1 Yes.

    The default for FontSizeMapping is 1 and FontSizeDefault, 10.

    This means that we would generate % sizes based on 10 point being 100%. Note that in notes rich text, all the text has a point size associated with it. Usually the default size is 10.

    So with the settings of the options as above, font size of 10 in rich text would be converted to html with NO extra style information. Font size of 20 would be 200% size in the style. So the default settings will work for the scenario you ask about.

    4Ian Morrison  05/17/2007 5:22:38 PM  What if.....we didn’t use <font> tags in our HTML output anymore?

    Wow! I've read this through a couple of times now, been for a cold shower and a lie down, then returned. I have to admit that I don't fully grasp all the details of what is being proposed, but I have enough of the gist of it to post. I think I'll come back later one the comment floodgates have opened!

    I agree with @2 that a convoluted solution like this is (probably) required, but at least there are a set of default options that you can override as required. It may also be nice to have a set of "ready reckoners", which would give you useful combinations of settings that many people would use.

    One question though: what is the performance impact on the server for using this? With all those options to process it seems fairly hefty. Then again, used wisely, these new options could drastically reduce the amount of HTML generated, along with providing huge flexibility for the savvy developer.

    5Tim Tripcony  05/17/2007 5:58:46 PM  What if.....we didn’t use <font> tags in our HTML output anymore?

    Hm.

    When a rich text item containing numerous paragraph styles is exported to DXL, the result is a bunch of pardef tags (paragraph definitions) sprinkled throughout the item, each with attributes like leftmargin, tabs, id, etc.; the remaining item content then includes par tags (paragraphs) with a def attribute. The value of a par's def maps to the id of a pardef. While this is bewildering to look at until you get used to it, a similar model might be useful in HTML rendering.

    In addition to one option you outlined (a default Domino stylesheet for spans that developers can leverage but override if desired), how's about having an inline auto-generated style tag that uses classes to apply paragraph styles to paragraph tags? That way each paragraph retains some measure of fidelity from how it's rendered in the client, and then spans can be used within paragraphs to apply properties like font-weight.

    Just a knee-jerk idea... have to ponder this some more...

    6Mark Vincenzes  05/17/2007 7:17:07 PM  What if.....we didn’t use <font> tags in our HTML output anymore?

    @5 yes, we do have something like you suggest in mind. I would plan to do a series of options for paragraphs to provide classes and stylesheets.

    7Martijn de Jong  05/18/2007 2:59:48 AM  What if.....we didn’t use &lt;font&gt; tags in our HTML output anymore?

    This would be absolutely great! One of the good things in this proposal, if I understand it correctly, is that I have a way as a developer to override any font settings people put in their Rich Text documents for our website, so we can finally have one universal style for the website.

    One other important thing in the Rich Text to HTML conversion btw should be that it outputs 100% correct HTML. The other day I had to work around a problem where the HTML output of some rich text suddenly contained a completely unexpected <lu> tag, which at the end wasn't closed, where if a list was the last line in the rich text field, that list also wasn't closed off (Domino 6.5.5). Those kind of things can be disastrous for a sites layout.

    8Mark Vincenzes  05/18/2007 5:42:38 AM  What if.....we didn’t use &lt;font&gt; tags in our HTML output anymore?

    @7 yes the intent is to give you a way of overriding font settings that people put in their documents.

    The goal is 100% correct HTML, the font tag changes are one step along the way.

    In the specific problem you mention, is there a way you can send the example rich text? Is there pass thru HTML Involved?

    The web server uses <ul> to do indentation so if the rich text were indented in some way, maybe that is what you are seeing. But still, the <ul> should have been closed.

    9Nathan T. Freeman  05/18/2007 7:37:44 AM  What if.....we didn’t use &lt;font&gt; tags in our HTML output anymore?

    I have really mixed feelings about this. On the one hand, I find Mark's spec absolutely thrilling in terms of the flexibility it can provide. We Domino developers have waited SO long to get this kind of granular control out of the box, and here's a feature set that seems to finally grant us some serious controls.

    On the other hand, the actual coding technique is... well, pretty Byzantine. We need a huge list of cross-referenced controls and examples to tell us what various 0, 1 and 2 parameters do. There are 30 different parameters here which can be applied at a server-level, a form-level or a field-level -- but all applied with a very confusing set of codes that in the end equation, require us to ALSO define detailed CSS to get the desired results.

    At it's core, this is a feature set who's goal is to turn off parts of the older Domino feature set. Ponder that.

    Then ponder that it took a year to get to a prototype implementation. One that handles overrides for font controls, and NOTHING ELSE. What if I need controls for table generation? For collapsible sections? For field styling? For view columns? What if I simply want to use <DIV> tags instead of <SPAN> tags -- because I'm retentive about saving two characters per text run?

    I don't mean to come across as unappreciative. I am ENORMOUSLY grateful for Mark's work here, and honestly -- since I'm sure there's a millennium of testing that's going to be involved in getting it into the product -- would love to see it included in an undocumented fashion into Domino 8 before Beta 3 goes out. I am absolutely salivating to get these controls NOW NOW NOW.

    I simply fear that if this is the model we're going to follow in the long run for improving Domino's HTTP generation, it's going to be unsustainable. We're constantly going to be waiting for enormous lists of $HTMLOptions controls that ultimately map to elaborate case statements in the underlying cross-platform C code of the HTTP renderer itself.

    There's gotta be a better way to do this. I just don't know what it is yet.

    10Martijn de Jong  05/18/2007 10:00:10 AM  What if.....we didn’t use &lt;font&gt; tags in our HTML output anymore?

    @8 - I could send you an empty db with the form and document. Where can I send it?

    11Brian Miller  05/18/2007 10:00:43 AM  What if.....we didn’t use &lt;font&gt; tags in our HTML output anymore?

    Ultimately, this is exactly what I wanted. I'm willing to be flexible on the how of configuration in order to get the server to generate HTML that I can live with. Extra plusses for making this available on a per-application basis with the $$HTMLOptions field.

    Thank you, Mark!

    12Martijn de Jong  05/18/2007 10:03:45 AM  What if.....we didn’t use &lt;font&gt; tags in our HTML output anymore?

    @8 - Forgot to mention. There's no Pass-Thru HTML involved in this specific case.

    13Mark Vincenzes  05/18/2007 3:34:15 PM  Problem list entry

    send it to me, I guess.

    Email is my name with an underscore separating the

    two, at notesdev dot ibm dot com.

    I am out of the office now and won't get to look

    at it until after 5/22

    14Michael Bourak  05/19/2007 4:42:47 AM  What if.....we didn’t use <font> tags in our HTML output anymore?

    Seems very flexible but I've some questions :

    - what about none rich text elements (the form part, or a domino page...), would they obey the "new rendering", how will we do this in "pages" as they is no fields

    - Would like to see all these kind of control for tables, embeded views etc

    - HTMLOPtions and HTMLOptions_... should be included in designer infoboxes for form/page etc and fields

    - Don't forget the ever increasing requirements about accessibility (this influence the html generated, the ability to swat the css to provide a more accessible one etc...)

    - On the same subject, being able to let domino generate rich text for some fields, or input tag for some fields but mark the whole form as "treat as html" would help a lot (for ex, now, $$SearchTemplate are considered in Edit mode and can not be marked "treated as HTML" which prevents any XHTML accessibility compliance...)

    Thanks for all this work

    PS : I join Nathan here, please give us a way to beta test as soon as you can cause it's already very late for the Domino HTML improvements if they come in 8.5 or 9...so I think we should test and provide feedback asap.

    PS 2 : Are there plan to extend the command cache that was introduced in 4.6.1 (then removed then reintroduced). I think about the $CacheValid and $CacheOptions. Making then work for authenticated request and making them "sensible" to criteria (such as browser, cookie etc...all this forming a "cache key") could really boost domino http performance (a bit like the websphere dynacache behaves)

    15Erik Brooks  05/28/2007 7:36:05 AM  What if.....we didn’t use <font> tags in our HTML output anymore?

    I've been out of the country, but here's my $0.02:

    - Definitely shoot for inclusion of this as a beta version in ND8 if possible.

    - Obviously expansion into tables, etc. will be needed.

    - How will future implementations in pages, views, etc.?

    And lastly: The implementation, while flexible, is very "Byzantine" as previously posted. If this is the future of Domino dev ($$xyz fields all over the place) then us uber-power-geeks will be happy, but the standard Domino dev guy will be overwhelmed.

    Some basic default set of settings that will be the 'new standard' would be good. E.g.:

    Font{X}Style=0, Font{X}Tag=2, Font{X}Class=1

    Implement it as a checkbox on the form in Designer:

    On Web Access: [x] Generate Domino CSS

    ...make it enabled on all new forms, and make Domino generate CSS for each "old-school" Domino class, and *bam* you've got a solution that moves forward gracefully, isn't too bandwidth-heavy, and will let the less-experienced Domino dev turn something into underlined, red, 13pt bold and actually see it happen.

    Overall it's a very flexible approach. It just needs some sort of "one size fits most" implementation to maintain Domino's status as an RAD tool.

    16Mark Vincenzes  05/29/2007 11:44:19 AM  Some comments and answers

    I'v been on vacation a while. Here are some comment. Thanks for all the input.

    @2 these font options will certainly allow you to strip out the font tag..

    The BR tags are used for paragraphs spacing, so stripping them out would loose your paragraphing.

    If I understand your second question, the doctype change capability does not affect the markup generated. The only way to get "HTML" generated is to use the URL argument "outputformat=xhtml10". But as has been pointed out the output of that option is NOT xhtml compliant, it just is "well formed XML" and even that has its problems.

    @4 I don't think these options add a significant performance problem. (But we haven't done any performance testing so I can't rule out some lurking problem -- but there isn't anything about the code that is much different than any other processing that is already going on)

    @9 Nathan, you summed up my misgivings about this. That is one of the reasons I waited so long to post.

    (Most of the dev work for this was done by the beginning of September. But even back then, all of the testing time for v8 was filled up and the font stuff wasn't going to make the cut. So I put it on hold till 8.0.1 and moved on to other things.)

    Yes, there are a lot of options, it is complicated, and this is just ONE thing. You can imagine a similar treatment for tables, paragraphs, lists, etc. The font stuff was easy coding because it is localized in the code. So of the other things (paragraphs in particular) I suspect will be more difficult, so maybe the option set will be fewer.

    Perhaps it makes more sense to think of these options more as an API rather than part of the designer's UI.

    If there were a layer of tooling on top of these options that grouped settings in to functional areas, perhaps had a "live example" that showed what happens to sample text as you twiddle the option. Of course, that would take more time to design and implement.

    Note you don't NEED to do your own stylesheet, only if you want to deviate from the built-in use of the "style" attribute.

    With regard to your last point: "I simply fear ... it's going to be unsustainable. We're constantly going to be waiting for enormous lists of $HTMLOptions controls that ultimately map to elaborate case statements in the underlying cross-platform C code of the HTTP renderer itself."

    I think we are already there. Consider "best fit for OS", vs "applet", "treat contents as...", the <@> property page, all the various "pseudo events" for adding headers and javascript, the DHTML vs "classic" implementations of sections, and so forth. And each user says: "it should be a simple thing -- and all I want is an option to..."

    It is a complex system that has evolved over several different incarnations of doing distributed computing.

    Evolving the existing code is tedious (the web serer is C++ not C), but rewriting has its own set of problems.

    I did consider some alternatives. Generating DXL and then transforming with a XSLT, was one. I did some work with

    Dick Annicchiarico, for Lotusphere 2005 converting DXL to HTML. Some of the stuff was straightforward and easy, but that was just for a simple demo. Transforming notes rich text lists (as they are currently presented in DXL) into HTML lists requires a recursive XSLT. Talk about a performance hits. So we would have to extend DXL to have it be more easily transformed.

    And in my opinion, the changes to DXL to make it easier to transform to HTML would be opposed to those changes that would need to be made to make DXL round trip fidelity better for archiving. Gee, I guess we need an option...

    And then there is the thing that the existing DXL converter does not "run the business logic" the way the web server does.

    @14 The only way right now to set options for elements that don't have fields is to do it at the server level using

    the DominoHTMLOptions notes.ini. We need to extend the html options idea to have it available on pages, databases, etc.

    @15 (and other). Note that the various font options described are NOT each a separate $$xyz field. There is ONE field, $$HTMLOptions, for the form.

    17Nathan T. Freeman  05/29/2007 11:09:20 PM  What if.....we didn’t use <font> tags in our HTML output anymore?

    LOL @16 - Someone's been reading my emails ;-)

    Fair enough point. And I've certainly requested my fair share of "just one more option" controls, too. But I glad you understand where I'm coming from.

    18Mark Vincenzes  05/30/2007 9:44:49 AM  What if.....we didn’t use <font> tags in our HTML output anymore?

    @2 edit mode makes no sense for treat contents as html.

    What is it you expect to happen?

    19Erik Brooks  05/31/2007 10:04:13 AM  What if.....we didn’t use <font> tags in our HTML output anymore?

    @16 Mark - Got it. My misunderstanding -- I didn't finish reading your entire orginal post and instead jumped (in a drooling, maniacal state) straight to the writeup. The server-level INI settings address my main concern, which is a definitive push forward by IBM away from the legacy rendering so that Domino stays RAD.

    I would suggest that whenever this makes it in as a formal Domino feature that you finalize a particular set of options as the "new method" for rendering and put those in the INI for the server on all new installs. The *only* reason to keep the legacy behavior around is just that -- for legacy apps.

    Then power-devs will be able to tweak things further via the INI, form-specific fields, etc., but new installs and new developers for Domino will simply notice that "It Just Works(tm)" as their Designer-set font attributes are actually carried over properly onto the web.

    Bottom line: If somebody installs a brand-new copy of ND9 and builds an app from scratch, Domino should *not* be generating <font> tags at all unless they go back and re-enable the 1995-style of tag generation. Deprecation can be a good thing.

    20chester  05/24/2008 1:09:10 PM  What if.....we didn’t use <font> tags in our HTML output anymore?

    css textboxt input (textfield) style - examples - -

    { Link }

    21Mathias Weisheit  02/15/2011 11:45:42 PM  What if.....we didn’t use <font> tags in our HTML output anymore?

    It's a pity, that IBM uses in his own Blog-Application a LotusScript-Class to Convert the "dirty" Code into clean HTML-Code!

    I think some options for the richtext-field will be better.

    Like "no font sytling" or so. So the user have not the option to set color and size. And the rendering-engine doesn't need to create font tags.

    ....

    ....

    ....

    22Bob Balaban  02/16/2011 3:54:35 AM  What if.....we didn’t use <font> tags in our HTML output anymore?

    @Mathias - I believe that as of v8.5, Designer has a setting that causes the web engine to generate more CSS-friendly HTML