We want the notifications in the flyout to behave just like links,
including standard middle-click and Ctrl-click behavior. The simplest
way to do that would be to actually make them links - but the area can
contain a few other links, so we can't do that and have to resort to
ugly hacks.
Or do we?
Turns out that while browsers won't accept HTML containing nested <a>
tags[1], such a structure is valid XHTML, and it's possible to create
such structure in HTML mode using DOM manipulation. It works like one
would expect: the entire thing is clickable, but inner <a> tags' hrefs
override outer ones.
Firefox even had a request to make that work[2] which was happily
fulfilled.
Tested the basic case [see below] on Firefox 22, Opera 12, Opera 15
(which uses the Blink engine like Chrome), IE 8 and IE 6 and it works
the same on all of them. Tested the XHTML variant [see below] on all
of the above except for the IEs which don't grok XHTML and it exhibits
the same behavior.
[1] Simple test: $('<div>1<a>2<a>3</a>4</a>5</div>').html() is
"1<a>2</a><a>3</a>45", not actually "1<a>2<a>3</a>4</a>5" like one
might expect.
[2] https://bugzilla.mozilla.org/show_bug.cgi?id=331959
----
The test cases used are below. When trying out the XHTML one make sure
that the browser uses application/xhtml+xml MIME type; saving the file
with .xhtml extension should be enough.
XHTML:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<body>
<div>1<a href="http://google.com/">2<a href="http://example.com/">3</a>4</a>5</div>
</body>
</html>
HTML:
<!DOCTYPE html>
<html>
<body>
<script type="text/javascript">
var div = document.createElement('div');
var a1 = document.createElement('a');
a1.href = "http://google.com/";
var a2 = document.createElement('a');
a2.href = "http://example.com/";
div.appendChild( document.createTextNode('1') );
div.appendChild( a1 );
a1.appendChild( document.createTextNode('2') );
a1.appendChild( a2 );
a2.appendChild( document.createTextNode('3') );
a1.appendChild( document.createTextNode('4') );
div.appendChild( document.createTextNode('5') );
document.body.appendChild(div);
</script>
</body>
</html>
----
Bug: 52319
Change-Id: I311eca70f025ce92129c828cd88f96686b7cff72
Out of the default MW skins these only seem to affect CologneBlue.
* Reset padding and list-style-image on ul#mw-echo-special-container
ourselves, do not rely on the skin doing it
* Use transparent background on .mw-echo-notification (and
semi-transparent black on hover) instead of solid white and
light grey to accomodate colored skin backgrounds
Change-Id: I2c178627e4dbe889c4958afc41e4969aaa45a717
In theory, a notification could not need any contextual information
so there's no reason we should make it required.
Now, if the title-params are not provided in the notifcation
definition, it just sets the value to an empty array.
Change-Id: Iba5ce5cc56010101c5e64976c95b37a215dc99fa
The current message key is notification-learn-more, but this message key
is not defined in the language file, it should be echo-learn-more
Change-Id: I4e2f19e3663727ff8c4083fd295c80cb350297c4
The reason I'm splitting this is that, not only do I want to create
a link to the 'title', but also for another param (in my case: link
to the AFTv5 permalink page)
Change-Id: I834b50ca144e7d08db830726480da19e1b406a27
To test the HTML email:
1. install the latest version of php-mail and php-mail-mime package, they are required
by the core sendmail function to send HTML email
2. set $wgAllowHTMLEmail = true before loading Echo in LocalSetting.php
Change-Id: Ia4b98b14e135742b84f1b0e04589b0efdd24e954
wgUserNewMsgRevisionId is null with only one revision and that revision is
not viewed, this makes it not reliable for determining if there is new
message. We just switch to check against $user->getNewtalk() instead.
We can still use wgUserNewMsgRevisionId to generate diff links if desired
Change-Id: I4cf50a944aada03151bd17f3610bd59b3bfb2bf2
