I found an old post on this subject, but seeing as that was with 7.6.8, and I'm using 7.7.03, I was hoping there is now a better answer for adding cell padding in an AHTML report.

I can't believe it would really be made so that the only option is to have the columns mashed together with no space in between, and no way to add padding either through the report painter or custom stylesheets.

A logical solution would be to add padding in CSS, but apparently

TYPE=DATA, CLASS='mydataclass',

doesn't actually apply the class, and there's no way select all the data cells since it's not given a class automatically (I've tried using an attribute selector, but unfortunately since the page loads in Quirks Mode, it won't recognize the rule (in IE8, which unfortunately most of my users are on)

Can anyone help? I'm at the end of my rope!

This message has been edited. Last edited by: Kerry,

As you had a workaround for the previous problem of the "ugly arrows", why not just extend that?

I added the following to the td[id^="I0r"] section and the padding was OK (ish?).

padding-left: 10px !important;
padding-right: 10px !important;

As I mentioned in your other post, IE8 (for me) doesn't load in quirks mode. All I am running for this test is -

SET CSSURL = '/approot/focalpoint/ahtml_style.css'
TABLE FILE IBISAMP/CAR
  SUM RCOST
      DCOST
   BY COUNTRY
   BY CAR
   BY MODEL
ON TABLE SET PAGE NOLEAD
ON TABLE SET HTMLCSS ON
ON TABLE PCHOLD FORMAT AHTML
ON TABLE SET STYLE *
TYPE=TITLE, CLASS='columntitle', $
ENDSTYLE
END
-RUN

The CSS that I have is basically what you posted earlier.

T

Just worth mentioning(?), but as the output of AHTML is not per the "normal" WF output, HTMLCSS setting is unlikely to come into play.

Normally, HTMLCSS=ON will cause the inline styling to be removed to a <style> section whereas HTMLCSS=OFF (default setting) gives the inline styling that many may hate.

Also, as AHTML is so different (necessarily so) the normal effect that a css class will have when specified as TYPE=DATA, CLASS=somecssstyle, $ will be nullified owing to the JS that is executed in building the active content. As this includes styling you can see why the !important attribute becomes so .... well, important to ensure that subsequent styling does not trump the initial styling that you set within the WF code.

I hope this helps you understand a little more but I am guessing that you are well versed in HTML and CSS anyway and have probably already pulled the AHTML output "to bits".

T

Okay, thanks very much for testing that. I'm really wondering now it is about my reports that are triggering Quirks mode since I'm running the same OS, WF, and browser as you. This may be the point at which I open up a case with IBI.