WIP: Add class="" wrapper to attribute values for CSS styling

[gogowitsch]

This PR addresses or contains one new feature:

• Wrap HTML output of property values in CSS-able <span /> tag.

  This will allow for custom styling such as an icon before the text
  added by wiki admins.

I couldn't get the PHPUnit tests to run locally yet. After 2 hours, I give up for today and let Travis do the work 😢

[mwjames]

I couldn't get the PHPUnit tests to run locally yet.

What was/is the problem? The documentation [0] should be fairly clear on what to do, or not?

[0] https://github.com/SemanticMediaWiki/SemanticMediaWiki/blob/master/tests/README.md

[gogowitsch]

Thanks for the quick reaction! I figured it out from the Travis output: the PHPUnit version cannot be 4.8, it must be 6.5. Now all is fine locally. I already committed an updated README.md, but you beat me 😊

[gogowitsch]

Assuming I get the PHPUnit test coverage green, do you think adding a <span /> to the HTML output is a viable thing to do in this code base?

[mwjames]

do you think adding a to the HTML output is a viable thing to do in this code base?

For now I cannot see an issue to add a span for the HTML output but of course it will generate the span for each text value that comes in contact with a DataValue instance when a HTML output is requested.

[mwjames]

For now I cannot see an issue to add a span for the HTML output but of course it will generate the span

@kghbln Any insights her? I want to avoid a similar issue as with the plainlist vs. list output discussion during the 3.0 release.

[jaideraf]

Won't this change affect plainlist format?

If the output should include class attributes to HTML elements then result format "List" needs to be used. [0]

[0] https://www.semantic-mediawiki.org/wiki/Help:Plainlist_format

EDIT: @mwjames was fast again 🥇

[mwjames]

Won't this change affect plainlist format?

Most likely for text (_txt) values, yes.

[kghbln]

Any insights her? I want to avoid a similar issue as with the plainlist vs. list output discussion during the 3.0 release.

I believe this is about in-text annotations not added via templates. I personally would use a template even for this too, i.e. embedding single values, and not change the output behavior of the value itself.

Also by default things should stay as they are, meaning if a wiki wants to have spans for these values there should be a dedicated config parameter or a feature flag to an existing parameter to enable rich formatting.

The issue with the list format rework was that it changed the default behavior which was in retrospect not the best decision (list/plainlist <--> list/richlist). We should avoid something like this here.

[mwjames]

This will allow for custom styling such as an icon before the text
added by wiki admins.

@fonata While I think I grasp the idea here, maybe explaining the exact intend or use case would help others on this thread to understand what you are trying to achieve to see whether a better solution is available otherwise we end up with something that causes unnecessary opposition.

[akuckartz]

@fonata Ping