Page MenuHomePhabricator

Table of contents shouldn't be a <table>
Closed, ResolvedPublic


Author: tom

Should be a real list and shouldn't be a <table>.

I'm working on a patch.

Version: 1.22.0
Severity: enhancement



Revisions and Commits

Event Timeline

bzimport raised the priority of this task from to Medium.Nov 21 2014, 6:57 PM
bzimport set Reference to bz658.

tom wrote:

TOC HTML fixes patch v1

This needs review to check it doesn't break anything.

Makes the TOC output with decent HTML, with a proper list and no tables. Also
allows skins to style the heading number and heading text differently. CSS is a
little weird, but I think I've covered all the skins I need to.

attachment TOC.patch ignored as obsolete

michael wrote:

(In reply to comment #1)

Created an attachment (id=76) [edit]
TOC HTML fixes patch v1

Can you post a link or HTML file with a TOC showing all of the features? We could use that to check rendering of the output HTML and CSS in
different web browsers.

tom wrote:

Comment on attachment 76
TOC HTML fixes patch v1

Found a bug with this, a weird selection of headings and IE. Will fix and post
a test page too.

tom wrote:

Patch commited to CVS - complete TOC recode: proper HTML list; CSS for layout; JS recode; hidden TOC stays hidden
across different pages; never show TOC if no headings; more opportunity to style TOC

gangleri wrote:

Hi! is bug 2405 "in an RTL wiki TOC seems to be generated always RTL" fixed also?

Regards Reinhardt

avarab wrote:

*** Bug 3949 has been marked as a duplicate of this bug. ***

avarab wrote:

The fix was reverted, the TOC is still a table, REOPENING

Is this bug asking to change the TOC *to* a table, or
*from* a table?

robchur wrote:

Apparently, *to* a table.

Right now it seems to be a <ul> list inside a <div> inside a <table>

Jeebus. :P

Making it fully a table would be dumb IMHO, as it's really an outline rather than a grid-like
table. Removing the outer <table> wrapper would be semantically correct, but as I recall there
were problems with getting a <div> to behave correctly in terms of width, wrapping, etc.

chtitux wrote:

The CSS attribut of display is good for that :
div.toc { display: table; }
It's exactly the same display with <table> tag, but it's some good xhtml ...

tom wrote:


Erm... the TOC shouldn't have any <table> elements anywhere.

It's a list, and should be a list, and nothing else.

robchur wrote:

Well this bug's history's confusing as hell isn't it. Yes, seems that somewhere
along the line I, in particular, got confused as to what was being
asked...apologies to those affected. ;-)

ayg wrote:

Googling "CSS shrink width to content" indicates that the only way to have
content shrink to fit in a non-table block element is floating. That seems
pretty ridiculous, and you'd have to clear the first section (which would
interfere with floated images, for instance). You could use display: table;,
but IE doesn't support that. There are other possibilities, but all are either
just as hacky as <table>s or not yet fully supported. The table will have to
stay until CSS is improved — closing as LATER.

ayg wrote:

Sigh . . . why am I so arrogant as to close bugs on the assumption I know all about CSS there is to know? A float could work fine, maybe wrapped in something with overflow: hidden to make a new block formatting context so it hopefully doesn't interfere with other floats. I await working demonstrations if anyone wants to provide them, although this will break existing scripts and styles and so I'm not going to commit immediately.

Floats? Ewwwwwwwwwwwwwwwwwwww.

ayg wrote:

*** Bug 10592 has been marked as a duplicate of this bug. ***

Looks like the TOC is still a <ul> inside a <table> (with the <table> used just to get a fitted box).

I feel like modern things like margin: auto should make this unnecessary now but I'm not sure. Would be nice to kill the table, but only if there's a sane alternative that's reasonably compatible to IE 6.

(In reply to comment #18)

Looks like the TOC is still a <ul> inside a <table>

Still in 1.21wmf6.

[Removing RESOLVED LATER as discussed in . Reopening and setting priority to "Lowest". For future reference, please use either RESOLVED WONTFIX (for issues that will not be fixed), or simply set lowest priority. Thanks a lot!]

I submitted change I4ecd0659 that attempts to fix the issue.

  • Bug 13766 has been marked as a duplicate of this bug. ***

Change 39792 merged by jenkins-bot:
skin: Convert table of contents from <table> to <div>

"but this isn't an issue here as the ToC is always sandwiched between other block-level elements."

Unless the ToC is preceded by a table... which is an inline-table.
Like here for instance:

Not sure what to do about this.

Change 80435 had a related patch set uploaded by Bartosz Dziewoński:
ToC: Use display:table, so that we can behave like a block element

Change 80435 merged by jenkins-bot:
ToC: Use display:table, so that we can behave like a block element

epriestley added a commit: Unknown Object (Diffusion Commit).Mar 4 2015, 8:20 AM