Last modified: 2010-05-15 14:36:22 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 642 - Expanded URLs should not be generated at server
Expanded URLs should not be generated at server
Status: RESOLVED FIXED
Product: MediaWiki
Classification: Unclassified
Parser (Other open bugs)
unspecified
All All
: Normal normal with 1 vote (vote)
: ---
Assigned To: Tom Gilder
:
Depends on:
Blocks: 367
  Show dependency treegraph
 
Reported: 2004-10-04 20:17 UTC by Tom Gilder
Modified: 2010-05-15 14:36 UTC (History)
1 user (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments
Patch to move URL expantion to CSS (or JS for IE) (5.33 KB, patch)
2004-10-05 00:28 UTC, Tom Gilder
Details
New patch, serveral fixes (5.99 KB, patch)
2004-10-05 01:15 UTC, Tom Gilder
Details
Patch take 3: remove all instances of .urlexpansion in CSS (8.59 KB, patch)
2004-10-05 01:45 UTC, Tom Gilder
Details

Description Tom Gilder 2004-10-04 20:17:57 UTC
Expanded URLs in parentheses generated for printing after external links (but only when the link text 
isn't the URL) should be a purely client-side business.

These URLs are currently outputted as plain text, which has accessibility side-effects - I doubt many 
screen-reader users want to hear the URL of every external link in the page.

They should be generated on the client via CSS, using:

  element:after { content: " (" attr(href) ") "; }

IE/win however doesn't support generated content, so it can have some JS (already written) to do the same 
thing.
Comment 1 Tom Gilder 2004-10-04 20:33:51 UTC
To do this, the current thinking is to have 3 different CSS classes for external links:

  * One for external links with custom text
     - generated by "[http://moo.com moo]", displayed as "moo"
     - should be printed as "moo (http://moo.com)"
  * One for external links where the link text is the same as the URL
     - generated by "http://moo.com" or "[http://moo.com http://moo.com]"
     - should be printed as "http://moo.com"
  * One for external links that are autonumbers
     - generated by "[http://moo.com]", displayed as "[1]"
     - should be printed as something like "[http://moo.com]"
Comment 2 Matthew "mpt" Thomas 2004-10-04 21:02:42 UTC
> IE/win however doesn't support generated content

IE/Win does, however, have the option of printing each link 
as an endnote, with a table of link URIs at the end of the 
page. So there's no need to reimplement this server-side 
just for IE/Win.
Comment 3 Tom Gilder 2004-10-05 00:28:34 UTC
Created attachment 65 [details]
Patch to move URL expantion to CSS (or JS for IE)

Here's a patch which seems to work, would appreciate it if someone could review
it (as I don't have all that much faith in my coding...).

It uses generated content for browsers which support it, or JS in IEFixes.js
with onbeforeprint/onafterprint.
Comment 4 Tom Gilder 2004-10-05 01:15:56 UTC
Created attachment 67 [details]
New patch, serveral fixes

Updated patch: use "free" (not URL) as class when autonumber is disabled;
remove suppressUrlExpansion from Skins (not needed anymore)
Comment 5 Tom Gilder 2004-10-05 01:45:11 UTC
Created attachment 68 [details]
Patch take 3: remove all instances of .urlexpansion in CSS
Comment 6 Rowan Collins [IMSoP] 2005-01-15 23:10:52 UTC
[please CC the bug-list-bot when changing the assignment of a bug]

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links