Template talk:Columns-start

From Wikipedia, the free encyclopedia

New template for making columns of content. Needs tweaking before going live.

Contents 1 Examples 1.1 Old 1.2 New 1.3 Old 1.4 New 2 The CSS 3 Comparison 4 Discussion 4.1 Nomagic 5 Results using screen reader

[edit] Examples

Has all the same variables as {{col-begin}}

[edit] Old

Boolean algebra topics Boolean domain Boolean function Boolean logic Boolean-valued function Canonical form

Complete Boolean algebra Finitary boolean function Forcing (mathematics) Free Boolean algebra Heyting algebra Karnaugh map

Laws of Form Logic gate Logical graph Logical matrix Venn diagram Zeroth order logic

[edit] New

[edit] Old

Text in column 1 more text text text text

Text in column 2 more text text text text

Text in column 3 more text text text text

[edit] New

More examples at old vs new

[edit] The CSS

The CSS used to format the tables:

/* Content in columns with CSS instead of tables [[Template:Columns]] */
div.columns-2 div.column {
    float: left;
    width: 50%;
    min-width: 300px;
}

div.columns-3 div.column {
    float: left;
    width: 33.3%;
    min-width: 200px;
}

div.columns-4 div.column {
    float: left;
    width: 25%;
    min-width: 150px;
}

div.columns-5 div.column {
    float: left;
    width: 20%;
    min-width: 120px;
}

[edit] Comparison

• Main advantage: Columns remain accessible to screen readers, cell phones, and so on. No columns visible on user agents without CSS.
• Advantage: Columns collapse into a straight line if screen is too narrow, due to min-width statement (which should be tweaked)
• Advantage: Display of columns can be turned off in user style sheets for people who don't like them
• Advantage: Only needs three templates; currently named {{columns}}, {{column}}, {{columns-end}}. (Probably need more memorable names.)
• Disadvantage: A little more complicated to remember: {{columns-start|num=2}} instead of {{col-2}} (Could be changed to {{columns|2}}?)
• Advantage: Needs one less template in the article ({{columns-start|num=2}}→{{column}}→{{columns-end}} vs {{col-begin}}→{{col-2}}→{{col-2}}→{{col-end}})
• Disadvantage: Style rules are centralized in the site-wide CSS, can't be edited instantaneously by anyone (though shouldn't need changing anyway, after tweaking. Can still use {{editprotected}} on Mediawiki:Common.css to ask for a change).
• Disadvantage: Not compatible with {{col-break}}, since widths are set by site-wide stylesheet for each div. If a similar setup is done without specifying widths, the divs just fill up the whole width. I don't know of a way to make them size to the content they wrap around like table cells do.
• Advantage: No extra <p><br></p> whitespace before the columns, like in the above example (though this is caused by a Mediawiki bug)

[edit] Discussion

See also previous discussion on content in columns.

Is this the best way to get multiple columns? — Omegatron 06:05, 19 March 2006 (UTC)

I strongly support this change. (Sorry i didnt notice it earlier). Webstandards would be a welcome relief :) --Quiddity 06:05, 1 April 2006 (UTC)

I can live with the linear output for more than three columns on legacy browsers. For two columns it's better to use Wiki makup (a table with align=right or left followed by content floating with it). Three columns are a border case, see below. -- Omniplex 17:53, 1 April 2006 (UTC)

What should the classes and templates be called? — Omegatron 06:00, 19 March 2006 (UTC)

What should the min-width be? Currently it's set for a 600px main content window. Anything narrower will "collapse" the columns back into a non-column layout. — Omegatron 06:00, 19 March 2006 (UTC)

This isn't entirely true. A smaller width will "wrap" the columns. If you set up a 5-column list, but the display is only large enough for three columns (at least 360px wide), the first three columns will appear normal, and the last two columns will appear below the first three columns. —Mike 20:21, 19 March 2006 (UTC)

Should the divs have padding or margins, like the table cells did? The rendering is not exactly the same. — Omegatron 06:00, 19 March 2006 (UTC)

What do we need to tweak to get it to work perfectly on lots of browsers? — Omegatron 06:00, 19 March 2006 (UTC)

Odd templates, both old and new, why not simply use a Wiki-table and be done with it, e.g. as on WP:VPS? With my legacy browser only the old stuff appears as (ugly) table, the new stuff comes in 3*3 rows. Maybe use CSS for the new effect keeping legacy markup for non-CSS browsers. And please use <br /> for valid backwards compatible XHTML instead of HTML <br>. Omniplex 08:16, 19 March 2006 (UTC)

why not simply use a Wiki-table and be done with it

Because you should not use tables for visual layout.

Because plain wiki-tables complicates the article source unnecessarily and makes it harder for non-technical people to edit.

The original template used tables; I am trying to get rid of them.

Without looking into the code, the old templates create a table, replacing simple Wiki markup by templates is harder to understand than the real thing as far as I'm concerned. Plus the known technical disadvantages of templates, e.g. the security issue with vandalism. If you think it's easier go for it, I like Wiki table syntax - okay, maybe I'll use templates later for simple tasks like "this cell valign top" or "that cell small centered bold", so far I do that manually. On WP:WP it's on the border where templates could simplify some tasks.

This isn't about whether to use templates for columns or not. I don't even like columns.  :-) This is about replacing the old column template with a better one.

