FF doesn't render the properties and the styles of <COL> tags

[Uqbar]

Binary package hint: firefox-3.0

Accordingly to the standard (http://www.w3.org/TR/html401/index/attributes.html), both the "width" and the "align" attributes can be defined into a <COL> tag.
After all, this is one of the reasons why the <COL> tag exists at all: to define properties related to columns.
What instead happens with Firefox 3 is that the "width" property gets honoured and rendered, while the "align" is not.

Disappointingly, Microsoft Internet Explorer v7 does it right!

ProblemType: Bug
Architecture: amd64
DistroRelease: Ubuntu 8.10
NonfreeKernelModules: nvidia
Package: firefox-3.0 3.0.8+nobinonly-0ubuntu0.8.10.2
ProcEnviron:
 LC_COLLATE=C
 PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games
 LANG=en_US.UTF-8
 SHELL=/bin/bash
SourcePackage: firefox-3.0
Uname: Linux 2.6.27-14-generic x86_64

[Buster (buster)]

this was a small coding error on my part related to the new frame creation
strategy. The content has a 4-column table, but provides only a single COL
(actually, just a COLGROUP with no SPAN attribute) so the table frame creation
code synthesizes the other 3 COLs. The COLGROUP frame was getting an Init() for
the first COL, but not the other 3.

[Christinehoff4 (christinehoff4)]

Using 11/30 devprev build. Re-opening bug. Behavior in the first column
heading is incorrect. Of the 4 column headings, only the first has a COLGROUP
element tag and it has a value of align=left; therefore, the first column
heading should align left (IT DOES NOT). The other column headings do not have
attributes and should slign to the default - center (they do).

[Christinehoff4 (christinehoff4)]

Let me correct my comments. The COLGROUP element only spans one column which
would only apply to the 'Element' heading. This column heading should align left
and it does not.

[Buster (buster)]

changed summary to reflect the real problem.

see discussion summary at
http://warp/client/raptor/table_column_style_resolution.html

[Buster (buster)]

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

[Leger-formerly-netscape (leger-formerly-netscape)]

Setting all current Open/Normal to M4.

[Paulmac (paulmac)]

per leger, assigning QA contacts to all open bugs without QA contacts according
to list at http://bugzilla.mozilla.org/describecomponents.cgi?product=Browser

[Peterl-retired (peterl-retired)]

Deferring to M10

[Ian-hixie (ian-hixie)]

This one is going to be interesting. Peter, you may wish to suggest the the
CSS WG that the 'text-align' property for cells should inherit from their
columns/column groups, or something along those lines. I believe what we are
currently doing would be correct in terms of CSS2, if attributes could be
simply mapped to properties. But it is wrong in terms of HTML4.

[Pierre-formerly-netscape (pierre-formerly-netscape)]

Reassigning peterl's bugs to myself.

[Pierre-formerly-netscape (pierre-formerly-netscape)]

Accepting peterl's bugs that have a Target Milestone

[Pierre-formerly-netscape (pierre-formerly-netscape)]

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

[Pierre-formerly-netscape (pierre-formerly-netscape)]

Pushing my M15 bugs to M16

[Pierre-formerly-netscape (pierre-formerly-netscape)]

Moving table bugs to M15 just to see how many we have.

[Pierre-formerly-netscape (pierre-formerly-netscape)]

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

[Christinehoff4 (christinehoff4)]

Adding 'beta1' to keywords. Beta1 should support CSS1 styles for all elements.

[Ekrock (ekrock)]

Pierre and I agree that we do need to get this fixed; if we don't, COL and
COLGROUP are fairly useless. However, if push comes to shove, I'll be
comfortable release noting this for beta 1 because (1) the W3C CSS1 test suite
doesn't test this, and (2) no existing browser supports this, so there isn't
existing content using it that will break. I think this is a "like to have" for
beta 1 (but I wouldn't stop ship for it) and a "must have" for FC beta and FCS.

[Leger-formerly-netscape (leger-formerly-netscape)]

Putting on PDT- radar for beta 1.

[Pierre-formerly-netscape (pierre-formerly-netscape)]

Created an attachment (id=4900)
a testcase extracted from bug 26376 (problem with height:100%)

[Christinehoff4 (christinehoff4)]

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

[Karnaze (karnaze)]

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

[Ian-hixie (ian-hixie)]

pierre/karnaze/troy: What was the WG's decision on text-align 'inherting'
through columns in CSS like it does in HTML?

david: cc'ing you, you might be interested.

[Pierre-formerly-netscape (pierre-formerly-netscape)]

Block-moved to attinasi the bugs related to style inside tables

[Karnaze (karnaze)]

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

[Ian-hixie (ian-hixie)]

Updating summary to more accurately reflect the bug.

[Attinasi (attinasi)]

Created an attachment (id=6578)
Smaller testcase for COLGROUP inheritance (easier debugging)

[Sacolcor (sacolcor)]

I'm CCing myself and attempting to summarize this bug after running into it in
some work I was doing and spending time reading through it and the dups:

This bug is cause by a contradiction between the CSS2 spec and the HTML4 spec.

http://www.w3.org/TR/REC-CSS2/tables.html#q4 states that
"The following properties apply to column and column-group elements:
'border', 'background', 'width', and 'visibility'"

However, http://www.w3.org/TR/html401/struct/tables.html#h-11.2.4 permits the
'align' attribute on COL and COLGROUP elements. If the 'align' attribute is to
be equated to the 'text-align' property, this contradicts the above secion of
CSS2.

Mozilla's current behavior complies with the CSS2 spec, however because the
'align' attribute does not inherit from COL/COLGROUP, it violates the HTML4
spec.

Restricting column inheritance to such a narrow group of properties also appears
to violate the intended purpose of the COL element, namely "The COL element
allows authors to share attributes among several columns without implying any
structural grouping." Limiting the 'attributes' to those specified by CSS2
greatly reduces the usefulness of COL/COLGROUP. Moreover, code which relies on
a wider range of columnar property inheritance is already extant, because IE
supports it.

A request for clarification to the W3C CSS working group is pending.

[Attinasi (attinasi)]

Moving off to M16 while we wait for clarification from the WG.

[Jlarsen-fsu (jlarsen-fsu)]

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

[Christinehoff4 (christinehoff4)]

PDT- removed from beta1; nsbeta2 added.

[Vyv03354 (vyv03354)]

<email address hidden>: HTML align inherits from COL/COLGROUP, but CSS text-align
doesn't inherit from COL/COLGROUP.
HTML align is not the same as CSS text-align. For example, HTML align can
center the block-level element, but CSS text-align can't.

[Sacolcor (sacolcor)]

Having layout control attributes in HTML that cannot be emulated using CSS seems
to violate the intended seperation between using HTML for structure and CSS for
layout. Is there a reason that text-align (and other properties) shouldn't
inherit from COL/COLGROUP?

[L. David Baron (dbaron)]

Yes. Inheritance works over the document structure. CSS doesn't know
beforehand what element is a column, or what is a cell, or what is a block.
That is all determined by the display property.

If you propose general inheritance from COL/COLGROUP, what if I had the rule
COLGROUP { display: table-cell; }
? Would the inheritance be determined by the element name or the display type?

[Karnaze (karnaze)]

IE seems to support cells inheriting from col and colgroup (at least color).

Dave, are you saying that the specs don't support this type of inheritance in
general or just for text-align.

[L. David Baron (dbaron)]

I'm saying that in terms of CSS, it's wrong. (Although perhaps there could be a
special exception for text-align on table-column elements...) However, it's
required for HTML.

[Sacolcor (sacolcor)]

I can see the difficulties with 'display', however there are many properties
(text-align, font, color, etc), that I can see authors wanting to apply on a
columnar basis fairly frequently. It now sounds like there is no way to
accomplish this without breaking the 'HTML is not for presentation' rule. Is
there a 'good' way to resolve this dillema using current specs? If not, are the
working groups attempting to resolve it in a future one?

[Karl Ove Hufthammer (huftis)]

IE 5.5 for Windows supports inheriting of 'text-align' from COLGROUPs and COLs.

[Vyv03354 (vyv03354)]

CSS2 Spec. 17.3 says that 'border', 'background', 'width', and 'visibility'
apply to column and column-group elements.

(http://www.w3.org/TR/REC-CSS2/tables.html#q4 )
|Table cells may belong to two contexts: rows and columns. However, in the
|source document cells are descendants of rows, never of columns. Nevertheless,
|some aspects of cells can be influenced by setting properties on columns.
|
|The following properties apply to column and column-group elements:
|
|'border'
(snip)
|'background'
(snip)
|'width'
(snip)
|'visibility'

And CSS Spec. 9.10 says CSS 'direction' doesn't inherit from column, but
HTML4 "dir" inherits from COL.
( http://www.w3.org/TR/REC-CSS2/visuren.html#direction )
|Note. The 'direction' property, when specified for table column elements, is
|not inherited by cells in the column since columns don't exist in the document
|tree. Thus, CSS cannot easily capture the "dir" attribute inheritance rules
|described in [HTML40], section 11.3.2.1.

What about 'text-align'? Probably 'text-align' should not inherit from column
and column-group since it is not listed in 17.3 as exception.

Win IE 5.5 is wrong. On MacIE 5, HTML4 "align" and CSS 'background' inherit
from column, but CSS 'text-align' and 'color' don't inherit from column.

[Vyv03354 (vyv03354)]

Created an attachment (id=8248)
Testcase demonstrating the MacIE 5 behavior

[Vyv03354 (vyv03354)]

>On MacIE 5, HTML4 "align" and CSS 'background' inherit from column,

It was not accurate. On MacIE5, HTML4 "align" inherit from COL and
CSS 'background' applys to column (but doesn't inherit from column).

CSS2 Spec. 17.3 is not relevant to inheritance.
If cell simply inherits 'background' from column, border-spacing would not be
painted. But border-spacing should also be painted.

[Serge-snkey (serge-snkey)]

I agree, Gecko should support column align via both HTML and CSS but now it haven't support at all.
$15 more form me.

[Xaviermd (xaviermd)]

I really need vertical align by a character, because that is the only reason some companies uses IE + Excel in the intranet.

I put € 15.

[Ian McCall (ian-eruvia)]

I'm ttempted to pay a bounty to keep the bug in place. Over the years, it's felt like an old and familiar friend. I feel part of an exclusive club, defending bugdom and keeping the world safe from the boring conformity of fully working software.

[enzo (vincenzo-romano-notorand)]

(In reply to Xavier Mouton-Dubosc from comment #368)
> I really need vertical align by a character, because that is the only reason
> some companies uses IE + Excel in the intranet.

Well, the <COL> group makes a lot of sense to tabular data presentation anyway.
And it seems that it doesn't make any sense without it being fully implemented.

But guys, read the previous (very old) comments. It seems there's been a number of unsuccessful fix attempts in the past.
The HTML 4.01 and the CSS2 are conflicting (shame on the standardisation board) and the developers of all opensource brosers decided to go the same way: CSS2 everywhere. There's no will at all to implement the <COL> stuff as per the standard.

[Korisu (korisu)]

Joking aside, since WebKit is also waiting on Mozilla to take action on this fix, has anyone thought of contacting Opera and asking how they implemented it? They seem to be a leader in CSS compliance and have somehow created an implementation that follows HTML 4.01 without seriously compromising their CSS compliance. Who knows, they may be sympathetic to Mozilla's plight here (seeing as how this bug is so infamous by now), and may be willing to help out.

I say it's worth a shot, but obviously I don't have the kind of connections necessary to pull it off. :) David [Baron]?

[Acelists (acelists)]

And it seems the *align and other useful attributes were removed in HTML5 (http://dev.w3.org/html5/spec/Overview.html#the-col-element) to fix this conflict.
So a new HTML4-only browser is not a real option.

[enzo (vincenzo-romano-notorand)]

Scott, even if the Opera devs would through their hints in, do you know what'd the Mozilla devs answer?
It's already here, at Comment 324: we don't mind any more.

[Korisu (korisu)]

Uqbar - but Comment 324 was effectively negated by Comment 347, where this bug was reopened. I think I had something to do with that, but regardless, I'm just trying to be helpful here at this late stage of the game.

aceman - you do have a valid point. I'm definitely not willing to try myself to persuade the W3C to re-include align/valign/etc. in the HTML5 spec, and I don't know what debates have taken place within the working group on this topic, but think of it this way: if HTML5 is supposed to be a spec based on the current support of HTML5 in modern browsers, don't you think it could possibly change their mind if a real implementation was made by Mozilla and then followed by WebKit? That would mean support in all 5 of the major modern browsers, and then maybe there would be a stronger reason to reinclude it in HTML5. As has been pointed out here numerous times, <col> is effectively useless without align, and there is no alternative CSS approach that could possibly be as useful as the align attribute from HTML4.

I think it's still worth a shot.

[Gurdiga (gurdiga)]

I think <col> would also be useful to DRY CSS: cells in a column usually share many of their presentation properties, so this would avoid having the same CSS class[es] for every cell in the column.

[Zéfling (zefling)]

Currently, "col" is useful only for background-color. Other than that and accessibily, I do not see.

[Gurdiga (gurdiga)]

I'd say that besides background-color, common cases are also font-*, color, padding, maybe even border.

[enzo (vincenzo-romano-notorand)]

You should discuss that here: http://www.w3.org/TR/2011/WD-html5-20110525/

[L. David Baron (dbaron)]

(In reply to Scott Trenda from comment #371)
> Joking aside, since WebKit is also waiting on Mozilla to take action on this
> fix, has anyone thought of contacting Opera and asking how they implemented
> it? They seem to be a leader in CSS compliance and have somehow created an
> implementation that follows HTML 4.01 without seriously compromising their
> CSS compliance. Who knows, they may be sympathetic to Mozilla's plight here
> (seeing as how this bug is so infamous by now), and may be willing to help
> out.
>
> I say it's worth a shot, but obviously I don't have the kind of connections
> necessary to pull it off. :) David [Baron]?

This isn't useful. comment 288 describes exactly the work that remains to be done. However, I'm more interested in doing that work in order to support the semantic column selectors in the selectors4 draft (in bug 371323) than to support the deprecated presentational attributes requested in this bug.

[Korisu (korisu)]

David, you should know by now that "deprecated presentational attributes requested" are fighting words in the context of this thread, but I'd like to discuss bug 371323 that you mentioned, instead.

I understand that as a volunteer contributor to an open-source project, the type of work that you are interested in doing does affect what makes it into the end product. On that note, I read the spec in the proposed selectors4 draft for :column(). I'd like to encourage you to pursue that implementation. I think that doing so will help both of us. It seems to be defined well enough from a CSS perspective to let you write it in a way that is compatible with the rest of your CSS engine. Once you have a :-moz-column() pseudo-class selector in place, couldn't you just add this set of rules to the internal Mozilla default stylesheet?

:-moz-column(col[align="left" ]) { text-align: left ; }
:-moz-column(col[align="center" ]) { text-align: center ; }
:-moz-column(col[align="right" ]) { text-align: right ; }
:-moz-column(col[align="justify" ]) { text-align: justify; }
:-moz-column(col[valign="top" ]) { vertical-align: top ; }
:-moz-column(col[valign="middle" ]) { vertical-align: middle ; }
:-moz-column(col[valign="bottom" ]) { vertical-align: bottom ; }
:-moz-column(col[valign="baseline"]) { vertical-align: baseline; }

Similar rules could be added for align/valign in colgroups:
:-moz-column(colgroup[align="left"] > col) { text-align: left; }

The downsides I see with this approach:
- it wouldn't cover align="char" and charoff
- I don't know if it'd be possible to handle cols with span defined
- assigning styles directly to the <col> element (e.g. col.style.textAlign = "center") wouldn't update the style

The upsides to this approach:
- it'd probably be good enough for most of the people in this thread
- it would be fairly harmless to add at that point (via the default stylesheet)
- it would finally bring an end to 13 years of fighting over this damn bug.

So please, godspeed on bug 371323. :)

[Ian-hixie (ian-hixie)]

(In reply to Scott Trenda from comment #374)
> I don't know what debates have taken place within the working group on
> this topic

All presentational features, such as <font>, align="", etc, were dropped in the new HTML standard, because they have been deprecated for over a decade and there's really no longer any reason for anyone to be using them in new documents. These features are now completely obsolete and it is non-conforming (invalid) to use them in HTML documents. I would not expect this to change even if browsers added support for this feature.

If you feel the need to discuss this decision, please do not do so on this bug (you can e-mail me directly if necessary to avoid posting here).

[brianary (brian-webcoder)]

Great! So what were the *semantic* elements used to distinguish a simple text value from numeric, date, or other values again?

[brianary (brian-webcoder)]

Apologies for any excessive snark in that last reply (and two volleys of bugspam), but there is a complete lack of semantic distinction to graduate to in order to meet reasonable presentational needs.

There may be a strong argument for a 'tn' (table numeric value) element in HTML5 for bare minimum numeric tabular data markup support (and consequential CSS alignment), even ignoring any need to align decimal characters or otherwise homogenize/improve the display of dissimilar/unsatisfactory numeric formats (like adding a printf-style format specifier to the col element). Allowing tr to directly contain elements like 'time' in HTML5 would be another practical solution. However, nothing like that exists today, or to my knowledge has even been fully proposed.

[Moz-jeka (moz-jeka)]

(In reply to Scott Trenda from comment #371)
> Joking aside,

No joke, my money is real

[Xaviermd (xaviermd)]

In reply to Brian, even if we had a <tn> element, it wouldn't help to align texts to a "pivot" character. align:"char" is/was a very interesting way in html/css to do the job.

And I even seen it used in a copy/paste from OpenOffice to a browser (in a html attribute)...

Every other "solution" is only... painful

As for col/colgroup to really group cols. And don't talk again about :nth in css, it simply fail stupidly where you have to colspan/rowspan

[enzo (vincenzo-romano-notorand)]

(In reply to Scott Trenda from comment #380)
> Once you have a
> :-moz-column() pseudo-class selector in place, couldn't you just add this
> set of rules to the internal Mozilla default stylesheet?

Scott, your remark seems to me to make a lot of sense. Pretty much.
Maybe not in the solution itself, but rather in its philosophy.
I mean, the missing parts you mentioned would need some extra programmatic approach, like linking (default, built-in) Javascript procedures to default CSS.

A few facts.
1. HTML4 documents and applications won't vanish overnight once HTML5 will be a standard. A better support to HTML4 will make the web a better place.

2. W3C standards have proven not to be bullet proof (among the most recent cases: http://it.slashdot.org/story/11/10/22/0310230/xml-encryption-broken-need-to-fix-w3c-standard).

3. Smart interpretation (of standards) and implementation (of browsers) in the mid- long-term are better than strict ones.

(In reply to Scott Trenda from comment #380)
> So please, godspeed on bug 371323. :)

Yes, pleeeease!

[Yuhong Bao (yuhongbao-386)]

"has anyone thought of contacting Opera and asking how they implemented it?"
I think the secret affairs algorithm had a lot to do with it:
http://ln.hixie.ch/?start=1037910467&count=1

[Francis-uy (francis-uy)]

This bug is old enough to drive a car.

Given that no progress has occurred in years, given that the property is officially obsolete, and given that WebKit/Blink renders the testcases identically to Gecko, I think it's time to be honest and resolve this WONTFIX.

[enzo (vincenzo-romano-notorand)]

I think everyone will concede to honesty here.
But, for the sake of honesty, everyone should concede that if you wait long enough, any bug will end up this very way. It's called the ostrich philophy.

Comment 17 (18 months later) was the technical key point for a fix and a quick one.
Comment 324 (12 years later) has been the political key point not to fix it.

I would bet that HTML5 doesn't have this feature because "no browser has ever had it" in the 16 years (well, I don't consider IE a real web browser). But I could be badly wwong.
So long, bug no.915!

[Uqbar (uqbar)]

https://bugzilla.mozilla.org/show_bug.cgi?id=915#c389

[David-rossde (david-rossde)]

When a bug report describes an actual discrepancy (not an RFE), closing it merely because it has not yet been fixed is a fantasy. Even if the bug is difficult to fix, something is definitely wrong with the code. As long as the code is discrepant, the bug report should thus remain open.

[Ernestcline (ernestcline)]

I can see closing the parts relating to character alignment as WONTFIX. Those are explicitly stated as optional in the HTML4 spec and they would definitely impact performance, especially when the engine has to calculate the character offset. The other attributes only require column inheritance of properties. That was fairly simple in the pre-CSS pre-DOM days as the user agent could know which column a cell was in and always would be. The former is still true and I doubt that there would be many cases where these attributes would be used where DOM manipulations would be done.

[brianary (brian-webcoder)]

While the alignment attributes are gone now, the style attribute remains.

Are we using "honesty" as a euphamism for avoiding difficult functionality?

Is there a reasonable solution to aligning by column, rather than cell-by-cell, other than this one or the CSS :numeric selector proposal at https://www.w3.org/Bugs/Public/show_bug.cgi?id=18026 ?

[enzo (vincenzo-romano-notorand)]

All this story makes no sense, in the end.
According to the previous comments above:

Those who wrote the standard had no clue about what was being defined. So no correction (aka 4.02?) to the HTML standard has been proposed/discussed/done in 15 years.

Implementing and reimplementing for years interim unstable specs has been considered more important than fixing the current stuff.

If anything is too hard to fix, than shame on application developers, each of them, to find a suitable workaround in their software.

Sounds like we are at Microsoft or IBM more than the Mozilla Foundation.
Despite the motto "We’re building a better Internet" (https://www.mozilla.org/en-US/mission/) and the manifesto "08 Transparent community-based processes promote participation, accountability and trust."
I need to be wrong and/or misinterpreting all these words. Shame on me.
Please close this bug with whatever tag you want. It won't matter anyway.

I only hope that challenging someone's choices is not interpreted as impolite, rude or unkind.
I hate to accept technical stuff blindly and with no factual justification.

[L. David Baron (dbaron)]

(In reply to Brian Lalonde from comment #392)
> Is there a reasonable solution to aligning by column, rather than
> cell-by-cell, other than this one or the CSS :numeric selector proposal at
> https://www.w3.org/Bugs/Public/show_bug.cgi?id=18026 ?

Please see comment 288 and comment 379 (which, really, you should have read before adding comments here; if people don't read the bug before commenting, it will grow too big for anybody deciding what to do about the bug to read the comments).

[brianary (brian-webcoder)]

(In reply to David Baron [:dbaron] (UTC-7) from comment #394)
> Please see comment 288 and comment 379 (which, really, you should have read
> before adding comments here; if people don't read the bug before commenting,
> it will grow too big for anybody deciding what to do about the bug to read
> the comments).

I am familiar with this bug, as I've been following it for more than ten years. I don't see the point in calling out bugspam by adding further bugspam, and replies should really be more constructive than scolding. I'd say the ship has probably already sailed on the size of the comments here.

The problem with a style (CSS :-moz-nth-column()) solution (as mentioned in the W3 bug I linked to) to a content problem, is that:

  1. Content authors are less likely to have access to a site's stylesheet
     than to a site's markup.
  2. It's unmaintainable for separate, centralized stylesheets. Every table
     would need a class or id and changes to the number of columns for any
     table would require splitting it from the class or updating the site
     stylesheet's column styles for that id. What does the WYSIWYG or wiki
     or CMS process look like for this?
  3. Maintaining it closer to the table using inline styles or (perhaps
     eventually) scoped CSS doesn't really have any advantage over the
     align attribute approach, and may have significant disadvantage
     (such as having to update the individual page's style when table
     changes are made).

There's more in the 18026 ticket, although using col element alignment doesn't address much of the problem of using a columns physical position to determine it's appearance either, but in the current absence of a td:numeric selector, a pure markup solution can be important.

[Gingerbread-man-2 (gingerbread-man-2)]

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

[Bugzilla+mozilla (bugzilla+mozilla)]

> Status: NEW
> Reported: 20 years ago

Perhaps it's time to close this one out?

[Korisu (korisu)]

(In reply to Ryan Hayle from comment #397)
> > Status: NEW
> > Reported: 20 years ago
>
> Perhaps it's time to close this one out?

Funny you should say that now - just earlier this week I came across a 16-year old bug in Bugzilla, and thought, "I wonder how old 915 is by now". Personally I would be happy to just sit and let it age with its "NEW" status, as an internet relic of browser and spec history... but with the HTML5 spec officially deprecating these attributes (and HTML5 being old and stable enough for that decision to be less contentious among developers), closing this bug as WONTFIX does sound appropriate.

[R-eric-0 (r-eric-0)]

(In reply to Scott Trenda from comment #398)

> Personally I would be happy to just sit and let it age with its "NEW"
> status, as an internet relic of browser and spec history... but with the
> HTML5 spec officially deprecating these attributes (and HTML5 being old and
> stable enough for that decision to be less contentious among developers),
> closing this bug as WONTFIX does sound appropriate.

I’m completely with you on wanting to leave it open, but I think it does need some sort of resolution, if for no other reason than clarity. I wish there was a status like OBSOLETE or NLR (No Longer Relevant) to indicate that it was closed not because a “fix” was found and rejected, or the original request was misguided, but because the original impetus was nullified by subsequent events.

[brianary (brian-webcoder)]

I'm not sure why this would be considered either obsolete or NLR. Is there some new solution to column alignment other than decorating each cell or setting up fragile rules using distant selectors based on physical location?

No real updates on https://www.w3.org/Bugs/Public/show_bug.cgi?id=18026 for the HTML spec so far, so maybe I'm missing something.

(The updated password requirements here are *absurd*. Is money handled somewhere here now?)

[Wayne Pollock (pollock-acm)]

HTML 4 and earlier have officially been superseded by HTML 5. So although browsers continue to support HTML 3 and 4 (and most of my web pages are written for those specifications), it is clear that Mozilla is not going to spend time or money fixing the browser to support what they apparently believe to be an obsolete standard. I think it's time to put this bug out of its misery.
Brian's link to the w3.org bug was interesting, but all modern browser now support nth-child. I will just have to redo my web pages. *sigh*

[AlastairC (ac-alastc)]

Agree with Wayne, and note that W3C spec dev is now done in github:
https://github.com/w3c/html/issues/

It is a while since bugzilla was used for HTML/CSS etc.

Previous versions of HTML (that include align attributes on col) are superseded, and the recent versions don't include align attributes on col:
https://www.w3.org/TR/html52/tabular-data.html#the-col-element

I beleive it is seen as a presentational, therefore CSS issue.

Which is a shame, this is the first bug I subscribed to in around 1998 ;-)

[Sledru (sledru)]

I guess it is safe to close it. It has been more than 20 years and it is unlikely we will spend time on it...

[brianary (brian-webcoder)]

(In reply to Wayne Pollock from comment #401)
> Brian's link to the w3.org bug was interesting, but all modern browser now
> support nth-child. I will just have to redo my web pages. *sigh*

As mentioned in that link, nth-child is not a solution, not due to lack of support though. There's a reason to one uses it.

Adding CSS somewhere, the style

[brianary (brian-webcoder)]

(In reply to Wayne Pollock from comment #401)
> Brian's link to the w3.org bug was interesting, but all modern browser now
> support nth-child. I will just have to redo my web pages. *sigh*

As mentioned in that link, nth-child is not a solution, not due to lack of support though. There's a reason to one uses it.

Adding CSS somewhere, even when you can, to style a single table by column position (which can change as you author/update it), is unmaintainable at best.

Examine tables in the wild. It's all cell-by-cell attributes, either by CSS classes or alignment attributes. Think about how inefficient that is. All because no one takes this bug seriously.

(Almost impossible to add a comment to this bug in Firefox Mobile.)