User talk:Interiot/js/RealTitle.js

[edit] Functional requirements

If the proposed new title is a valid wikilink version of the real underlying title (eg. if it can be copy-and-pasted into wikitext and create a valid link to the page), then change the <h1> (the bit that shows up below the "tabs" just above the article text)
Change the <html><title> (the bit that shows up at the very top of the browser window) in all cases to the proposed title
If the proposed title contains HTML, remove the HTML bits from the <h1> title and the <html><title> (especially the last one, because HTML doesn't render there)
- However, if the proposed title contains only <sup> and/or <sub>, then keep those HTML tags in the <h1> title, but still remove them from the <html><title>, of course
If the proposed title is pasteable, and it doesn't contain HTML (other than sup/sub), then hide the "due to technical restrictions" blurb because the <h1> title contains all the information the article author wishes to convey about the title

It's probably not obvious to editors what triggers the hiding of the "due to technical restrictions" blurb... It depends solely on whether the proposed title matches the underlying database title closely enough to be pasteable. While this is a clear technical requirement, it may be an unexpected subtlety.

~~Automatically add the namespace if it's not there~~
~~Calculate "isPastable" on whether the name matches its canonical (what's the term they use in MediaWiki code?) version~~
"innerHTML" is not sufficient for the title or the H1, if users include HTML tags inside. We need to do something like "innerText". CO2 rocket and It's On (Dr. Dre) 187um Killa are ones where the HTML ends up appearing in the title.
Is there anything we can do about things like Nano (text editor)? It's unfortunate, because looking at it, you can see that there's a clear title that should be displayed, but it's not, because in most cases, people don't want the "due to technical restrictions" blurb to include the (disambig) suffix. Is there a third way for this?
Due to a bug (in MediaWiki?), pages like Lac operond don't show up because the <span> is actually fucked up
When printing, it would be good to always replace the <h1> title with the proposed title, even when it's not pasteable (presumably with some @media print)

Confirm these work on Firefox/Opera/MSIE whenever a change is made:

one of the mainspace {{lowercase}} (eg. iPod should be changed)
one of the non-mainspace {{lowercase}} that doesn't contain the namespace (eg. Category:x86 microprocessors should be changed)
a non-namespace {{lowercase}} that does contain the namespace (eg. User:interiot/Test realtitle1 should be changed)
one of the {{lowercase-user}} (eg. User:rambot should be changed)
one of the {{downsize}} (eg. K_a band should be changed)
one of the {{pipe in title}} (eg. Softimage XSI should not be changed)
something with HTML in the name (eg. lac operon or It's On (Dr. Dre) 187um Killa or User:Interiot/Test realtitle2 should be changed, and their title should look reasonable)
RealTitles with underscores in the front shouldn't be idenfied as pasteable (eg. NSAKEY should not be changed)
Try pages with somewhat far-out HTML title formatting, and make sure the "due to technical restictions..." blurb still appears: House of Leaves, Apple IIGS, Only Revolutions

01:45, 25 November 2006 — add the ability to handle sub/superscripts (this version was tested thoroughly and posted to MediaWiki:Common.js)
21:29, 24 November 2006 — innerHTML ⇒ innerText, handle HTML-ized titles better (this version was tested thoroughly and posted to MediaWiki:Common.js)
04:11, 21 November 2006 — isPastable is automatically calculated; the namespace is automatically added
07:22, 16 November 2006 — isPastable based on hardcoded divs in templates
06:54, 16 November 2006 — modification of the french version to update the title as well