MediaWiki talk:Gadget-Site.css

Cornerbox

I think the css for #cornerbox should be moved to MediaWiki:monobook.css. This css is used for all skins and places the cornerbox in strange places in other skins (example: featured template in the standard skin). /82.212.68.183 16:47, 3 July 2006 (UTC)

<stabs other skins> I'll tweak the other stylesheets to correct the display later. // [admin] Pathoschild (^talk/_map) 16:55, 3 July 2006 (UTC)

Italic redirects?

I think it could be useful to add style to redirects in Special:Allpages. Maybe italics, like this:

.allpagesredirect {font-style: italic;}

/82.212.68.183 18:59, 11 July 2006 (UTC)

I'll add the style if there's no opposition after a few days. In the meantime, you can customise the stylesheet for yourself by logging in and editing your skin's CSS file; for example, see User:Pathoschild/monobook.css. // [admin] Pathoschild (^talk/_map) 23:04, 11 July 2006 (UTC)

I think that's probably a good idea to distinguish between redirects and actual pages.—Zhaladshar ^(Talk) 23:11, 11 July 2006 (UTC)

I was intending on posting about this myself, but forgot. :) I'm for it. Jude (talk) 23:24, 11 July 2006 (UTC)

.plainlinksneverexpand?

Just a little feature that's useful for suppressing the external link arrow for internal links created using the internal link syntax and the fullurl colon function. See w:MediaWiki:Common.css and its use on w:Template:Intellectual property (the small "edit box" link at the bottom). Not a big deal if people don't want to add this css class to this wiki. —dto 05:17, 10 September 2006 (UTC)

Isn't the existing css class "plainlinks" in the monobook skin enough to suppress the external link arrow. I don't think other skins use any arrows for external links. The "plainlinksneverexpand" class has something to do with printing Template:Ref on Wikipedia. Wikisource has the same (or a similar) template, so maybe plainlinksneverexpand is of use here too. /81.229.40.226 09:07, 10 September 2006 (UTC)

Oops. Thanks very much. Didn't even know .plainlinks existed. w:Template:Intellectual property threw me off; maybe it's using the wrong css class. But it seems .plainlinksneverexpand could still be of use. —dto 17:56, 10 September 2006 (UTC)

removed 2em indent in Page: namespace

I've removed the 2em indent in the Page: namespace; the only way to override this indent is to specify a different indent for every single paragraph separately. This is simply too annoying. Sorry.--GrafZahl (talk) 14:20, 27 July 2007 (UTC)

class lefttext

when the class=lefttext is used, it has a very large top margin. I am wondering why that is as when it is used as the defining class for the page, it starts a page to what seems to be an excessive amount down the page. billinghurst (talk) 21:17, 11 December 2009 (UTC)

Documenting table css

Recently I have been adding some css for tables to the file. Documentation can be found at Wikisource:Style guide/Tables billinghurst (talk) 13:08, 1 January 2010 (UTC)

Page numbers from <page /> don't print well

With .indented-page and the output of the <page /> element, printable view (on Firefox on MacOS) has the page numbers in their little square brackets superimposed over the text; rather ugly. The .indented-page CSS is within an @media rule that excludes print. Perhaps fixing this is as easy as making .indented-page apply to all media? I'd be very grateful if someone could have a look at this! (Especially as the book tool isn't working yet.) Thanks! — Sam Wilson ( Talk • Contribs ) … 09:51, 11 March 2010 (UTC)

Ah, I've just realised that the interferring page numbers are only on the first page of the output. I've no idea why.  :-) — Sam Wilson ( Talk • Contribs ) … 09:57, 11 March 2010 (UTC)

Presume that we are talking <pages />. Do you have an example of a page that you prepared earlier? — billinghurst sDrewth 10:26, 11 March 2010 (UTC)

Right. Yes. I meant <pages />.  :-) And I'll upload a shot of what the output from print preview of Miscellaneous Papers on Mechanical Subjects/A Paper on Plane Metallic Surfaces or True Planes. — Sam Wilson ( Talk • Contribs ) … 10:40, 11 March 2010 (UTC)

Got it. For Firefox (WinDoze) the indented-page displays it similarly for screen in main NS, and printable. I presume that you are saying that the two forms behave differently. — billinghurst sDrewth 11:40, 11 March 2010 (UTC)

