PmWiki | PITS / 01173

Summary: Add a configuration to disable/replace rendering of style attribute

Created: 2010-02-26 09:07

Status: Open

Category: CoreCandidate

From: Jan Bernitt ?

Assigned:

Priority: 5

Version: 2.2.0+

OS:

Description:

Abstract

I would like to have the possibility to disable/replace/format any style attributes rendered.

Example of the effect

A simple example:

(:div style='color:red':)
Some text
(:divend:)

Some text

Through that configuration it should be rendered like:

<div class="colorred">
Some text
</div>

instead of

<div style="color:red">
Some text
</div>

Some Thought About The Implementation

First every solution I can think of has to recognize the style attribute in every markup syntax belongs to the core markup used in the markup PM-Wiki is shipped with. So I guess it is indeed a core feature to detect it and call a hook to handle processing. The default processing will be the implementation like it is currently. The style is simply forwarded into the generated markup output.

I can imagine some different ways to solve this providing different level of customization abilities:

A simple configuration flag is used to turn of rendering of any style attribute in general, they are replaced with nothing
A fix conversion algorithm converts style into class like in the example above.
A configurable algorithm can be set to do conversion on your own providing a function like: String convert(String styleAttribute);

I have no idea how complicated it is to add such a hook to the core. But I think it might be quite easy for someone who knows the core in detail. At least though the possibility to configure this behaviour it will not break old wikis ;)

Moved request from InitialSetupTasks-Talk

I add the following to this talk page because every time I setup a new PM-Wiki same things popup into my brain and hurts it. Don't get me wrong: I love PM-Wiki otherwise I would use another wiki. In most cases its pretty easy to use ...but It there are some issus make me go crazy:

Why all this explicit styling by rendering markup with style attributes instead of style classes ?

There is a lot of this bullshit which can't be customised by simply add some custom CSS. Best example are trails and those "boxes"... Please remove all those complicated "in markup style support" and replace it with one single plain and really easy to understand but powerful feature: Set right style class or id for the markup which will be rendered. The rest is pure CSS in a CSS file which can be overridden!!

The are only 2 reasons I can imagine where direct one-time styling is useful and reasonable

Styling the text-color of a single phrase, word, or letter which might have a very special meaning which is nonrecurring so a class would be better option
Styling the background and text-color of a tables cells (again.. only for nonrecurring meanings -- context of a page)

Jan Bernitt ?

Moved request from WikiStyles-Talk

Why use direct style= anywhere

To make it PITA to customise PM-Wiki by simply editing CSS files ? Please!! no more solutions with generated style= attributes. Thanks! Jan Bernitt ?

Hello. PmWiki allows styling both with style= and with class= attributes. I see that this is really bothering you (reading your comments here and on other talk pages: sorry about that), so if I may suggest, don't use style= which you dislike. You can define and re-define all styles. Set in config.php $EnableStdWikiStyles = 0; and see CustomWikiStyles to learn how to define your own styles. As for changing PmWiki, you can add your feature requests to PITS -- if we find a way to implement it without breaking existent wikis which may rely on the current feature set, it is possible that we add it. --Petko February 22, 2010, at 05:28 AM

Thanks for your replay. Indeed I dislike any use of the style attribute. Adding $EnableStdWikiStyles = 0; would not remove the mess of style definitions generated by %define (like the one for the authors box and maybe more). I can't and I don't like to make a guess about that. But I can see that there are still lots of style= attributes in the generated markup even if I pull that trigger in my local config... so.. please: stop that. Add a nice support for define CSS Classes directly through markup syntax (for example in Headers). I don't mind. But avoid any style attributes because you cant override em by redefining that definition like you can easily for classes in external CSS files as you mentioned. I am able to use those wiki-styles but I think its the wrong concept so I'm not willing to increase this mess. I try to clean it up, divide layout from content. The question below having such a style in a (:div:) is a good example. If you allow it someone will use it - FAIL! Adding somthing like that to PITS is useless. I added several requests more than a year ago - nothing happens excepting a boost of priority - Don't get me wrong but I'm searching for a solution not for a research. And of cause you can never remove the support for the style attribute without breaking old wikis design. Jan Bernitt ? February 25, 2010, at 01:48 PM

Adding change requests to PITS is not useless, it is a way to see if what you want is popular among other users from the PmWiki community. (1) PmWiki's philosophy is to avoid creeping featuritis. When more than a year later nobody else wants those features, then probably they should be implemented as cookbook recipes (please do!), and not in the PmWiki core. If the core needs some switch or hook to allow a cookbook recipe, we'll add it. (2) Another rule we follow is that wikis do not break between upgrades. WikiStyles is what it is now, people use it and need it, so unless we find a way to automatically fix all broken wikis, indeed the chances are small that we do what you ask for in the core. Again, if you write a proof-of-concept Cookbook recipe, you can prove us that the change can be painless. (3) Your requests may be interesting, insightful and useful, but the developers may simply not know how to implement them. Again, proof of concept and running code could be a good starting point for a discussion. (4) The PmWiki developers are giving away many hours of their personal time to the project, instead of making money or staying with their families. They can work on the features they want to. See also PITS.Guidelines for a note about economic and market incentives to help adjust Pm's priorities. Thanks! --Petko February 25, 2010, at 03:12 PM

Well at least 01046 is quite a useful feature for everyone works with souce-code snipples in a wiki to explain what's going on in a peace of code. Link up words inside this code allow you to easily build a powerful code documentation wiki. At least you can use it to improve the PM-Wiki documentation itself, which is nearly not existing for the php-script internals. In addition I'm sure It will only take some minutes to implement it if you know the core of PM-Wiki. But if you doesn't its simple a bad idea because you cannot be sure not to break other markup with such a basic escape or not escape thing. At least I added a new PIT just to show that it will not help in any way to get the problem solved instead of discussing about what Pms priorities are.