Hi everyone,
One thing we're struggling with right now is getting a chunk of the Flagged Revs UI to look right. None of us working on Flagged Revs right now are CSS gurus, and the people that we have at Wikimedia Foundation that are really good with CSS are buried in other work, so we could really use some help.
What we're struggling with is that the "[review pending revisions]" with the little lock icon beside it to look right in a cross-browser and cross-skin fashion. A couple of the problems we're seeing: 1. In Vector, the placement of the text can be too high or too low, depending on the browser in use 2. In Monobook, the problem is even worse. For example, in Chrome on Linux, the text hovers way up above article, covering up the "My contributions" link, for example
You can see all of this in action here: http://flaggedrevs.labs.wikimedia.org/wiki/Backmasking
..and there are screenshots of the problem here: http://www.pivotaltracker.com/story/show/2937207
Is there anyone here who can look at the CSS and offer up a better version of what's there?
Rob
2010/5/28 Rob Lanphier robla@wikimedia.org:
..and there are screenshots of the problem here: http://www.pivotaltracker.com/story/show/2937207
For some reason that won't let me click on the screenshots. It shows a hand when hovering over them, but clicking simply doesn't do anything (using FF 3.6 on Linux). Could you just put these screenshots somewhere else, e.g. on a wiki?
Roan Kattouw (Catrope)
2010/5/28 Rob Lanphier robla@wikimedia.org:
Is there anyone here who can look at the CSS and offer up a better version of what's there?
I think I've discovered the main problem.
The div with the lock icon (div#mw-fr-revisiontag) is positioned with position: absolute; . This doesn't really mean it's gonna be positioned with absolute coordinates, but it means it'll be postitioned relative to the closest parent element that has a position: property set. In Monobook, this is div#content, whereas in Vector this is div#bodyContent (a child of div#content). Because there are children of div#content preceding div#bodyContent (div#siteNotice and h1#firstHeading), they start at different heights, so the same CSS (something like position: absolute; top: -2.5em;) will cause the icons to be positioned differently in each skin.
The way I see this (and, mind you, I'm not a CSS ninja at all, just someone with a more-than-basic knowledge of CSS), there's two ways to solve this (assuming you want the lock icon to be next to the page title, above the horizontal line):
1) Use different positioning offsets for each skin. This is ugly, but will probably work. For Monobook, top: 3.6em; seems to work for me, whereas on Vector, top: -2.5em; produces the same effect. You can do skin-specific CSS with rules like body.skin-monobook .flaggedrevs_short { top: 3.6em; } , but again, you don't want to be doing this (there's another half dozen skins out there) and I have no idea whether these offsets will work well in other browsers.
2) Move div#mw-fr-revisiontag to just before or just after h1#firstHeading and position it right from there. That way you're sure the closest positioned parent will be div#content, but it's probably even easier to position it relatively.
Roan Kattouw (Catrop
Hi Roan,
Thanks for looking into this! More below:
On Fri, May 28, 2010 at 3:02 AM, Roan Kattouw roan.kattouw@gmail.comwrote:
The way I see this (and, mind you, I'm not a CSS ninja at all, just someone with a more-than-basic knowledge of CSS), there's two ways to solve this (assuming you want the lock icon to be next to the page title, above the horizontal line):
- Use different positioning offsets for each skin. This is ugly, but
will probably work. For Monobook, top: 3.6em; seems to work for me, whereas on Vector, top: -2.5em; produces the same effect. You can do skin-specific CSS with rules like body.skin-monobook .flaggedrevs_short { top: 3.6em; } , but again, you don't want to be doing this (there's another half dozen skins out there) and I have no idea whether these offsets will work well in other browsers.
I think this is the crux of the problem. From what Aaron tells me, Monobook and Vector are already using different offsets here. I've not had a chance to do a deep dive myself, so that I think you've identified what's the most challenging here. This is one of those areas in CSS where different browsers handle things very differently, so getting this right has been a bit of a mess.
At any rate, thanks again for looking, and if you have more ideas or do more digging, please let us know. Aaron and Adam (from the Usability team) are hopefully going to get a chance to look at this in more detail next week, but I'm sure they'd be delighted if someone figures out the right way of dealing with this before then.
Rob
Why do you need to use CSS absolute positioning? Since it's output from an extension, you could place it on an appropiate place outside the bodyContent.
On Fri, May 28, 2010 at 12:43 AM, Rob Lanphier robla@wikimedia.org wrote:
What we're struggling with is that the "[review pending revisions]" with the little lock icon beside it to look right in a cross-browser and cross-skin fashion. A couple of the problems we're seeing:
- In Vector, the placement of the text can be too high or too low,
depending on the browser in use 2. In Monobook, the problem is even worse. For example, in Chrome on Linux, the text hovers way up above article, covering up the "My contributions" link, for example
Try just putting your div right before the <h1 id="firstHeading"> or equivalent, and float: right it. You can put some margins or padding on the top and/or right to adjust it a bit if you like. Something like that should work. This will be much more reliable than trying to absolutely position it, because different skins will use different heights, and the heights won't be consistent at all in the face of things like site notices.
On Fri, May 28, 2010 at 6:53 PM, Rob Lanphier robla@wikimedia.org wrote:
I think this is the crux of the problem. From what Aaron tells me, Monobook and Vector are already using different offsets here. I've not had a chance to do a deep dive myself, so that I think you've identified what's the most challenging here. This is one of those areas in CSS where different browsers handle things very differently, so getting this right has been a bit of a mess.
This is CSS 2.1. All browsers we care about should handle it interoperably except for possibly IE 6 and 7. I see pixel-perfect identical results in recent Firefox, Opera, and Chrome on Linux for your Backmasking page. I even booted to Windows to check in IE8, and that was basically identical, just as it should be. (Not quite pixel-perfect, but seemingly only because different fonts were used.) Only in IE6 does it look correct -- in all the others it's mispositioned in exactly the same way.
You're not developing for IE6 and then trying to port to other browsers, are you? You should be doing the reverse.
At 2010-05-30 17:45, Aryeh Gregor wrote:
On Fri, May 28, 2010 at 12:43 AM, Rob Lanphierrobla@wikimedia.org wrote:
What we're struggling with is that the "[review pending revisions]" with the little lock icon beside it to look right in a cross-browser and cross-skin fashion. A couple of the problems we're seeing:
- In Vector, the placement of the text can be too high or too low,
depending on the browser in use 2. In Monobook, the problem is even worse. For example, in Chrome on Linux, the text hovers way up above article, covering up the "My contributions" link, for example
Try just putting your div right before the<h1 id="firstHeading"> or equivalent, and float: right it. You can put some margins or padding on the top and/or right to adjust it a bit if you like. Something like that should work. This will be much more reliable than trying to absolutely position it, because different skins will use different heights, and the heights won't be consistent at all in the face of things like site notices.
I agree. Don't use CSS for positioning if you can do it better. Except for the problems mentioned by others there is a box model problem: http://en.wikipedia.org/wiki/Internet_Explorer_box_model_bug Which might be a problem as #content has padding.
Regards, Nux.
On Sun, May 30, 2010 at 12:20 PM, Maciej Jaros egil@wp.pl wrote:
I agree. Don't use CSS for positioning if you can do it better. Except for the problems mentioned by others there is a box model problem: http://en.wikipedia.org/wiki/Internet_Explorer_box_model_bug Which might be a problem as #content has padding.
We don't render in quirks mode and don't really care about anything before IE6, so thankfully, we don't have to worry about that.
At 2010-05-30 18:55, Aryeh Gregor wrote:
On Sun, May 30, 2010 at 12:20 PM, Maciej Jarosegil@wp.pl wrote:
I agree. Don't use CSS for positioning if you can do it better. Except for the problems mentioned by others there is a box model problem: http://en.wikipedia.org/wiki/Internet_Explorer_box_model_bug Which might be a problem as #content has padding.
We don't render in quirks mode and don't really care about anything before IE6, so thankfully, we don't have to worry about that.
Hm... Indeed... Weird. I haven't noticed that Wiki is shown in compatibility view just because of the by domain settings... That alone at least doesn't change much in horizontal positions of elements (only the search bar seems to be affected).
Still, using CSS for positioning is always risky unless an element to be positioned is anchored inside an element over which you want to position it.
Regards, Nux
On Mon, May 31, 2010 at 1:38 AM, Maciej Jaros egil@wp.pl wrote:
Hm... Indeed... Weird. I haven't noticed that Wiki is shown in compatibility view just because of the by domain settings... That alone at least doesn't change much in horizontal positions of elements (only the search bar seems to be affected).
The site might be in IE7 compatibility mode, but it still should use correct box widths.
Still, using CSS for positioning is always risky unless an element to be positioned is anchored inside an element over which you want to position it.
More precisely, absolute positioning is only a good idea if a) you know for sure which element will act as the anchor, and b) really want a fixed offset from the borders of that element without regard to any other elements that may be present. Neither one of those two seems to be the case here, so absolute positioning doesn't seem ideal.
wikitech-l@lists.wikimedia.org