![]() | This is an archive of past discussions. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page. |
Archive 5 | ← | Archive 10 | Archive 11 | Archive 12 | Archive 13 | Archive 14 | Archive 15 |
font-family /**/: inherit;
is declared after font-family for the Unicode, IPA, etc. classes. The comment explains that the second declarations reset the styles for all browsers except IE6, which chokes on the empty comment tags, but I don't understand. What does this exactly do? -- Paul_012 ( talk) 13:16, 31 January 2010 (UTC)
span.mw-headline:target {
background-color: #fbe54e;
display:block;
}
I would like this code to be added to
MediaWiki:Monobook.css to highlight targeted heading (e.g. clicked links from the TOC). The span need to be set to a block element, which is the parent h2 element, so the background extends across all the way. We can also use other CSS properties (color:maroon; border-bottom:1px dashed blue;
) if this is going to break custom styles. —
Dispenser
18:11, 7 February 2010 (UTC)
<h2 style="display:inline;">section</h2>
breaks when highlighted (:target isn't supported on IE). This would be easier if the H2 had the ID, but then <h2 id="
... The whole thing, by the way, is stolen from the
new python documentation interface. Which also has this nifty thing to permalink to section. —
Dispenser
19:21, 7 February 2010 (UTC)
.mw-headline span:target,
span.mw-headline:target {
background-color: #fbe54e;
display: block;
}
== <span id="An example">An <nowiki>{{example}}</nowiki> heading</span> ==
Could "display:inline-block
" be added to the styles for ol's and ul's? When either an ordered or unordered list is to the right of a left-floated image or other div, the numbers or bullets run into the image. (Effect can be seen on any stub article with a picture that extends into the references section.. off the top of my head, one can be found
here.) By adding the inline-block display setting, the problem is fixed. I probably haven't done as much cross-browser testing as I should, but it works in Firefox, Safari, Opera, and Camino.. those are the only ones I have (Mac OS X). Can someone test it in IE and possibly some other browsers? --
Dudemanfellabra (
talk)
07:47, 4 February 2010 (UTC)
I'm aware that multi-digit numbers will overlap; but I don't see any serious problem with the example above on FF3.5. What browsers do you see a problem on? Are you really saying that left-floated images in the middle of multi-digit ordered lists, are a sufficiently serious problem to require us to impose this fix on all lists? More seriously, have you tried with a long line?
The list simply wraps underneath the image, defeating the purpose of the exercise. As I said before. Happy‑ melon 23:07, 4 February 2010 (UTC)
background-color: #fbe54e; display: block;
background-color: #dfe6ff; display: block;
background-color: #dfe6ff;
color: #008040;
End of test headers. The below discussion is a continuation of the discussion above the test headers, and is about all the above headers and more.
-- David Göthberg ( talk) 19:32, 8 February 2010 (UTC)
display: block;
". Or we can make the gadget insert the [edit] button inside the "<span class="mw-headline"></span>
" thus we will still have the full width colour bar. (We'll have to test to see which looks best, but both should at least work technically.)/* Add an icon before a targeted heading (e.g. clicked links from the TOC). */
.mw-headline span:target,
span.mw-headline:target {
background: url("http://upload.wikimedia.org/wikipedia/en/0/00/Lock_icon_blue.gif") center left no-repeat;
padding-left: 18px;
}
The div.noarticletext
rule is for the
MediaWiki:Noarticletext message. I am planning to change that rule to instead have no border, margin, padding, and transparent background. (I can't just simply remove the rule since it is also declared in
monobook/main.css.) The reason is that we need to be able to control the border and background from code in
MediaWiki:Noarticletext. If anyone wants to know more, see
MediaWiki talk:Noarticletext#More notices.
-- David Göthberg ( talk) 08:37, 15 February 2010 (UTC)
I am considering adding the following:
.iezoomfix div,
.iezoomfix table {
zoom: 1;
}
This would allow people to fix the rendering of right floating elements inside a div block, under Internet Explorer (see Template_talk:Documentation#Problem_with_right-aligned_images). This code does nothing on standards compliant browsers. We can also add it through JS, as IE only code of course. — TheDJ ( talk • contribs) 22:23, 5 March 2010 (UTC)
Hi. There is a discussion at:
that may concern this page. One of the possible solutions to the issues at hand (re-coloring wikitables and reducing their font-size) might be implemented by adding some new classes and/or options to the site-wide css. class="wiki-filmograpy-table" or some such. And if this precedent is set, expect hundreds of more requests for things like "wiki-Hannah-Montana-colors". I'm posting here per a suggestion there by Ms2ger. I've expressed my views in the discussion, already. There is a related prior discussion at:
Cheers, Jack Merridew 20:03, 8 March 2010 (UTC)
{{ latinx}} was recently deleted. Perhaps we should remove its accompanying class ? It seems to be hardly in use as far as I can determine. — TheDJ ( talk • contribs) 11:18, 8 February 2010 (UTC)
{{
Reflist-2}} has been deleted and was the last major use of references-2column
. I did a standard search and see no uses in article or template spaces, but we need to verify this with a dump search. ---—
Gadget850 (Ed)
talk
16:21, 28 February 2010 (UTC)
Proposal: Add the folllowing code
cite:target {
background-color: #ddeeff;
}
If this is added, the line with the text vos Savant, Marilyn (2006). "Ask Marilyn" column, Parade Magazine p. 6 (26 November 2006). will be light blued in the back ground when pressing this link: Monty_Hall_problem#refWhitaker1990.
It has been implemented at the Norwegian Wikipedia [1] and it works there.
See also proposing it here Template_talk:Citation#Coloring_of_the_Cited_source.3F. Nsaa ( talk) 14:35, 5 March 2010 (UTC)
{{
cite xxx}}
for a reason. One of those reasons, is that <cite> is actually an incorrectly used here, considering it's latest HTML5 definition. We use {{
Ref}} in order to be able to change such things. —
TheDJ (
talk •
contribs)
15:10, 5 March 2010 (UTC){{
cite xxx}}
for a reason." However,
WP:CITE#Citation templates and tools says, "The use of citation templates is neither encouraged nor discouraged. ..." Many editors prefer to hand-craft cites. I'm not among them, but WP editors are constrained by
WP:CITE to use the existing citation style in articles which they edit -- to hand-craft cites in articles which use hand-crafted cites. There are now some number of articles out there with handcrafted <cite id=whatever>...</cite> in them which now have the cite highlighting broken. I vaguely recall that there is an issue there with later versions of HTML, but don't recall the details and don't have time to re-research that at the moment. Anyhow, I'm wondering what approach you would suggest for applying citation highlighting to hand-crafted cites.<cite>...</cite>
is supposed to be used only for the title of a work.
[2] We use it for full citations and notes. Wikipedia does not use HTML5 as yet, but there is a push towards it. ---—
Gadget850 (Ed)
talk
02:17, 8 March 2010 (UTC)
<cite>...</cite>
elements directly in articles?
Nsaa (
talk)
13:46, 14 March 2010 (UTC)<cite>...</cite>
element is to be used for, and only used for, the title of a work. (see
here). Given the guidance in
WP:CITE that "The use of citation templates is neither encouraged nor discouraged", I would say that discouraging the use of the <cite>...</cite>
element in articles implies encouraging the use a template which would take a title and do whatever special handling is needed for titles (i.e., wrap it in a <cite>...</cite>
). The alternative to that would seem to be to change the guidance in WP:CITE and encourage templated vs. hand-crafted citations.<cite>...</cite>
elements appeared as of 2010-Feb-03 (about 75 templates and 2500 articles).
Wtmitchell
(talk) (earlier Boracay Bill)
05:48, 18 March 2010 (UTC)Here is the CSS for striped tables, with a minor color adjustment. This will work in Firefox, Safari, Chrome, Opera and Internet Explorer 9. Dread Lord CyberSkull ✎☠ 13:26, 12 March 2010 (UTC)
/* wikitable/prettytable class for skinning normal tables */
table.wikitable,
table.prettytable {
margin: 1em 1em 1em 0;
background: #f9f9f9;
border: 1px #aaa solid;
border-collapse: collapse;
}
.wikitable th, .wikitable td,
.prettytable th, .prettytable td {
border: 1px #aaa solid;
padding: 0.2em;
}
.wikitable th,
.prettytable th {
background: #f1f1f1;
text-align: center;
}
.wikitable tr:nth-child(odd),
.prettytable tr:nth-child(odd) { /* The striping is handled by the :nth-child pseudo-class, with the odd row adjusted. */
background: #f5f5f5;
}
.wikitable caption,
.prettytable caption {
font-weight: bold;
}
Header |
---|
Table |
Cells |
All the same |
Colour |
Header |
---|
Table |
Cells |
Alternating |
Colour |
I can't tell the difference between the stripe colours, but I can tell that the table cells are less differentiated from the header cells. Why is this considered a good idea? Happy‑ melon 18:26, 12 March 2010 (UTC)
A few points; the two colors are too close to each other and a bit more differentiation would be needed to deploy this. Also, it's likely that the even/odd arrangement is backwards and that it would be better to have the first (odd) rows be the ones with the lighter cell color. And I do believe this would be best as an option on wikitables, not the norm; i.e. invoke it with:
{{ class="wikitable striped"
Wandering a bit, I think the the bolding of th-elements should be made explicit rather than relying on the typical browser default styling. This would be something like:
.wikitable th,
.prettytable th {
background: #f1f1f1;
text-align: center;
font-weight: bold; /* added */
}
Cheers, Jack Merridew 18:35, 3 April 2010 (UTC)
× | 1 | 2 | 3 |
---|---|---|---|
1 | 1 | 2 | 3 |
2 | 2 | 4 | 6 |
3 | 3 | 6 | 9 |
.wikitable.zebra tr:nth-child(odd)
{
background-color: yellow;
}
.wikitable.zebra tr:nth-child(even)
{
background-color: pink;
}
If we add something like the above, we'll have an optional version of this. I'm not advocating yellow or pink, they're just for clarity in the example (which is all hard-coded). I've omitted "prettytable" as we want to be deprecating that and should not offer any new features under the old name. I've also used the class name 'zebra' per zebra striping, but would be fine plain "striping", although we might want that for non-even/odd striping, someday. nb: the keywords odd/even and this multiplication table example are a bit at odds, as the heading row counts as row '1' while row '1' is the second row ;)
Cheers, Jack Merridew 22:01, 6 April 2010 (UTC)
ok. The pink and yellow sucks. Let's float something more realistic.
xyzzy | Plover | Get Axe | Fee Fie Foe Foo |
---|---|---|---|
Little maze of twisting passages | Little maze of twisty passages | Little twisty maze of passages | Little twisting maze of passages |
Maze of little twisting passages | Maze of little twisty passages | Maze of twisting little passages | Maze of twisty little passages |
Twisting little maze of passages | Twisting maze of little passages | Twisty little maze of passages | Twisty maze of little passages |
Little maze of twisting passages | Little maze of twisty passages | Little twisty maze of passages | Little twisting maze of passages |
Maze of little twisting passages | Maze of little twisty passages | Maze of twisting little passages | Maze of twisty little passages |
Twisting little maze of passages | Twisting maze of little passages | Twisty little maze of passages | Twisty maze of little passages |
.wikitable th
{
background-color: #e9e9e9; /* changed */
text-align: center;
font-weight: bold; /* added */
}
/* new: */
.wikitable.zebra tr:nth-child(odd)
{
background-color: #f1f1f1;
}
.wikitable.zebra tr:nth-child(even)
{
background-color: #f9f9f9;
}
This example darkens the header cells a tad (to #e9e9e9) and uses the former header color (#f1f1f1) for the odd rows and is explicitly setting the usual data cell background-color to the normal (#f9f9f9); 'even' could be omitted and allowed to inherit from the ambient table styles.
Any interest?
Cheers, Jack Merridew 05:08, 15 April 2010 (UTC)
Is the bit about being supported in "Internet Explorer 9" a joke? --
MZMcBride (
talk)
21:36, 18 April 2010 (UTC)
Ya, all the modern browsers support this, and Microsoft may-well have one, too; next year (or moar;). And it should all degrade gracefully. I'm not too fussed about just what shades of gray are used and there may be a bit of concern about changing the header cell background. It would also bee goodness to offer a bit of guidance about when this is appropriate to use. Tables with rowspans would get odd effects, for example. Cheers, Jack Merridew 22:09, 18 April 2010 (UTC)
Hi. I believe the following css would be cleaner as it avoids displaying empty <ul>
elements (i.e. those with 0 visible <li>
elements):
status quo | suggestion |
---|---|
.toclimit-2 .toclevel-2,
.toclimit-3 .toclevel-3,
.toclimit-4 .toclevel-4,
.toclimit-5 .toclevel-5,
.toclimit-6 .toclevel-6,
.toclimit-7 .toclevel-7 { display: none; }
|
.toclimit-2 .toclevel-1 ul,
.toclimit-3 .toclevel-2 ul,
.toclimit-4 .toclevel-3 ul,
.toclimit-5 .toclevel-4 ul,
.toclimit-6 .toclevel-5 ul,
.toclimit-7 .toclevel-6 ul { display: none; }
|
Rather than affecting the list items directly, it invisiblizes whole lists starting at the previous depth. ― AoV² 09:25, 18 March 2010 (UTC)
Bump to avoid archive-bot. ― AoV² 03:57, 4 April 2010 (UTC)
Discussion moved from Template talk:Infobox UK place#Centred text?
Microsoft recently removed en.wikipedia.org from its IE8 compatibility-mode list, so IE8 clients with the latest list now see Wikipedia rendered in standards-mode by default. This seems to have caused <TH>
table-header content to render with centered text even where the parent <TABLE>
table tag has inline CSS style="text-align:left"
. For example, the infobox headings at
Template:Infobox UK place/testcases now render center-aligned in IE8.
The problem appears to be that table-header elements do not inherit the text-align style of their parent TABLE element in IE8 standards mode, as documented here. Should MediaWiki:Common.css be amended to include a workaround?
— Richardguk ( talk) 21:50, 13 April 2010 (UTC)
This is not really a bug in IE8 at all. Both the HTML5 and CSS2.1 specs recommend this result. I've filed bugs against Gecko and WebKit. Apparently this weird behavior of th (that alignment is mysteriously inherited from the parent element sometimes but not always) is due to some kind of pre-CSS legacy constraints.
Bug or not, the suggested fix will hurt far more than it helps. It will make all th elements left-aligned, not just ones with text-align:left specified on a parent. I'd recommend you code for the (standards-compliant, CSS-based) IE8 behavior and explicitly specify left alignment on your th's when you want it. — Aryeh Gregor ( talk • contribs) 18:30, 14 April 2010 (UTC)
.infobox td, .infobox th { vertical-align: top; }
.infobox td, .infobox th { vertical-align: top; text-align: left; }
.infobox.geography th { text-align: left }
<table class="infobox geography"><tr align="center"><th>...
; the change I suggest isn't free of side effects. The only side effect-free solution would be to alter all the templates by hand. —
Aryeh Gregor (
talk •
contribs)
17:08, 16 April 2010 (UTC)
.infobox th { text-align: inherit; }
I think you′ll find more of them have an over-ridden style attribute text-align:left;
. Perhaps only the <th>
cells on the first row of a table (or those whose colspan is such that it occupies an entire row) should have text-align:center;
as a default, something like:
th { font-weight:bold; text-align:left; }
tr:first-child th, th:only-child { text-align:center; }
Typical arrangement in rendered infobox:
<tr><th>Population </th><td>Over 9,000</td></tr> <!-- th should be text-align:left; -->
<tr><th>Power level</th><td>Over 9,000</td></tr> <!-- th should be text-align:left; -->
<tr><th colspan="2">Politics</th></tr> <!-- th should be text-align:center; -->
In wikitable:
{| class="wikitable" ! Year ! Foo !! Bar !! Baz <!-- should all be text-align:center; --> |- ! 1979 <!-- should be text-align:left; --> | Lorem || Ipsum || … |- ! 1980 <!-- should be text-align:left; --> | … || … || … |}
― AoV² 19:10, 18 April 2010 (UTC)
[[Main Page|Foo <code>Bar</code> Baz]] |
→ |
Foo Bar Baz
|
→ | see screen-shot |
For whatever reason the <code>
tag interrupts the under-lining of a link which contains it, at least on my screen (see above):
Recommend:
a code { text-decoration:inherit; }
― AoV² 02:15, 14 April 2010 (UTC)
<tt>
is a deprecated element. What are we supposed to recommend they use instead?
Happy‑
melon
10:23, 15 April 2010 (UTC)
This is because of
Mozilla bug 365970, and a similar bug in WebKit. Opera behaves correctly, and it seems so does IE. text-decoration: inherit will not work quite right in general, because the underlines will be inherited instead of drawn from the parent element: this can produce weird results in cases like
AB
C. In Firefox, this displays with a noticeably different underline for "B", because the underline is redrawn with the different font size. (WebKit seems to use the same underline thickness independent of font size.)
This oddity might not be serious enough to be worried about, though. Probably
a code, a tt { text-decoration: inherit }
is a reasonable addition to the site CSS for skins that use different backgrounds for code. Or just doing
code, tt { background: none }
would solve the problem, too, removing the barely-visible gray background. — Aryeh Gregor ( talk • contribs) 16:57, 16 April 2010 (UTC)
a * { background: none !important; }
<tt>...</tt>
is not deprecated for HTML 4 and XHTML,
[3] but CSS is recommended instead. It is not supported in HTML 5, nor are center, big, small and s.
[4] We are moving toward HTML 5, so this is something to keep in mind, ---—
Gadget850 (Ed)
talk
19:33, 18 April 2010 (UTC)I propose to add
page-Special_UserLogin .mw-label { white-space : nowrap; }
This avoids that the labels of the input fields on Special:UserLogin are spread over two lines ("retype password" and "E-mail (optional)". This is especially notable on the Signup page, when you are not logged into Wikipedia. I think it makes it a lot more readable. — TheDJ ( talk • contribs) 18:07, 3 April 2010 (UTC)
page-Special_UserLogin .mw-label label { white-space : nowrap; }
{{ editprotected}}
.page-Special_UserLogin .mw-label label { white-space : nowrap; }
{{ editprotected}} Not to be a nudge, but where did the "_signup" come from?
body.page-Special_UserLogin_signup .mw-label label { white-space : nowrap; }
it should be:
body.page-Special_UserLogin .mw-label label { white-space : nowrap; }
(or both, if the _signup form is used somewhere). Cheers, Jack Merridew 00:27, 7 April 2010 (UTC)
It would also leave less width for the <div class="prefsectiontip">
which follows. I think we′d address this best by putting it in its own cell on a separate row with colspan="2"
, either directly below the wpEmail
row or below the mw-submit
buttons. Also the asterisk in that message invokes an unordered list rather than matching the literal asterisk in “E-mail (optional)*”. ―
AoV²
00:03, 4 April 2010 (UTC)
<p id="userloginlink"><p>Already have an account? <a href="/?title=Special:UserLogin&type=login">Log in</a>. </p></p>
The differing body-class appears only when you use url with a slash after the title of a special page, not in the default link which uses a separate parameter, viz. title=Special:UserLogin&type=signup. See also bugzilla:23315. ― AoV² 12:14, 28 April 2010 (UTC)
Hi there, I have my own MediaWiki set up, and I saw another has this code.
.page-Special_RecentChanges [title="User:<USERNAME>"] { font-weight: bold; color:#70B04A; }
I'm wondering why this isn't working for me. I placed it near the end of my Common.css. If someone could get back to me I'd be much obliged. Smashman2004 ( talk • contribs • email) 10:34, 27 April 2010 (UTC)
body.page-Special_RecentChanges atitle="User:<USERNAME>"
I proposed a change to {{
portal box}}
that requires also a change of this page. See the discussion at
Template talk:Portal box#Better syntax.
Svick (
talk)
20:58, 3 May 2010 (UTC)
I just noticed that since the wikitable move, there is no longer wikitable css for print. See this. We need to follow that up. — TheDJ ( talk • contribs) 02:54, 13 May 2010 (UTC)
From the indications at the VP and many other related pages, it is clear that the new logo is much despised. I therefore suggest the unusual, but possibly warranted inclusion of the following line:
#p-logo a {background-image: url(http://upload.wikimedia.org/wikipedia/en/6/6b/Wiki.PNG) !important;}
-- Ipatrol ( talk) 20:25, 13 May 2010 (UTC)
WP:VPT#New logo AON. Also, lack of complaints from readers does not mean approval. It usually means that they don't know how to or want to get involved with us. Consensus of the interested should decide this.-- Ipatrol ( talk) 01:50, 14 May 2010 (UTC)
{{
editprotected}}
Since the talk page of
MediaWiki:Print.css (
|
talk |
history |
links |
watch |
logs) redirects here, I'm putting my request here. Please add .ns-0 .rellink,
to the first CSS item there. {{
Rellink}}, which uses this class, is a meta template for showing links to related articles. The template and its derivatives are currently in the category "Exclude in print", but this only prevents the templates from being shown in the book tool. To make it work with the usual printing, skinning it here would be needed. An alternative would be to add class="noprint" to the template itself, but there might be situations in which one might want to print it, possibly in other namespaces. Thanks, --
The Evil IP address (
talk)
15:31, 19 May 2010 (UTC)
See Wikipedia:Requests for comment/May 2010 skin change/Bug reports#Reflist template. ---— Gadget850 (Ed) talk 21:16, 7 June 2010 (UTC)
I wanted to ask how to do the line around the code when you add the <syntaxhighlight> or <SOURCE> tags to show the code? I wanted to know so that i can add it for pa wiki, i think it looks better that way, with code separated from rest of article. Thank You. Also is there a better place to ask these sort of questions? Gman124 talk 14:03, 14 July 2010 (UTC)
[6] That latest change disabled my Firefox (3.6.7) browser (using Windows 7) from choosing the fonts I have specified for IPA in my own user:Mahmudmasri/vector.css. I need help. The latest change made it only possible for my browser to choose my specified fonts if there were texts written as {{IPA|/tekst/}} only after I wrote that: span[class|=IPA] rather than .IPA, but still I have a problem: all the IPA wikitables such as Help:IPA conventions for English#Vowels don't choose my specified font for IPA. Please, help me overcome the problem. -- Mahmudmasri ( talk) 07:39, 24 July 2010 (UTC)
Wikitable is now defined in shared.css. [12] ---— Gadget850 (Ed) talk 17:55, 27 April 2010 (UTC)
I removed the wikitable definitions and left the prettytable ones until we get the above list sorted out. — TheDJ ( talk • contribs) 23:57, 27 April 2010 (UTC)
content
property or just break it like with .hiddenStruct
? Its been on the
/to do list for the last ten months. I fear the stalemate will continue. —
Dispenser
04:12, 28 April 2010 (UTC)I pulled the trigger on this one. It was about time. — TheDJ ( talk • contribs) 17:10, 13 May 2010 (UTC)
Because of a long-standing Firefox bug, marking up transliterated text as such results in ugly output, e.g. consider {{IAST|thiṣ}}, rendered as "thiṣ" when it really ought to look the same as "thiṣ". This happens because the transliterated text is marked up by the CSS as being in a <span lang="sa-Latn">…</span>, which the browser is failing to understand is still in Latin script. As the comment on the Firefox bug says, we're "left with the choice of forcing a latin compatible font on the user, or removing lang tags for transliterated text". Could we do something in CSS to fix this? For further details please see MediaWiki_talk:Common.css/Archive_7#Ugly_fonts_for_transliteration_templates, Template talk:IAST#Font selection and Template talk:Transl#Font for translated words. As dab suggests there, it may be possible to fix this by introducing a pseudo-class for sa-latn, ar-latn, and a few others. Shreevatsa ( talk) 17:57, 30 July 2010 (UTC)
Here's the problem as it appears for me (Firefox 3.6.8 Vista) in Clay Sanskrit Library. The surrounding font is Gentium (according to my style sheet), whereas the Template:IAST text is an atrocity. The bottom line is that, if there is nothing I can do to get a correct result here, then I would be far better off with the template scrapped. Wareh ( talk) 18:19, 5 August 2010 (UTC)
The code discussed at MediaWiki talk:Common.css/Archive 12#Noarticletext should be moved into Monobook.css and Modern.css because all other skins do not have CSS for this class. — AlexSm 04:01, 6 September 2010 (UTC)
{{
edit protected}}
Could a sysop replace
http://upload.wikimedia.org/wikipedia/commons/thumb/a/a6/Gnome-speakernotes.png/30px-Gnome-speakernotes.png
with
http://upload.wikimedia.org/wikipedia/commons/3/3f/Gnome_speakernotes_30px.png
And also protect the new image? I've losslessly compressed it to save 101 bytes. Smallman12q ( talk) 13:20, 8 September 2010 (UTC)
To keep discussion centralised please comment at Wikipedia:Village pump (technical)#Proposal, Rambo's Revenge (talk) 11:51, 4 October 2010 (UTC)
Permalink: http://en.wikipedia.org/?title=Wikipedia:Village_pump_(technical)&oldid=389777733#Proposal -- MZMcBride ( talk) 22:15, 9 October 2010 (UTC)
Proposed: Add the following code to MediaWiki:Handheld.css in order to stop unwanted font size transformations on devices like the iPhone when the non-mobile site is used.
body {
-webkit-text-size-adjust: none;
}
Thoughts? -- MZMcBride ( talk) 17:43, 9 October 2010 (UTC)
body.iphone {
-webkit-text-size-adjust: none;
}
I guess this could work. — TheDJ ( talk • contribs) 21:23, 11 October 2010 (UTC)
Hey. I've floated a few ideas on a number of talk pages and I'd like some feedback from the regulars here.
I know that wikitable went to shared.css, which is great, and what I'm taking about might be better discussed on whatever meta page goes with that. But I'm thinking that a trial here might precede that; talk first, of course. Below are some snippets. They arose out of discussions that are still underway regarding accessibility.
/* existing: */
.wikitable th
{
background: #f2f2f2;
text-align: center;
}
/* new override: row-headers get left-aligned */
.wikitable thscope=row
{
text-align: left;
}
/* new override: lists in data cells are always left-aligned */
.wikitable td ul,
.wikitable td ol,
.wikitable td dl
{
text-align: left;
}
/* new explicit rule; most browsers do this for us */
.wikitable th
{
font-weight: bold;
}
/* new explicit rule; but don't bold refs */
.wikitable th sup
{
font-weight: normal;
}
If the new practice of scope-tagging row-headers sticks in the MOS, I believe the center-alignment will produce push back because many will not like the presentation applied to row headers; I expect the centering is primarily about targeting column headers, which are far more common. The paucity of row-headings is likely due to people not liking the current styling.
The DISCOG people like lists in data cells and lists really look terrible when not left aligned. This has resulted in huge amounts of align="left" getting baked into tables. User agents typically center table header cells, so we're getting that effect for the most part, already; I think we should make it explicit. The final snippet is a special case for refs that appear in headings; they're getting bolded and it is not a nice effect. FWIW, I'm not too keen on refs in headings, and things really get messy when there are sorting controls present, too. Comments?
Cheers, Jack Merridew 00:37, 15 August 2010 (UTC)
.wikitable th[scope=row]
looks like CSS3. How is this going to render on older browsers?
Happy‑
melon
23:54, 15 August 2010 (UTC)! style="text-align:left;"
at every row. Hey, the Usability initiative is trying to make it easier to edit by removing excessive code from articles (template folding), and we are only increasing the quantity of code we use? That just won't do. Even worse, users are now starting to use the deprecated align="left"
. Now which one is more important? Compatibility to IE6 who will eventually die sooner or later, or future-proof code? I'd say we should aim for future-proof code. Kind regards,
Dodoïste (
talk)
23:59, 29 September 2010 (UTC)
scope="row"
would be added (by hand, as I believe I took it) to every such cell. That sounds awful, to be sure, and it's not great, but very often it'd be replacing align=left
or similar. As I understand it, the scope attribute tells UAs something important (useful for assistive technology, I think) whereas the align attribute just says "show it to the left". I believe some discussion touched on classes and as I recall, Jack Merridew had strong reasons for preferring the scope approach. However, I may very well have this backwards, and maybe Jack didn't passionately hate the idea of adding a new class to the CSS (and we'd still have to add them to all the wikitables); the best thing to do would be to invite Jack over to clear things up for us. Certainly my memory and understanding of these bits are rather foggy. —
JohnFromPinckney (
talk)
20:24, 30 September 2010 (UTC)
! scope="row" |
- themselves, and they will do so only if the layout result is appropriate. Thus the CSS selector and the align left by default.style="text-align:left;"
or deprecated align="left"
. Actually, I really doubt any class could be shorter than the deprecated code..wikitable th[scope=row]
at least temporarily, and when a developer makes the corresponding change to MediaWiki we will simply remove it in favor of MediaWiki.style="text-align:left;"
already. The issue is, most of the time editors are not making row headers.{{
editprotected}}
This proposal was refined through the discussion. This proposal seems almost consensual, since Edokter is the only one to oppose. 6 users support this proposal, and this proposal is much needed that the WikiProject discographies (and later on other projects, when they will try to improve their accessibility).
A few changes happened during the discussion, and the explanation of this proposal is dispatched here and there. So here is a summary.
Concerning table accessibility, headers must be marked manually as either row headers or column headers. As explained in the data tables tutorial I recently made according to W3C's WCAG 2.0 techniques. Sighted users can visually deduce from context which headers are supposed to be column headers or row headers. But a machine can't, thus blind users using a screen reader can't either and will have a hard time to navigate the data. And machines reusing the content will also have a hard time to associate cells to their headers.
So users must make row headers and mark them with scope="row"
. But row headers are centered by default, which makes them look messy. So users have to add extra code in every row header (style="text-align:left;"
) to have them left aligned. This makes the table more complicated to newbies and more complicated to produce. Thus, users are reluctant to make row headers. This proposal is about adding a single line of code into MediaWiki:Common.css that does the job for them.
This code works in every major browsers, except IE6. But it's not a problem since this is only a minor layout bonus: no lost of content or important info happens when this is not supported. IE6 users will simply have their row headers centered as they are now anyway. This proposal complies to the Progressive enhancement best practice.
As explained above, other solutions are either impossible or suboptimal. This one is very simple and much needed to encourage the users to improve accessibility. This proposal is much needed in a ongoing improvement of the accessibility of WP:DISCOG tables, and will be necessary when reaching to other projects.
/* row-headers get left-aligned */
.wikitable thscope=row
{
text-align: left;
}
Dodoïste ( talk) 17:17, 2 October 2010 (UTC)
Not done for now: I have disabled this request due to lack of consensus. While it is just one editor who is expressing concern about this change, Edokter does seem to have valid points which do not seem to have been fully addressed. As edits to this page cannot easily be reverted due to caching, we must be completely sure that all changes correct. Therefore I ask that you continue to discuss this issue and work around the issues. — Martin (
MSGJ ·
talk)
17:38, 10 October 2010 (UTC)
scope="col"
to <th>
column headings. I have started doing this already. So far (as I've noticed, anyway), nobody has reverted or removed this somewhat strange and unfamiliar addition. As for changing table cells to headers, well, that's just good common sense and how all Web sites on the planet should be coded. That one of the ten most-visited sites (based on the ease of editing by such smart people from all over the world) has incorrect mark-up is a large embarrassment. I know that other sites, including large and popular ones, often have inappropriate mark-up or invalid HTML or JavaScript errors or rely on colors or assume a certain window size or exhibit any of a zillion other dumb mistakes, but we don't have to do that. We can do it right, and this change is about making doing the right thing more attractive. —
JohnFromPinckney (
talk)
23:08, 11 October 2010 (UTC)scope="col"
can be automated on a per-project basis. For example, the discographies tables are consistent, so a bot could do it and we'll definitely try this approach. But in order to produce relevant row headers, the DISCOG tables must be restructured, so this can't be automated. Done. We seem to have consensus that this change is warranted. If a better solution turns up, we can modify this later. — Martin (
MSGJ ·
talk)
12:11, 12 October 2010 (UTC)
The
WP:DISCOG people like lists in data cells. Their cells have often centered text applied to the whole table, so the list get left aligned by default. And lists really look terrible when not left aligned. This has resulted in huge amounts of the deprecated align="left"
getting baked into tables, instead of the longer but correct style="text-align:left;"
. There are similar other cases where cells are added manually these codes, which makes the table more complex, especially for newbies.
Not to mention it is suboptimal regarding bandwidth too because these styles are contained in every cell, instead of being once in MediaWiki:Common.css as proposed. This proposal seems consensual. It is about adding:
/* lists in data cells are always left-aligned */
.wikitable td ul,
.wikitable td ol,
.wikitable td dl
{
text-align: left;
}
Dodoïste ( talk) 16:59, 2 October 2010 (UTC)
Added — Martin (
MSGJ ·
talk)
12:14, 12 October 2010 (UTC)
{{
editprotected}}
I've been bothered by the font selection for
IAST
Sanskrit transliteration, chosen by
Template:IAST. It looks like it isn't defaulting to something that is totally unreadable and hideous anymore, but the selection of "Free Serif" as a top choice is troubling. I have been working with web design that involves Sanskrit transliteration, and I spent a fair amount of time digging through fonts and CSS settings, finding exactly which fonts can support it, and will render well on
Windows (and
Mac OS X and
Linux too, for that matter). Now today I finally dug into the matter and inspected the CSS being applied to the IAST template, using the Firebug add-on in Firefox. The exact CSS class that chooses these fonts is part of a Windows-specific CSS file:
MediaWiki:Common.css/WinFixes.css, and in here it is the "Unicode" class. I am proposing the following change to the "Unicode" class in this file, which I will explain.
.Unicode {
font-family: "Microsoft Sans Serif", "Arial Unicode MS", "Free Sans",
"Gentium Basic", "Gentium", "GentiumAlt", "DejaVu Sans",
"DejaVu Serif", "Free Serif", "TITUS Cyberbit Basic",
"Bitstream Cyberbit", "Bitstream CyberBase", "Doulos SIL",
"Code2000", "Code2001";
font-size-adjust: 0.54;
}
Arial Unicode MS and Microsoft Sans Serif are probably the best available fonts widely available on Windows for this Unicode class. They harmonize with the default Arial font, and they are both very full-featured. Neither has a real oblique or italic, but the faked oblique is legible and clear. Most importantly, Arial Unicode MS is installed on every system with MS Office, and Microsoft Sans Serif is installed on every Windows system, at least since Windows XP. Free Sans is a similarly good font in the same exact style as the other two, also full-featured, albeit with less hinting. The rest go on to Gentium and the DejaVu fonts, which are each good in their own right and Open Source, and can display acceptably, but are not well hinted. Then come the other Unicode fonts that are in general a bit ugly, but can cover a larger range than some of the other Unicode fonts. Therefore, everything goes by aesthetics and functionality, generally from better to worse.
The second line is very important, which is a CSS font-size-adjust directive. Without this directive, fonts such as Gentium and FreeSerif will appear too small to be legible. This is because fonts display at very different sizes even if the point size is calculated the same. This is due to the difference in x-height and the general difference in metrics between fonts. This can be very pronounced between sans-serif and serif faces. Without this directive, a serif fallback such as Gentium, Free Serif, or one of the others, would be too small to be legible. This is currently happening with the "Unicode" class when it falls back to Free Serif, which is one of the current top choices. Adding this directive will fix the problem. The setting of 0.54 is tuned for the top choices and tested in the major browsers, so they will display at sizes that are even with the rest of the text.
Those are my two rationales for the changes to the "Unicode" class in MediaWiki:Common.css/WinFixes.css. If an administrator could help make that change to the page, it would be much appreciated. Tengu800 ( talk) 01:58, 24 August 2010 (UTC)
{{
rfctag|policy}}
.Unicode {
font-family: "Arial Unicode MS", "Microsoft Sans Serif", "Free Sans",
"Gentium Basic", "Gentium", "GentiumAlt", "DejaVu Sans",
"DejaVu Serif", "Free Serif", "TITUS Cyberbit Basic",
"Bitstream Cyberbit", "Bitstream CyberBase", "Doulos SIL",
"Code2000", "Code2001";
font-size-adjust: 0.54;
}
Can we move the in-line styles from {{ Unbulleted list}} to the main stylesheet? The current markup is:
<ul style="list-style:none none; padding:0px; margin:0px">
I propose to change that to
<ul class="unbulleted-list">
or, if a shorter name is needed, class="ublist"
.
This template is used (primarily in infoboxes) to create lists such as:
cat
dog
mouse
using the correct HTML list mark-up, currently:
<ul style="list-style: none outside none; padding: 0px; margin: 0px;">
<li>cat</li>
<li>dog</li>
<li>mouse</li>
</ul>
with styles to hide the bullets, replacing the common but unsemantic markup:
cat<br />
dog<br />
mouse<br />
It will be increasingly and very widely deployed; often multiple times on one page. It's also intended that the style should be available to other templates, not necessarily by calling this one. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 15:46, 16 August 2010 (UTC)
display: inline;
to produce more semantic and accessible list in Navboxs. Like ul#inline li { display: inline; }
. Yours,
Dodoïste (
talk)
20:01, 16 August 2010 (UTC)
|primeminister=
and |party=
in the Infobox on
Charles de Gaulle. I created {{
Flatlist}} and its class="horizontal"
some time ago, for your other use-case. It still needs a little polishing.
Andy Mabbett (User:Pigsonthewing);
Andy's talk;
Andy's edits
23:03, 16 August 2010 (UTC)
So how do we actually make this happen. Is there an equivalent of {{ Editprotected}}? Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 20:18, 21 August 2010 (UTC)
I feel that it would be better that table row headers did not display in bold on Wikipedia and that we should impose normal font weight. This overwhelms the lists it has been used on, such as on Fantasia Barrino discography. I am not aware of the reasoning behind the use of bold in row headers, but would be keen to find out. The Rambling Man ( talk) 15:34, 4 November 2010 (UTC)
! scope="row" |
" is necessary. Headers a simply bolded by default by browsers, as it was already explained..wikitable th[scope=row] {text-align: left;}
. The Rambling Man is only asking that the same consideration be given to removing the stylistic impact of the bolding; in other words, could we add: .wikitable th[scope=row] {text-weight: normal;}
. I think it is worthy of proper discussion here, as it would resolve multiple concerns at FLC, but obviously we need to take into consideration its potential impact in other areas of the project. --
RexxS (
talk)
17:59, 4 November 2010 (UTC)th
{
display: table-cell;
font-weight: bold;
padding: 1px;
vertical-align: inherit;
}
I've attempted to start a centralised discussion here. Thanks. The Rambling Man ( talk) 19:03, 4 November 2010 (UTC)
We can't just change the bolding of row column headers to non-bold. There are probably many tables that depend on this. The problem here is that ACCESS team is adding header fields to tables for the sake of semantics and not for visual effect. As such our current visual effect for such headers is applied, while that is not really appropriate. Suggest adding adding a new class.
table.wikilist thscope=row {
background: #F9F9F9;
font-weight: normal;
text-align: left;
}
This would give you "plain layout" when you use class="wikitable wikilist", while still being semantically correct for screenreaders. — TheDJ ( talk • contribs) 23:10, 4 November 2010 (UTC)
table.wikilist thscope=row {
background: transparent;
font-weight: normal;
}
th
(!
) mark-up, but omit the scope="row"
that we're supposed to be adding; orth
(!scope="row"
), which we've cranked down to normal weight, and add '''
to add bold mark-up on the header cell contents (assuming that'll work, of which I'm not sure); orActually, text-align for this case should probably be reset to "inherit". So final code proposal:
.wikilist thscope=row {
background: transparent;
font-weight: normal;
text-align: inherit;
}
— TheDJ ( talk • contribs) 03:44, 5 November 2010 (UTC)
This began months ago. I began experimenting with more explicit row headers (!) in things like filmography tables and Dodoïste began advocating explicit scope attributes in table header-cells. This all kicked-up some dust when Kelly Rowland discography became a FLC. The WP:DISCOG crowd's style-guidance was sharply at odds with the MOS, and the proposals above at #some wikitable ideas emerged in my talks with them.
I'm not keen for the "wikilist" solution. First, the name is poor; that should be for the list elements, such as OL, UL, DL. Second, it amounts to a purely presentational option, a fork of our table-styling. The word 'list' would seem to be simply an artifact of where the fuss originates. If this route is pursued, name it 'plain'. Consider the following rule to simply force normal weight for scope-tagged row headers:
/* row-headers get normal-weight */
.wikitable thscope=row
{
font-weight: normal;
}
or the following to de-bold when someone's explicitly italicized the contents of a scope-tagged row header:
/* row-headers get normal-weight when italics on-offer */
.wikitable thscope=row i
{
font-weight: normal;
}
These won't sort all cases, notably the quoted-but-not-italic stuff at: Rihanna discography#Studio albums and Fantasia Barrino discography#Singles. In the above #some wikitable ideas thread, Edokter had some valid concerns about the futility of attempting to hard-code millions of pages with proper scope attributes. The approach of having them generated needs to be explored as it is the only way to get consistency. This may even entail a tweak to our wiki-text syntax for table. Cheers, Jack Merridew 18:24, 5 November 2010 (UTC)
I have to agree with TheDJ here, in that the majority of editors expect to see behaviour that is inherent to tables. I still believe that forcing all row headers to show as plain by default is not the way to go. I do however like the idea of adding a seperate class for those that want plain row headers, but .wikilist is a poor name. Instead, the name should convey it's function, so I propose it would be called .plainrowheaders, which gives row headers normal weight and left-aligned text. But I do recommend leaving the original header background color, so it remains recognizable as a header. This gives editors a choice on how to format their row headers, without forcing others to work with semantically-incorrect behaving headers with regards to styling. So this would be my proposed code:
/* Normal font styling for table row headers with scope="row" tag */
.plainrowheaders thscope=row {
font-weight: normal;
text-align: left;
}
— Edokter • Talk • 13:31, 6 November 2010 (UTC)
/* row-headers get left-aligned */
.wikitable thscope=row {
text-align: left;
}
So now we've gone ahead and changed common.css, allowing row headers to be non-bold and left-aligned (or bold and centered). Are we already so happy with this universally that we can say it's a (permanent, at least in wiki-terms) "go" WP-wide? Are we waiting for feedback from the WikiProject:Military folks or the WikiProject:Lighthouses people? Is it all right to blend this into the proposed guidleine at WP:DISCOGSTYLE as if this is the direction we intend to go? (Someone mentioned "a manual methodology and we experiment first", but it seems we've skipped that.)
And what's going on with the idea of Wikimedia auto-generating the scope attributes? Is that a realistic possibility that's moving forward now (somewhere), or is it some wishful thinking for six monthes from now? — JohnFromPinckney ( talk) 20:36, 7 November 2010 (UTC)
Having tried this out on a couple of the tables I helped get to featured status, I now see a very clear grey background in the first cell of each row. Sorry for being so dense for having missed this thus far. What is the purpose of this? Can it be (easily) overridden? The Rambling Man ( talk) 14:53, 8 November 2010 (UTC)
Do we want a plain background color (same as data cell) for .plainrowheaders? — Edokter • Talk • 17:37, 8 November 2010 (UTC)
/* ability to cancel background-color, too */
.plainrowheaderbackgroundtoo thscope=row
{
background-color: #f9f9f9;
}
and class="wikitable plainrowheaders plainrowheaderbackgroundtoo sortable"
would make it optional. Just sayin', not proposing.
Jack Merridew
19:11, 8 November 2010 (UTC)
I'm just trying to find a situation mutually acceptable. ACCESS is important, and our project want to buy into it, but suddenly introducing a grey background after five years (when we've stridently avoid "colour-only" backgrounds, for ACCESS believe it or not) where we, in general, can't see any use for it, and being rather hand-wavy and glib and smug about it, will just result in us ignoring it. I thought we had gone some way to compromise if we accepted the "scope" changes, so screen-readers could use our tables? The Rambling Man ( talk) 20:41, 8 November 2010 (UTC)
Since it was my proposal not to change the background, I feel a bit responsible for the whole debate. I think the initial proposal was to style the entire row header as a data cell, as TheDJ proposed. So I'm withdrawing my objection here. Since it is called .plainrowheaders, not .plainrowheaderfonts, it would actually make more sense. I'll make the background transparent (and simultaniously restrict it's use to .wikitable). The impact will be low, and with enough education, there should be little problem adopting the class="plainrowheaders" + scope="row" method. Remember, there's no rush and nothing is irreversable. — Edokter • Talk • 23:28, 8 November 2010 (UTC)
So... what, now? It seems we've gone to the greatest effort possible to get the smallest possible effect.
We've endeavored to make sure that only users of screen readers recognize row headings, and everybody else goes without. Editors are not to be encouraged to structure tables according to the data they present, but rather based on what "looks nice", which appears to equate to what the FLC guys are used to seeing.
When given the opportunity to formalize tabular data into semantically correct markup, we've chosen to munge the table markup to most closely approximate a layout table. Editors now have a choice of row headings which are bold, centered and background-shaded (defaults for wikitable, a 67% match with browser defaults), and normal-weight, left-aligned, and unshaded, so that it looks like a (somewhat uncooperative) <td>
table cell. Both of these options force a certain alignment no matter the table's default alignment, so anything else needs to be specified inline on every cell. The first of the two options was described as unusably ugly; the second is imperceptably better to most users. We've really achieved some impressive things: The FLC crowd doesn't have to do anything new, or suffer the trauma of seeing something (ew!) different.
Please tell me we're not going to stop here. When I got on this bus, I thought it was going to take me somewhere nicer. Can't we keep going, or back up a couple of blocks, or something? — JohnFromPinckney ( talk) 03:39, 9 November 2010 (UTC)
plainrowheaders
to subvert the proper rendering of table headings in bold. All-with-JohnFromPinckney, who's right. This change to common.css does not have consensus and subverts the MOS. From under the bus,
Jack Merridew
17:25, 9 November 2010 (UTC)
plainrowheaders
to subvert the proper rendering of table headings in bold" is not a decision for any non-FL director to make, especially because it is your opinion that this rendering is "proper", and is not the opinion of those editors who are working to build content in this encyclopedia. I won't comment further on this issue because I've no desire to be dragged into all this mess, but I've said my piece and will now withdraw. —
KV5 •
Talk •
18:34, 9 November 2010 (UTC)
OK, here are the three examples. No example without scopes, as that is not part of this dispute. — Edokter • Talk • 15:36, 9 November 2010 (UTC)
No .plainrowheaders
|
.plainrowheaders with shaded background
|
.plainrowheaders with plain background
|
Technically, any deviation from standard bold, centered and gray background for headers is violating the MOS. I am going to repeat some key elements here as to how this change came to be: WP:DISCOGSTYLE was eager to adopt the scope=row method to make their tables more accessable, but did not like the rendering. First, the headers were left aligned, then unbolded. I think most people were happy with that. Then WP:FLC wanted pure plain header cells that look like data cells, so away went the gray background. I am going to ask everyone again: what is the purpose of styling the row headers any different then standard headers? If I can't get a definitive answer, I am going to remove the styling alltogether, as it is clear that no implementation is going to get the necessary consensus. — Edokter • Talk • 20:27, 9 November 2010 (UTC)
/* row-headers get normal-weight when bold explicitly on-offer; i.e. a it's a route to 'cancel' the ambient bold... */
.wikitable thscope=row b
{
font-weight: normal;
}
We were closest to consensus with only resetting the font styling. I still agree that some indication of a header is the best way to go, and as far as I can see, WP:FLC (well, Rambling Man) was the only one with a very vocal opposition to background remaining untouched. Ironic, as he is the one who suggested to unbold the row headers in the first place, and that is precicely the outcome. Not forgetting that me removing the gray shading started this whole discussion, I am going to revert to the previous incarnation that gained the widest consensus ( #Solution 3). That means only the font-styling is reset, but the background shading remains in all headers. If any project has a problem with this, please remind them that this styling option is offered as an aid to help accessability, not intended to trump any standing conventions. If and how to use it is now entirely up to the projects, and any discussion of its implementation and MOS related issues is outside the scope of this talk page. — Edokter • Talk • 22:17, 9 November 2010 (UTC)
![]() | This is an archive of past discussions. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page. |
Archive 5 | ← | Archive 10 | Archive 11 | Archive 12 | Archive 13 | Archive 14 | Archive 15 |
font-family /**/: inherit;
is declared after font-family for the Unicode, IPA, etc. classes. The comment explains that the second declarations reset the styles for all browsers except IE6, which chokes on the empty comment tags, but I don't understand. What does this exactly do? -- Paul_012 ( talk) 13:16, 31 January 2010 (UTC)
span.mw-headline:target {
background-color: #fbe54e;
display:block;
}
I would like this code to be added to
MediaWiki:Monobook.css to highlight targeted heading (e.g. clicked links from the TOC). The span need to be set to a block element, which is the parent h2 element, so the background extends across all the way. We can also use other CSS properties (color:maroon; border-bottom:1px dashed blue;
) if this is going to break custom styles. —
Dispenser
18:11, 7 February 2010 (UTC)
<h2 style="display:inline;">section</h2>
breaks when highlighted (:target isn't supported on IE). This would be easier if the H2 had the ID, but then <h2 id="
... The whole thing, by the way, is stolen from the
new python documentation interface. Which also has this nifty thing to permalink to section. —
Dispenser
19:21, 7 February 2010 (UTC)
.mw-headline span:target,
span.mw-headline:target {
background-color: #fbe54e;
display: block;
}
== <span id="An example">An <nowiki>{{example}}</nowiki> heading</span> ==
Could "display:inline-block
" be added to the styles for ol's and ul's? When either an ordered or unordered list is to the right of a left-floated image or other div, the numbers or bullets run into the image. (Effect can be seen on any stub article with a picture that extends into the references section.. off the top of my head, one can be found
here.) By adding the inline-block display setting, the problem is fixed. I probably haven't done as much cross-browser testing as I should, but it works in Firefox, Safari, Opera, and Camino.. those are the only ones I have (Mac OS X). Can someone test it in IE and possibly some other browsers? --
Dudemanfellabra (
talk)
07:47, 4 February 2010 (UTC)
I'm aware that multi-digit numbers will overlap; but I don't see any serious problem with the example above on FF3.5. What browsers do you see a problem on? Are you really saying that left-floated images in the middle of multi-digit ordered lists, are a sufficiently serious problem to require us to impose this fix on all lists? More seriously, have you tried with a long line?
The list simply wraps underneath the image, defeating the purpose of the exercise. As I said before. Happy‑ melon 23:07, 4 February 2010 (UTC)
background-color: #fbe54e; display: block;
background-color: #dfe6ff; display: block;
background-color: #dfe6ff;
color: #008040;
End of test headers. The below discussion is a continuation of the discussion above the test headers, and is about all the above headers and more.
-- David Göthberg ( talk) 19:32, 8 February 2010 (UTC)
display: block;
". Or we can make the gadget insert the [edit] button inside the "<span class="mw-headline"></span>
" thus we will still have the full width colour bar. (We'll have to test to see which looks best, but both should at least work technically.)/* Add an icon before a targeted heading (e.g. clicked links from the TOC). */
.mw-headline span:target,
span.mw-headline:target {
background: url("http://upload.wikimedia.org/wikipedia/en/0/00/Lock_icon_blue.gif") center left no-repeat;
padding-left: 18px;
}
The div.noarticletext
rule is for the
MediaWiki:Noarticletext message. I am planning to change that rule to instead have no border, margin, padding, and transparent background. (I can't just simply remove the rule since it is also declared in
monobook/main.css.) The reason is that we need to be able to control the border and background from code in
MediaWiki:Noarticletext. If anyone wants to know more, see
MediaWiki talk:Noarticletext#More notices.
-- David Göthberg ( talk) 08:37, 15 February 2010 (UTC)
I am considering adding the following:
.iezoomfix div,
.iezoomfix table {
zoom: 1;
}
This would allow people to fix the rendering of right floating elements inside a div block, under Internet Explorer (see Template_talk:Documentation#Problem_with_right-aligned_images). This code does nothing on standards compliant browsers. We can also add it through JS, as IE only code of course. — TheDJ ( talk • contribs) 22:23, 5 March 2010 (UTC)
Hi. There is a discussion at:
that may concern this page. One of the possible solutions to the issues at hand (re-coloring wikitables and reducing their font-size) might be implemented by adding some new classes and/or options to the site-wide css. class="wiki-filmograpy-table" or some such. And if this precedent is set, expect hundreds of more requests for things like "wiki-Hannah-Montana-colors". I'm posting here per a suggestion there by Ms2ger. I've expressed my views in the discussion, already. There is a related prior discussion at:
Cheers, Jack Merridew 20:03, 8 March 2010 (UTC)
{{ latinx}} was recently deleted. Perhaps we should remove its accompanying class ? It seems to be hardly in use as far as I can determine. — TheDJ ( talk • contribs) 11:18, 8 February 2010 (UTC)
{{
Reflist-2}} has been deleted and was the last major use of references-2column
. I did a standard search and see no uses in article or template spaces, but we need to verify this with a dump search. ---—
Gadget850 (Ed)
talk
16:21, 28 February 2010 (UTC)
Proposal: Add the folllowing code
cite:target {
background-color: #ddeeff;
}
If this is added, the line with the text vos Savant, Marilyn (2006). "Ask Marilyn" column, Parade Magazine p. 6 (26 November 2006). will be light blued in the back ground when pressing this link: Monty_Hall_problem#refWhitaker1990.
It has been implemented at the Norwegian Wikipedia [1] and it works there.
See also proposing it here Template_talk:Citation#Coloring_of_the_Cited_source.3F. Nsaa ( talk) 14:35, 5 March 2010 (UTC)
{{
cite xxx}}
for a reason. One of those reasons, is that <cite> is actually an incorrectly used here, considering it's latest HTML5 definition. We use {{
Ref}} in order to be able to change such things. —
TheDJ (
talk •
contribs)
15:10, 5 March 2010 (UTC){{
cite xxx}}
for a reason." However,
WP:CITE#Citation templates and tools says, "The use of citation templates is neither encouraged nor discouraged. ..." Many editors prefer to hand-craft cites. I'm not among them, but WP editors are constrained by
WP:CITE to use the existing citation style in articles which they edit -- to hand-craft cites in articles which use hand-crafted cites. There are now some number of articles out there with handcrafted <cite id=whatever>...</cite> in them which now have the cite highlighting broken. I vaguely recall that there is an issue there with later versions of HTML, but don't recall the details and don't have time to re-research that at the moment. Anyhow, I'm wondering what approach you would suggest for applying citation highlighting to hand-crafted cites.<cite>...</cite>
is supposed to be used only for the title of a work.
[2] We use it for full citations and notes. Wikipedia does not use HTML5 as yet, but there is a push towards it. ---—
Gadget850 (Ed)
talk
02:17, 8 March 2010 (UTC)
<cite>...</cite>
elements directly in articles?
Nsaa (
talk)
13:46, 14 March 2010 (UTC)<cite>...</cite>
element is to be used for, and only used for, the title of a work. (see
here). Given the guidance in
WP:CITE that "The use of citation templates is neither encouraged nor discouraged", I would say that discouraging the use of the <cite>...</cite>
element in articles implies encouraging the use a template which would take a title and do whatever special handling is needed for titles (i.e., wrap it in a <cite>...</cite>
). The alternative to that would seem to be to change the guidance in WP:CITE and encourage templated vs. hand-crafted citations.<cite>...</cite>
elements appeared as of 2010-Feb-03 (about 75 templates and 2500 articles).
Wtmitchell
(talk) (earlier Boracay Bill)
05:48, 18 March 2010 (UTC)Here is the CSS for striped tables, with a minor color adjustment. This will work in Firefox, Safari, Chrome, Opera and Internet Explorer 9. Dread Lord CyberSkull ✎☠ 13:26, 12 March 2010 (UTC)
/* wikitable/prettytable class for skinning normal tables */
table.wikitable,
table.prettytable {
margin: 1em 1em 1em 0;
background: #f9f9f9;
border: 1px #aaa solid;
border-collapse: collapse;
}
.wikitable th, .wikitable td,
.prettytable th, .prettytable td {
border: 1px #aaa solid;
padding: 0.2em;
}
.wikitable th,
.prettytable th {
background: #f1f1f1;
text-align: center;
}
.wikitable tr:nth-child(odd),
.prettytable tr:nth-child(odd) { /* The striping is handled by the :nth-child pseudo-class, with the odd row adjusted. */
background: #f5f5f5;
}
.wikitable caption,
.prettytable caption {
font-weight: bold;
}
Header |
---|
Table |
Cells |
All the same |
Colour |
Header |
---|
Table |
Cells |
Alternating |
Colour |
I can't tell the difference between the stripe colours, but I can tell that the table cells are less differentiated from the header cells. Why is this considered a good idea? Happy‑ melon 18:26, 12 March 2010 (UTC)
A few points; the two colors are too close to each other and a bit more differentiation would be needed to deploy this. Also, it's likely that the even/odd arrangement is backwards and that it would be better to have the first (odd) rows be the ones with the lighter cell color. And I do believe this would be best as an option on wikitables, not the norm; i.e. invoke it with:
{{ class="wikitable striped"
Wandering a bit, I think the the bolding of th-elements should be made explicit rather than relying on the typical browser default styling. This would be something like:
.wikitable th,
.prettytable th {
background: #f1f1f1;
text-align: center;
font-weight: bold; /* added */
}
Cheers, Jack Merridew 18:35, 3 April 2010 (UTC)
× | 1 | 2 | 3 |
---|---|---|---|
1 | 1 | 2 | 3 |
2 | 2 | 4 | 6 |
3 | 3 | 6 | 9 |
.wikitable.zebra tr:nth-child(odd)
{
background-color: yellow;
}
.wikitable.zebra tr:nth-child(even)
{
background-color: pink;
}
If we add something like the above, we'll have an optional version of this. I'm not advocating yellow or pink, they're just for clarity in the example (which is all hard-coded). I've omitted "prettytable" as we want to be deprecating that and should not offer any new features under the old name. I've also used the class name 'zebra' per zebra striping, but would be fine plain "striping", although we might want that for non-even/odd striping, someday. nb: the keywords odd/even and this multiplication table example are a bit at odds, as the heading row counts as row '1' while row '1' is the second row ;)
Cheers, Jack Merridew 22:01, 6 April 2010 (UTC)
ok. The pink and yellow sucks. Let's float something more realistic.
xyzzy | Plover | Get Axe | Fee Fie Foe Foo |
---|---|---|---|
Little maze of twisting passages | Little maze of twisty passages | Little twisty maze of passages | Little twisting maze of passages |
Maze of little twisting passages | Maze of little twisty passages | Maze of twisting little passages | Maze of twisty little passages |
Twisting little maze of passages | Twisting maze of little passages | Twisty little maze of passages | Twisty maze of little passages |
Little maze of twisting passages | Little maze of twisty passages | Little twisty maze of passages | Little twisting maze of passages |
Maze of little twisting passages | Maze of little twisty passages | Maze of twisting little passages | Maze of twisty little passages |
Twisting little maze of passages | Twisting maze of little passages | Twisty little maze of passages | Twisty maze of little passages |
.wikitable th
{
background-color: #e9e9e9; /* changed */
text-align: center;
font-weight: bold; /* added */
}
/* new: */
.wikitable.zebra tr:nth-child(odd)
{
background-color: #f1f1f1;
}
.wikitable.zebra tr:nth-child(even)
{
background-color: #f9f9f9;
}
This example darkens the header cells a tad (to #e9e9e9) and uses the former header color (#f1f1f1) for the odd rows and is explicitly setting the usual data cell background-color to the normal (#f9f9f9); 'even' could be omitted and allowed to inherit from the ambient table styles.
Any interest?
Cheers, Jack Merridew 05:08, 15 April 2010 (UTC)
Is the bit about being supported in "Internet Explorer 9" a joke? --
MZMcBride (
talk)
21:36, 18 April 2010 (UTC)
Ya, all the modern browsers support this, and Microsoft may-well have one, too; next year (or moar;). And it should all degrade gracefully. I'm not too fussed about just what shades of gray are used and there may be a bit of concern about changing the header cell background. It would also bee goodness to offer a bit of guidance about when this is appropriate to use. Tables with rowspans would get odd effects, for example. Cheers, Jack Merridew 22:09, 18 April 2010 (UTC)
Hi. I believe the following css would be cleaner as it avoids displaying empty <ul>
elements (i.e. those with 0 visible <li>
elements):
status quo | suggestion |
---|---|
.toclimit-2 .toclevel-2,
.toclimit-3 .toclevel-3,
.toclimit-4 .toclevel-4,
.toclimit-5 .toclevel-5,
.toclimit-6 .toclevel-6,
.toclimit-7 .toclevel-7 { display: none; }
|
.toclimit-2 .toclevel-1 ul,
.toclimit-3 .toclevel-2 ul,
.toclimit-4 .toclevel-3 ul,
.toclimit-5 .toclevel-4 ul,
.toclimit-6 .toclevel-5 ul,
.toclimit-7 .toclevel-6 ul { display: none; }
|
Rather than affecting the list items directly, it invisiblizes whole lists starting at the previous depth. ― AoV² 09:25, 18 March 2010 (UTC)
Bump to avoid archive-bot. ― AoV² 03:57, 4 April 2010 (UTC)
Discussion moved from Template talk:Infobox UK place#Centred text?
Microsoft recently removed en.wikipedia.org from its IE8 compatibility-mode list, so IE8 clients with the latest list now see Wikipedia rendered in standards-mode by default. This seems to have caused <TH>
table-header content to render with centered text even where the parent <TABLE>
table tag has inline CSS style="text-align:left"
. For example, the infobox headings at
Template:Infobox UK place/testcases now render center-aligned in IE8.
The problem appears to be that table-header elements do not inherit the text-align style of their parent TABLE element in IE8 standards mode, as documented here. Should MediaWiki:Common.css be amended to include a workaround?
— Richardguk ( talk) 21:50, 13 April 2010 (UTC)
This is not really a bug in IE8 at all. Both the HTML5 and CSS2.1 specs recommend this result. I've filed bugs against Gecko and WebKit. Apparently this weird behavior of th (that alignment is mysteriously inherited from the parent element sometimes but not always) is due to some kind of pre-CSS legacy constraints.
Bug or not, the suggested fix will hurt far more than it helps. It will make all th elements left-aligned, not just ones with text-align:left specified on a parent. I'd recommend you code for the (standards-compliant, CSS-based) IE8 behavior and explicitly specify left alignment on your th's when you want it. — Aryeh Gregor ( talk • contribs) 18:30, 14 April 2010 (UTC)
.infobox td, .infobox th { vertical-align: top; }
.infobox td, .infobox th { vertical-align: top; text-align: left; }
.infobox.geography th { text-align: left }
<table class="infobox geography"><tr align="center"><th>...
; the change I suggest isn't free of side effects. The only side effect-free solution would be to alter all the templates by hand. —
Aryeh Gregor (
talk •
contribs)
17:08, 16 April 2010 (UTC)
.infobox th { text-align: inherit; }
I think you′ll find more of them have an over-ridden style attribute text-align:left;
. Perhaps only the <th>
cells on the first row of a table (or those whose colspan is such that it occupies an entire row) should have text-align:center;
as a default, something like:
th { font-weight:bold; text-align:left; }
tr:first-child th, th:only-child { text-align:center; }
Typical arrangement in rendered infobox:
<tr><th>Population </th><td>Over 9,000</td></tr> <!-- th should be text-align:left; -->
<tr><th>Power level</th><td>Over 9,000</td></tr> <!-- th should be text-align:left; -->
<tr><th colspan="2">Politics</th></tr> <!-- th should be text-align:center; -->
In wikitable:
{| class="wikitable" ! Year ! Foo !! Bar !! Baz <!-- should all be text-align:center; --> |- ! 1979 <!-- should be text-align:left; --> | Lorem || Ipsum || … |- ! 1980 <!-- should be text-align:left; --> | … || … || … |}
― AoV² 19:10, 18 April 2010 (UTC)
[[Main Page|Foo <code>Bar</code> Baz]] |
→ |
Foo Bar Baz
|
→ | see screen-shot |
For whatever reason the <code>
tag interrupts the under-lining of a link which contains it, at least on my screen (see above):
Recommend:
a code { text-decoration:inherit; }
― AoV² 02:15, 14 April 2010 (UTC)
<tt>
is a deprecated element. What are we supposed to recommend they use instead?
Happy‑
melon
10:23, 15 April 2010 (UTC)
This is because of
Mozilla bug 365970, and a similar bug in WebKit. Opera behaves correctly, and it seems so does IE. text-decoration: inherit will not work quite right in general, because the underlines will be inherited instead of drawn from the parent element: this can produce weird results in cases like
AB
C. In Firefox, this displays with a noticeably different underline for "B", because the underline is redrawn with the different font size. (WebKit seems to use the same underline thickness independent of font size.)
This oddity might not be serious enough to be worried about, though. Probably
a code, a tt { text-decoration: inherit }
is a reasonable addition to the site CSS for skins that use different backgrounds for code. Or just doing
code, tt { background: none }
would solve the problem, too, removing the barely-visible gray background. — Aryeh Gregor ( talk • contribs) 16:57, 16 April 2010 (UTC)
a * { background: none !important; }
<tt>...</tt>
is not deprecated for HTML 4 and XHTML,
[3] but CSS is recommended instead. It is not supported in HTML 5, nor are center, big, small and s.
[4] We are moving toward HTML 5, so this is something to keep in mind, ---—
Gadget850 (Ed)
talk
19:33, 18 April 2010 (UTC)I propose to add
page-Special_UserLogin .mw-label { white-space : nowrap; }
This avoids that the labels of the input fields on Special:UserLogin are spread over two lines ("retype password" and "E-mail (optional)". This is especially notable on the Signup page, when you are not logged into Wikipedia. I think it makes it a lot more readable. — TheDJ ( talk • contribs) 18:07, 3 April 2010 (UTC)
page-Special_UserLogin .mw-label label { white-space : nowrap; }
{{ editprotected}}
.page-Special_UserLogin .mw-label label { white-space : nowrap; }
{{ editprotected}} Not to be a nudge, but where did the "_signup" come from?
body.page-Special_UserLogin_signup .mw-label label { white-space : nowrap; }
it should be:
body.page-Special_UserLogin .mw-label label { white-space : nowrap; }
(or both, if the _signup form is used somewhere). Cheers, Jack Merridew 00:27, 7 April 2010 (UTC)
It would also leave less width for the <div class="prefsectiontip">
which follows. I think we′d address this best by putting it in its own cell on a separate row with colspan="2"
, either directly below the wpEmail
row or below the mw-submit
buttons. Also the asterisk in that message invokes an unordered list rather than matching the literal asterisk in “E-mail (optional)*”. ―
AoV²
00:03, 4 April 2010 (UTC)
<p id="userloginlink"><p>Already have an account? <a href="/?title=Special:UserLogin&type=login">Log in</a>. </p></p>
The differing body-class appears only when you use url with a slash after the title of a special page, not in the default link which uses a separate parameter, viz. title=Special:UserLogin&type=signup. See also bugzilla:23315. ― AoV² 12:14, 28 April 2010 (UTC)
Hi there, I have my own MediaWiki set up, and I saw another has this code.
.page-Special_RecentChanges [title="User:<USERNAME>"] { font-weight: bold; color:#70B04A; }
I'm wondering why this isn't working for me. I placed it near the end of my Common.css. If someone could get back to me I'd be much obliged. Smashman2004 ( talk • contribs • email) 10:34, 27 April 2010 (UTC)
body.page-Special_RecentChanges atitle="User:<USERNAME>"
I proposed a change to {{
portal box}}
that requires also a change of this page. See the discussion at
Template talk:Portal box#Better syntax.
Svick (
talk)
20:58, 3 May 2010 (UTC)
I just noticed that since the wikitable move, there is no longer wikitable css for print. See this. We need to follow that up. — TheDJ ( talk • contribs) 02:54, 13 May 2010 (UTC)
From the indications at the VP and many other related pages, it is clear that the new logo is much despised. I therefore suggest the unusual, but possibly warranted inclusion of the following line:
#p-logo a {background-image: url(http://upload.wikimedia.org/wikipedia/en/6/6b/Wiki.PNG) !important;}
-- Ipatrol ( talk) 20:25, 13 May 2010 (UTC)
WP:VPT#New logo AON. Also, lack of complaints from readers does not mean approval. It usually means that they don't know how to or want to get involved with us. Consensus of the interested should decide this.-- Ipatrol ( talk) 01:50, 14 May 2010 (UTC)
{{
editprotected}}
Since the talk page of
MediaWiki:Print.css (
|
talk |
history |
links |
watch |
logs) redirects here, I'm putting my request here. Please add .ns-0 .rellink,
to the first CSS item there. {{
Rellink}}, which uses this class, is a meta template for showing links to related articles. The template and its derivatives are currently in the category "Exclude in print", but this only prevents the templates from being shown in the book tool. To make it work with the usual printing, skinning it here would be needed. An alternative would be to add class="noprint" to the template itself, but there might be situations in which one might want to print it, possibly in other namespaces. Thanks, --
The Evil IP address (
talk)
15:31, 19 May 2010 (UTC)
See Wikipedia:Requests for comment/May 2010 skin change/Bug reports#Reflist template. ---— Gadget850 (Ed) talk 21:16, 7 June 2010 (UTC)
I wanted to ask how to do the line around the code when you add the <syntaxhighlight> or <SOURCE> tags to show the code? I wanted to know so that i can add it for pa wiki, i think it looks better that way, with code separated from rest of article. Thank You. Also is there a better place to ask these sort of questions? Gman124 talk 14:03, 14 July 2010 (UTC)
[6] That latest change disabled my Firefox (3.6.7) browser (using Windows 7) from choosing the fonts I have specified for IPA in my own user:Mahmudmasri/vector.css. I need help. The latest change made it only possible for my browser to choose my specified fonts if there were texts written as {{IPA|/tekst/}} only after I wrote that: span[class|=IPA] rather than .IPA, but still I have a problem: all the IPA wikitables such as Help:IPA conventions for English#Vowels don't choose my specified font for IPA. Please, help me overcome the problem. -- Mahmudmasri ( talk) 07:39, 24 July 2010 (UTC)
Wikitable is now defined in shared.css. [12] ---— Gadget850 (Ed) talk 17:55, 27 April 2010 (UTC)
I removed the wikitable definitions and left the prettytable ones until we get the above list sorted out. — TheDJ ( talk • contribs) 23:57, 27 April 2010 (UTC)
content
property or just break it like with .hiddenStruct
? Its been on the
/to do list for the last ten months. I fear the stalemate will continue. —
Dispenser
04:12, 28 April 2010 (UTC)I pulled the trigger on this one. It was about time. — TheDJ ( talk • contribs) 17:10, 13 May 2010 (UTC)
Because of a long-standing Firefox bug, marking up transliterated text as such results in ugly output, e.g. consider {{IAST|thiṣ}}, rendered as "thiṣ" when it really ought to look the same as "thiṣ". This happens because the transliterated text is marked up by the CSS as being in a <span lang="sa-Latn">…</span>, which the browser is failing to understand is still in Latin script. As the comment on the Firefox bug says, we're "left with the choice of forcing a latin compatible font on the user, or removing lang tags for transliterated text". Could we do something in CSS to fix this? For further details please see MediaWiki_talk:Common.css/Archive_7#Ugly_fonts_for_transliteration_templates, Template talk:IAST#Font selection and Template talk:Transl#Font for translated words. As dab suggests there, it may be possible to fix this by introducing a pseudo-class for sa-latn, ar-latn, and a few others. Shreevatsa ( talk) 17:57, 30 July 2010 (UTC)
Here's the problem as it appears for me (Firefox 3.6.8 Vista) in Clay Sanskrit Library. The surrounding font is Gentium (according to my style sheet), whereas the Template:IAST text is an atrocity. The bottom line is that, if there is nothing I can do to get a correct result here, then I would be far better off with the template scrapped. Wareh ( talk) 18:19, 5 August 2010 (UTC)
The code discussed at MediaWiki talk:Common.css/Archive 12#Noarticletext should be moved into Monobook.css and Modern.css because all other skins do not have CSS for this class. — AlexSm 04:01, 6 September 2010 (UTC)
{{
edit protected}}
Could a sysop replace
http://upload.wikimedia.org/wikipedia/commons/thumb/a/a6/Gnome-speakernotes.png/30px-Gnome-speakernotes.png
with
http://upload.wikimedia.org/wikipedia/commons/3/3f/Gnome_speakernotes_30px.png
And also protect the new image? I've losslessly compressed it to save 101 bytes. Smallman12q ( talk) 13:20, 8 September 2010 (UTC)
To keep discussion centralised please comment at Wikipedia:Village pump (technical)#Proposal, Rambo's Revenge (talk) 11:51, 4 October 2010 (UTC)
Permalink: http://en.wikipedia.org/?title=Wikipedia:Village_pump_(technical)&oldid=389777733#Proposal -- MZMcBride ( talk) 22:15, 9 October 2010 (UTC)
Proposed: Add the following code to MediaWiki:Handheld.css in order to stop unwanted font size transformations on devices like the iPhone when the non-mobile site is used.
body {
-webkit-text-size-adjust: none;
}
Thoughts? -- MZMcBride ( talk) 17:43, 9 October 2010 (UTC)
body.iphone {
-webkit-text-size-adjust: none;
}
I guess this could work. — TheDJ ( talk • contribs) 21:23, 11 October 2010 (UTC)
Hey. I've floated a few ideas on a number of talk pages and I'd like some feedback from the regulars here.
I know that wikitable went to shared.css, which is great, and what I'm taking about might be better discussed on whatever meta page goes with that. But I'm thinking that a trial here might precede that; talk first, of course. Below are some snippets. They arose out of discussions that are still underway regarding accessibility.
/* existing: */
.wikitable th
{
background: #f2f2f2;
text-align: center;
}
/* new override: row-headers get left-aligned */
.wikitable thscope=row
{
text-align: left;
}
/* new override: lists in data cells are always left-aligned */
.wikitable td ul,
.wikitable td ol,
.wikitable td dl
{
text-align: left;
}
/* new explicit rule; most browsers do this for us */
.wikitable th
{
font-weight: bold;
}
/* new explicit rule; but don't bold refs */
.wikitable th sup
{
font-weight: normal;
}
If the new practice of scope-tagging row-headers sticks in the MOS, I believe the center-alignment will produce push back because many will not like the presentation applied to row headers; I expect the centering is primarily about targeting column headers, which are far more common. The paucity of row-headings is likely due to people not liking the current styling.
The DISCOG people like lists in data cells and lists really look terrible when not left aligned. This has resulted in huge amounts of align="left" getting baked into tables. User agents typically center table header cells, so we're getting that effect for the most part, already; I think we should make it explicit. The final snippet is a special case for refs that appear in headings; they're getting bolded and it is not a nice effect. FWIW, I'm not too keen on refs in headings, and things really get messy when there are sorting controls present, too. Comments?
Cheers, Jack Merridew 00:37, 15 August 2010 (UTC)
.wikitable th[scope=row]
looks like CSS3. How is this going to render on older browsers?
Happy‑
melon
23:54, 15 August 2010 (UTC)! style="text-align:left;"
at every row. Hey, the Usability initiative is trying to make it easier to edit by removing excessive code from articles (template folding), and we are only increasing the quantity of code we use? That just won't do. Even worse, users are now starting to use the deprecated align="left"
. Now which one is more important? Compatibility to IE6 who will eventually die sooner or later, or future-proof code? I'd say we should aim for future-proof code. Kind regards,
Dodoïste (
talk)
23:59, 29 September 2010 (UTC)
scope="row"
would be added (by hand, as I believe I took it) to every such cell. That sounds awful, to be sure, and it's not great, but very often it'd be replacing align=left
or similar. As I understand it, the scope attribute tells UAs something important (useful for assistive technology, I think) whereas the align attribute just says "show it to the left". I believe some discussion touched on classes and as I recall, Jack Merridew had strong reasons for preferring the scope approach. However, I may very well have this backwards, and maybe Jack didn't passionately hate the idea of adding a new class to the CSS (and we'd still have to add them to all the wikitables); the best thing to do would be to invite Jack over to clear things up for us. Certainly my memory and understanding of these bits are rather foggy. —
JohnFromPinckney (
talk)
20:24, 30 September 2010 (UTC)
! scope="row" |
- themselves, and they will do so only if the layout result is appropriate. Thus the CSS selector and the align left by default.style="text-align:left;"
or deprecated align="left"
. Actually, I really doubt any class could be shorter than the deprecated code..wikitable th[scope=row]
at least temporarily, and when a developer makes the corresponding change to MediaWiki we will simply remove it in favor of MediaWiki.style="text-align:left;"
already. The issue is, most of the time editors are not making row headers.{{
editprotected}}
This proposal was refined through the discussion. This proposal seems almost consensual, since Edokter is the only one to oppose. 6 users support this proposal, and this proposal is much needed that the WikiProject discographies (and later on other projects, when they will try to improve their accessibility).
A few changes happened during the discussion, and the explanation of this proposal is dispatched here and there. So here is a summary.
Concerning table accessibility, headers must be marked manually as either row headers or column headers. As explained in the data tables tutorial I recently made according to W3C's WCAG 2.0 techniques. Sighted users can visually deduce from context which headers are supposed to be column headers or row headers. But a machine can't, thus blind users using a screen reader can't either and will have a hard time to navigate the data. And machines reusing the content will also have a hard time to associate cells to their headers.
So users must make row headers and mark them with scope="row"
. But row headers are centered by default, which makes them look messy. So users have to add extra code in every row header (style="text-align:left;"
) to have them left aligned. This makes the table more complicated to newbies and more complicated to produce. Thus, users are reluctant to make row headers. This proposal is about adding a single line of code into MediaWiki:Common.css that does the job for them.
This code works in every major browsers, except IE6. But it's not a problem since this is only a minor layout bonus: no lost of content or important info happens when this is not supported. IE6 users will simply have their row headers centered as they are now anyway. This proposal complies to the Progressive enhancement best practice.
As explained above, other solutions are either impossible or suboptimal. This one is very simple and much needed to encourage the users to improve accessibility. This proposal is much needed in a ongoing improvement of the accessibility of WP:DISCOG tables, and will be necessary when reaching to other projects.
/* row-headers get left-aligned */
.wikitable thscope=row
{
text-align: left;
}
Dodoïste ( talk) 17:17, 2 October 2010 (UTC)
Not done for now: I have disabled this request due to lack of consensus. While it is just one editor who is expressing concern about this change, Edokter does seem to have valid points which do not seem to have been fully addressed. As edits to this page cannot easily be reverted due to caching, we must be completely sure that all changes correct. Therefore I ask that you continue to discuss this issue and work around the issues. — Martin (
MSGJ ·
talk)
17:38, 10 October 2010 (UTC)
scope="col"
to <th>
column headings. I have started doing this already. So far (as I've noticed, anyway), nobody has reverted or removed this somewhat strange and unfamiliar addition. As for changing table cells to headers, well, that's just good common sense and how all Web sites on the planet should be coded. That one of the ten most-visited sites (based on the ease of editing by such smart people from all over the world) has incorrect mark-up is a large embarrassment. I know that other sites, including large and popular ones, often have inappropriate mark-up or invalid HTML or JavaScript errors or rely on colors or assume a certain window size or exhibit any of a zillion other dumb mistakes, but we don't have to do that. We can do it right, and this change is about making doing the right thing more attractive. —
JohnFromPinckney (
talk)
23:08, 11 October 2010 (UTC)scope="col"
can be automated on a per-project basis. For example, the discographies tables are consistent, so a bot could do it and we'll definitely try this approach. But in order to produce relevant row headers, the DISCOG tables must be restructured, so this can't be automated. Done. We seem to have consensus that this change is warranted. If a better solution turns up, we can modify this later. — Martin (
MSGJ ·
talk)
12:11, 12 October 2010 (UTC)
The
WP:DISCOG people like lists in data cells. Their cells have often centered text applied to the whole table, so the list get left aligned by default. And lists really look terrible when not left aligned. This has resulted in huge amounts of the deprecated align="left"
getting baked into tables, instead of the longer but correct style="text-align:left;"
. There are similar other cases where cells are added manually these codes, which makes the table more complex, especially for newbies.
Not to mention it is suboptimal regarding bandwidth too because these styles are contained in every cell, instead of being once in MediaWiki:Common.css as proposed. This proposal seems consensual. It is about adding:
/* lists in data cells are always left-aligned */
.wikitable td ul,
.wikitable td ol,
.wikitable td dl
{
text-align: left;
}
Dodoïste ( talk) 16:59, 2 October 2010 (UTC)
Added — Martin (
MSGJ ·
talk)
12:14, 12 October 2010 (UTC)
{{
editprotected}}
I've been bothered by the font selection for
IAST
Sanskrit transliteration, chosen by
Template:IAST. It looks like it isn't defaulting to something that is totally unreadable and hideous anymore, but the selection of "Free Serif" as a top choice is troubling. I have been working with web design that involves Sanskrit transliteration, and I spent a fair amount of time digging through fonts and CSS settings, finding exactly which fonts can support it, and will render well on
Windows (and
Mac OS X and
Linux too, for that matter). Now today I finally dug into the matter and inspected the CSS being applied to the IAST template, using the Firebug add-on in Firefox. The exact CSS class that chooses these fonts is part of a Windows-specific CSS file:
MediaWiki:Common.css/WinFixes.css, and in here it is the "Unicode" class. I am proposing the following change to the "Unicode" class in this file, which I will explain.
.Unicode {
font-family: "Microsoft Sans Serif", "Arial Unicode MS", "Free Sans",
"Gentium Basic", "Gentium", "GentiumAlt", "DejaVu Sans",
"DejaVu Serif", "Free Serif", "TITUS Cyberbit Basic",
"Bitstream Cyberbit", "Bitstream CyberBase", "Doulos SIL",
"Code2000", "Code2001";
font-size-adjust: 0.54;
}
Arial Unicode MS and Microsoft Sans Serif are probably the best available fonts widely available on Windows for this Unicode class. They harmonize with the default Arial font, and they are both very full-featured. Neither has a real oblique or italic, but the faked oblique is legible and clear. Most importantly, Arial Unicode MS is installed on every system with MS Office, and Microsoft Sans Serif is installed on every Windows system, at least since Windows XP. Free Sans is a similarly good font in the same exact style as the other two, also full-featured, albeit with less hinting. The rest go on to Gentium and the DejaVu fonts, which are each good in their own right and Open Source, and can display acceptably, but are not well hinted. Then come the other Unicode fonts that are in general a bit ugly, but can cover a larger range than some of the other Unicode fonts. Therefore, everything goes by aesthetics and functionality, generally from better to worse.
The second line is very important, which is a CSS font-size-adjust directive. Without this directive, fonts such as Gentium and FreeSerif will appear too small to be legible. This is because fonts display at very different sizes even if the point size is calculated the same. This is due to the difference in x-height and the general difference in metrics between fonts. This can be very pronounced between sans-serif and serif faces. Without this directive, a serif fallback such as Gentium, Free Serif, or one of the others, would be too small to be legible. This is currently happening with the "Unicode" class when it falls back to Free Serif, which is one of the current top choices. Adding this directive will fix the problem. The setting of 0.54 is tuned for the top choices and tested in the major browsers, so they will display at sizes that are even with the rest of the text.
Those are my two rationales for the changes to the "Unicode" class in MediaWiki:Common.css/WinFixes.css. If an administrator could help make that change to the page, it would be much appreciated. Tengu800 ( talk) 01:58, 24 August 2010 (UTC)
{{
rfctag|policy}}
.Unicode {
font-family: "Arial Unicode MS", "Microsoft Sans Serif", "Free Sans",
"Gentium Basic", "Gentium", "GentiumAlt", "DejaVu Sans",
"DejaVu Serif", "Free Serif", "TITUS Cyberbit Basic",
"Bitstream Cyberbit", "Bitstream CyberBase", "Doulos SIL",
"Code2000", "Code2001";
font-size-adjust: 0.54;
}
Can we move the in-line styles from {{ Unbulleted list}} to the main stylesheet? The current markup is:
<ul style="list-style:none none; padding:0px; margin:0px">
I propose to change that to
<ul class="unbulleted-list">
or, if a shorter name is needed, class="ublist"
.
This template is used (primarily in infoboxes) to create lists such as:
cat
dog
mouse
using the correct HTML list mark-up, currently:
<ul style="list-style: none outside none; padding: 0px; margin: 0px;">
<li>cat</li>
<li>dog</li>
<li>mouse</li>
</ul>
with styles to hide the bullets, replacing the common but unsemantic markup:
cat<br />
dog<br />
mouse<br />
It will be increasingly and very widely deployed; often multiple times on one page. It's also intended that the style should be available to other templates, not necessarily by calling this one. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 15:46, 16 August 2010 (UTC)
display: inline;
to produce more semantic and accessible list in Navboxs. Like ul#inline li { display: inline; }
. Yours,
Dodoïste (
talk)
20:01, 16 August 2010 (UTC)
|primeminister=
and |party=
in the Infobox on
Charles de Gaulle. I created {{
Flatlist}} and its class="horizontal"
some time ago, for your other use-case. It still needs a little polishing.
Andy Mabbett (User:Pigsonthewing);
Andy's talk;
Andy's edits
23:03, 16 August 2010 (UTC)
So how do we actually make this happen. Is there an equivalent of {{ Editprotected}}? Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 20:18, 21 August 2010 (UTC)
I feel that it would be better that table row headers did not display in bold on Wikipedia and that we should impose normal font weight. This overwhelms the lists it has been used on, such as on Fantasia Barrino discography. I am not aware of the reasoning behind the use of bold in row headers, but would be keen to find out. The Rambling Man ( talk) 15:34, 4 November 2010 (UTC)
! scope="row" |
" is necessary. Headers a simply bolded by default by browsers, as it was already explained..wikitable th[scope=row] {text-align: left;}
. The Rambling Man is only asking that the same consideration be given to removing the stylistic impact of the bolding; in other words, could we add: .wikitable th[scope=row] {text-weight: normal;}
. I think it is worthy of proper discussion here, as it would resolve multiple concerns at FLC, but obviously we need to take into consideration its potential impact in other areas of the project. --
RexxS (
talk)
17:59, 4 November 2010 (UTC)th
{
display: table-cell;
font-weight: bold;
padding: 1px;
vertical-align: inherit;
}
I've attempted to start a centralised discussion here. Thanks. The Rambling Man ( talk) 19:03, 4 November 2010 (UTC)
We can't just change the bolding of row column headers to non-bold. There are probably many tables that depend on this. The problem here is that ACCESS team is adding header fields to tables for the sake of semantics and not for visual effect. As such our current visual effect for such headers is applied, while that is not really appropriate. Suggest adding adding a new class.
table.wikilist thscope=row {
background: #F9F9F9;
font-weight: normal;
text-align: left;
}
This would give you "plain layout" when you use class="wikitable wikilist", while still being semantically correct for screenreaders. — TheDJ ( talk • contribs) 23:10, 4 November 2010 (UTC)
table.wikilist thscope=row {
background: transparent;
font-weight: normal;
}
th
(!
) mark-up, but omit the scope="row"
that we're supposed to be adding; orth
(!scope="row"
), which we've cranked down to normal weight, and add '''
to add bold mark-up on the header cell contents (assuming that'll work, of which I'm not sure); orActually, text-align for this case should probably be reset to "inherit". So final code proposal:
.wikilist thscope=row {
background: transparent;
font-weight: normal;
text-align: inherit;
}
— TheDJ ( talk • contribs) 03:44, 5 November 2010 (UTC)
This began months ago. I began experimenting with more explicit row headers (!) in things like filmography tables and Dodoïste began advocating explicit scope attributes in table header-cells. This all kicked-up some dust when Kelly Rowland discography became a FLC. The WP:DISCOG crowd's style-guidance was sharply at odds with the MOS, and the proposals above at #some wikitable ideas emerged in my talks with them.
I'm not keen for the "wikilist" solution. First, the name is poor; that should be for the list elements, such as OL, UL, DL. Second, it amounts to a purely presentational option, a fork of our table-styling. The word 'list' would seem to be simply an artifact of where the fuss originates. If this route is pursued, name it 'plain'. Consider the following rule to simply force normal weight for scope-tagged row headers:
/* row-headers get normal-weight */
.wikitable thscope=row
{
font-weight: normal;
}
or the following to de-bold when someone's explicitly italicized the contents of a scope-tagged row header:
/* row-headers get normal-weight when italics on-offer */
.wikitable thscope=row i
{
font-weight: normal;
}
These won't sort all cases, notably the quoted-but-not-italic stuff at: Rihanna discography#Studio albums and Fantasia Barrino discography#Singles. In the above #some wikitable ideas thread, Edokter had some valid concerns about the futility of attempting to hard-code millions of pages with proper scope attributes. The approach of having them generated needs to be explored as it is the only way to get consistency. This may even entail a tweak to our wiki-text syntax for table. Cheers, Jack Merridew 18:24, 5 November 2010 (UTC)
I have to agree with TheDJ here, in that the majority of editors expect to see behaviour that is inherent to tables. I still believe that forcing all row headers to show as plain by default is not the way to go. I do however like the idea of adding a seperate class for those that want plain row headers, but .wikilist is a poor name. Instead, the name should convey it's function, so I propose it would be called .plainrowheaders, which gives row headers normal weight and left-aligned text. But I do recommend leaving the original header background color, so it remains recognizable as a header. This gives editors a choice on how to format their row headers, without forcing others to work with semantically-incorrect behaving headers with regards to styling. So this would be my proposed code:
/* Normal font styling for table row headers with scope="row" tag */
.plainrowheaders thscope=row {
font-weight: normal;
text-align: left;
}
— Edokter • Talk • 13:31, 6 November 2010 (UTC)
/* row-headers get left-aligned */
.wikitable thscope=row {
text-align: left;
}
So now we've gone ahead and changed common.css, allowing row headers to be non-bold and left-aligned (or bold and centered). Are we already so happy with this universally that we can say it's a (permanent, at least in wiki-terms) "go" WP-wide? Are we waiting for feedback from the WikiProject:Military folks or the WikiProject:Lighthouses people? Is it all right to blend this into the proposed guidleine at WP:DISCOGSTYLE as if this is the direction we intend to go? (Someone mentioned "a manual methodology and we experiment first", but it seems we've skipped that.)
And what's going on with the idea of Wikimedia auto-generating the scope attributes? Is that a realistic possibility that's moving forward now (somewhere), or is it some wishful thinking for six monthes from now? — JohnFromPinckney ( talk) 20:36, 7 November 2010 (UTC)
Having tried this out on a couple of the tables I helped get to featured status, I now see a very clear grey background in the first cell of each row. Sorry for being so dense for having missed this thus far. What is the purpose of this? Can it be (easily) overridden? The Rambling Man ( talk) 14:53, 8 November 2010 (UTC)
Do we want a plain background color (same as data cell) for .plainrowheaders? — Edokter • Talk • 17:37, 8 November 2010 (UTC)
/* ability to cancel background-color, too */
.plainrowheaderbackgroundtoo thscope=row
{
background-color: #f9f9f9;
}
and class="wikitable plainrowheaders plainrowheaderbackgroundtoo sortable"
would make it optional. Just sayin', not proposing.
Jack Merridew
19:11, 8 November 2010 (UTC)
I'm just trying to find a situation mutually acceptable. ACCESS is important, and our project want to buy into it, but suddenly introducing a grey background after five years (when we've stridently avoid "colour-only" backgrounds, for ACCESS believe it or not) where we, in general, can't see any use for it, and being rather hand-wavy and glib and smug about it, will just result in us ignoring it. I thought we had gone some way to compromise if we accepted the "scope" changes, so screen-readers could use our tables? The Rambling Man ( talk) 20:41, 8 November 2010 (UTC)
Since it was my proposal not to change the background, I feel a bit responsible for the whole debate. I think the initial proposal was to style the entire row header as a data cell, as TheDJ proposed. So I'm withdrawing my objection here. Since it is called .plainrowheaders, not .plainrowheaderfonts, it would actually make more sense. I'll make the background transparent (and simultaniously restrict it's use to .wikitable). The impact will be low, and with enough education, there should be little problem adopting the class="plainrowheaders" + scope="row" method. Remember, there's no rush and nothing is irreversable. — Edokter • Talk • 23:28, 8 November 2010 (UTC)
So... what, now? It seems we've gone to the greatest effort possible to get the smallest possible effect.
We've endeavored to make sure that only users of screen readers recognize row headings, and everybody else goes without. Editors are not to be encouraged to structure tables according to the data they present, but rather based on what "looks nice", which appears to equate to what the FLC guys are used to seeing.
When given the opportunity to formalize tabular data into semantically correct markup, we've chosen to munge the table markup to most closely approximate a layout table. Editors now have a choice of row headings which are bold, centered and background-shaded (defaults for wikitable, a 67% match with browser defaults), and normal-weight, left-aligned, and unshaded, so that it looks like a (somewhat uncooperative) <td>
table cell. Both of these options force a certain alignment no matter the table's default alignment, so anything else needs to be specified inline on every cell. The first of the two options was described as unusably ugly; the second is imperceptably better to most users. We've really achieved some impressive things: The FLC crowd doesn't have to do anything new, or suffer the trauma of seeing something (ew!) different.
Please tell me we're not going to stop here. When I got on this bus, I thought it was going to take me somewhere nicer. Can't we keep going, or back up a couple of blocks, or something? — JohnFromPinckney ( talk) 03:39, 9 November 2010 (UTC)
plainrowheaders
to subvert the proper rendering of table headings in bold. All-with-JohnFromPinckney, who's right. This change to common.css does not have consensus and subverts the MOS. From under the bus,
Jack Merridew
17:25, 9 November 2010 (UTC)
plainrowheaders
to subvert the proper rendering of table headings in bold" is not a decision for any non-FL director to make, especially because it is your opinion that this rendering is "proper", and is not the opinion of those editors who are working to build content in this encyclopedia. I won't comment further on this issue because I've no desire to be dragged into all this mess, but I've said my piece and will now withdraw. —
KV5 •
Talk •
18:34, 9 November 2010 (UTC)
OK, here are the three examples. No example without scopes, as that is not part of this dispute. — Edokter • Talk • 15:36, 9 November 2010 (UTC)
No .plainrowheaders
|
.plainrowheaders with shaded background
|
.plainrowheaders with plain background
|
Technically, any deviation from standard bold, centered and gray background for headers is violating the MOS. I am going to repeat some key elements here as to how this change came to be: WP:DISCOGSTYLE was eager to adopt the scope=row method to make their tables more accessable, but did not like the rendering. First, the headers were left aligned, then unbolded. I think most people were happy with that. Then WP:FLC wanted pure plain header cells that look like data cells, so away went the gray background. I am going to ask everyone again: what is the purpose of styling the row headers any different then standard headers? If I can't get a definitive answer, I am going to remove the styling alltogether, as it is clear that no implementation is going to get the necessary consensus. — Edokter • Talk • 20:27, 9 November 2010 (UTC)
/* row-headers get normal-weight when bold explicitly on-offer; i.e. a it's a route to 'cancel' the ambient bold... */
.wikitable thscope=row b
{
font-weight: normal;
}
We were closest to consensus with only resetting the font styling. I still agree that some indication of a header is the best way to go, and as far as I can see, WP:FLC (well, Rambling Man) was the only one with a very vocal opposition to background remaining untouched. Ironic, as he is the one who suggested to unbold the row headers in the first place, and that is precicely the outcome. Not forgetting that me removing the gray shading started this whole discussion, I am going to revert to the previous incarnation that gained the widest consensus ( #Solution 3). That means only the font-styling is reset, but the background shading remains in all headers. If any project has a problem with this, please remind them that this styling option is offered as an aid to help accessability, not intended to trump any standing conventions. If and how to use it is now entirely up to the projects, and any discussion of its implementation and MOS related issues is outside the scope of this talk page. — Edokter • Talk • 22:17, 9 November 2010 (UTC)