(And there are no technical disadvantages with templates, as far as I know. Vandalism is an imaginary problem, as widely-used templates are protected, and the regular ones can be reverted just as easily as anything else. None of the templates these are intended to replace have ever been vandalized. There is no significant server load increase with templates, either, according to the lead developer. I think three templates is much easier to understand than 7+ lines of non-intuitive table markup. But again, that's not what this page is about. We're replacing a widely-used template with a better one, not debating whether they should be used in the first place.) — Omegatron 18:31, 19 March 2006 (UTC)

With my legacy browser only the old stuff appears as (ugly) table, the new stuff comes in 3*3 rows

The "new" example shows up as three rows instead of three columns? Did you Wikipedia:Bypass your cache? They're only ugly because I was demonstrating that they can handle all the same options as the old template, including background color, class, and width. I'll find a better example. — Omegatron 15:29, 19 March 2006 (UTC)

Yep, the effect is so simple that we don't need to bother with screen shots, I just copy and paste the output as I see it adding four colons to each line for the threading here...

New

 

Text in column 1

more text text text text

 

Text in column 2

more text text text text

 

Text in column 3

more text text text text

 

...right or wrong, that's the output with my browser. Omniplex 18:07, 19 March 2006 (UTC)

Well, that's what it should degrade to on browsers that don't reproduce the columns, at least. What browser? It's only been tested in Firefox and IE6 so far, and will no doubt need some tweaks for all browsers before going live, as I pointed out above. — Omegatron 18:31, 19 March 2006 (UTC)

Netscape Navigator, more or less all of HTML 3.2, no CSS. Too lazy to check Lynx, but that beast also doesn't know CSS. Netscape 4.x claims to support some CSS, but in reality users should either disable it or up/downgrade their browser. Today probably as irrelevant as IE 4 and 5.

Ick, now I looked into your new code, you want to emulate tables by puzzles of adjacent <div>s. That's a very dubious idea. Get some CSS and accessibility experts to comment on it, my gut feeling is that it's just wrong. Omniplex 19:02, 19 March 2006 (UTC)

Ok. We'll see what some other people say about it.

It's not to emulate tables, though. The content being put into these columns isn't tabular in the first place; they're using tables to emulate columns of content, which is wrong.

Some people want to visually format things next to each other. (Splitting a long list of See also links into multiple columns for visual effect.) I don't think it should ever be done, but some people clearly want to. If it's going to be done, it should be done with divs and CSS like this, so that it isn't misinterpreted as tabular data and degrades gracefully into its original non-column structure on browsers like lynx, cell phones, and screen readers. That's what it's supposed to do. — Omegatron 20:06, 19 March 2006 (UTC)

That is how it appears in my browser, and my browser can reproduce the columns. The problem is the width specifications. The "new" example specifies a 3-column display with a total width of only 50%. This means that the min-width of 200px times three must fit within only 50% of the width of the content. Or in other words, the content width must be at least 1200px wide to see three columns. To see even just two columns (with the third "wrapped") the content width must be at least 800px. If you are seeing three columns in less horizontal space than that it is probably because your browser doesn't support the "min-width" property. —Mike 20:21, 19 March 2006 (UTC)

The min width is currently set for a viewing area of 600px. So if you shrink your browser so that the main content section of the page is narrower than 600px, it "wraps" the divs. This is preferable to squishing them like a table would. This was one of the concerns raised with the current table-based layout. I'm sure the values could be tweaked to an optimal setting for lots of screens and browsers, though.

The columns are a visual enhancement, not a mandatory structural feature. The content looks fine without them, and they should only be rendering when the user agent can handle them nicely. — Omegatron 20:47, 19 March 2006 (UTC)

Point, my nomagic proposal fails miserably when I shrink the browser window width, OTOH my browser is old. Limiting this method to two columns makes sense, that at least preserves the order of the left and the middle table, no right table coming before the middle table. Omniplex 21:18, 19 March 2006 (UTC)

[edit] Nomagic

Proposal without templates and without bullets, here a screen reader would probably confuse columns 2 & 3:

Same idea adding the bullets, the source is short and very simple, but I didn't check the resulting XHTML:

Works with a 10 years old browser, and without any template. Omniplex 21:01, 19 March 2006 (UTC)

Added table summaries for a screen reader. Omniplex 12:20, 21 March 2006 (UTC)

[edit] Results using screen reader

Both templates read fine here with JAWS with the default setting of not detecting layout tables. When tables were used, they were detected as layout tables so that was fine. However, the new solution works no matter what the setting for table reading is.

However, I'd discourage the use of columns this way. I don't notice this because of the settings I use, but by default, the beginnings and ends of lists are announced. When columns are used, the list looks like 4 lists of 6 items, and when a plain bulleted list is used, it seems like one long list of 24 items.

For some reason, all versions of JAWS I'm testing at the moment are ignoring monobook.css and common.css, so I haven't had the chance to use it with the site-wide css enabled. Graham talk 09:45, 20 March 2006 (UTC)

Yeah, I don't like the columns, either, but some people want them, so I'm trying to make them as good as possible. So the new div style is marginally better than the table style? I didn't know screen readers detected layout tables. I don't believe there's any way to make content truly continuous while breaking it into multiple columns. It looks like that will be included in CSS3, but that's years away. — Omegatron 00:44, 21 March 2006 (UTC)

Yep, screen readers can detect layout tables if they are set up that way. But I don't see the point: it just makes them speak useless info. The new layout is therefore marginally better than the old one. Graham talk 12:11, 21 March 2006 (UTC)