Hi,
FTP external link CSS looks like that:
#bodyContent a.external[href ^="ftp://"], .link-ftp { background: url(file_icon.gif) center right no-repeat; padding: 0 18px; }
The padding is 18px on the left AND on the right and 0px otherwise. This is though I guess to reserve space for the small icon placed on the right of the link.
I have two questions: * Why we have defined a padding also on the left (and not set padding: 0 18px 0 0;)? * Why on the online site we do not see the padding on the left?
I ask these questions, because after using the dumpHTML extension, I have this issue: I see the 18px big padding on the left with the static html files.
See this old bug report https://bugzilla.wikimedia.org/show_bug.cgi?id=20828
Thanks for your help Emmanuel
On Tue, Nov 9, 2010 at 4:51 AM, emmanuel@engelhart.org wrote:
Hi,
FTP external link CSS looks like that:
#bodyContent a.external[href ^="ftp://"], .link-ftp { background: url(file_icon.gif) center right no-repeat; padding: 0 18px; }
This is so it works correctly for both LTR and RTL. Note the following rules:
/* for rtl wikis */ .rtl #bodyContent a.external { background-position: left; padding-right: 0; } .rtl a.feedlink { background-position: right; padding-right: 16px; padding-left: 0; }
/* correction for ltr wikis */ .ltr #bodyContent a.external { padding-left: 0; }
This way only one rule is needed for each icon type, not one for LTR and one for RTL. Notice that the icon widths are different for each type, so this is the most economical way to do it. Your site is probably missing the .ltr/.rtl class on the body.
In trunk we've switched to using a script that just swaps left and right everywhere for RTL, so the rule is instead
#bodyContent a.external[href ^="ftp://"], .link-ftp { /* @embed */ background: url(file_icon.gif) center right no-repeat; padding-right: 18px; }
with the directions presumably flipped somehow. (By the resource loader, I'm guessing? That will cause even more trouble for static dumps, I guess.)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 09/11/2010 20:21, Aryeh Gregor wrote:
On Tue, Nov 9, 2010 at 4:51 AM, emmanuel@engelhart.org wrote:
Hi,
FTP external link CSS looks like that:
#bodyContent a.external[href ^="ftp://"], .link-ftp { background: url(file_icon.gif) center right no-repeat; padding: 0 18px; }
This is so it works correctly for both LTR and RTL. Note the following rules:
/* for rtl wikis */ .rtl #bodyContent a.external { background-position: left; padding-right: 0; } .rtl a.feedlink { background-position: right; padding-right: 16px; padding-left: 0; }
/* correction for ltr wikis */ .ltr #bodyContent a.external { padding-left: 0; }
This way only one rule is needed for each icon type, not one for LTR and one for RTL. Notice that the icon widths are different for each type, so this is the most economical way to do it. Your site is probably missing the .ltr/.rtl class on the body.
In trunk we've switched to using a script that just swaps left and right everywhere for RTL, so the rule is instead
#bodyContent a.external[href ^="ftp://"], .link-ftp { /* @embed */ background: url(file_icon.gif) center right no-repeat; padding-right: 18px; }
Thank you for this explanation, this is perfecly clear now for me. I will try to find why the .ltr/.rtl classe is not defined for the body and close the bug report.
with the directions presumably flipped somehow. (By the resource loader, I'm guessing? That will cause even more trouble for static dumps, I guess.)
This is perfectly true, I have discovered that a few days ago. The DumpHTML extension was "broked" by the introduction of the resourceLoader. Consequently static pages are missing essential CSS directives and are not correctly displayed. So we have here a regression.
I hope this will be fixed at the moment the new version of Mediawiki using the resourceLoader will be rollouted on WMF servers.
Thanks again for your help Emmanuel
On 11/9/10 11:32 AM, Emmanuel Engelhart wrote:
This is perfectly true, I have discovered that a few days ago. The DumpHTML extension was "broked" by the introduction of the resourceLoader. Consequently static pages are missing essential CSS directives and are not correctly displayed. So we have here a regression.
If DumpHTML is being fixed up, please consult Roan or me about ResourceLoader things, we can help out.
- Trevor
2010/11/9 Aryeh Gregor Simetrical+wikilist@gmail.com:
with the directions presumably flipped somehow. (By the resource loader, I'm guessing? That will cause even more trouble for static dumps, I guess.)
ResourceLoader does this based on the &lang= parameter passed to it when grabbing the CSS. Static dumps wouldn't be affected as long as they use one language consistently and fetch the CSS through RL.
Roan Kattouw (Catrope)
On Tue, Nov 9, 2010 at 4:57 PM, Roan Kattouw roan.kattouw@gmail.com wrote:
ResourceLoader does this based on the &lang= parameter passed to it when grabbing the CSS. Static dumps wouldn't be affected as long as they use one language consistently and fetch the CSS through RL.
If they're running ResourceLoader, they're hardly static, are they? The idea is that you shouldn't have to run PHP to get a working static (possibly partial) copy of a wiki's content. Before ResourceLoader the CSS and JS was a nonissue, since that was just static files, but that's no longer the case. Whatever script generates static dumps is presumably just creating them with no working CSS at all anymore, which is bad.
I don't think this should be too hard to fix, though, if someone cares enough to do it. Whatever script makes static dumps should just get ResourceLoader to output one CSS file that contains everything that could be needed, probably with no JS (unless there's some JS static dumps will actually want that I can't think of), and include that statically.
On 11/10/10 6:52 AM, Aryeh Gregor wrote:
Whatever script makes static dumps should just get ResourceLoader to output one CSS file that contains everything that could be needed, probably with no JS (unless there's some JS static dumps will actually want that I can't think of), and include that statically.
You will need to generate one for right-to-left and one for left-to-right. ResourceLoader has an API that supports generating these responses directly in PHP.
- Trevor
2010/11/10 Trevor Parscal tparscal@wikimedia.org:
On 11/10/10 6:52 AM, Aryeh Gregor wrote:
Whatever script makes static dumps should just get ResourceLoader to output one CSS file that contains everything that could be needed, probably with no JS (unless there's some JS static dumps will actually want that I can't think of), and include that statically.
You will need to generate one for right-to-left and one for left-to-right. ResourceLoader has an API that supports generating these responses directly in PHP.
CSSJanus::transform( $css ) in includes/libs/CSSJanus.php is what Trevor's talking about here.
I guess you could take a concatenated version of all style sheets and generate an RTL version of that. What do the current static dumps do?
Roan Kattouw (Catrope)
2010/11/10 Roan Kattouw roan.kattouw@gmail.com:
I guess you could take a concatenated version of all style sheets and generate an RTL version of that.
Hmm, and remap image paths, now I think of it. It'd probably be easier to pull the CSS for all modules from the resource loader this way:
load.php?modules=all|module|names|here&only=styles&lang=en
Which will do concatenation and path remapping for you, and will do RTL transformation if &lang is set to an RTL language.
Roan Kattouw (Catrope)
wikitech-l@lists.wikimedia.org