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-*)
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.