Render empty WAnchors as <a>, not <span>
|Assignee:||Koen Deforche||% Done:|
The fact that Wt renders WAnchors with empty WLinks as <span>s instead of <a>s causes CSS problems with projects like Bootstrap whose CSS selectors specifically require <a>s. Could there perhaps be a setting (or simply a behavior change) so that empty links are always rendered as <a> tags? All versions of the HTML specification have never required an href attribute on <a>, so this should not be a problem; see http://dev.w3.org/html5/spec/single-page.html#the-a-element
- If the a element has no href attribute, then the element represents a placeholder for where a link might otherwise have been placed, if it had been relevant.
- The target, rel, media, hreflang, and type attributes must be omitted if the href attribute is not present.
#1 Updated by Koen Deforche 11 months ago
- Status changed from New to Assigned
- Assignee set to Koen Deforche
I don't exactly recall what was the problem with an anchor without href, but there issues. But perhaps only with older (mobile) browsers.
I'ld be happy to revisit this indeed, since it is an annoyance.
#2 Updated by Jake Petroules 11 months ago
- File a-span-patch.diff added
Yeah, I have also read that iOS devices require href="#" for certain things (the Twitter Bootstrap team has taken note of this), but that can easily be worked around by the user (using
I started working on this but Wt still renders an href attribute with no value, i.e.
#3 Updated by Koen Deforche 11 months ago
- Status changed from Assigned to Feedback
I tried your patch. All you are missing is : needsUrlResolution = false, because otherwise the href is set client-side.
I'ld be interested in hearing if you hit any adverse problems ? The '#' trick is somewhat problematic on older browsers (IE6 - IE9) since it might interfere with the internal path handling using URL fragments.
#4 Updated by Jake Petroules 11 months ago
If the WAnchor has a null WLink, it can simply render without an href attribute at all, which should not have any problems at all in the first place and it is valid for an <a> tag to lack an href attribute. That part I think we are in agreement with? The only thing to be careful about is to make sure that empty href attributes cannot be set, i.e.:
<a>Link</a> // OK <a href>Link</a> // Problem <a href="">Link</a> // Problem <a href="/items">Link</a> // OK
Now the second part of this topic and the only actual issue as far as I am aware, is that some links require href="#" to work properly in certain situations and environments as I noted above.
I believe I have a solution but first I need to ask: is '#' by itself an invalid internal path (you need at least #/ I think)? If that is true, we could check if the WAnchor's WLink is comprised solely of #, then its click event could be set to call e.preventDefault() so the browser won't react to a navigation event and mess up internal paths (but should still be able to participate in Wt event handling).
What are your thoughts on this approach? I will also do more testing later today with
needsUrlResolution = false as you noted.
#5 Updated by Koen Deforche 11 months ago
Setting needsUrlResolution to false will make this work.
As to the '#' problem, we should first find out if it is actually Internet Explorer which would require the href attribute in the first place, otherwise it is effectively not a problem.
#7 Updated by Jake Petroules 11 months ago
- File a-span-patch.diff added
Koen, please take a look at this: http://stackoverflow.com/a/11404263/343845
Also, do note that there IS a difference between
href="". From everything I've looked into in the past couple of days I can't find anything that would appear to indicate that the lack of an href attribute is a problem. I've attached my updated patch that accounts for
needsUrlResolution; please let me know if we can proceed with this.
Also I think we still need a solution to href="#" since I expect it will interfere with internal paths. I will test this later.
#8 Updated by Koen Deforche 11 months ago
That looks correct (although I will refactor things a bit since link_.isNull() really is a different code path)
I've looked it up: this is a change since August last year, but I cannot trace any reasoning for it. So I am inclined to accept the proposal to drop the <span> workaround (after the final Wt 3.2.2 release).