Decide if and how to map style `command` parameter to CSS

[hernot]

While for style and color parameter a rather straight forward mapping between ConTeXt and CSS for html/xml/xhtml seems to be handled by merging pull-request #38 and the further improvements applied before next release. On the other hand the mapping between command parameter is still neither solved nor decided yet.

I went through the list of possible CSS attributes which could be used as shortcut for handling content of command parameter. In general to map command onto HTML and/or XHTML/XML using CSS there are two general possibilities:

A) the command implements tagging either using \dostarttagging \dostoptagging or \startelement \stopelement properly and provides its own CSS snipped.

• The advantage is that no further action is necessary exempt ensuring that tag(s) inserted by command either are properly enclosed within <syntaxgroup> or properly decorate it.
• The disadvantage is that each <div> tag resembles an individual box with a content area, a boarder and a margin. In worst each <div> adds in addition to the desired decoration additional space between its boundary and the inner content thereby changing layout of document unexpectedly.
  • solution to this disadvantage could be to enclose command within an additional set of <div> tag which predefines reasonable values for margin boarder distances etc assuming that <div> tags added by command inherit everything from their parent exempt the decoration and style they add explicitly. In some cases the extra set of tags might not even be required as the corresponding settings could be introduced by <syntaxgroup> directly.
  • Second disadvantage in case command does not emit tags than corresponding style is lost on html and xml/xhtml output or must be added manually to styles which is possible in default and name mode but not auto.

B) do not rely upon implementation of command and establish a mapping between ConTeXt styling commands / styles and CSS style attributes.

• The advantage is no dependency upon implementation and CSS styling of <div> tags corresponding to command if any and the styling of <syntaxgroup> tags.
• The disadvantage is requires strategy to map between command and CSS attribute or attributes if to be split onto multiple.
• The second disadvantage is that mapping can grow quite complex task given the large number of possibilities to change all or only parts.

I have too little know-how upon ConTeXt inner workings and design guidelines related to XML/HTML export especially to be able to judge that or even express some helpful preference. I'm not sure if it would be helpful in decision between the two options above but i have compiled a list of CSS attributes which commands could be mapped to if mapping should be an option at all. As you will see the majority of CSS attributes does not add additional options but just limits style to some substyle or subitem of a more general style eg. boarder defines all four sides of the border whereas boarder-left limits the whole just to the left line of the boarder frame.

I have split the list into several sections. The first contains the attributes which i would consider reasonable within the context of vimtyping. The second contains attributes where i have the impression or the maybe false idea that these are handled anyway by ConTeXt implicitly or differently. It also contains those where I know that they are set by vimtyping to values which ensure proper display. The third section contains basically stuff where i have no idea if they would be relevant at all for vimtyping and also do not feel having enough knowledge to judge about. And the last section contains attributes where when playing around with CSS had the impression that they behave at least in Firefox and chrome differently when displaying html output or xml/xhtml output.

Feel free to ignore the list, or edit it in case mapping could be at least for some very common style commands be an option to make output in html and xml/xhtml appear as expected from corresponding pdf output.

context-css-mapable-attr.md.txt (content is in markdown even though ending states txt) Currently this files is just resorted version of CSS reference table of contents plus some extra notes where i was not sure what could be meant, no details yet what values would be available. In case mapping is an option how ever it will be implemented i will include the possible values for those attributes which are considered for mapping between command parameter and CSS style. In case you would need some more details for deciding let me know than i will amend the relevant parts.

[adityam]

The value of command key can be any ConTeXt command. So implementing mapping command to CSS is basically equivalent to implementing a mechanism of configuring CSS using ConTeXt. I am not going to attempt that.

I like the idea of automatically generating the CSS file, but in the absence of mapping the command key, effectively all it is doing is mapping the colors, which is relatively easy to do by hand.

So, I have implemented a mechanism with a default CSS file (currently only for pscolor colorscheme and only for display style). See the export-2 branch. I have also added documentation for both t-filter and t-vim, which suggests to the user to tweak the default CSS file to get the desired output.

[hernot]

The value of command key can be any ConTeXt command. So implementing mapping command to CSS is basically equivalent to implementing a mechanism of configuring CSS using ConTeXt. I am not going to attempt that.

I already feared that command is any ConTeXt command. And yes I'm with you mapping is in this case no option. As a consequence the only option which remains is that commands are carefully written and proprely use tagging and provide their own CSS.

I like the idea of automatically generating the CSS file, but in the absence of mapping the command key, effectively all it is doing is mapping the colors, which is relatively easy to do by hand.

So, I have implemented a mechanism with a default CSS file (currently only for pscolor colorscheme and only for display style). See the export-2 branch. I have also added documentation for both t-filter and t-vim, which suggests to the user to tweak the default CSS file to get the desired output.

Not sure if you have already commited anywhere or is just in your local working copy. Nevertheless may i suggest that you include the hint about enclosing within \startelement \stopelement and enabling \setupexport[properties=yes] or \setupexport[properties=mycodeprefix] to obtain a better controll about styling of command as in this case it would not be necessary to exactly know which tag/detail pair vimtyping uses and styling like underline, overline would be independent of colorsheme used just dependent upon command. This all just in case documentation of command does not explicitly state that it uses export tagging anyway and thus provides direct hint how corresponding tags could be styled using *template.css or alike.

Just for the sake of completeness.

Not sure if it is really necessary to check how inheritance from parent element works and if margin, boarder etc width are set by default upon <div> tags. At least i would also put some note telling uses that they might set these values explicitly to a reasonable value to get expected output. Not sure whether explicitly predefining values at vimtyping side would make sense at all or in worst would lead to strange layout. Therefore i would leave tuning to users only.

[adityam]

The value of command key can be any ConTeXt command. So implementing mapping command to CSS is basically equivalent to implementing a mechanism of configuring CSS using ConTeXt. I am not going to attempt that.

I already feared that command is any ConTeXt command. And yes I'm with you mapping is in this case no option. As a consequence the only option which remains is that commands are carefully written and proprely use tagging and provide their own CSS.

Or, simply write the CSS for each syntaxgroup element.

Not sure if you have already commited anywhere or is just in your local working copy.

It is in the export-2 branch on the github repo.

[adityam]

I added CSS (and documentation) for the inline style, and also added CSS for the blackandwhite color scheme.

[adityam]

Features merged to dev: 20544c1875106c8da0ceec07f14a507ea8c78be5

I'll test a bit, and then upload a new release.