MediaWiki talk:Common.css/Archives/2008

From Meta, a Wikimedia project coordination wiki

Wikitable borders in email and outside web pages

Later note: Let me summarize this. The standard table created by the table button in the Wikipedia editing form does not add the necessary bit of code to solve this problem. So the tables lose their borders when pasted into web pages, blogs, or email. A jumbled mess.

I noticed that the table borders disappear when wikitables are pasted into email and web page editors.

For class="wikitable" tables could border="1" be added to the table header in the HTML of the wiki article itself instead of to CSS?

For example; the wikitable template would produce this in the article HTML:

<table class="wikitable" border="1">

Then wikitables would be much more useful to the world. People paste all, or part of, wikipedia articles frequently into email or web page editors. Right now the tables end up without borders in email, and in many web pages, because many people do not want to use CSS to define class="wikitable".

Wikipedia images can't or shouldn't be hotlinked, I believe. So image tables may not show up in email either. It is even less likely that the image tables would show up in email archives. Wikipedia is more likely to block hotlinking to those locations probably. See commons:Commons:Reusing content outside Wikimedia#Hotlinking

Therefore it is important that HTML tables show up with borders. Otherwise an important aspect of info presentation (tables) will not be shared much via wikipedia.

Please see the wikitable below the image table on this image description page:

Here is an example of how that wikitable shows up in email:

---

Number of persons held in State or Federal prisons or in local jails, 1995-2005
    Prisoners in custody    
Year Total inmates in custody Federal State Inmates held in local jails Incarceration ratea
1995 1,585,586 89,538 989,004 507,044 601
2000b 1,935,753 133,921 1,176,269 621,149 683
2001b 1,961,247 143,337 1,180,155 631,240 685
2002b 2,033,331 151,618 1,209,640 665,475 701
2003b 2,081,580 161,673 1,222,135 691,301 712
2004b June 2,129,802 169,370 1,239,656 713,990 725
December ... 170,535 1,244,311 ...
2005b June 30 2,186,230 175,954 1,255,514 747,529 738
Percent change,
6/30/04-6/30/05
2.6% 3.9% 1.3% 4.7%
Average annual change,
12/31/95 - 6/30/05
3.4% 7.4% 2.5% 3.9%
Note: Jail counts are for midyear (June 30) and exclude persons who were supervised outside of a jail facility. State and Federal prisoner counts for 1995-2003 are for December 31.
...Not available.
aPersons in custody per 100,000 residents in each reference year.
bTotal counts include Federal inmates in non-secure privately operated facilities: 6,143 in 2000, 6,192 in 2001, 6,598 in 2002, 6,471 in 2003, 6,786 (June) and 7,065 (December) in 2004, and 7,233 in June, 2005.

---

This change would make no difference in how readers would see the wikitable on wikipedia pages. It would still look exactly the same as before:

Number of persons held in State or Federal prisons or in local jails, 1995-2005
    Prisoners in custody    
Year Total inmates in custody Federal State Inmates held in local jails Incarceration ratea
1995 1,585,586 89,538 989,004 507,044 601
2000b 1,935,753 133,921 1,176,269 621,149 683
2001b 1,961,247 143,337 1,180,155 631,240 685
2002b 2,033,331 151,618 1,209,640 665,475 701
2003b 2,081,580 161,673 1,222,135 691,301 712
2004b June 2,129,802 169,370 1,239,656 713,990 725
December ... 170,535 1,244,311 ...
2005b June 30 2,186,230 175,954 1,255,514 747,529 738
Percent change,
6/30/04-6/30/05
2.6% 3.9% 1.3% 4.7%
Average annual change,
12/31/95 - 6/30/05
3.4% 7.4% 2.5% 3.9%
Note: Jail counts are for midyear (June 30) and exclude persons who were supervised outside of a jail facility. State and Federal prisoner counts for 1995-2003 are for December 31.
...Not available.
aPersons in custody per 100,000 residents in each reference year.
bTotal counts include Federal inmates in non-secure privately operated facilities: 6,143 in 2000, 6,192 in 2001, 6,598 in 2002, 6,471 in 2003, 6,786 (June) and 7,065 (December) in 2004, and 7,233 in June, 2005.

People would still see the above table on wikipedia pages. Here below is one variation of what people would see in email, and outside web pages, by adding border="1"

Number of persons held in State or Federal prisons or in local jails, 1995-2005
    Prisoners in custody    
Year Total inmates in custody Federal State Inmates held in local jails Incarceration ratea
1995 1,585,586 89,538 989,004 507,044 601
2000b 1,935,753 133,921 1,176,269 621,149 683
2001b 1,961,247 143,337 1,180,155 631,240 685
2002b 2,033,331 151,618 1,209,640 665,475 701
2003b 2,081,580 161,673 1,222,135 691,301 712
2004b June 2,129,802 169,370 1,239,656 713,990 725
December ... 170,535 1,244,311 ...
2005b June 30 2,186,230 175,954 1,255,514 747,529 738
Percent change,
6/30/04-6/30/05
2.6% 3.9% 1.3% 4.7%
Average annual change,
12/31/95 - 6/30/05
3.4% 7.4% 2.5% 3.9%
Note: Jail counts are for midyear (June 30) and exclude persons who were supervised outside of a jail facility. State and Federal prisoner counts for 1995-2003 are for December 31.
...Not available.
aPersons in custody per 100,000 residents in each reference year.
bTotal counts include Federal inmates in non-secure privately operated facilities: 6,143 in 2000, 6,192 in 2001, 6,598 in 2002, 6,471 in 2003, 6,786 (June) and 7,065 (December) in 2004, and 7,233 in June, 2005.

