simetrical@svn.wikimedia.org wrote:
--- trunk/phase3/skins/monobook/main.css 2007-09-09 23:58:10 UTC (rev 25705) +++ trunk/phase3/skins/monobook/main.css 2007-09-10 00:45:32 UTC (rev 25706) @@ -114,28 +114,22 @@ h1, h2, h3, h4, h5, h6 { color: black; background: none;
- font-weight: normal; margin: 0; padding-top: .5em; padding-bottom: .17em;
- font-size: 100%;
+}
[snip]
+h1 .mw-headline { font-size: 188%; }
This kind of creeps me out, forcing all headings to have another container to bump the size back out.
It also reduces the spacing, such as at the top of the page, which feels rather cramped.
-- brion vibber (brion @ wikimedia.org)
On 9/10/07, Brion Vibber brion@wikimedia.org wrote:
simetrical@svn.wikimedia.org wrote:
--- trunk/phase3/skins/monobook/main.css 2007-09-09 23:58:10 UTC (rev 25705) +++ trunk/phase3/skins/monobook/main.css 2007-09-10 00:45:32 UTC (rev 25706) @@ -114,28 +114,22 @@ h1, h2, h3, h4, h5, h6 { color: black; background: none;
font-weight: normal; margin: 0; padding-top: .5em; padding-bottom: .17em;
font-size: 100%;+}
[snip]
+h1 .mw-headline { font-size: 188%; }
This kind of creeps me out, forcing all headings to have another container to bump the size back out.
They've had the extra container since I added a wrapper to align the edit link properly. You have a wrapper around the actual heading, a wrapper around the section edit link, and a wrapper around both together.
It also reduces the spacing, such as at the top of the page, which feels rather cramped.
That part kind of sucks. It's frankly a pretty good argument for pixel measurements. To restore old behavior, it would be necessary to manually multiply out the desired figures and set separate paddings/margins for each heading. Or, we could just make them all have the same padding, which should be like 1.5 times current.
There doesn't seem to be any way to get Opera and Firefox to both display the edit sections in consistent sizes using the inherit-and-reverse method, at least without browser-specific fixes. Firefox intelligently keeps pixel sizes to reasonable precision when inheriting, whereas Opera appears to round them down to the nearest pixel internally on every inheritance.
For instance, 12px text at 80% (h6) works out to 9.6 pixels. Opera's Developer Console displays the relevant text as being 9 pixels, and sure enough, the edit section link needs to be jacked up to 134% for it to display at 12px. Sure enough, 9px*134% = 12.06, while 9px*133% = only 11.97. The correct figure is of course 125%, because 125%*80% = 5/4 * 4/5 = 1, and this is how Firefox and IE appear to treat it. Maybe a bad interpretation of the provision that computed values are what are inherited in CSS?
Anyway, I'll just do an Opera-specific fix, since this change is mucking stuff up. But it would be exceedingly handy if we could use the CSS rem unit!
Simetrical wrote:
This kind of creeps me out, forcing all headings to have another container to bump the size back out.
They've had the extra container since I added a wrapper to align the edit link properly. You have a wrapper around the actual heading, a wrapper around the section edit link, and a wrapper around both together.
Well, what about something like this structure which I've floated in previous discussions?
<div class="mw-sectionheader"> <h2>The header part</h2> <span class="editsection">[edit]</span> </div>
The CSS can then make the section-header h*s inline so everything wraps together as desired.
That would allow other uses of headers (say in UI code) to work without being disrupted.
-- brion vibber (brion @ wikimedia.org)
On 9/11/07, Brion Vibber brion@wikimedia.org wrote:
Well, what about something like this structure which I've floated in previous discussions?
<div class="mw-sectionheader"> <h2>The header part</h2> <span class="editsection">[edit]</span> </div>
That's the correct markup that we should have been using all along, yes (although better to use mw-h1, mw-h2, etc. for the wrapper -- in fact necessary to get things like padding to stay like they are now). We had that, and for some reason I thought it was more semantic to have the section edit link inside the h#. Then when it caused problems for screen readers, I tried to revert it, but (of course) it broke all the sites and needed to be backed out.
On 9/10/07, Simetrical Simetrical+wikilist@gmail.com wrote:
Anyway, I'll just do an Opera-specific fix, since this change is mucking stuff up.
You know, I don't think I *can* do an Opera-specific fix. The percentages needed to accurately reverse the size changes on Opera will depend on the base font size, I'm pretty sure.
wikitech-l@lists.wikimedia.org