I am finding the "toggles" very useful. (Terrible name, great feature)
I would like to add css to format the line-cell table that is generated, but not having much luck. The basic idea is to apply common styling (i.e., background color, cell padding etc.) to every toggle-generated table in a (customized) skin. I see the instructions for customizing the "a" tag, but can't seem to apply the same scheme to the table element. Some hints would be helpful.
Toggles - table formatting
Moderators: Alexander Halser, Tim Green
-
Tim Green
- Site Admin
- Posts: 23189
- Joined: Mon Jun 24, 2002 9:11 am
- Location: Bruehl, Germany
- Contact:
Re: Toggles - table formatting
Hi Phil,
There are two easier ways to do this, which you can also combine: First, define a table style for the tables you use for your toggles in Write > Styles > Edit Styles and choose that when you create a toggle. Second, save dummy copies of the toggles you want to use as snippets, complete with all the formatting, custom icons, table styles etc you want to use. Then you can just insert a snippet in Copy/Paste mode instead of building the toggle from scratch every time.
Basically you just do this: 1) Build the dummy toggle in the editor with a little dummy text in the header and table. 2) Select the entire toggle. 3) Select File > Save Snippet in Project > Manage Topics and save the snippet with a descriptive name in your project folder. 4) To insert a new toggle select the Snippet tool in Write > Insert Object and select From File and Copy/Paste to insert the snippet.
There are two easier ways to do this, which you can also combine: First, define a table style for the tables you use for your toggles in Write > Styles > Edit Styles and choose that when you create a toggle. Second, save dummy copies of the toggles you want to use as snippets, complete with all the formatting, custom icons, table styles etc you want to use. Then you can just insert a snippet in Copy/Paste mode instead of building the toggle from scratch every time.
Basically you just do this: 1) Build the dummy toggle in the editor with a little dummy text in the header and table. 2) Select the entire toggle. 3) Select File > Save Snippet in Project > Manage Topics and save the snippet with a descriptive name in your project folder. 4) To insert a new toggle select the Snippet tool in Write > Insert Object and select From File and Copy/Paste to insert the snippet.
Regards,
Tim (EC Software Documentation & User Support)
Private support:
Please do not email or PM me with private support requests -- post to the forum directly.
Tim (EC Software Documentation & User Support)
Private support:
Please do not email or PM me with private support requests -- post to the forum directly.
Re: Toggles - table formatting
Hi Tim,
td.some_tag {my formatting}
Compared to this, tagging each individual table somehow doesn't seem "easier".
(Like all programmers, I am basically a lazy person. We like to have computers do as much of the work as possible. I am a CSS fanatic.
)
Thanks for the tip with the snippet idea. However, in my particular case, I am reformatting existing text with toggles, by selecting headings, then cutting and pasting the headed text into the generated table.
It is unclear what you mean by "easier". Easier than what? I already realized I could manually tag each dropdown table individually with a table style. That is one step further down in the CSS cascade than I wanted to apply the style. My intention was to apply a default style to every dropdown table in the project. using CSS in the form of:Tim Green wrote:Hi Phil,
There are two easier ways to do this, which you can also combine: First, define a table style for the tables you use for your toggles in Write > Styles > Edit Styles and choose that when you create a toggle. Second, save dummy copies of the toggles you want to use as snippets, complete with all the formatting, custom icons, table styles etc you want to use. Then you can just insert a snippet in Copy/Paste mode instead of building the toggle from scratch every time.
Basically you just do this: 1) Build the dummy toggle in the editor with a little dummy text in the header and table. 2) Select the entire toggle. 3) Select File > Save Snippet in Project > Manage Topics and save the snippet with a descriptive name in your project folder. 4) To insert a new toggle select the Snippet tool in Write > Insert Object and select From File and Copy/Paste to insert the snippet.
td.some_tag {my formatting}
Compared to this, tagging each individual table somehow doesn't seem "easier".
(Like all programmers, I am basically a lazy person. We like to have computers do as much of the work as possible. I am a CSS fanatic.
)Thanks for the tip with the snippet idea. However, in my particular case, I am reformatting existing text with toggles, by selecting headings, then cutting and pasting the headed text into the generated table.
Re: Toggles - table formatting
From reading the generated xml, I realize the problem is that the dropdown table is not part of the "toggle" element. It is just a generic table that follows the toggle element. Strange. Intuitively, the dropdown is part and parcel of the toggle. The "hidden" part.
Would love to have that table be inside a sub-element of the toggle element (seems only logical) and have the ability to style the sub-element generically using CSS.
Would love to have that table be inside a sub-element of the toggle element (seems only logical) and have the ability to style the sub-element generically using CSS.
Re: Toggles - table formatting
Some random thoughts relevant to this topic: (Sorry if some of this was discussed years ago WRT HM5, I never used it)
It is suggested several places in the manual that experts can drop in custom html, css and js for better control. Although I think I am relatively comfortable in all these realms, it is clear as mud how to make effective use of this, because I am having trouble finding where various parts of the predefined html, css, and js reside. The problem isn't a lack of understand html, css and js, it is a lack of understanding what is done where in HM6.
Specifically, I am unable to figure out where/how various things are implemented/stored/interact, e.g..:
Although I do know where skins are stored, likewise the default page template, and how to edit them, and it appears the skins replace default project elements, it isn't clear, for instance, whether named topic templates in my project are overridden.
There are references to .js and .css files in the templates that do not exist on my computer and hence are essentially black boxes. It is suggested I could replace or extend the HM6-provided javascript. But, it is difficult to override and extend a totally opaque black box.
I find references in the manual to a "generated css file" that is supposedly "output" with the default name of "default.css". A customizing dialog allows me to change the name of this, but I am at a loss to understand why I would want or need to. No such file exists anywhere on my computer, so I assume that is also a black box. Without at least read-only access to the existing css stylesheet, how is one supposed to know how to write custom overriding css?
Toggles are an example of a feature that seems to have no handles at all to grasp hold of. It does not appear to be possible to customize (via template) the source html that implements a toggle. It appears that the html for it is generated in toto via a blackbox javascript function.
Likewise, because of the relatively primitive nature of what can be specified in H&M styles vis-a-vis the power of css, it would certainly be nice to understand the scope/limitations of css usage within HM6. Just as one example it does not appear to be possible to define style classes in css, and apply them within HM6 (without manually typing css class names into the XML) It isn't as clear whether it is impossible to write css that effectively overrides and/or extends styles defined in the HM6 style-editing dialog. (If one could peek at the existing css to see the the existing class definitions.)
It is suggested several places in the manual that experts can drop in custom html, css and js for better control. Although I think I am relatively comfortable in all these realms, it is clear as mud how to make effective use of this, because I am having trouble finding where various parts of the predefined html, css, and js reside. The problem isn't a lack of understand html, css and js, it is a lack of understanding what is done where in HM6.
Specifically, I am unable to figure out where/how various things are implemented/stored/interact, e.g..:
- skins
- templates
- styles
- css
- javascript
Although I do know where skins are stored, likewise the default page template, and how to edit them, and it appears the skins replace default project elements, it isn't clear, for instance, whether named topic templates in my project are overridden.
There are references to .js and .css files in the templates that do not exist on my computer and hence are essentially black boxes. It is suggested I could replace or extend the HM6-provided javascript. But, it is difficult to override and extend a totally opaque black box.
I find references in the manual to a "generated css file" that is supposedly "output" with the default name of "default.css". A customizing dialog allows me to change the name of this, but I am at a loss to understand why I would want or need to. No such file exists anywhere on my computer, so I assume that is also a black box. Without at least read-only access to the existing css stylesheet, how is one supposed to know how to write custom overriding css?
Toggles are an example of a feature that seems to have no handles at all to grasp hold of. It does not appear to be possible to customize (via template) the source html that implements a toggle. It appears that the html for it is generated in toto via a blackbox javascript function.
Likewise, because of the relatively primitive nature of what can be specified in H&M styles vis-a-vis the power of css, it would certainly be nice to understand the scope/limitations of css usage within HM6. Just as one example it does not appear to be possible to define style classes in css, and apply them within HM6 (without manually typing css class names into the XML) It isn't as clear whether it is impossible to write css that effectively overrides and/or extends styles defined in the HM6 style-editing dialog. (If one could peek at the existing css to see the the existing class definitions.)
-
Tim Green
- Site Admin
- Posts: 23189
- Joined: Mon Jun 24, 2002 9:11 am
- Location: Bruehl, Germany
- Contact:
Re: Toggles - table formatting
Hi Phil,
Hold your horses there pardner, you're trying to run before you can walk.
The information is pretty much all there if you read the chapters on templates in the More Advanced Procedures and you can also get anything you are missing here. There will be gaps, but then you just need to ask. The difficulty here is that it is quite a complex subject that doesn't become entirely clear until you have grasped the basic concepts and the fundamental structure of how Help & Manual works and handles its output and its templates and skins.
Skins:
A skin is basically a normal Help & Manual project without topics and with a more limited number of Configuration sections in the Project Explorer. It is created by saving a project as a skin with Save As. You can then choose what you want it to contain. This can include HTML templates, user-defined variables, baggage files (more on that below), user-defined build options and your text and table styles. When you save the skin you decide which of these elements are to be included. You can also edit the skin later like any other project, because it is really a Help & Manual project.
The most fundamental principle of skins is that everything they contain has absolute priority over the project. The principle is that in the publication chain, the last element chosen wins. So when you apply a skin, all the elements it contains are used instead of the matching elements in your project. If it contains HTML templates it replaces the matching templates in your project. For WebHelp this means that it always replaces all three navigation pane templates and the navigation section settings. It will also always replace the "Default" HTML page template. However, if you have defined additional HTML page templates in your project and the skin does not contain templates with matching names, then those templates will be passed through to the final output. Similarly, any variables in the skin with names that match those in your project will overwrite the variables in your project. Any variables in your project that are NOT duplicated in the skin will "survive" and will be used. The same applies to Baggage files: If the skin contains a Baggage file with the same name as one in your project, the skin version will win. If your project contains a unique Baggage file it will be passed through.
Additional files:
These are generally stored in the Baggage Files section of the project and/or the skin, which you can access in the Project Files section in the Project Explorer. Any files you add here will automatically be exported with your project, so you can add your own JavaScript and PHP files, CSS files, graphics logos etc. referenced in your templates here. You can then reference these files in your code without any path information, you can depend on them being available. You can also edit text-based files directly in the Baggage, there is an integrated code editor with syntax highlighting.
Styles and CSS:
CSS is not used directly in the Help & Manual editor because it's a multi-output tool and not all output formats are HTML-based. The ratio between non-HTML and HTML output formats is moving in HTML's favor, so this may change in the future, but at the moment it is still necessary to cater for both CSS-based and non CSS-based outputs. WinHelp didn't use CSS, but it no longer exists, so now it is only PDF and RTF for which CSS is irrelevant. PDF is the most important there and is essential. RTF/DOC is really pretty useless as a documentation format but lots of people still want it so we have to support it. Because of this, and also because most users are most comfortable with this, HM defines text, paragraph and table styles in the same way as a word processor.
When you publish your project to an HTML-based format a CSS stylesheet based these styles is generated and referenced in your pages. Theoretically you can add your own CSS stylesheets redefining and extending the same styles. You just need to add your CSS file to the Baggage and reference it in your HTML page template after the standard stylesheet generated and referenced by HM. In practice, that would defeat the purpose of using a tool like HM except in isolated special cases. If you really want 100% CSS control over every little detail of your page content you should probably be using a web editor to create your help and not a help authoring tool. This goes for the content of your actual topic pages, where the HTML is generated by Help & Manual when you publish your project. Where you have more control is over the HTML template pages into which that content is inserted.
HTML Templates:
These are the actual HTML pages used in your HTML-based layout, and they are fully editable. The content of the pages is inserted into the empty templates when you publish your project. In the case of your topic pages, for example, the <%TOPIC_TEXT%> variable inserts the rendered HTML from your topics, everything above and below that comes from the template file, with additional variables providing other components. A new copy of the template is generated for every topic page, of course. Similarly, variables in the Table of Contents, Keyword Index and Search templates insert the actual content from your project into the template to create the final HTML file, and other variables provide other components. External JS and CSS files from the Baggage can be referenced with includes. Similarly, the main index.html file that creates the layout of the WebHelp page with the panes that display the navigation pages, topic pages, header etc. is also a template with additional components inserted by variables.
Here you have full control with your own CSS and JavaScript and also server-side scripts if you want. You can design and lay out the template pages in pretty much any way you want, using all the scripting and CSS skills at your disposal.
All the scripts are in helpman_topicinit.js and helpman_navigation.js that are exported when you publish your output. If you want, you can completely replace these script files by putting your own versions in your Baggage. Then they will overwrite HM's versions when you publish (Baggage files are always written LAST so that you can do this). Or you can just redefine or extend the functions you want to change, in your own scripts referenced after Help & Manual's script references in the templates, making use of the toggle links generated by Help & Manual, which you can analyze in the output files. There is a topic for experts in the help that explains how to make use and change of the automatic CSS and script references.
The same applies to any other functions performed by Help & Manual's scripting. If you want to rewrite, it we have designed the output so that you can.
Hold your horses there pardner, you're trying to run before you can walk.
The information is pretty much all there if you read the chapters on templates in the More Advanced Procedures and you can also get anything you are missing here. There will be gaps, but then you just need to ask. The difficulty here is that it is quite a complex subject that doesn't become entirely clear until you have grasped the basic concepts and the fundamental structure of how Help & Manual works and handles its output and its templates and skins.Skins:
A skin is basically a normal Help & Manual project without topics and with a more limited number of Configuration sections in the Project Explorer. It is created by saving a project as a skin with Save As. You can then choose what you want it to contain. This can include HTML templates, user-defined variables, baggage files (more on that below), user-defined build options and your text and table styles. When you save the skin you decide which of these elements are to be included. You can also edit the skin later like any other project, because it is really a Help & Manual project.
The most fundamental principle of skins is that everything they contain has absolute priority over the project. The principle is that in the publication chain, the last element chosen wins. So when you apply a skin, all the elements it contains are used instead of the matching elements in your project. If it contains HTML templates it replaces the matching templates in your project. For WebHelp this means that it always replaces all three navigation pane templates and the navigation section settings. It will also always replace the "Default" HTML page template. However, if you have defined additional HTML page templates in your project and the skin does not contain templates with matching names, then those templates will be passed through to the final output. Similarly, any variables in the skin with names that match those in your project will overwrite the variables in your project. Any variables in your project that are NOT duplicated in the skin will "survive" and will be used. The same applies to Baggage files: If the skin contains a Baggage file with the same name as one in your project, the skin version will win. If your project contains a unique Baggage file it will be passed through.
Additional files:
These are generally stored in the Baggage Files section of the project and/or the skin, which you can access in the Project Files section in the Project Explorer. Any files you add here will automatically be exported with your project, so you can add your own JavaScript and PHP files, CSS files, graphics logos etc. referenced in your templates here. You can then reference these files in your code without any path information, you can depend on them being available. You can also edit text-based files directly in the Baggage, there is an integrated code editor with syntax highlighting.
Styles and CSS:
CSS is not used directly in the Help & Manual editor because it's a multi-output tool and not all output formats are HTML-based. The ratio between non-HTML and HTML output formats is moving in HTML's favor, so this may change in the future, but at the moment it is still necessary to cater for both CSS-based and non CSS-based outputs. WinHelp didn't use CSS, but it no longer exists, so now it is only PDF and RTF for which CSS is irrelevant. PDF is the most important there and is essential. RTF/DOC is really pretty useless as a documentation format but lots of people still want it so we have to support it. Because of this, and also because most users are most comfortable with this, HM defines text, paragraph and table styles in the same way as a word processor.
When you publish your project to an HTML-based format a CSS stylesheet based these styles is generated and referenced in your pages. Theoretically you can add your own CSS stylesheets redefining and extending the same styles. You just need to add your CSS file to the Baggage and reference it in your HTML page template after the standard stylesheet generated and referenced by HM. In practice, that would defeat the purpose of using a tool like HM except in isolated special cases. If you really want 100% CSS control over every little detail of your page content you should probably be using a web editor to create your help and not a help authoring tool. This goes for the content of your actual topic pages, where the HTML is generated by Help & Manual when you publish your project. Where you have more control is over the HTML template pages into which that content is inserted.
HTML Templates:
These are the actual HTML pages used in your HTML-based layout, and they are fully editable. The content of the pages is inserted into the empty templates when you publish your project. In the case of your topic pages, for example, the <%TOPIC_TEXT%> variable inserts the rendered HTML from your topics, everything above and below that comes from the template file, with additional variables providing other components. A new copy of the template is generated for every topic page, of course. Similarly, variables in the Table of Contents, Keyword Index and Search templates insert the actual content from your project into the template to create the final HTML file, and other variables provide other components. External JS and CSS files from the Baggage can be referenced with includes. Similarly, the main index.html file that creates the layout of the WebHelp page with the panes that display the navigation pages, topic pages, header etc. is also a template with additional components inserted by variables.
Here you have full control with your own CSS and JavaScript and also server-side scripts if you want. You can design and lay out the template pages in pretty much any way you want, using all the scripting and CSS skills at your disposal.
That's correct and it's by design. It's supposed to be a function that works that you don't need to touch, and for the great majority of users that's fine and the way they want to have it. However, because of the way Help & Manual's output is built, there's nothing to prevent you from completely rewriting the toggle scripts and doing something completely different if you want to and have the coding abilities.Toggles are an example of a feature that seems to have no handles at all to grasp hold of. It does not appear to be possible to customize (via template) the source html that implements a toggle. It appears that the html for it is generated in toto via a blackbox javascript function.
All the scripts are in helpman_topicinit.js and helpman_navigation.js that are exported when you publish your output. If you want, you can completely replace these script files by putting your own versions in your Baggage. Then they will overwrite HM's versions when you publish (Baggage files are always written LAST so that you can do this). Or you can just redefine or extend the functions you want to change, in your own scripts referenced after Help & Manual's script references in the templates, making use of the toggle links generated by Help & Manual, which you can analyze in the output files. There is a topic for experts in the help that explains how to make use and change of the automatic CSS and script references.
The same applies to any other functions performed by Help & Manual's scripting. If you want to rewrite, it we have designed the output so that you can.
Regards,
Tim (EC Software Documentation & User Support)
Private support:
Please do not email or PM me with private support requests -- post to the forum directly.
Tim (EC Software Documentation & User Support)
Private support:
Please do not email or PM me with private support requests -- post to the forum directly.
Re: Toggles - table formatting
Hi Tim,
Excellent response that explains a lot that I wrote I didn't understand. I am still missing some pieces.
You state:
To give you some context:
The project is in hmxp format.
The project is published exclusively to html help output. (.chm)
H&M 6 is installed on partition C of Win7 Ultimate x64.
The project folder is under an H&M-dedicated root folder on partition Q of the same drive.
When published to chm, the htm topic files are exported to the Topics subfolder of the folder where the .hmxp project file resides. However, the "exported" css and js files do not exist anywhere on either the C or Q partitions of my hard drive, before or after publishing. I know this because I have used FileLocator Pro to search these entire partitions.
AFAIK, H&M has no way to know of the existence of any other drive letters, so I have not searched for the files on any other drive letters. (which include other partitions on the same and another drive, removable drives, and network shares)
Excellent response that explains a lot that I wrote I didn't understand. I am still missing some pieces.
You state:
That pretty much describes how I want to use it. I really don't want to spend a lot of time with css. I only want to be able to use it when necessary to achieve a particular effect I can't get with normal styling.When you publish your project to an HTML-based format a CSS stylesheet based these styles is generated and referenced in your pages. Theoretically you can add your own CSS stylesheets redefining and extending the same styles. You just need to add your CSS file to the Baggage and reference it in your HTML page template after the standard stylesheet generated and referenced by HM. In practice, that would defeat the purpose of using a tool like HM except in isolated special cases.
I have read this in the manual. The manual also states all styles are exported to "default.css". It appears what I need is a definition of the word "exported".All the scripts are in helpman_topicinit.js and helpman_navigation.js that are exported when you publish your output.
To give you some context:
The project is in hmxp format.
The project is published exclusively to html help output. (.chm)
H&M 6 is installed on partition C of Win7 Ultimate x64.
The project folder is under an H&M-dedicated root folder on partition Q of the same drive.
When published to chm, the htm topic files are exported to the Topics subfolder of the folder where the .hmxp project file resides. However, the "exported" css and js files do not exist anywhere on either the C or Q partitions of my hard drive, before or after publishing. I know this because I have used FileLocator Pro to search these entire partitions.
AFAIK, H&M has no way to know of the existence of any other drive letters, so I have not searched for the files on any other drive letters. (which include other partitions on the same and another drive, removable drives, and network shares)
Re: Toggles - table formatting
I forgot to add, in my context description:
The project uses the "Integrated IFrames with Header - Blue" skin. (slightly modified)
The project uses the "Integrated IFrames with Header - Blue" skin. (slightly modified)
-
Malcolm Jacobson
- Posts: 289
- Joined: Wed Oct 18, 2006 3:17 am
- Location: Brisbane, Australia
- Contact:
Re: Toggles - table formatting
Hi Phil,
Cheers,
Malcolm.
The files are exported, but the reason they don't appear when you search for them is that they're part of the compressed output format you've chosen - CHM. When you publish to CHM, Help and Manual packs all of these files into the single CHM file. If you have 7zip (or a similar zip/unzip tool) on your machine, you can open the CHM and see all of the packaged files, including the css and javascript.Phil C wrote:When published to chm, the htm topic files are exported to the Topics subfolder of the folder where the .hmxp project file resides. However, the "exported" css and js files do not exist anywhere on either the C or Q partitions of my hard drive, before or after publishing. I know this because I have used FileLocator Pro to search these entire partitions.
Cheers,
Malcolm.
-
Tim Green
- Site Admin
- Posts: 23189
- Joined: Mon Jun 24, 2002 9:11 am
- Location: Bruehl, Germany
- Contact:
Re: Toggles - table formatting
Hi Phil,
In addition to Malcom's comments, you can access and view all the source files generated if you turn off the "Delete temporary files" checkbox on the Publish page. You will then find a standard CHM source project in a folder called /~tmpchm in your project folder. You can then edit all the components manually and you can also edit the project settings and compile the CM manually directly with Microsoft HTML Help Workshop, the free Microsoft compiler package you installed to be able to create CHMs. This package also includes an extensive help file that minutely documents all the features and the API of the CHM format. HTML Help Workshop can also decompile CHMs to source.
If you want to add your own CSS to modify the styles generated by HM it's a good idea to study the generated CSS stylesheet first to get an understanding of how the styles are named and used. The paragraph and text attributes are split up into two classes, and the text attributes are applied with <span> tags.
You can change the name of the generated stylesheet if you want in Publishing Options > WebHelp > HTML Export Options. There you can also specify whether styles are to be exported with human-readable names or shorter computer-generated codes.
In addition to Malcom's comments, you can access and view all the source files generated if you turn off the "Delete temporary files" checkbox on the Publish page. You will then find a standard CHM source project in a folder called /~tmpchm in your project folder. You can then edit all the components manually and you can also edit the project settings and compile the CM manually directly with Microsoft HTML Help Workshop, the free Microsoft compiler package you installed to be able to create CHMs. This package also includes an extensive help file that minutely documents all the features and the API of the CHM format. HTML Help Workshop can also decompile CHMs to source.
If you want to add your own CSS to modify the styles generated by HM it's a good idea to study the generated CSS stylesheet first to get an understanding of how the styles are named and used. The paragraph and text attributes are split up into two classes, and the text attributes are applied with <span> tags.
You can change the name of the generated stylesheet if you want in Publishing Options > WebHelp > HTML Export Options. There you can also specify whether styles are to be exported with human-readable names or shorter computer-generated codes.
Regards,
Tim (EC Software Documentation & User Support)
Private support:
Please do not email or PM me with private support requests -- post to the forum directly.
Tim (EC Software Documentation & User Support)
Private support:
Please do not email or PM me with private support requests -- post to the forum directly.
Re: Toggles - table formatting
Hi Tim,
However, equally importantly, now that I can see the generated html, I can understand (sigh) why my css trial and error tests are yielding such weird results. The toggles are designed to be a near-perfect catch-22 WRT css. There seems to be no way to prevent H&M from generating "style=" into toggles. Which anyone with familiarity with css knows, is anathema to css. That part was a total stunner to me. I just naturally assumed the styling was in the css. Silly me.
It appears as if my best bet now is to eschew "toggles" altogether, and substitute css-styled lists for that. I will play around with that and see what I can come up with. I have several years of familiarity with styling lists with css. Dropdowns and inline flyouts are among the least difficult things to do with lists using css.
The key is, based on some quick experimentation it appears that I can assign H&M styles to lists and list elements, and the resulting html will be free of the css-killing "style=" attributes your programmers are so fond of, leaving me free to actually put the css to work.
Precisely the piece of information I have been missing, Tim. Thank you very much for that tidbit.Tim Green wrote:Hi Phil,
In addition to Malcom's comments, you can access and view all the source files generated if you turn off the "Delete temporary files" checkbox on the Publish page. You will then find a standard CHM source project in a folder called /~tmpchm in your project folder.
Yes, I know. That is precisely the reason I was interested in seeing the default css. For numerous reasons.If you want to add your own CSS to modify the styles generated by HM it's a good idea to study the generated CSS stylesheet first to get an understanding of how the styles are named and used. The paragraph and text attributes are split up into...
However, equally importantly, now that I can see the generated html, I can understand (sigh) why my css trial and error tests are yielding such weird results. The toggles are designed to be a near-perfect catch-22 WRT css. There seems to be no way to prevent H&M from generating "style=" into toggles. Which anyone with familiarity with css knows, is anathema to css. That part was a total stunner to me. I just naturally assumed the styling was in the css. Silly me.
It appears as if my best bet now is to eschew "toggles" altogether, and substitute css-styled lists for that. I will play around with that and see what I can come up with. I have several years of familiarity with styling lists with css. Dropdowns and inline flyouts are among the least difficult things to do with lists using css.
The key is, based on some quick experimentation it appears that I can assign H&M styles to lists and list elements, and the resulting html will be free of the css-killing "style=" attributes your programmers are so fond of, leaving me free to actually put the css to work.
Re: Toggles - table formatting
One final (I guess) question on this topic:
I know it says in the help, with respect to to the XSL and XSD, DO NOT EDIT but...
...If I were to simply define a new XML element (with a name unique enough to not conflict with any existing ones), and define how to translate the element to html, what sort of risks would I be running? I realize monkeying with the existing elements would almost certainly entail confusing the javascript logic, but surely it would ignore elements it doesn't manipulate?
What I have in mind is an element that generates a ul tag with nothing but id and class attributes. "list" throws in a lot of unwanted baggage. (I would of course, have to implement instances of the element using a snippet of xml.)
I know it says in the help, with respect to to the XSL and XSD, DO NOT EDIT but...
...If I were to simply define a new XML element (with a name unique enough to not conflict with any existing ones), and define how to translate the element to html, what sort of risks would I be running? I realize monkeying with the existing elements would almost certainly entail confusing the javascript logic, but surely it would ignore elements it doesn't manipulate?
What I have in mind is an element that generates a ul tag with nothing but id and class attributes. "list" throws in a lot of unwanted baggage. (I would of course, have to implement instances of the element using a snippet of xml.)
-
Tim Green
- Site Admin
- Posts: 23189
- Joined: Mon Jun 24, 2002 9:11 am
- Location: Bruehl, Germany
- Contact:
Re: Toggles - table formatting
Hi Phil,
On the table styling: This is one of the elements where inline CSS is still used in the output, even when user-defined table styles are used in the project. I'm not quite sure on the reasons for it at the moment, it may just be a legacy thing.
It would make more sense to use the HTML code object tool in Write > Insert Object to insert inline code that would be exported to your HTML-based output as-is. You could then post-process the output in any way you like. However, the more things like this you do the more you defeat the purpose of using a help authoring tool in the first place...
On the table styling: This is one of the elements where inline CSS is still used in the output, even when user-defined table styles are used in the project. I'm not quite sure on the reasons for it at the moment, it may just be a legacy thing.
Defining it could be possible but how do you want to "define" how to translate it to HTML? To do that you would have to write your own XML parser and do all the conversion of your project to XML yourself, because you have no way to hook into HM's publishing process and it would not output your XML as HTML....If I were to simply define a new XML element (with a name unique enough to not conflict with any existing ones), and define how to translate the element to html, what sort of risks would I be running?
It would make more sense to use the HTML code object tool in Write > Insert Object to insert inline code that would be exported to your HTML-based output as-is. You could then post-process the output in any way you like. However, the more things like this you do the more you defeat the purpose of using a help authoring tool in the first place...
Regards,
Tim (EC Software Documentation & User Support)
Private support:
Please do not email or PM me with private support requests -- post to the forum directly.
Tim (EC Software Documentation & User Support)
Private support:
Please do not email or PM me with private support requests -- post to the forum directly.
-
Martin Wynne
- Posts: 2656
- Joined: Mon May 12, 2003 3:21 pm
- Location: West of the Severn, UK
Re: Toggles - table formatting
Not forgetting that you can use #MERGE to pull in external HTML files. If you use the HTML to include an <iframe>, you can put anything you like in your topics, including an entire external web site. If you prefer to work in XML you can insert all this stuff as CDATA blocks. What's more, because the ZoomIndexer works on the output, not the source, everything gets indexed and included in the Search function (except iframe).Tim Green wrote:It would make more sense to use the HTML code object tool in Write > Insert Object to insert inline code that would be exported to your HTML-based output as-is. You could then post-process the output in any way you like. However, the more things like this you do the more you defeat the purpose of using a help authoring tool in the first place...
Most of my topics are created this way. I have entire topics inserted as HTML code, and programmatically-generated topic XML files containing vast chunks of CDATA. I have a replacement for index.html in my Baggage files and additional css and js files. It all works fine.
But it definitely doesn't defeat the object of using H&M. I don't know of any other software which can do all that, and create a keyword index and synchronised expanding TOC at the same time. It may not be "professional help authoring" but it takes H&M back to its roots as a handyman tool for software developers.
regards,
Martin.
Re: Toggles - table formatting
Never mind.
I finally solved the css issue.
You see, my css "expertise" was lacking an !important piece.
Somewhere, sometime, several years ago, I learned about the css !important attribute modifier. Which I promptly dismissed from my mind, because 99.99% of the time it isn't needed when working with properly designed html and css. But, you see, my html experience has all previously been formatting my own (web-based) html, which I design for strict css styling.
But, the html generated by the H&M xml translator is altogether a different animal. Because the H&M translator inserts style="" styling into tags all over the place, instead of putting the styling attributes in the default css file where it properly belongs. It belongs in the default css, of course, because styling in the default css is easily overridden by custom css. Putting it instead into style="" attributes nicely (or rather, not so nicely) defeats the very purpose of inserting the class="classname" attributes. Because styling in html tags is at the top of the css cascade.
Or, so I had thought. Thus my various gyrations over how to overcome the translator with different schemes.
After spending some time this morning reviewing the css documentation on the css cascade priority, I rediscovered my new friend !important.
It is my new friend because, you see, putting !important on an attribute in the css file will override the same attribute in the html if it has the same specificity. A fact I failed to fully grasp and appreciate in my css upbringing. Using !important, my css can now override those pesky style= attributes all over the html, and can now do anything I want it to do.
My custom css looks a little clumsy, with all those !important modifiers. But, never mind that, because the important thing is, it works!
I finally solved the css issue.
You see, my css "expertise" was lacking an !important piece.
Somewhere, sometime, several years ago, I learned about the css !important attribute modifier. Which I promptly dismissed from my mind, because 99.99% of the time it isn't needed when working with properly designed html and css. But, you see, my html experience has all previously been formatting my own (web-based) html, which I design for strict css styling.
But, the html generated by the H&M xml translator is altogether a different animal. Because the H&M translator inserts style="" styling into tags all over the place, instead of putting the styling attributes in the default css file where it properly belongs. It belongs in the default css, of course, because styling in the default css is easily overridden by custom css. Putting it instead into style="" attributes nicely (or rather, not so nicely) defeats the very purpose of inserting the class="classname" attributes. Because styling in html tags is at the top of the css cascade.
Or, so I had thought. Thus my various gyrations over how to overcome the translator with different schemes.
After spending some time this morning reviewing the css documentation on the css cascade priority, I rediscovered my new friend !important.
It is my new friend because, you see, putting !important on an attribute in the css file will override the same attribute in the html if it has the same specificity. A fact I failed to fully grasp and appreciate in my css upbringing. Using !important, my css can now override those pesky style= attributes all over the html, and can now do anything I want it to do.
My custom css looks a little clumsy, with all those !important modifiers. But, never mind that, because the important thing is, it works!