Version Filters in HTML5 Output (persisting display instead of toggling)

In the previous post, the sample included a JavaScript which toggled the display attribute of elements between none and block depending on the value of a select element and the MadCap conditions applied to the elements.

But what if the display attribute wasn’t set to block in the first place? This second sample project includes a variation of the previous script which uses a custom data-* attribute to persist the original value of the display elements toggled. Instead of toggling between block and none, the original display attribute value is stored in a custom data* attribute and applied to the display element when the element is made visible again.

Section in W3C Working Draft: Embedding custom non-visible data with the data-* attributes

Why is this better? Not all elements start with a value of block for the display attribute and the default is inline anyhow. As an example, many menus implemented with CSS use a display value of inline to place the menus next to each other instead of underneath the previous. If you don’t care about that sort of thing, the original sample is sufficient. In other words if your granularity for tagging content by version doesn’t extend to elements which use display values of inline or something other than block, you can just toggle between block and none as the values for the display attribute.

Why is this controversial? The controversy surrounds the separation of markup and presentation. It also surrounds the idea of semantic misrepresentation. And the specification at one point indicated as much. Here are some links about that:

HTML Doctor: HTML5 Custom Data Attributes (data-*)

danwebb.net: Put that data-* attribute away, son…You might hurt someone

These are all valid concerns. Add to that, there is another way to indicate visibility. But given the situation of acting on markup in a help system after it has been built, isn’t this worth it? It definitely works. You can have filtering before publishing and in the output itself.

But it wouldn’t hurt to run the filtered content through a screen reader to see how the custom attribute and the filtering technique influences accessibility. My instinct is that it wouldn’t have a negative impact. But that is a subject for another post. This is an ongoing exploration.

sample project (version filter) 2

4 comments

  1. Thanks for this Thomas – very handy stuff to know about.
    Can you tell me which version Flare started using the “data-mc*” tags? I have only just noticed it in Flare 9 (thanks to your posts) and was wondering if it was also available in v8?

    1. The data-mc-conditions has been used in Flare HTML5 output since at least the last update of Flare 8. I checked an output built with the last update to version 8 and found the attribute. My guess is that it has been that way since it was introduced. I never noticed that condition tags conveyed to the output this way either until I looked into how to create a filter such as in the blog post.

  2. I’m trying to use this great feature to create a drop-down selector that displays different programming language examples (C#, Perl, Ruby, etc.) based on which language is selected. It works great as long as I use the Default conditional text file, but if I try to use a conditional text file named “API”, it doesn’t work. In the js file, how do I specify data-mc-conditions to point to my API conditional text file? data-mc-conditions=”API” didn’t work, so I’m at a loss.

Leave a comment

Your email address will not be published.

HTML tags are not allowed.

253,514 Spambots Blocked by Simple Comments