#289 [log] element inherits weird styling

[Lee Worden]

because the [log] text is inserted into the HTML at the same place as the file it connects to (even though it's displayed over to the right and separate), it gets CSS styling that's applied to whatever elements contain the file.

For instance, if one writes

== <project-file filename="Important file" display=link/> ==

we get, as intended, a header whose text is a link to the file contents. But we also get a [log] element over at the right margin that's extra-big and bold, because it's got the header's styling even though it's displayed elsewhere.

I'm not sure how to fix this, because there's no good way to write css to say inherit certain things (like the styling of the MW page, so it shows up sans-serif, etc.) but not others. I guess I could:

• hard-code all the styling for the [log] part instead of inheriting from the MW page, even though it'll end up looking wrong if the rest of the page gets styled differently in the future
• put the [log] into the html somewhere separate from the project-file output, somehow
• use JavaScript to grab the page's style and apply it directly to this element
• move the element into a different part of the html using JavaScript and let the CSS get sorted out that way
• or something?

[Jonathan Dushoff]

In theory, you should be able to inherit everything, and then override some of it -- that's the whole idea of CSS. Don't know, though, whether that works in this particular case.

[Lee Worden]

Of course, but I don't think you can say "Don't inherit the size from the <h2> you're in, but do inherit it from the <div id="globalWrapper"> that's further up the cascade". You can either say what the size should be, or let it be inherited.

[Lee Worden]

However, I just realized that the [edit] link that the [log] is modeled after actually has the same issue because it is bundled into headers of various levels. I think they handle it by including a list of cases:

h1 { font-size: 188%; }
h1 .editsection { font-size: 53%; }
h2 { font-size: 150%; }
h2 .editsection { font-size: 67%; }
etc.

So editsections ([edit] elements) in headers of various sizes are scaled down the right amount so that they all come out the same size. So I could do that (or I could just use the "editsection" class and get the existing styling tricks??).

[Lee Worden]

It would probably be good to piggyback on the editsection styling rather than mimic it, since it's apparently going to be styled differently in later MW releases: https://meta.wikimedia.org/wiki/Change_to_section_edit_links

[Andrei Akhmetzhanov]

Is it possible just to hide this log-link? (ok, got it)

[Andrei Akhmetzhanov]

just noticing: Contents menu also looks strange in that case

[Lee Worden]

Oh man, that contents thing is even worse! Thanks for showing this to me. I think we need to adopt the editsection styling technique. That would allow saying what the [log] should look like attached to headers of each size (smaller) and what it should look like in a table of contents (not visible).

[Lee Worden]

OK, I don't see any advantage to using "editsection" class for my links, because I want to use some slightly different rules (in the table of contents for example), and because the proposed changes will change the name of the class anyway - so I'll have to change my code no matter what. So I'm leaving it as "ww-altlinks" class.

Header/[log] styling is fixed now, in r1018. The TOC issue is tougher - requires the HTML output to be different. I think I'll wait because it may be easier to fix in MW 1.18+ or whichever, and/or because the asynchronous interface to project files will do these links differently.

I notice there's also a problem with the "WorkingWiki messages" box, which appears all big and boldface if it's connected to a project file in a header. But again, those messages will be handled differently with asynchronous project files.