Have a look at File:2010-03-11 Print preview of “Miscellaneous Papers on Mechanical Subjects - A Paper on Plane Metallic Surfaces or True Planes".pdf. — Sam Wilson ( Talk • Contribs ) … 12:19, 11 March 2010 (UTC)

Prose

It has been noted by several people that the fixed width and justified text in "prose" classes is not ideal, since the fixed width breaks in narrow browsers and justification is a print-medium technique that is ill-suited to the Internet. I propose a change to:

.prose
{
  padding-left: 3em;
  max-width: 35em;
  margin: 0 auto;
}

The padding prevents page numbers getting overlapped (same as "indented-page"). The max-width limits the length of the text lines on wide screens (a 1200px line of text is, I find, very hard to read), but on narrow screens allows wrapping, unlike a fixed width div as we currently have. The margin setting is unchanged and allows a float to centre, just as we have now. The alignment is now left-justified, with a ragged right margin. You can see an example at here.

Comments or suggestions? Inductiveload—talk/contribs 01:12, 8 June 2010 (UTC)

I like the idea, and think that it can address some of the problems that we have been having. I do believe that we should be less controlling of the right margin, especially around the justification. Is it implemented by all major browsers? Or do we envisage any incompatibility issues? — billinghurst sDrewth 02:18, 8 June 2010 (UTC)

Apparently it works in all major browsers, including IE (which doesn't support inheritance of the value, but we're not doing that), according to this. Tested in Firefox 3.6.3 and Opera 10. Inductiveload—talk/contribs 13:20, 8 June 2010 (UTC)

Update also works in IE 7. Inductiveload—talk/contribs 11:21, 15 June 2010 (UTC)

I say go for it. — billinghurst sDrewth 12:27, 15 June 2010 (UTC)

I agree with the max-width idea, but why do you want to get rid of justification ? ThomasV (talk) 13:51, 15 June 2010 (UTC)

It's not my primary concern: no longer controlling the right margin position is, as well as stopping the overlapping of the page numbers on narrow screens. However, as Billinghurst has noted before (somewhere I can't find right now) justified text is not, in general, the appropriate format for web-based text, since it is primarily done to increase the usage of the page's space, which is what costs in books, at the expense of readability by altering work spacing. We don't have the constraint on the web, and in fact most of our pages are not justified. This is my understanding, at least. If a page absolutely positively needs to be justified, it can always be done by adding to the div style manually. Inductiveload—talk/contribs 13:17, 22 June 2010 (UTC)

see below, but user preferences should not be overridden by User: preference. 13:30, 22 June 2010 (UTC)

Use of max-width is pretty common these days. It's not supported by IE6, not that we should care about that dead browser. A lot of machines have very wide displays these days and we should be using a max-width on a fair number of things; like all pages (but that's another discussion). I'm not much concerned about the justification and it's really a separate issue; mostly I find ragged-right fine. Cheers, Jack Merridew 23:00, 23 June 2010 (UTC)

The reader can adjust the window size to their preference, or change the fount. If the variety of 'right' widths is imposed then one has more scrolling to do, I contend that that also interferes with reading text online. I've an unanswered question on this, and it makes for a interesting thought experiment, why doesn't wikipedia do this? I suspect people have tried, but the default is to let the reader decide. To be blunt, are readers so thick they cannot do something as simple as resizing a window? If they are lucky enough to have a new wide screen, they would quickly learn how to make the tradional 'portrait view' of a page presentable on a 'landscape' screen. Providing the opportunity for Users to choose what looks right for them, 350-800px, by overriding everyone else's preferences was a bad idea. Cygnis insignis (talk) 00:57, 24 June 2010 (UTC)

I agree wholeheartedly with Cygnis. We are taking books and putting them on the web. The medium has changed, for better or for worse. We should be rolling with that, not trying to force our web-pages to take on book-like characteristics like fixed widths. Hesperian 02:21, 24 June 2010 (UTC)

I have listened and respect the opinions for those who want a free right margin, and believe that is what we should do. I have also heard the opinions of others that like the tight and justified right margin, and I don't disagree with their opinion. Both are right. I don't believe that asking people to resize their browser for our pages is the solution however, especially when we should be able to provide a technical solution. One would presume that there is someone clever enough to do coding that would allow people to click between a wider or narrower version of our presented works, and even the possibility for users to set their preferred width(s) as a gadgetised solution, maybe even to present the works justified or not. I would see that this would present users an easier choice, and a flexible choice. — billinghurst sDrewth 02:57, 24 June 2010 (UTC)

