Summary: Add a configuration to disable/replace rendering of
Created: 2010-02-26 09:07
I would like to have the possibility to disable/replace/format any style attributes rendered.
Example of the effect
A simple example:
Through that configuration it should be rendered like:
<div class="colorred"> Some text </div>
<div style="color:red"> Some text </div>
Some Thought About The Implementation
First every solution I can think of has to recognize the
I can imagine some different ways to solve this providing different level of customization abilities:
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
Moved request from WikiStyles-Talk
Why use direct
Hello. PmWiki allows styling both with
Thanks for your replay. Indeed I dislike any use of the
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.