It is not as pretty as what the full CSS produces, but at least it is a legible table with borders. --Timeshifter 16:13, 31 March 2008 (UTC)

Here is another example. See the list table in this page:
w:List of countries by tax revenue as percentage of GDP
I added border="1" to the table wikicode. See this version diff: [1] Try pasting the table into email, or into web page editors. The table looks fine. Try pasting the previous version of the table into email to see the problem. You will see what I mean.
It could take me a few years to add border="1" manually to all the tables on wikipedia pages. Thus the need for border="1" to be added by the mediawiki software to all the tables using the standard table format for class="wikitable" --Timeshifter 22:36, 19 April 2008 (UTC)
I really don't think it's possible to have the MediaWiki system change the HTML code output based solely on a CSS class; just on its own, the two are very different beasts (the key to good web production is to separate out presentational markup from the functional markup of a site), and then there's the matter of the MediaWiki system not knowing the difference between a "wikitable" class and a "wikiable" class. If a border value of 1 can be overridden by the style sheet, then it might be better/simpler/more efficient to just have the system output tables with a border of 1 and turn it off in the CSS instead, but even that could cause mayhem for any table-based template that doesn't bother to specify a border at all.
However, this might all be a moot point; the whole border/no border thing is dependent upon the user's OS, web browser, and what they're pasting into. For example, I'm copying out of Safari 3.1 on a Mac running OSX 10.4.11, pasting into a new email in Mail; both tables in the email look exactly the same as they do in Safari; when I do the exact same thing but copying from 2.0.0.11, both tables lack any border at all. When I copy out of Safari and paste into BBEdit, the table loses all formatting (listing it all cell by cell) regardless of which version I copy, whereas when I copy it from Firefox, I get a tab-delimitated version, also regardless of which version I copy.
This could all be done and it cause very little effect for anyone that has a different setup than yours. There's also the matter of how often do people copy and paste entire tables? Outside of this example, I've never thought about doing so, though I'll admit that I'm not 100% representative of everyone. EVula // talk // // 23:50, 19 April 2008 (UTC)

(unindent) Thanks for responding. And thanks for the effort. I am using Windows XP Home (fully updated) and the latest Firefox 2.x browser. I also use MS Internet Explorer (latest one) sometimes. I am pasting into Google Mail and Yahoo Mail. I am also pasting into a WYSIWYG web editor, Frontpage 2003. I saved the Frontpage web page to my desktop, and opened it in both browsers.

Please don't copy from the above tables. I may not have explained well what I did with them. For consistency and to make things simple please use the table from here: w:List of countries by tax revenue as percentage of GDP. Here is the diff [2] for the 2 versions below:

I am copying the line of text above and below the table also, in order to get the full table formatting. I am copying from the web page, and not the wikicode. I just retested all of the above. In all cases I end up with borders (for the table and the cells within it) when copying and pasting from 1. I end up without borders when copying and pasting from 2.

I do not pretend to understand the ins and outs of CSS, or how mediawiki renders tables into HTML. I am just trying to figure out a way to get the borders to show up when standard wikitables are copied and pasted into email and web pages. Without having to set up CSS. People can't set up CSS for email. And many don't get it right in web pages and blogs.

Many, many people paste wikipedia pages into email and blogs. Public email archives such as Yahoo Groups, etc. keep such email available to others later. I moderate some Yahoo Groups. Many people combine bits and pieces of various wikipedia pages into email, blogs, web pages, etc. It is a shame that the tables get mangled when copied elsewhere.

Maybe eventually the mediawiki software will need to be changed so that a 1-pixel border is the default setting for all tables, not just ones using class="wikitable"

Then MediaWiki:Common.css would only need to change the border width for those table classes with different border widths, or no borders. Here is the table produced by the wikipedia table button (found in the wikipedia edit window):

header 1 header 2 header 3
row 1, cell 1 row 1, cell 2 row 1, cell 3
row 2, cell 1 row 2, cell 2 row 2, cell 3

Here is the wikicode for it:

{| class="wikitable"
|-
! header 1
! header 2
! header 3
|-
| row 1, cell 1
| row 1, cell 2
| row 1, cell 3
|-
| row 2, cell 1
| row 2, cell 2
| row 2, cell 3
|}

Here is the table without class="wikitable":

header 1 header 2 header 3
row 1, cell 1 row 1, cell 2 row 1, cell 3
row 2, cell 1 row 2, cell 2 row 2, cell 3

So the current default for "classless" wikipedia tables is for no borders. Tables would be more widely copied if mediawiki rendered the root table template ...

{| 
...
|}