I was commenting on the use of max-width, not the specific 35em, which is on the narrow side. I'm on a pretty wide screen, usually, and know to adjust my viewport and zoom, but most on the web do not know this; they just surf with a full-screen view and default settings. It is unwise to expect much from typical readers. The 35em does seem geared towards mimicking a typical book page, and I'm not advocating that, at least not for very wide use. People have trouble reading lines over about 60em; they get lost tracking back to the left of a next line. There's a lot of research in to this out there. Also, the units to be thinking in are 'em', not 'px'. L/R justification really breaks down in narrow columns, resulting in 'rivers' of whitespace running through the text; at wider widths, the effect is less pronounced, although this will vary with the language (i.e. German; long words;).

My comment about whole pages referred to everything — from the logo top-left to the powered-by-mediawiki at bot-right; An awful lot of websites are now enforcing both min and max widths to avoid presenting ridiculously long lines of text to people (including most site I work on). Cheers, Jack Merridew 07:37, 24 June 2010 (UTC)

So is there an upshot to this discussion? I will implement the change I proposed unless there is opposition. I am not changing the width of the prose column for most people, just those for whom it would have run off the right hand side of the screen and overlapped the page numbers. I will also introduce the ragged right-margin, but separately, so it can be easily reverted if people hate it. But note that many online sources use ragged-right, such as BBC News and the New York Times, precisely because it is easier to read when the word spacings aren't all screwy due to automatic justification in a narrow column. Inductiveload—talk/contribs 04:27, 12 August 2010 (UTC)

I don't see any opposition here. Several of us are opposed to the use of this styling class at all, but our reasons for that are unaffected by your proposal. Go ahead and make the change, and we'll continue to hate the class all the same. ;-) Hesperian 04:48, 12 August 2010 (UTC)

Hopefully with a freer right margin, it will only be distasteful rather than hateful. :-p Inductiveload—talk/contribs 06:04, 12 August 2010 (UTC)

Well, for me ragged right margin make sense only for non-constrained width, with class prose the rendering look like really ugly as in this test page. I hope browser will implement hyphenation, it'll fix definitively the problem. Phe (talk) 06:09, 14 August 2010 (UTC)

Not helped by the 'ragged left' margin, created by the insertion of an empty line and an indented first line. This uses wikicode and the indent from a different formatting style redundantly, by repeating, 'new paragraph, newparagraph'. Just like the broken words of the justified blocks crammed onto a printed page, preserving this formatting element is pointless and ungainly. cygnis insignis 13:12, 30 August 2010 (UTC)

Look at the html, this is the standard way to generate paragraph, there is only a <p> in the html. If you think <p> is broken, fix it but don't break other thing as a band aid. I wonder where you can see 'new paragraph, newparagraph', there is not. Indentation is one of the most useful typographic trick to help readers. What you are doing actually is to regressing a lot our quality. Phe (talk) 13:30, 30 August 2010 (UTC)

You miss the point, the 'typographical trick' that 'helps the reader' by indicating a new paragraph. Go to this page, there is no empty line between the end of one paragraph and the beginning of another. The 'meaning' of the indent is 'this is the start of a new paragraph'. A sentence ending in the middle of the page indicates 'the paragraph ends here'. It looks bad because it looks 'good' when the economical printing justified text and broke words with hyphens. We don't don't preserve it, we can arry on getting more text. Don't take my word for it, look at a modern text, we dumped this stuff a hundred.

Good grief, I'm doing what! "push en.ws in the direction of low-cost site and printing,?! I believe that I am producing some of the most well presented works on the site, if you wanted some arcane and pointless legacy of the printed page, you can view them with you preferences. cygnis insignis 14:17, 30 August 2010 (UTC)

Than your works is the best is your personal opinion. Mine is than all work with unconstrained max-width is a poor presentation of works. Did you get than on one side you argue than we are not books sot we don't take care to lost screen space (using bigger line-height to mark paragraph) and on another you are arguing you want utterly wide line because you don't want to lost space? Phe (talk) 14:38, 30 August 2010 (UTC)

It is my preference that every one have their own preference, as at wikipedia, not someone else's. 16:46, 30 August 2010 (UTC)

