A Compromise

The newest upload (Test 4), is a compromise to improve speed, compatibility, and functionality. The previous test interfered with the normal operation of some pages, especially complex web pages. The 'next to address' option was rewritten to prevent this situation.

This changes mean that detecting 'dirty' links will have to be implemented some other way, but it is possible to do using the new method. This will likely be re-added in the next test version.

Finally, automatic detection is now triggered sooner. The extension is triggered to execute before some non-essential items, like images, are finished downloading. Pages with a large number of these items to download would stall the execution of this function.

Yet Another Public Beta

In the current beta version upload (v1.0.2 Test 3), I've added a new feature and fixed a popup display issue.

The new feature to automatically add links directly next to the web address was initially problematic. This method requires a completely different way of accessing the web page. Without special handling, data could be inserted into the wrong places and this would interfere with the page's code or visual layout. This has been improved upon in the newest upload to be less of a problem.

Using this new method, though, allows for me to detect and handle 'dirty' links. These are text addresses that are split into smaller pieces using formatting tags, though the text still appears to be a single item. For example, part of the link may be in bold. This type of detection is not possible using the default link detection method.

Lastly, the popup would sometimes not show or function on certain web sites [like avclub.com]. Sites that used layers to show some items above or below others would be affected. This has been fixed by making sure that the MakeLinks popup is defined to be above all other layers.

The Newest Public Beta

In the newest Public Beta, I've implemented three new changes.

The first option will split a link into breadcrumbs, when the highlight mechanic is used. Each section of the link becomes clickable to optionally only use part of the web address. Though I think this a very useful option, I've decided to disable it by default since it does change a major feature of this utility.

The second option is based on user feedback. This option will detect missing or incorrect "http://" prefixes and correct them. Currently, if the address has no protocol prefix at all, a link will only be detected if it is followed by a path (eg www.example.com/stuff). This prevents most false positive detections when two words are separated by a period, like "document.write".

The last item is a fix. The detection of web addresses has been improved. This removes many false positives as well as greatly improves the new option correct detection of addresses missing the prefix.

The Next Changes

Now that MakeLinks has a Preferences page, I can add more optional features that allow for flexibility without interfering with the normal work-flow. Options that may interfere will not be enabled by default.

I've already had a request to add support for links that do not begin with the http prefix. Addresses like "www.example.com/stuff" are not currently detected, since this would require a secondary and more restrictive search to prevent false positives. The current detection for "http:" addresses is currently very lax, to the point of actually being incorrect.

Another thing I've noticed is that addresses are often found enclosed in parenthesis as follows: (see http://example.com). Currently, the trailing parenthesis will be included in the link though this is not likely the desired behavior. An option to detect and correct these addresses would work well.

I've, also, been thinking about a breadcrumbs option in the popup. This would split an address into separate clickable parts, instead of manually removing part of the address after clicking it.

A New Beta

In the current Public Beta v1.0.1 Test 1 upload, I've added the requested feature for an option to enable automatic detect of links. As said below, it is disabled by default because it may be process intensive on slower systems and it inserts content to the target page.

When links are detected in Automatic mode, a small icon link is place after the element containing the web address. Unlike the highlighting method, this will fail to detect web addresses that are split up with HTML tags. For example, if part of the web address is enclosed in Bold tags, part or none of the address may be detected. I've found no workaround for this issue besides manually highlighting these items. Also, the location of the icon may appear much further away than when using the highlight mode since a reliable means of locating the web address position seems to be not possible.

I've also added an option to detect text web addresses enclosed with link tags. This is an experiment, since these items are already clickable links. I may remove this options for the official release since it effectively only adds a visual indicator.

First Feedback

The first feedback has come in and an automatic feature has been requested three times. While it could be a trivial addition, I will have to put some thought into it. There are rules, in my mind, that must be followed.

The utility must be non-intrusive. I toyed with having the actual target pages code altered, but having a separate popup was least likely to conflict with existing code. Having a popup triggered by a highlight that was easy to close also made it non-intrusive.

Scanning the target page on load and then displaying a popup would be intrusive. Displaying a small popup near each individual text web address would follow the rule more closely. It would have to be extremely small to not interfere with the existing text, but recognizable.

Another rule would be to not interfere with normal work-flow. Scanning an entire page on load could be taxing on slower systems. So such a new addition must be optional and likely disabled by default.

First Official Release

Version 1.0.0 of MakeLinks is now available via the Opera Extension catalog. Those that installed the previous beta test versions are encouraged to uninstall the beta and install the official release version.