Is there any particular reason we limit the table HTML tags to the Documentation format? I'd like to add them to Filtered so folks who are writing and helping maintain pages with tables on them don't have to become doc admins just for that. If there are no objections, I'll go ahead and do it.


xmacinfo’s picture

This limit on a default Drupal, and probably on, is to keep the control on the layout. Badly formatted table layout can break a web site layout quickly. In a table td or td we can force width, height, etc.

I guess for documentation you can let them use tables. We could tell them to add as few table attributes as possible.

But on a regular web site, I'D keep this to Full HTML.

kiamlaluno’s picture

I don't think there could be any problem in adding the table HTML tags to the filtered HTML format; at least it would avoid to make a person documentation administrator just to give him the possibility to use tables.

kiamlaluno’s picture

I am so used to Better Formats that I forgot the input format is not limited to a content type; if the table HTML tags are added to the filtered format, then it would be possible to create tables in every content type.
As reported from xmacinfo, to allow to use tables in all the content types could be a problem.

xmacinfo’s picture

BTW, I'm not a D.O. webmaster. So maybe the situation is different for documentation.

add1sun’s picture

Someone brought up on IRC that there is some sort of security risk with table tags. Either way, I'd like to get a definitive solution because this is ungodly annoying to the docs team.

john.kenney’s picture

I am not on the docs team, but I can verify that it is ungodly annoying for them because I'm one of the people annoying them about it ( -- which means that it is also ungodly annoying for people like me who want to contribute to d.o.

Some material just simply needs to be presented in a tabular format -- there is no other way around it.

As to table tags breaking pages, couldn't you, if you enabled table tags, figure a way to set a class for pages written by authenticated users and then hide table overflow?

Or perhaps you can define a new class of users that has table creation privileges, but lesser rights than whatever comes with being on the doc team? Such would require approval still, but such approval could be easily done, probably fully automatically, based on simple criteria such as 'x months member' or '>y forum posts', or something like this.

I don't know exactly, but current setup leads to a stupid outcome and it should be changed sooner than later.

kiamlaluno’s picture

Status: Active » Postponed (maintainer needs more info)

Is there anybody else who wants to chime in?

greggles’s picture

In core the filtered html isn't allowed to use "block" elements. I think this is because those make it easier to break the entire page layout, though it's harder to break layouts now that we have the html validator in core.

Gerhard Killesreiter’s picture

Status: Postponed (maintainer needs more info) » Fixed

I added the requested tags.

Gábor Hojtsy’s picture

Made the same changes on l.d.o to keep the formats in sync. This helps users expect the same set of stuff to work with. Updated #570408: Add more HTML tags to the input format with info on this, since this also obsoleted the Rich HTML format we used to have on l.d.o. Removed that on l.d.o.

fgm’s picture

Great. Now quite a few pages will be switchable to filtered html format and still work (I've been waiting for for months).

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.