It has already been said than people use default site preference. What you are doing is forcing all contributors to use your own preference. Phe (talk) 16:58, 30 August 2010 (UTC)

courtopinion class

I would like to suggest a "courtopinion" class to format judicial opinions. I would use the prose class, but I think it is too narrow. Having a separate class will allow us to format to the specific needs of a judicial opinion.

Here is the proposed CSS:

.courtopinion 
{
  padding: 0 15em 0 5em; 
  margin: 0 auto; 
  text-align:justify;
}

Here is a demo, compared to this version of the same opinion without css. The justified text is more readable in my opinion, and it looks more like a printed judicial decision. The right padding distinguishes between the court documents box and the actual text of the court decision. The left padding leaves some space for a page number template (I used template:Left sidenote in the demo above), making it easy for citation (people have appreciated Google Scholar's approach to putting page numbers in the margin). Have any thoughts? Cheers, stephen (talk) 02:37, 15 June 2010 (UTC)

We currently do put page numbers as part of our transclusion using <pages> of ProofreadPage, use of .indented-page, and where they are not of the transclusion, then the page numbers can be created with {{page break}} utilising the 'left' option. Also see Side by side proof reading

As part of the legal aspect, we do indeed need to have a wider margin to make space for sidenotes, and as noted elsewhere putting left and right sidenotes is an ugly look in a webpage, there are a few examples around of legislation with sidenotes.

Justification and right margins. As these are webpages, it has been discussed that we should not be imposing right margins, well we should not be particularly imposing hard right margins, possibly we can set soft right margins (max width), possibility of horizontal scrolling, and there are those who dislike having their right margins dictated. Similarly there are people who see that full justification into webpages is also problematic, and in some cases, it gets bloody ugly as hyphenation is the usual means to control formatting, and with the web and the variation of fonts & sizes in play we cannot typeset exactly enough to manage all displays. — billinghurst sDrewth 12:26, 15 June 2010 (UTC)

I just posted on this elsewhere, as it happens, I said the users are able to apply this as a preference, but not if we impose it. Same goes for width, and there are many ways a user might wish to control that. I honestly find it difficult to read on a screen. And yes, it required careful typesetting and hyphens to stop the 'gutters' appearing in the middle of the text, modern print adopted ragged right margin for good reasons. Cygnis insignis (talk) 13:26, 22 June 2010 (UTC)

Invalid code?

Just a heads-up in case it is important, but the line reading " -webkit-transition: color .2s linear;" (line 11) is flagged as invalid by the W3C CSS Validation Service linked at the top of the page. Inductiveload—talk/contribs 07:31, 12 August 2010 (UTC)

I added that. It's a vendor-specific property ("webkit" means Safari and Chrome); these are pretty common, really, and are about pre-releasing code. Over time, they get full support without the prefixes (which can be kept around a while for people on older versions of browsers. See #css transitions, below, where I'm suggesting more of this. See: w:Progressive enhancement, too. 125.162.150.88 09:40, 13 July 2011 (UTC)

Header template code updates

This point has come up in a few places (Scriptorium and other discussions). I have changed the classes the header templates ({{header}}, {{author}}, {{process header}} and {{portal header}}) to a unified set. Now we have:

General header classes

• gen_header_backlink Right-aligned forelink
• gen_header_title Centred text
• gen_header_forelink Right-aligned forelink

Specific classes for the header tables

These contain the colours for the table background and border. Everything else is handled together for consistency.

• headertemplate
• footertemplate
• authortemplate
• processheadertemplate
• portalheadertemplate

Specific classes for the header tables' notes sections

These contain the colours for the table background and border. Everything else is handled together for consistency.

• header_notes
• author_notes
• process_note
• portal_notes

It should now be easier to add new kinds of header (if we need to) and adjust the styles for all headers globally. Inductiveload—talk/contribs 04:27, 13 August 2010 (UTC)

Not sure what happened but it appears that portal headers are broken; see Portal:Texts by Country. —Spangineer^wp (háblame) 20:04, 13 August 2010 (UTC)

You have the old CSS cached; it should look fine when you clear your cache. Normally CSS changes should not be added to the templates for a few weeks, to make sure visitors have the new CSS before the template changes go live. —Pathoschild 20:22:36, 13 August 2010 (UTC)

Sure enough; purging the page worked. Thanks. —Spangineer^wp (háblame) 21:02, 13 August 2010 (UTC)

Sorry, I didn't know that. Inductiveload—talk/contribs 03:24, 14 August 2010 (UTC)

Changes to headertemplate banner

Recent changes to this file or .js has changed the display of the header banner for main ns pages when transcluding. The template used to produce a full width banner, and now it displays a white gutter for the page numbers. I prefer the banner to run the full width, whether transcluding or not, and was wondering whether we could return that feature. Thanks. — billinghurst sDrewth 16:16, 29 August 2010 (UTC)

And would changes here have broken sidenotes again? (I'm again experiencing the same thing as described here, using either {{page}} or <pages>, at various places (see here and here). —Spangineer^wp (háblame) 18:06, 29 August 2010 (UTC)

Plus I have found that prose and lefttext classes are broken. I will revert at least until issues are sorted and the discussion has been undertaken. — billinghurst sDrewth 04:57, 30 August 2010 (UTC)

Damn it! This was an improvement, it corrected alignment of the whole page and produced a layout that begins to make sense. What the maverick and novel layouts do is produce a 'page within a page', they attempt to go their own way, a perilous path on a collaborative site. There is no reason given for using either class, and sidenotes is an experimental implementation. Who is expected to sort out the issues these produce, we can't accommodate every users theory on layout.

Millions of pages, millions of readers, yet wikipedia doesn't force a layout - answer that before insisting on a Right to have the grotesque left text or forcing width or justification. cygnis insignis 08:12, 30 August 2010 (UTC)

Cygnis, whether you think lefttext and prose are ugly, or whether they are forced upon people is actually not relevant to this situation. Adding your colourful adjectives is also not helpful to getting a consultative solution, it seems more to degrade. These classes are long existing formats, and they should not have been nullified without consultation or a solution provided. I would argue that the solution should be arrived at and implemented prior to the conversion. I would also argue that there are valid uses of these templates, and ask that the discussion takes precedence to the changes. If my revision is to the wrong place, then we can correct it to a more appropriate place, the difficulty is that the recent changes have been made without commentary and note which adds an element of difficulty, and I think that a better practice of annotation changes would have been useful. When the changes have been made, the why and wherefore have not been evident. At least my changes have been noted and able to be commented upon, rather than undertaken in isolation without notification. — billinghurst sDrewth 16:14, 30 August 2010 (UTC)

Would it not make sense to at least give us time to agree that sidenotes should be scrapped, so that we can avoid complaints like this? —Spangineer^wp (háblame) 11:52, 30 August 2010 (UTC)

Meh, looks like sidenotes is still not working. —Spangineer^wp (háblame) 12:50, 30 August 2010 (UTC)

Then perhaps we should restore Thomas' improvement? cygnis insignis 12:59, 30 August 2010 (UTC)

[ec]I don't think side note should be scrapped, but it is a recent implementation and under development. Conceptually and, I suspect, technically, the problems arise from creating a new wrapper with the standard one: the page within a page. The left/right slim column created in the Page:ns for the label/note should display in a left column beside the new gutter, if it is this simple there should be no need to use anything other than the default 'indented class'. What made the layout coherent was reverted because it broke an experimental template, that it needed a different approach was identified before these changes. cygnis insignis 12:59, 30 August 2010 (UTC)

The same problem that recently came to light regarding transcluded page breaks causing a "break" of searchable terms also exists in the current application of side notes. Since these side notes are frequently tied to specific and proper terms & such in a large swath of government or legal works, breaking the target in the main body defeats non-WS reader accessibility by baring it from being a hit when searched. I'm reluctant to incorporate side notes until at least this basic issue is also addressed. George Orwell III (talk) 14:34, 30 August 2010 (UTC)

With regard to sidenotes. There are several discussions around the place, and several discussions about left and right side. Due to concerns raised by Cygnis insignis about forced widths on right hand margins, I have moved my sidenotes to the left hand side to allow a dynamic right margin. You can see the results of my trials at works such as 1836 (33) Registration of Births &c. A bill for registering Births Deaths and Marriages in England, and after the recent changes to page numbering, I had to add an extra <div> wrapper around the outside to push the page numbering wider. — billinghurst sDrewth 16:25, 30 August 2010 (UTC)

That looks wonderful! - though the embedded page links stopped working for me 2 or 3 revisions ago anyway. It is not a good example, however, of what I was talking about since the side notes are always at the start of the associated content paragraphs and are all (save Preamble) strictly the section codification titles in this case. Most instances, folks arbitrarily place the side note according to its perceived physical position when viewing the scanned page in question rather than with its intended target within the main content (it may look right until you switch up font sizes and browser windows in short).

The real problem I was getting at is when one properly places the Side Note template within the main content according to the intended target it is meant to 'give note' to. When transcluded, and when peppered throughout the paragraph and not just at the paragraph start, the intended notable target within the main no longer remains a searchable term when it obviously should be one.

As for the fixed margin thing - for me, the bulk of the works where it is required for such side note citations is not going to be poetry - its mostly legal-ish stuff. Such standardization, like fixed margin widths, are prefered if not simply desired. Apparently, this sub-set of works will not easily align its layouts with some of the other types on this point. George Orwell III (talk) 17:10, 30 August 2010 (UTC)

It is worth having, and that idea is right I think, but we need take a fresh look at. Can't we create a new column in the Page:ns? Relevant here: Is there a reason why can't have the improvement restored? cygnis insignis 16:35, 30 August 2010 (UTC)

I would agree that the sidenotes needs rewriting. It wasn't written with the transclusion of the Page: namespace in mind and it seems a cludgy hack. It is why I implemented {{outside L}}/{{outside RL}} pair, which I have just realised that I didn't document and doing so now. — billinghurst sDrewth 17:04, 30 August 2010 (UTC)

In my opinion (and from what I have gleamed to date) the entire side note endeavour makes applying them more complicated than it probably should have been. A side note note is nothing more than an anchored footnote, minus the reference symbol or number, that is displayed in the margins rather than at the bottom. A comparible symbiotic interaction similar to the one {{ref}} & {{note}} share might have made for more interesting approach allowing the "note" to float with in the margins while still anchored to its target regardless of margin width, style, etc. George Orwell III (talk) 17:32, 30 August 2010 (UTC)

That is essentially what they do now. it is the combination and interplay of relative/absolute method of positioning that causes a few issues for the older template. What I did with {{outside}}, a span of text, that floats to the left, with some controlability. Only floating to the left makes display easier in main ns. [{{outside L}} cheats, for display purposes, in the Page namespace by using {{left sidenote}} and its own code for transclusion, similarly {{outside RL}} uses {{right sidenote}}] — billinghurst sDrewth 18:00, 30 August 2010 (UTC)

Again quite nicely done.

Getting back to Spangineer's concern about the improperly displaying side notes, would it be possible to disable them, temporarily, in transclusions somehow? Seems like some changes in the CSS breaks them so my simpleton reasoning makes me believe there must be some combination of settings that could keep them from appearing upon transclusion (if one chooses) altogether. George Orwell III (talk) 18:48, 30 August 2010 (UTC)

sorry, I’ve been afk. No wonder the sidenotes template is broken ; this template needs to be adapted to the various possible layouts. It is possible to have it display a sidenote on the right of the text column when there is a text column, and to display the note else elsewhere (for instance in a floating box) when there is no column. ThomasV (talk) 12:57, 31 August 2010 (UTC)

I have adapted the dynamic layouts to sidenotes at fr.ws. Sidenotes are now rendered in a layout-dependent manner. See here for an example. ThomasV (talk) 15:22, 14 September 2010 (UTC)

Standard pages look ratty, the glimpse I had of the new changes seemed to resolve this. If this 'side issue' is resolved, can we have the rest of the changes implemented. cygnis insignis 15:47, 14 September 2010 (UTC)

This is not a technical problem, but more a problem of how community decision are taken at en.ws. I have been reverted by sDrewth, for reasons that are certainly bad, but the fact is that this revert did not cause any protestation. Therefore I will not re-enable this myself. ThomasV (talk) 17:26, 14 September 2010 (UTC)

I protested, and posed the question, "Is there a reason why can't have the improvement restored?" There being no further reasons given, and having received no answer except on the side issue, restoring it would be unobjectionable. I will restore, please check what I do. cygnis insignis 17:38, 14 September 2010 (UTC)

I would agree with ThomasV that this is a bit of an issue for enWS, and I would also say that the changes that were made without consultation with the community, without documentation within edit summaries to allow informed reversion points was less then ideal. There were comments made here and Scriptorium that there were problems with the changes, yet the person who made the changes was not around to have the discussion, so at the time a reversion was the only option available. So while maybe the reversion point was considered imperfect, however, look at the whole picture, the options available, not the one action.
I do not agree that solely reverting back to the last place is the answer either and feel that the actions taken by immediately reverting are more imposing only that one view on one set of changes without resolving other issues that have been raised. I hope that we can now have a proper discussion, and practices that allow a wholistic management of the styles.— billinghurst sDrewth 23:24, 14 September 2010 (UTC)

I understand your point of view. I have been unavailable for 2 weeks, and there is no documentation for the moment. However, you cannot expect me to improve something if you revert what I do.

Concerning the management of styles, I think that we first need to know what the community wants. There are 2 questions :

1. is there community support for dynamic layouts ?
2. what particular style properties do we want to implement in these layouts ?

Concerning the first question, I think that form should be, whenever possible, separated from content. This is the reason why I implemented these dynamic layouts : they force you to separate form from content. However, some contributors might not accept the idea, because they are no longer free to enforce a particular style (see this comment, 2nd part). In contrast, this solution gives more freedom to end users, who are free to define the layout that best suits their needs. Thus, this question is very much about who should decide how a text is rendered.

Concerning the second question (style), I have no particular preferences. I will provide some documentation, so that you can work on this more easily.

ThomasV (talk) 08:04, 15 September 2010 (UTC)

Will this work all browsers of the day or is it tailored to only some? Which ones? George Orwell III (talk) 08:40, 15 September 2010 (UTC)

How am I supposed to answer this question ? "tailored" suggests that incompatibilities are being introduced on purpose. ThomasV (talk) 15:39, 16 September 2010 (UTC)

Didn't mean to imply anything of the sort - forgive me for that. I only asked because I recall a testbed that lacked I.E. as part of your array was all. It goes to the point earlier about how rough the changes being made are swallowed by users as a whole I guess. George Orwell III (talk) 21:35, 16 September 2010 (UTC)

if is practically impossible to guarantee that a script will behave correctly in all browsers. All we can do is fix problems as we notice them. To request a guarantee that everything will work everywhere is a good way to make any improvement impossible. ThomasV (talk) 09:33, 17 September 2010 (UTC)

Fine - I'm a realist. One's improvement at the expense of another's functionality cannot be avoided in every case I suppose. All I ask for is a little more discussion on whatever changes are to come and the continued attempt at some sort of balance balance between the two extremes. George Orwell III (talk) 10:10, 17 September 2010 (UTC)

Hide TOC numbers

As requested here, please add

span.tocnumber { display:none;}

Laws and even books like Thus_Spake_Zarathustra/Part_One will have a nicer TOC. Giro720 (talk) 03:15, 17 December 2010 (UTC)

Done — billinghurst sDrewth 12:50, 19 December 2010 (UTC)

css transitions

{{editprotected}} -- implemented by User:Billinghurst

Safari was early:^diff

/* make Safari moar-kewl */
a:link,
a:visited {
 -webkit-transition: color .2s linear;
}

more browsers now support this, so the above should be replaced with the following:

/* make user experience moar-kewl */
a:link,
a:visited
{
 -webkit-transition: color 0.4s ease;
    -moz-transition: color 0.4s ease;
      -o-transition: color 0.4s ease;
         transition: color 0.4s ease;
}

The 0.2s/0.4s is aesthetic; linear/ease, too. The idea here is that when you click a link to open in a new tab, it changes color... gently, instead of abruptly. Could work on all wikis, including benighted ones. 125.162.150.88 09:40, 13 July 2011 (UTC) (nb: the offset braces are *so* 70s ;)

I'll elaborate, a bit. CSS Transitions allow properties to change non-instantaneously; this is usually viewed as aesthetically more pleasing. The change to 0.4s from 0.2s seems better to me in uses I've made of this since the original was added here; the 'ease' is nicer, too (it's an 'S' curve). The above will make this work in most browsers. If consensus is against this; fine; ya should prolly lose the webkit-specific rule as well, in that case. I was also User:The Inheritance of Loss; feel free to delete it, block it, tar-and-feather it... Ya might read it, first. It's from the ending of w:The Inheritance of Loss, by Kiran Desai; a few lines before this is another key theme: is was time for "Sai" to leave. I have seven years invested in WMF, so leaving is hard. But I don't believe the projects are succeeding, so I've given up. I expected a hey, that's neat Jack, thanks! Instead a typical wiki-squawk occurred. 125.162.150.88 09:40, 13 July 2011 (UTC)

Done already. -- George Orwell III (talk) 09:50, 13 July 2011 (UTC)

I'd missed that. (no watchlist;). No hard feelings, here. I'm quite tempted to just go cut all the noise on your reconfirmation; I do BOLD and IAR a lot. Jack 09:57, 13 July 2011 (UTC)

Protocol independence

If someone could change

 background: url(http://upload.wikimedia.org/wikipedia/commons/thumb/b/b6/Paragraph-mark.svg/6px-Paragraph-mark.svg.png) 0 .3em no-repeat;

to

 background: url(//upload.wikimedia.org/wikipedia/commons/thumb/b/b6/Paragraph-mark.svg/6px-Paragraph-mark.svg.png) 0 .3em no-repeat;

I think we'd have https working properly everywhere throughout the site. Prosody (talk) 23:12, 16 October 2011 (UTC)

Done - then again... I did manage to clip the last edit didn't I? Respectfully ask for a more diligent follow-up this time. -- George Orwell III (talk) 23:24, 16 October 2011 (UTC)

Looks right, and my browser isn't reporting an insecure content problem any more. Prosody (talk) 01:08, 17 October 2011 (UTC)

Edit request (limiting scope of Main Page header hiding)

Hi. Please make the following change:

Current content:

body.page-Main_Page .firstHeading,
body.page-Main_Page #siteSub
{
 display: none;
}

New content:

body.page-Main_Page.action-view .firstHeading,
body.page-Main_Page.action-view #siteSub
{
 display: none;
}

This will limit the Main Page header hiding to only (the implicit) action=view, allowing the title to be shown for other actions such as action=history, action=info, etc. Similar changes have already been made at Meta-Wiki and the English Wikipedia. Thank you! --MZMcBride (talk) 18:46, 9 January 2013 (UTC)

Done AdamBMorgan (talk) 19:40, 9 January 2013 (UTC)

Sweet, thanks! --MZMcBride (talk) 07:53, 15 January 2013 (UTC)

Updated common.css: hlist

There have been updates to the .hlist class, with a request to update at meta

• the script now housed at mw:Snippets/Horizontal lists for easier reference
• so updated code, and I have put start and end markers to make it easier to cut and paste
• also puts in some modifications for IE, which means having to import a script via MediaWiki:Common.js
• the modifications in the created file MediaWiki:Common.js/IEFixes.js

— billinghurst sDrewth 12:42, 27 January 2013 (UTC)

External links icons removed

Hello! If this CSS adds or modifies icons shown after external links, you'll be interested in knowing that such icons have been removed from MediaWiki core, a change which will reach this wiki in few days. You may want to consider whether you still need them. If you have questions, please ask at bugzilla:63725. Regards, Nemo 09:45, 10 April 2014 (UTC)

need to update Css Image crop styles

Template:Css image crop positioning is not working as styles such as thumbcaption, thumbinner, thumb, left etc, are not present in the default style sheet used by Medaiwiki on Wikisource --Arjunaraoc (talk) 04:15, 18 April 2014 (UTC)

• Problem traced to an outdated code in template. Updating fron en.wikipedia.org solved the problem.--Arjunaraoc (talk) 04:35, 18 April 2014 (UTC)

border-box * selector needs to be removed

Using the * selector means you are targeting elements that you don't own. This will break various extensions including OOUI widgets and VisualEditor. This has been filed on phabricator: https://phabricator.wikimedia.org/T133152 ESanders (WMF) (talk) 14:22, 20 April 2016 (UTC)

@ESanders (WMF): This is something that we should fix here? Could you be kind enough to suggest a remedy if we need to fix the css locally? — billinghurst sDrewth 22:47, 20 April 2016 (UTC)

Done to avoid the inevitable disagreements (if nothing else). Right to revert reserved as future developments may or may not dictate however (ie OOUI-based themes/extensions aren't exactly free from needing further refinements as well :). -- George Orwell III (talk) 04:42, 21 April 2016 (UTC)

Thanks. I can't see in which circumstance you would revert though, issues with OOUI shouldn't be fixed with on-wiki CSS. ESanders (WMF) (talk) 08:11, 21 April 2016 (UTC)