Last modified: 2014-01-30 23:01:24 UTC
Aaagggg, you fellows put table borders into CSS: /* wikitable class for skinning normal tables */ table.wikitable { border: 1px #aaa solid; meaning that nobody will use the standard border="1" for tables, pulling the rug out of under text browser users! Allow us to examine a before and after case, http://www.mediawiki.org/w/index.php?title=Help:Links&oldid=255680#External_links http://www.mediawiki.org/w/index.php?title=Help:Links&oldid=255681#External_links Both look great to you, but to me the before case is a shambles. So now if you pull borders out of CSS, lots of tables will fall apart. (No "drug withdraw" program available.) So it seems the only solution is to put big warnings in documentation. Who knows, seeing this bug report you might even go looking for tables to trash, like the ones that thanks heavens still use both methods, e.g., 'class="sortable wikitable" border="2"' etc.
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.
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 [details] add missing table borders of Mediawiki own tables The following patch fixes Mediawiki's own tables. (I did not dabble with Parser Tests though.)
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.
(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.
(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.
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.
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/
(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.
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?
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
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 +---+ |a|b| |-+-| |1|2| +---+
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.
(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> <table> <tr><td>a <td>b <tr><td>c <td>d </table> $ 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.