Tags:
create new tag
, view all tags

Feature Proposal: Auto Links break when inside HTML tags with no whitespace

Motivation

Usability issue when people mix html with wiki syntax. They expect auto linking to work the same in a html tag that outside.

Description and Documentation

Occurs when a wikiword comes after a tag with no whitespace:

<br>WebHome

<i>WebHome<i>

<u>WebHome<u>

renders:


WebHome

WebHome

WebHome

This causes the wiki word not to autolink which is contrary to what users expect.

Examples

Impact

WhatDoesItAffect: Usability

Implementation

-- Contributors: ChadMinick - 02 Jun 2008

Discussion

I know as a fact that many people take advantage of this to not autolink. A common one is <nop>WikiWord.

I would be very scared to change this fundamental property of TML. When we decided to make numbers equivalent to lower case letters (a change I pushed and supported myself) we ended up creating quite a lot of noise among users. We often do not realize the negative impact of such changes until it is actually implemented.

I understand the issue and often see it in the context of EditTablePlugin but I really fear making such a radical change in the definition of TWiki markup is going to create a major issue for many TWiki sites after an upgrade.

-- KennethLavrsen - 02 Jun 2008

I have seen <nop> quite a bit as well. If said feature is implemented by breaking all other tags, we could make <nop> an exception could we not?

-- ChadMinick - 02 Jun 2008

It is unfortunate, yes.

Most TWiki users are surprised by the seemingly arbitrary way that Autolinking works. A few have come to rely on non-spaced prevention of autolinking.

Personally I think we should simplify this as Chad suggests, as those that are making use of it, mostly know enough to fix it too.

With regards to the nop example, that is actually different, as there is code that explicitly does the nop - it is an intentional signal to the render-er to not autolink/process.

In this case, I would suggest that this change be an option (on by default) that can be turned off for older TWiki's, and a reporting / upgrade tool be written to list all the cases where the linking would change - perhaps even with a 'convert' UI to explicitly fix things.

-- SvenDowideit - 03 Jun 2008

I do not think it is a good idea to change the spec for two reasons:

1. Compatibility with existing content.

2. Incorrect rendering caused by a WikiWord in HTML getting linked more than once. Example:

<a href="http://google.com/">HelloGoogle</a>

If we would remove the leading whitespace rule we'd get:

<a href="http://google.com/"><a href="/cgi-bin/Sandbox/HelloGoogle">HelloGoogle</a></a>

Which is clearly not valid HTML.

I believe a better approach is to have a TML aware WYSIWIG editor, or an HTML editor with solid TML -> HTML -> TML roundtrip. This hides the not-so-intuitive parts of TML.

-- PeterThoeny - 03 Jun 2008

Peter, what you say above implies that you think we do not currently have a solid round trip WYSIWYG editor. If that were the case I would have expected to see a lot more bug reports from you relating to this. I have put a lot of work into WYSIWYG, and to have it damned by implication this way is depressing.

I also agree that it is not a good idea to change the spec. The constraints on CamelCase linking in raw edit are clear, and have been in place since TWiki's inception.

-- CrawfordCurrie - 03 Jun 2008

Sorry Crawford, it was not my intention to imply anything. I know you took an almost impossible task, and you solved the round trip problem by bringing it to relatively solid grounds.

-- PeterThoeny - 03 Jun 2008

Edit | Attach | Watch | Print version | History: r7 < r6 < r5 < r4 < r3 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r7 - 2008-06-03 - PeterThoeny
 
  • Learn about TWiki  
  • Download TWiki
This site is powered by the TWiki collaboration platform Powered by Perl Hosted by OICcam.com Ideas, requests, problems regarding TWiki? Send feedback. Ask community in the support forum.
Copyright © 1999-2017 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.