with border="1" added at the HTML level of the final page, not in the wikicode.

I probably need to summarize all this, and ask for comments at en:MediaWiki talk:Common.css too. --Timeshifter 21:59, 20 April 2008 (UTC)

Note: At one point (August 2008) this was fixed. See:
en:MediaWiki talk:Common.css/Archive 5#Wikitable borders without CSS --Timeshifter 15:24, 14 August 2009 (UTC)

Common.css on Mt.wiki

Hi there, trying to figure out this on my own, I'm now a bit baffled. At some point common.css was deleted on mt.wiki by the maintenance script. (cf. http://mt.wikipedia.org/w/index.php?title=MediaWiki:Common.css&action=history ). The message says no longer required. From where is the system supposed to draw the stylesheet - which it apparently isn't - instead?. On request of a user, I rolled back the empty stylsheet and copied over the missing rules he needed. Of course I'm missing rules too but before copying over all the rules I'd like to know how this was supposed to work after your update. Kind regards --Joelemaltais 21:44, 1 August 2008 (UTC)

Hi Joelemaltais, the message was deleted by this script (which does not come from Meta but from the developers) because it contained nothing more than the header, which is already included in the default message. [3]. That had been done with all messages that were not other than the default one because they would block globally translated messages if they remained locally. As You have filled it with content now [4] such a script won't delete it anymore ;)
If You are interested in translating globally, please be invited and welcomed to betawiki:, You can contact me if You have any questions about it or want to translate the interface to mt or another language :)
Best regards, --birdy geimfyglið (:> )=| 01:01, 2 August 2008 (UTC)
Hi Birdy thanks. No longer required as message was a bit misleading. Am I getting this right: Is it now considered best practice to edit the css via betawki, clear the temporary solution on mt.wiki, and deploy from betawiki, and from then on keep checking out further modifications from there? It never crossed my mind that this practice would apply for the css rules too. So in future we'll always have to contact somebody on beta to check out for us. Or do we get check out rights via Beta?
Slightly OT: We also have a request for localizing further namespaces. When this is done we'd eventually have to grep through articles and rename the namespaced wikilinks. Can you line me up to some place for advice there too? Thanks for everything :)). --Joelemaltais 12:25, 3 August 2008 (UTC)

Limited TOC CSS rules

The following rules exist to facilitate the creation of a Compact TOC by means of the en:Template:TOClimit, which has been recently adapted in ar.wikisource (and probably many other projects before)


 /* Allow limiting of which header levels are shown in a TOC; <div class="toclimit-3">, for
   instance, will limit to showing ==headings== and ===headings=== but no further (as long as
   there are no =headings= on the page, which there shouldn't be according to the MOS).
   Thanks to w:en:User:Ais523 for that code.*/
 .toclimit-2 .toclevel-2 {display:none;}
 .toclimit-3 .toclevel-3 {display:none;}
 .toclimit-4 .toclevel-4 {display:none;}
 .toclimit-5 .toclevel-5 {display:none;}
 .toclimit-6 .toclevel-6 {display:none;}
 .toclimit-7 .toclevel-7 {display:none;}

The problem is that the number designator component of the classes assigned by the wiki code to the HTML elements of the TOC are assigned incrementally to the TOC structure, regardless of the actual document level to which each TOC element links.

This is a problem for complex documents where some sections may skip certain levels of hierarchy to the following, as occurred in constitutions and other legal documents.

For example, a document having the structure:


 ==Chapter A==
 ====Item 1===
 ..
 ..
 ..
 ====Item 6===


 ==Chapter B===

 ===Section 1===
 ====Item 7===
 ====Item 8===

 ===Section 2===
 ..
 ..

In this example, items 1 to 6, and 7 and 8 are semantically on the same level, even if 7 and 8 have a super-section 1 that 1 to 6 don't have an equivalent of.

This may not seem very logical, but it does exist in real world documents. In this kind of document, there's a main level of numbering going all over the document from start to end, and it is this numbering that is the main reference, with extra super-levels added as annotation and to divide the document to logical sections, but are also useful to have in a TOC.

For a live example see sections s:ar:دستور_مصر_1971#الباب الأول: الدولة and s:ar:دستور_مصر_1971#الباب الثاني: المقومات الأساسية للمجتمع

In order for the CSS rules above to effectively produce a limited TOC for this document (and maybe other cases), en:Template:TOClimit will have to have its limit at a hierarchy level common to all sections.

I guess that each each TOC level should have a class specifier correspond to the actual document sections' level it represents (that is the number of equal marks, regardless of its actual place in the TOC, and it is this class that should be used in the above CSS for the purpose of limiting TOCs.

As a weaker solution, is there a work around that would create an empty section on the right level which won't appear in the document?

--A. Gharbeia 18:55, 17 November 2008 (UTC)

I was aware of that issue when I created the TOClimits, and wasn't aware of any solution at the time. It was designed for project pages (originally enwiki's Requests for Adminship process, which has a fixed structure); I'm not sure how easy, if even possible, it would be to adapt it to use for ragged-style real-world documents like that. Ais523 20:32, 17 November 2008 (UTC)