On Feb 8, 2008 12:20 PM, huji@svn.wikimedia.org wrote:
+/**
- Lists (fixing for RTL display_
- */
+body.rtl #body-content ul { display:table; } +body.rtl #body-content ol { display:table; }
Could you expand on the reason for this a little? It seems pretty odd. There seems to be no element with id="body-content" in any skin, or at least not on a typical page view, and I don't understand why you would want to try setting lists to display as tables. That should do all sorts of weird (if perhaps subtle) things, per the standard.
Simetrical wrote:
On Feb 8, 2008 12:20 PM, huji@svn.wikimedia.org wrote:
+/**
- Lists (fixing for RTL display_
- */
+body.rtl #body-content ul { display:table; } +body.rtl #body-content ol { display:table; }
Could you expand on the reason for this a little? It seems pretty odd. There seems to be no element with id="body-content" in any skin, or at least not on a typical page view, and I don't understand why you would want to try setting lists to display as tables. That should do all sorts of weird (if perhaps subtle) things, per the standard.
I guess it should be #bodyContent.
Setting "display: table" may seem odd, but it works and fixes Firefox bug that lists in RTL display with some floating elements on their left are outdented, beyond the page borders (see https://bugzilla.mozilla.org/show_bug.cgi?id=262195 ). This fix doesn't have unexpected affects on unordered lists. It had some affects on ordered lists in some older versions of Firefox, but they don't seem to occur anymore in newer versions. This is the known fix for the problem in the CSS files of RTL wikis (hewiki, arwiki and fawiki all set it this way).
I think the list of pages in a category should not have "display: table" set, and it should definitely be disabled for the filetoc in image files, which is defined using ul.
Furthermore, since this bug is fixed in Firefox 3.0, I'm not sure fixing this in the MediaWiki level is currently necessary. RTL wikis can fix this in their CSS files until it is fixed in the browser level, and some of them already do this.
On Feb 8, 2008 4:07 PM, Rotem Liss rotemliss@gmail.com wrote:
I guess it should be #bodyContent.
Well, that only exists in Monobook, so probably not a good idea. #content, maybe, but of course that breaks in Modern, as people have repeatedly observed.
Setting "display: table" may seem odd, but it works and fixes Firefox bug that lists in RTL display with some floating elements on their left are outdented, beyond the page borders (see https://bugzilla.mozilla.org/show_bug.cgi?id=262195 ). This fix doesn't have unexpected affects on unordered lists. It had some affects on ordered lists in some older versions of Firefox, but they don't seem to occur anymore in newer versions. This is the known fix for the problem in the CSS files of RTL wikis (hewiki, arwiki and fawiki all set it this way).
And it doesn't affect other browsers at all either? I'm pretty sure there should be some differences between list-items nested in a table and in a block, like width handling for the container.
At any rate, this should all be carefully explained in comments. Cryptic code like this needs to be well-documented.
Furthermore, since this bug is fixed in Firefox 3.0, I'm not sure fixing this in the MediaWiki level is currently necessary. RTL wikis can fix this in their CSS files until it is fixed in the browser level, and some of them already do this.
We maintain fixes for browsers as old as IE5, so it seems appropriate to maintain fixes for FF2. We don't currently have a CSS fixes file for any Firefox version, though, oddly.
About the ID, yeah you're right. It should've been #bodyContent, and I was mistakenly thinking that the element exists on all Skins :( I guess I have to fix the other skins accordingly.
About showing lists as table: Firefox-family browsers render the page incorrectly if the design is RTL and the list is to the right of a an object that is floated to the left (like an image thumbnail). The lists will be rendered not in their place, but as many pixles to the right as the width of the floated object is. (In simple, if you have an image to the left and a list to the right, the list will jump off the page, and even make a horizontal scrollbar appear). The fix doesn't make any visible change in other browsers, yet fixes the bug in Gecko browsers. It is being actively used on many of Wikimedia wikis atm.
About why to try to limit it to #bodyContent: Because we have lists outside this section too, particularly in navigation boxes, and that fix makes the lists in those sections to move to the left a little (few pixles) in some browsers. So we need the fix to only touch the "content" section of the page.
About why to try to implement it in shared.css: Because this problem is not limited to a skin, and a fix should affect all skins.
Hope I've answered it fully.
Btw, do you have any suggestions on how to expand it to other skins?
Huji
PS: I'm also considering changing the code in a way that it only affects FF2 et al.
On Feb 9, 2008 12:47 AM, Simetrical Simetrical+wikilist@gmail.com wrote:
On Feb 8, 2008 4:07 PM, Rotem Liss rotemliss@gmail.com wrote:
I guess it should be #bodyContent.
Well, that only exists in Monobook, so probably not a good idea. #content, maybe, but of course that breaks in Modern, as people have repeatedly observed.
Setting "display: table" may seem odd, but it works and fixes Firefox
bug that
lists in RTL display with some floating elements on their left are
outdented,
beyond the page borders (see
https://bugzilla.mozilla.org/show_bug.cgi?id=262195
). This fix doesn't have unexpected affects on unordered lists. It had
some
affects on ordered lists in some older versions of Firefox, but they
don't seem
to occur anymore in newer versions. This is the known fix for the
problem in the
CSS files of RTL wikis (hewiki, arwiki and fawiki all set it this way).
And it doesn't affect other browsers at all either? I'm pretty sure there should be some differences between list-items nested in a table and in a block, like width handling for the container.
At any rate, this should all be carefully explained in comments. Cryptic code like this needs to be well-documented.
Furthermore, since this bug is fixed in Firefox 3.0, I'm not sure fixing
this in
the MediaWiki level is currently necessary. RTL wikis can fix this in
their CSS
files until it is fixed in the browser level, and some of them already
do this.
We maintain fixes for browsers as old as IE5, so it seems appropriate to maintain fixes for FF2. We don't currently have a CSS fixes file for any Firefox version, though, oddly.
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On Feb 9, 2008 2:55 AM, Huji huji.huji@gmail.com wrote:
Hope I've answered it fully.
Sure. Just make sure you write the whole explanation in a comment with the rule. I'd also look into Rotem's suggestion about lists whose display it should not affect.
Btw, do you have any suggestions on how to expand it to other skins?
How about using #content instead of #bodyContent? Of course, River has refused to add a #content div to Modern, so you'll probably have to make a separate hack to its CSS files if you want to fix it as well.
PS: I'm also considering changing the code in a way that it only affects FF2 et al.
I think that would be a good thing.
On Feb 10, 2008 3:13 AM, Simetrical Simetrical+wikilist@gmail.com wrote:
River has refused to add a #content div to Modern
Where and why?
On Feb 10, 2008 3:47 AM, Huji huji.huji@gmail.com wrote:
On Feb 10, 2008 3:13 AM, Simetrical Simetrical+wikilist@gmail.com wrote:
River has refused to add a #content div to Modern
Where and why?
On IRC is where I saw it. As for why, you'd best ask River.
wikitech-l@lists.wikimedia.org