Short description
Content features of "special" pages in the underlay should be marked to allow specific styling to be applied using CSS.
Full description
There are a number of features implemented as pages in the underlay that call on specialized macros to perform some work, and then "decoration" of the result is performed by adding normal page content. One example of this is the RecentChanges page: the table of changes is produced using the RecentChanges macro, but the legend that describes the various annotation marks is included as a table in the underlay content.
Some features aren't implemented in the underlay but in the themes; many of these are already marked with classes since styling is being applied, but it would be nice to have an element marked with a class for the main content well for a "normal" page impression (that should also be used for the preview in the editing view). This would make it easier to apply styles only to the content and not the accidentally affect the page-wrap generated by the theme.
Ideally, it would be easy to style such page elements in theme-specific CSS. For tables, this could easily be done using something like <tableclass="moin-recent-changes-legend">, but it should be done as part of the standard underlay, rather than relying on individual sites customizing their pages. This would also allow translations to use the same class or id when the translated content contains the same structure, or to use an alternate class if the table structure needs to be different. The reason for the long class names is to avoid clashing with class names already introduced in particular wikis.
Having the classes or ids set in the underlay allows sites that want to style these sorts of features to update their underlays to take advantage of improved help text or other features that have been added to the underlay pages.
Audience
This feature is only important for sites that want to customize the presentation of content features of the "special" underlay pages.
It is not expected to have a negative impact on other sites, since they are not required to deal with it. (It may prove helpful to decide on a common prefix for such classes or ids, to avoid interfering with classes or ids already introduced by HTML generated on such sites.)
It does have an impact on the translators (hopefully minimal).
Implementation issues
Identifying all such features in the existing pages, including the translations, is likely the most problematic aspect of this feature. The approach of adding a class or id to each feature allows it to be approach incrementally with minimal impact, since existing pages aren't affected until someone makes the change, and existing CSS would need to be changed to affect the page features.
Discussion
It is not clear why you need so specific class like 'moin-recent-changes-legend', maybe more general class like 'legend' is just fine.
I'm not as interested in the specific classes used as I am about having something to hook styling on. I tend to think of the "special" pages as user interface more than normal content, so I often want to apply different styling. It's also legal to use more than one class for an HTML element, so it may be that adding both a general and more specific class is good, and the style writer can decide what they want to do with it. Part of the motivation for long class names is to avoid clashing with class names already introduced in a particular wiki; speaking as someone predominantly using ReStructuredText, I have a number of classes in use already for semantically-identifiable page sections, "enforced" in template pages. I guess I should be applying a prefix for all my local classes as well. --FredDrake
The basic problem here is that except tables, you can't mark page element with CSS class. You can use plugin like SectionParser to do this, but it is limited because you can't nest parsers. The basic feature missing is a way to add attributes to page elements, like you can with rst.
That does make it more difficult to implement. On the other hand, I expect that if SectionParser were available out of the box, that SectionParser and <tableclass="..."> would be sufficient for most interesting features. --FredDrake
See if this feature and patch is sufficient to allow you to do what you want, FeatureRequests/FormatterApiConsistencyForHtmlAttributes -- DeronMeranda 2006-01-12 20:55:54