Link Appearance Control

Feature Request versus Extensions request

There are, effectively, 2 types of text that users input into a document: Regular reading text and links to other resources. There are a variety of ways to style text for presentation purposes but very limited tools for doing so with respect to links.

For users/editors of pages, you can dynamically adjust many properties of your textual presentation yet any changes to the appearance of link text require contacting a system administrator to have them make available the style(s) you wish to use, even if that style is to be used in a very limited fashion on the site.

This is for visual PRESENTATION control only, it is not functional but visual rendering of the link yet it requires a server/system administrator to enable it? This, in a nutshell, is why a feature request versus an extension -- wherever possible, visual formating should be handled by the user/editor versus requiring special requests and reviews by system administrators or developers (CSS files are server/service control files) and providing exposure of the link color and decoration effects should expedite delivery of content and off-load some work from admins/sysops.

Problem

Link presentation such as Problem Statements draws from the base CSS definitions for how links are displayed with such attributes as the links color, font-weight, mouseover reaction, etc...

When a contributor inputs information, due to the format of the presentation, they may require colorization/effect adjustments to be made to accommodate what they are presenting. Currently the only way to accomplish this is by involvement of a sysop/administrator to put CSS classes in place for use.

This can be both a troublesome and time consuming process for a busy user who is trying to input information in a clean, concise fashion.

Examples

NOTE: This sites links are 'mild' compared to what some sites use for default link behavior. This problem will show here but to a much lesser degree than some other wiki sites might show with their default link styles.

Example 1

{| class="wikitable" width="50%" style="text-align:center; background:black; color:white"
  |-
    |style="color: yellow"|'''A list of known problems'''
    |style="color: yellow" width="70%"|'''Description'''
  |-
    || [[:Category:Problem statements|Problem Statements]]
    |style="text-align: left"| Links look ugly in this layout.
|}

Outputs:

A list of known problems	Description
Problem Statements	Links look ugly in this layout.

As you may notice, the link is virtually unreadable. There are some 'workarounds' for this beyond having CSS classes input into system files by an administrator but, if one can HIDE links, have different text for links, provide images for links, etc... The basic ability to adjust the links display properties should also be exposed so the users do not require server administrative assistance to provide legible/attractive/functional content.

Example 2 (a span workaround)

{| class="wikitable" width="50%" style="text-align:center; background:black; color:white"
  |-
    |style="color: yellow"|'''A list of known problems'''
    |style="color: yellow" width="70%"|'''Description'''
  |-
    || [[:Category:Problem statements|<span style="color: cyan">Problem Statements</span>]]
    |style="text-align: left"| Links look ugly in this layout.
|}

Outputs:

A list of known problems	Description
Problem Statements	Links look ugly in this layout.

This example changes the color for 1 link, not for all links that may be used in such a table so each and every link would require this done to it -AND- it does not address the decoration (blue line) when you mouse over the link.

The difficulty with this comes into play with mous-eover inconsistencies (mouse-over the link above -- note the 'blue line' that appears under the text). This 'style' doesn't fit for an appropriately colored link. It should interact with the user based upon that new color, not mixing system default behavior like it does.

The other difficulty is that EVERY link would need this applied to it in each table that is to use such adjustments. If you have a large table, with links interspersed through out the text, the chances of typing errors, etc.. increases. On a large site, that may have several color schemes needed to properly present information, the load on a sysop can grow or the information is reformatted to accommodate the limitations of the medium being used to present the data (MediaWiki).

---

Currently, you have 2 options to address this: Contact a sysop and have a style sheet/class defintion ready to be reviewed and made available across the server or try and find an extension that may allow the formatting and then have that extension loaded on the server.

There are some extensions that allow for CSS tags to be used but they tend to provide far wider access to CSS than simply allowing text formatting of links to be done such as the <css> </css> tag extension. Full CSS access is usually not desired by administrators and why their involvement in the process is required. By limiting controls to only the :link :active, etc... pseud-class formatting controls, the formatting may be accomplished without involvement of a server admin.

Thoughts on Syntax, Implementation and Usage

This 'fix' also can simplify a common error in using link color controls -- you must use a specific order and include all pseudo-clases, up to the one you wish to adjust, for most browsers as in :link, :visited, :hover THEN :active, for some browsers to work correctly. If someone attempts to modify just the hover effect, they need to include the previous 3 in the definition of the change, without changing them. If this is 'exposed' that limitation can be built into 'the back end' allowing the user to set the properties of only the pseudo-classes without stubbing the others as would be needed in a CSS style definition.

Example Pseudo-Code Structure

The idea would be to ask for a LinkControl (or whatever name) to be made available.

{{#LinkControl
ClassID=(required-unique)
linkEffect=(optional)
visitedEffect=(optional)
hoverEffect=(optional)
activeEffect=(optional)
}}

Where the optional values would be the properly formatted link controls. Example Usage:

==

Headline text

==

Example Calls to the New Function

{{#LinkControl
  |ClassID="blackBGLinks"
  |linkEffect="color:yellow; text-decoration: underline"
  |visitedEffect="color:yellow; text-decoration: underline"
  |hoverEffect="color:yellow; font-weight: bold; text-decoration: underline"
  |activeEffect="color:yellow; text-decoration: underline"
}}

{{#LinkControl
  |ClassID="grayBGLinks"
  |hoverEffect="color:yellow; font-weight: bold; text-decoration: underline"
}}

These would both generate full link style defintions and add them to the page.

Example 'output' Code by the Function

Pseudo CSS the function would generate:

.{(ClassID}} a:link { {{linkEffect}} }
.{(ClassID}} a:visited { {{visitedEffect}} }
.{(ClassID}} a:hover { {{hoverEffect}} }
.{(ClassID}} a:active { {{activeEffect}} }

or, from above examples, the output would be.

.blackBGLinks a:link { color:yellow; text-decoration: underline }
.blackBGLinks a:visited { color:yellow; text-decoration: underline }
.blackBGLinks a:hover { color:yellow; font-weight: bold; text-decoration: underline }
.blackBGLinks a:active { {color:yellow; text-decoration: underline }

.grayBGLinks a:link
.grayBGLinks a:visited
.grayBGLinks a:hover { color:yellow; font-weight: bold; text-decoration: underline }
.grayBGLinks a:active

Thus you end up with a class (or classes) that can be used in <div>, <span>, etc.. which also allows for multiple link control formats to be used, by their class name, on a page. Flexible and relatively safe with respect to how 'exposed' the CSS controls are and the scope of any potential malformed link syntax may be.