banaticus wrote:

I think the problem may have been that not everyone put in: border="1" before. I, uhm, I never did when I created a wikipedia table. Could you post a screen capture of what it looks like to you? Which text-based browser are you using?

That's the problem, hooked on the CSS sugar you never guessed what
shaky ground you had built your tables upon.

You should see the same effect it you do View>Page Style>No Style in
Firefox (ALT V Y N, at least in Linux Firefox).

$ for i in 0 1; do w3m -dump "http://www.mediawiki.org/w/index.php?title=Help:Links&oldid=25568$i#External_links"; done|grep -A 13 ^External\ links|sed 's/^/>/'
External links

Description You type You get
External http://mediawiki.org http://
link mediawiki.org$
External
link with [http://mediawiki.org MediaWiki] MediaWiki$
different
label
External [http://mediawiki.org]
link [1]$
numbered

[http://en.wikipedia.org/wiki/.avi video]
[http://en.wikipedia.org/wiki/.wav sound]                                       video sound

External links

┌───────────┬───────────────────────────────────────────────────────────────────────────────┬──────────────┐
│Description│ You type │ You get │
├───────────┼───────────────────────────────────────────────────────────────────────────────┼──────────────┤
│External │http://mediawiki.org │http:// │
│link │ │mediawiki.org$│
├───────────┼───────────────────────────────────────────────────────────────────────────────┼──────────────┤
│External │ │ │
│link with │[http://mediawiki.org MediaWiki] │MediaWiki$ │
│different │ │ │
│label │ │ │
├───────────┼───────────────────────────────────────────────────────────────────────────────┼──────────────┤
│External │ │ │

$

So what exactly is the bug here? If people want to put border=1 in all their tables for the small fraction of users using text browsers that support it (it doesn't seem to make a difference in lynx), they're free to do so. There's no editing documentation in the software itself.

Throw web standards to the winds and it will be just that much more
work to clean back up when you want to support a new device you didn't
expect would come on the market.

I added a notes to
http://en.wikipedia.org/wiki/Wikipedia:Accessibility#Tables
http://www.mediawiki.org/wiki/Help:Table#Borders_vs._CSS
http://www.mediawiki.org/wiki/Manual:CSS

http://en.wikipedia.org/wiki/MediaWiki_talk:Common.css/Archive_5#Wikitable_borders_without_CSS

I note the CSS in question ships with MediaWiki.
Though the main promotion of it is via Wikipedia.
I found another fun example:
http://meta.wikimedia.org/wiki/Help:Table#Viewing_tables_in_email_and_web_pages_outside_Wikipedia
which looks to me like

[edit] Viewing tables in email and web pages outside Wikipedia

Tables are an essential part of presenting info in an easily
understandable way. Everything on Wikipedia can be copied elsewhere,
and it is encouraged. But Wikipedia tables oftentimes lose their
borders when pasted into web pages, blogs, or email.

The Wikipedia table button produces this:

header 1      header 2      header 3

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

Note the borders around all the cells, and the whole table. Copy and
paste the table into your email, and the borders disappear. This makes
the table look something like this below. It is much less
understandable.

header 1      header 2      header 3

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

This is easily fixed. If you want and expect your table to be passed
around in email, blogs, and other web pages, then add

border=1

Recommending INVALID: this doesn't seem to be a MediaWiki issue (we can't control which attributes users put on their tables), and AFAIK modern text browsers understand CSS and render these tables correctly (see also comment #3).

OK, I verified that
"Note: As of August 20, 2008 new tables created by using the Wikipedia
table button include border=1 and so they do not have this problem."
on
http://meta.wikimedia.org/wiki/Help:Table#Viewing_tables_in_email_and_web_pages_outside_Wikipedia
is true.

Perhaps a bot could be made to repair the earlier bad tables.

But how could it tell which tables were intentionally without borders.

You see all the regret that is caused by not following standards, and
now there is no easy way to back out nor stop shipping MediaWiki with
the dangerous borders in the table CSS.

All we can say is if a user encounters a table that he cannot read,
(assuming he can even tell it was supposed to be a table in the first
place), he should feel free to add a border, unless he encounters a
<!--no border on purpose! --> comment.

Perhaps add a warning in skins/common/shared.css

Closing this bug.

(In reply to comment #8)

You see all the regret that is caused by not following standards, and
now there is no easy way to back out nor stop shipping MediaWiki with
the dangerous borders in the table CSS.

Oh but we are following standards, just not the same type as you. We mostly follow the W3C standards where it's recommended that page content only should be in the HTML/PHP ect files and styling should be seperated and stored in a seperate file using CSS.

Show me one HTML <table>s tutorial that says it is cool to put border=
only in CSS. Anyway, never mind that. Instead lets turn to how to
clean up the pre 8/2008 damage.

Wait a second. Couldn't there be a bot that marches through Wikipedia,
and every time it encounters class wikitable not followed by a border
statement, it could add border="1", fully confident that as it is a
class wikitable, its author intends to have borders. One could always put a border="0"
or whatever to avoid the bot, but that would be a very devious class
wikitable table.

banaticus wrote:

Or they could simply sst a switch that does that by default unless a user specifies something specific, which is what they did. I don't think new devices will ever ba a problem, because a new text-based browser will recognize media="tty" and thus allow us to style CSS specifically for it.

(In reply to comment #10)

Show me one HTML <table>s tutorial that says it is cool to put border=
only in CSS. Anyway, never mind that. Instead lets turn to how to
clean up the pre 8/2008 damage.

Wait a second. Couldn't there be a bot that marches through Wikipedia,
and every time it encounters class wikitable not followed by a border
statement, it could add border="1", fully confident that as it is a
class wikitable, its author intends to have borders. One could always put a
border="0"
or whatever to avoid the bot, but that would be a very devious class
wikitable table.

There probably could be, but that should be discussed elsewhere.

and thus allow us to style CSS specifically for it.

If indeed it reads CSS in the first place.

OK, filed
http://en.wikipedia.org/wiki/Wikipedia:Bot_requests#Bot_to_repair_tables_created_before_Aug_2008.2C_for_Accessibility

Created attachment 6204
add missing table borders of Mediawiki own tables

The following patch fixes Mediawiki's own tables. (I did not dabble
with Parser Tests though.)

Attached:

happy.melon.wiki wrote:

Jidanni, I'm not sure what to make of all the bugs you've opened with titles "Must check X", "X must do Y", etc. We're (almost) all volunteers here, no one "must" do anything. It's not fair to say "fix it yourself", because I know you're sitting in the same queue as me for SVN commit access (and have been for a month now), but in general, posting your bugs as prescriptions is not going to achieve anything constructive. "X should do Y" for enhancements, "Y does not do Z" for bugs.

I'm sure that patch isn't anywhere near getting all the MediaWiki system tables, although I'm sure it wasn't intended to. You would achieve a lot by adding something to TablePager (in Pager.php); that's used for quite a few things, and *should* be used for many more.

OK, sorry. I suppose I was making reminders for myself.

OK, I've traced Pager.php's $s = "<table class=\"$navClass\" down to
"TablePager_nav a { text-decoration: none; }", meaning that all
browsers including text browsers should see a default of border="0".
So Pager.php doesn't need any fixing, although explicitly saying
<table border="0"...> wouldn't hurt.

Anyway, maybe there are still some places where Mediawiki is cheating
text browsers out of border="1", by assuming everybody uses
stylesheets. All I can do is a very non-scientific
$ find|xargs grep '<table'|grep -v border
every few months, for the rest of my life. Very whack-a-mole.
Perhaps you can rig up a better mousetrap.

happy.melon.wiki wrote:

(In reply to comment #16)

OK, I've traced Pager.php's $s = "<table class=\"$navClass\" down to
"TablePager_nav a { text-decoration: none; }", meaning that all
browsers including text browsers should see a default of border="0".
So Pager.php doesn't need any fixing, although explicitly saying
<table border="0"...> wouldn't hurt.

I thought the issue was that, without stylesheets, text browers *didn't* display borders when they *should* do?? Won't "a default of border='0'" result in no cell borders on text browsers? Am I misunderstanding?

The fellow who made r52060 didn't know about the above patch. But submitting patches is the best we on the forgotten(?) http://www.mediawiki.org/wiki/Commit_access_requests list can do.

ayg wrote:

(In reply to comment #8)

You see all the regret that is caused by not following standards

What standards are you referring to? CSS has been a W3C standard since December 1996. If your browser refuses to implement standards that have been approved and used for over a decade, then frankly that's your problem.

Presentational attributes such as border= on <table> are deprecated. border is invalid in HTML 5, which we might soon be switching to:

"The following attributes are obsolete (though the elements are still part of the language), and must not be used by authors:
"...
"border on table elements
"...
"Use CSS instead."
http://www.whatwg.org/specs/web-apps/current-work/multipage/obsolete-features.html#attr-table-border

It was also removed in XHTML 2.0, not that anyone has ever used or will ever use that:

"All style associated with table rendering MUST use proper CSS2 properties."
http://www.w3.org/TR/xhtml2/mod-tables.html#sec_30.4.

WCAG recommends the use of CSS instead of presentational HTML as well:

"An HTML document uses the structural features of HTML, such as paragraphs, lists, headings, etc., and avoids presentational features such as font changes, layout hints, etc. CSS is used to format the document based on its structural properties."
http://www.w3.org/TR/2008/NOTE-WCAG20-TECHS-20081211/G140

border= is presentational. A guiding principle of the web for the last ten years has been separation of style and content. Presentational attributes such as border= should be, and in MediaWiki generally are, avoided in favor of CSS. In all cases, there should be acceptable fallback, such that the content is usable. If your client doesn't render tables properly without border=, you may want to reconfigure it, or use a different client.

Resolving WONTFIX.

OK, apparently to e.g., keep
http://validator.w3.org/check?uri=http://transgender-taiwan.org/index.php?title=推薦
valid and looking the same as it does now, one should replace all
{|border="1" with some CSS (any recommendations?), and also hope Non CSS browsers,
will use border="1" as their new rendering default, instead of
border="0", as the average table is more readable that way, if you
aren't using the information (CSS) to know the author's intention.
http://article.gmane.org/gmane.emacs.w3m/8314

And do remove all recommendations for using border="1" from
http://meta.wikimedia.org/wiki/Help:Table#Viewing_tables_in_email_and_web_pages_outside_Wikipedia
and everywhere else on that page, or else you are promoting illegal HTML 5!

(In reply to comment #20)

one should replace all
{|border="1" with some CSS (any recommendations?)

{|class="wikitable"

http://thread.gmane.org/gmane.emacs.w3m/8314/ is how I hacked my non CSS text browser to guess if a table should have a border or not,
without needing to pull in the "optional" stylesheets...

More excitement in
http://en.wikipedia.org/wiki/MediaWiki_talk:Common.css#Wikitable_borders_disappear_in_email.2C_blogs.2C_disks.2C_mobile_devices

Clarifying subject.

Reopening now that there's actually some visible result under discussion.

ayg wrote:

Seems like a minor enough issue that we may as well stick with what the standard says, which is also fewer bytes/more elegant. We don't produce many tables in the actual software that anyone would be interested in copying, do we? I'd expect people mostly copy infoboxes and such.

I removed the "accessibility" keyword since this is by no means an accessibility issue. Maybe an interoperability issue.

ayg wrote:

FWIW, the HTMLWG is currently debating the validity of this, under the name ISSUE-155. There's a survey up now, which will close on Monday, and the chairs will likely make a decision within a few weeks:

http://www.w3.org/2002/09/wbs/40318/issue-155-objection-poll/

happy.melon.wiki wrote:

(In reply to comment #29)

FWIW, the HTMLWG is currently debating the validity of this, under the name
ISSUE-155. There's a survey up now, which will close on Monday, and the chairs
will likely make a decision within a few weeks:

http://www.w3.org/2002/09/wbs/40318/issue-155-objection-poll/

That link is under an http_auth wall, for me at least. Is there a public link?

(In reply to comment #30)
http://www.w3.org/html/wg/tracker/issues/155 perhaps.

I don't think we common people are allowed to comment there.
Besides it is mostly over my head. However,
please tell them to also allow border="0"!
Stop pulling the rug out of people who want their HTML to work as intended in both HTML4 and HTML5.

ayg wrote:

Oops, didn't realize it was secret. Obnoxious of them. It's not really secret, since anyone can apply to be an Invited Expert in the HTMLWG, but whatever. It will close tomorrow night, and the chairs will judge it within the next few weeks.

(In reply to comment #32)

please tell them to also allow border="0"!

What's the point of this? Don't tables have no border by default?

So then then why spitefully cause peoples pages who used it to become invalid?
And if they break this, what next will they spitefully break for no reason in HTML6?

And how else can text browsers still distinguish which tables really don't want borders, without implementing CSS?

ayg wrote:

The spec now permits <table border=1>:

http://lists.w3.org/Archives/Public/public-html/2011Apr/0377.html
http://www.whatwg.org/specs/web-apps/current-work/multipage/tabular-data.html#attr-table-border

(In reply to comment #36)

The spec now permits <table border=1>

Thanks for the heads up.
Now we will see there on
http://www.w3.org/Bugs/Public/show_bug.cgi?id=12413
if they can also figure out that they also need border="0",
Ah, tables,
"Just like mom used to make",
http://www.youtube.com/watch?v=_npZF7Ah6s8

happy.melon.wiki wrote:

The semantic meaning of "border=1" is "this is definitely not a layout table, don't you dare treat it like one". The semantic meaning of "border=0" is "this *is* a layout table". The HTML5 spec deprecates layout tables even more strongly than its predecessors, and in particular indicates that they "must" be marked with an attribute "role=presentation". The "border=0" marker makes no sense in the spec because it gives no additional data. Now the OP of that bug is correct to note that this tableless nirvana, while a worthy goal, is not currently a feature of the web environment that HTML5 is being launched into, but that bug (and W3C's perspective) is about interoperability between a new standard and old websites. There is no reason for new MediaWiki code to support what will, if at all, be introduced as a deprecated feature ("users may do X, but should not do so; UAs should interpret it as Y"). Rather, we should be supporting the spec's positively-endorsed implementations (in this case, preferably not using layout tables at all, and if we do, marking them with "role=presentation". There should never be a need to introduce deprecated syntax, and so no reason for us to support it.

Why take away people's ability to do the first of
$ w3m -dump a.html
a b
1 2
$ w3m -dump b.html
+---+

+---+

happy.melon.wiki wrote:

Because the spec says that coding things in that fashion is undesirable and deprecated and people should be discouraged from doing it. I'm not necessarily saying that I agree with that, but that's the position they're working from. The area that you're looking at is, to them, the loose ends of a much larger issue; if you don't interact with them on that basis, you're just rearranging deckchairs on the Titanic.

ayg wrote:

(In reply to comment #38)

The semantic meaning of "border=1" is "this is definitely not a layout table,
don't you dare treat it like one". The semantic meaning of "border=0" is "this
*is* a layout table".

No, border=0 could be a non-layout table that you don't want to have a border for whatever reason. There are such things. It doesn't have any semantic meaning. The semantic meaning for border=1 was made up by HTML5.

The HTML5 spec deprecates layout tables even more
strongly than its predecessors, and in particular indicates that they "must" be
marked with an attribute "role=presentation".

This is actually a point of divergence between the W3C and WHATWG copies: the W3C allows role=presentation on tables, the WHATWG prohibits it.

http://dev.w3.org/html5/spec/tabular-data.html#the-table-element
http://www.whatwg.org/specs/web-apps/current-work/multipage/tabular-data.html#the-table-element

Not that it makes much difference, since both of them say role=presentation on a table is valid.

(In reply to comment #39)

Why take away people's ability to do the first of
$ w3m -dump a.html
a b
1 2

border=0 is redundant. You don't need it to achieve that effect.

$ cat a.html
<!doctype html>

$ w3m -dump a.html
a b
c d

(In reply to comment #41)

border=0 is redundant. You don't need it to achieve that effect.

OK, but it makes things explicit, e.g., for Comment #10.
And I don't see why they insist on making it invalid, just to break compatibility with HTML4.

Proposing WONTFIX - I don't see that setting border="1" is actually wanted here.

In any case, this patch should go into Gerrit:
You are welcome to use Developer access

https://www.mediawiki.org/wiki/Developer_access

to submit this as a Git branch directly into Gerrit:

https://www.mediawiki.org/wiki/Git/Tutorial

Putting your branch in Git makes it easier to review it quickly.

WONTFIXing per Andre and per no response.