Open Bug 2212 (character-alignment) Opened 25 years ago Updated 11 months ago

character alignment not implemented (align=char, charoff=, text-align:<string>)


(Core :: Layout: Tables, defect, P3)




Tracking Status
firefox76 --- verified
firefox77 --- verified
firefox78 --- verified


(Reporter: karnaze, Unassigned)




(4 keywords, Whiteboard: [bae:20011119][HTML4-11.3.2])


(2 files)

tables need to support the html4 align="char". Peter needs to add mAlignChar to
nsStyleTable and allow nsStyleTable to be inherited. Next, reassign the bug to
Kipp so he can make nsBlockFrame honor char alignment. Next, reassign the bug to
me so I can change the table code. I will be adding 2 data members
(useAlignCharOffset, alignCharOffset) to nsIFrameReflow.h
Setting all current Open/Normal to M4.
The 2 data members were added to nsIHTMLReflow.h with some comments. If
nsStyleTable has mAlignChar set to NS_STYLE_TEXT_ALIGN_CHAR and line layout gets
a reflow state where mUseAlignCharOffset is false, then line layout should set
mAlignCharOffset. If mUseAlignCharOffset is true, then line layout should use
mAlignCharOffset in its calculations.
*** Bug 2752 has been marked as a duplicate of this bug. ***
Assigning QA contact to chrisd, adding URL as an example and transferring
comments from duplicate bug #2752

Using 1/27 build - tested on Win 95, Win NT, Win 98, Mac 8.5 and Linux (Sujay).

Open URL. A table should display with THEAD, TBODY and TFOOT sections. In the
TBODY section there are three columns/two rows of numbers. The TBODY element
has 'ALIGN' and 'CHAR' attributes assigned to it which instruct the cell
contents (numbers) to align on the decimal point.

Expected result: Numbers should align on the decimal point.

Actual results: Numbers do not align on the decimal point.
Severity: normal → enhancement
OS: Windows NT → All
Hardware: PC → All
There is a very simple test case for this bug outside the netscape firewall at:

It applies the align and alignchar on the COL element. Note that CSS2 also has
a way of doing this, namely the text-align property takes a <string> value
which has the same effect as the char attribute in html tables.

[ Reducing severity to 'enhancement', since this is a feature addition
request, and not really a bug. Changing platform and OS to 'All'. ]
Target Milestone: M4 → M7
Severity: enhancement → normal changed severity to 'enhancement' but I am changing
back to 'normal'. Since we are supporting HTML 4.0 100%, this really isn't an
enhancement request, rather it is a requirement. If I'm off base, please inform.
Target Milestone: M10 → M11
Pushing off non-beta 1 issues
Summary: character alignment not implemented → {css2} character alignment not implemented
Reassigning peterl's bugs to myself.
Accepting peterl's bugs that have a Target Milestone
Pushing my M15 bugs to M16
Keywords: css2
Migrating from {css2} to css2 keyword. The {css1}, {css2}, {css3} and {css-moz}
radars should now be considered deprecated in favour of keywords.
I am *really* sorry about the spam...
Summary: {css2} character alignment not implemented → character alignment not implemented
Since this attribute is completely failing, adding beta1 to keywords.
Keywords: beta1
petersen: I hope you won't mark 'beta1' all the small things in the product that 

are "completely failing" just for the sake of it. Is there a specific reason for 

marking this bug beta1? Does it block someone? Does it cause a top100 page to 

render incorrectly?

Anyhow, I'm reassigning it to attinasi since it's related to style inside tables.

Assignee: pierre → attinasi
Removing beta1 keyword since we decided long ago that it will not make it. There  
is too much code that needs to change - style, block, table.
Keywords: beta1
Target Milestone: M16 → M20
Priority: P2 → P3
This bug has been marked "future" because we have determined that it is not 
critical for netscape 6.0. If you feel this is an error, or if it blocks your 
work in some way -- please attach your concern to the bug for reconsideration.
Target Milestone: M20 → Future
Since Mozilla is *supposed to* to support HTML 100 %, I don't think this bug 
should be marked as 'Future'.
Is character alignment a very widely used attribute / property? I understand 
that we are suppossed to be 100% HTML 4.01 compliant, but we have limited time 
and this does not seem like a widely used feature. If anyone knows of any sites 
using this that look really bad without it please attach the URLs to this bug so 
we can check them out.

Part of the problem with implementing this is the large number of impacted 
areas: layout has to actually do the alignment, style has to support the 
'string' value on the text-align property, table elements have to support 
mapping the attribute into the style context, and the inheritance from COL to 
the cells has to be at least partially implemented.
That's fair enough, but we CANNOT claim 100% HTML4 compliance unless we support
this (and all the other bugs blocking bug 7954).
Thanks for pointing out the meta-bug, Ian. If we get to final ship and this is 
the only one left, we'll probably have to fix it...
I disagree with the "future" milestone. HTML compliance should be the top 
priority even if it is not widely used.

im upping priority to reflect this
Priority: P3 → P1
To put it blantly... There is no doubt Mozilla1 will be 100% compliant one day. 
When? I don't know. In the meanwhile, Netscape6 MUST and WILL ship this year. As 
we wrote, "this bug has been marked "future" because we have determined that it 
is not critical for netscape 6.0."
Can we split jobs up in order to get this implimented? After all the statements
about mozilla being the most compiliant browser, it would be a shame to fall
short. I'm volunteering.
JCE2 - thanks for volunteering to take a look at implementing this. Please feel 
free to ask questions or request reviews through this bug. We'd love to see this 
get into the release!

I'm setting the priority back to P3. In general it is up to the owning engineer 
to assign priorities. Contributors can advise and argue about the priority, 
however ultimately it is the module owner who has the last say. In this case, 
the priority of P1 is not justified as this is not crashing or losing data...
Priority: P1 → P3
Ok, my first question is "Which features that need to be added to these
components are blocking other bugs?" I'm obviously going to have to
land this with several patches, and I want to see which part would be beneficial
The StyleSystem needs to parse and store the value of text-align (may already be 
doing that OK), then the various frames invloved (nsBlockFrame at least, I 
think) needs to detect the style property and do the alignment, and finally 
tables need to follow a similar path as the BlockFrame.

Sorry to be so vague, but I cannot look deeper right now... Thanks!
The main thing that needs to be done is implement <string> values the CSS
text-align property.  Then you just map align=char and the character to the
appropriate text-align in the attribute mapping code.

I suspect blockFrame may already handle CSS text-align <string> correctly,
although it's worth checking.  All frames *except* table cell frames should
treat it as 'left' (or 'right', if 'direction' is 'rtl').

Making tables do this is somewhat hard, because (among other issues) it adds
additional constraints to column widths (forcing them to be wider).  See my test
page at for an exploration
of some of the issues.
*** Bug 50000 has been marked as a duplicate of this bug. ***
*** Bug 50000 has been marked as a duplicate of this bug. ***
*** Bug 50000 has been marked as a duplicate of this bug. ***
eek, the Bugzilla Mid-Air Collision bug rears it's head once more.
Sorry about that.
Summary: character alignment not implemented → character alignment not implemented (align=char, charoff=, text-align:<string>)
*** Bug 50096 has been marked as a duplicate of this bug. ***
*** Bug 50087 has been marked as a duplicate of this bug. ***
*** Bug 50101 has been marked as a duplicate of this bug. ***
*** Bug 50021 has been marked as a duplicate of this bug. ***
Adding to CC, sorry for the spam
So after going through the trouble of implementing support for this in 
Composer's Table Properties dialog, we don't layout correctly!
So much for assuming complete HTML 4.0 implementation.
My only concern is this: What do I do when I encounter align="char" on a TD?
If I ommit that option from the Alignment menulist in the dialog, the user
won't know the real attribute and might inadvertantly change it.
Maybe better to leave Composer's support in even if we don't layout correctly?

added keyword "html4", this is really an HTML standards issue at least as much 
as a CSS2 issue.

Charlie, to answer your question:  the editor should support the attribute.  The 
editing experience shouldn't have to change just because layout has a missing 
feature.  It's still perfectly valid for the author to want to add or change 
these properties, even though they won't see the WYSIWYG results in our editor 
until we implement this feature.  We should be able to rev the layout engine and  
have the editor just work with the new feature in NS 6.01.  We shouldn't have to 
rev the editor UI to match the improvements in the layout engine.
Keywords: html4
Blocks: robin's
Nominating for Mozilla 0.9 because it is work that could have far reaching
consequences on the layout engine (as stated by David Barron), and therefore we
should get it done sooner rather then later.

Nominating for Mozilla 1.0 if we don't get it done by 0.9, because there is no
way that we should ship a 1.0 without having this feature.
I have very strong doubts that this will make mozilla1.0.  It's a nice feature,
but far from critical.  Support for it in other browsers is weak or non-existent.

Netscape developers are highly focused on stability, correctness, and
performance for mozilla1.0.  We are adding very few new features this round.  So
if this feature were to be included, it would almost certainly have to be by
someone outside of Netscape.  Netscapers are available for consulting, design,
reviews, etc. of course.

JCE2, did you ever make any progress?  Getting the style system up to snuff is
the first step, and reading through the comments it seems like you said you'd
take a crack at it.  Until that's done, no one else can really do much in layout
to support this.
I'm looking at the code in layout/html/style/src right now.

Is there some better documentation about how all of these structures work?
Or at least where I should begin?
There is nothing in the way of documentation to help you, sorry.

There are two different issues to consider in getting the data into the style
system: 1) the nsStyleTable struct needs a field to hold the align character,
and it needs to manage that value in terms of inheritance (nsIStyleContext.h,
nsStyleContext.cpp) and 2) the alignment can be set via HTML attributes (align=)
or via CSS (text-align:). The former requires changes to how the HTML elements
parse their attribute values, and the latter requires a change to the CSS Parser
to allow the character string value to the text-align property.

HTML Elements usually get their stylistic properties pushed into style
structures via the MapAttributesInto method, so look at existing examples of that.

One other note: somebody could always fake the frame code to think that it has
an align char - that way the separate tasks of getting the style system tweaked
and the layout code implemented could be tackled independently - just a thought.
Netscape's standard compliance QA team reorganised itself once again, so taking 
remaining non-tables style bugs. Sorry about the spam. I tried to get this done 
directly at the database level, but apparently that is "not easy because of the 
shadow db", "plus it screws up the audit trail", so no can do...
QA Contact: chrisd → ian
Blocks: 69795
Note that after more research by beppe, it seems that no one really supports
this, so we removed the UI in Composer (to be checked in to fix bug 69795).
Thus this no longer blocks 69795.
No longer blocks: 69795
Nominating this bug for the next netscape release because this is needed for the 
feature complete..
I have put up a page that is based on Ian Hickson's test case for this bug, but
I have also included a second table that displays almost what I believe would be
the correct rendering of the table (it IS effectively character aligned (except
the header), but there are a few boundary and gap problems, since this simulates
the alignment by splitting each cell into 3); it is at
Blocks: 104166
*** Bug 85830 has been marked as a duplicate of this bug. ***
reduced to P4 added testcase keyword
Keywords: testcase
Priority: P3 → P4
Whiteboard: [bae:20011119]
Whiteboard: [bae:20011119] → [bae:20011119][HTML4-11.3.2]
Assignee: attinasi → karnaze
Component: Style System → HTMLTables
Priority: P4 → P3
QA Contact: ian → amar
in this testcase, the text-align style has the value <string>. It does not work
as desired. see
Given the age of this bug, I'm surprised it has not been implemented yet. The 
reasons given are that it's not widely used, but that is only because no 
browser supports it. Character alignment, and decimal alignment in particular, 
are extremely important for making tabular data easy to read. That IE doesn't 
support it should be irrelevant.

There is a table at the bottom of this URL that can be used as a test case. It 
contains alignments both on the decimal point and on the colon (for time).
Peter: I agree! Note that UI for supporting this in Composer, including setting 
the "char" has been ready for many months.
Not only does Mozilla not support text-align:<string>. It also does not ignore
occurences of text-align:<string> correctly as specified in section 4.2 of the
CSS spec - that is, if "invalid" means "not known by Mozilla" (is this a
reasonable translation?). Instead text-align:<string> has the same effect as

The following style sheet is meant to align the text on the decimal point, or -
if text-align:<string> is not supported - to right-align the text. {
	text-align: right;
	text-align: ".";

Mozilla acts as if the style sheet were {
	text-align: left;

though it should act (assuming that text-align:<string> is still not
implemented) as if it were {
	text-align: right;
*** Bug 197766 has been marked as a duplicate of this bug. ***
Filed bug 197771 on the CSS parsing issue.
->default owner
Assignee: karnaze → table
QA Contact: amar → madhur
Target Milestone: Future → ---
mass reassign to default owner
Target Milestone: --- → Future
*** Bug 7510 has been marked as a duplicate of this bug. ***
Will this still be highrisk after the rearchitecturing that's going on? Perhaps
it might be a good idea to target this for Mozilla1.6a. It is a feature that
would make financial intranet applications more useable.

Alias: character-alignment
Keywords: mozilla1.0
QA Contact: madhur → ian
No longer blocks: badtests
*** Bug 246015 has been marked as a duplicate of this bug. ***
Blocks: majorbugs
No longer blocks: majorbugs
For what it's worth, character alignment must affect preferred intrinsic width calculation (although probably not minimum intrinsic width) -- and this doubles -- or maybe even triples -- the number of variables that need to be maintained per-column while computing intrinsic widths (you need intrinsic width before the alignment point, intrinsic width after the alignment point, and perhaps intrinsic width for other lines in the cell, depending on what the rules for such lines are).
Nothing new here... still no support???
Well... ran into this missing feature, that is always described into HTML4, XHTML, HTML5.
Having it could be useful from financial applications (web commerce, calc,...)
This bug is a duplicate with #915.
I'm really surprised nobody noticied this before.
This is not a duplicate of 915.
This is concerned with a particular kind of column alignment that is missing.
915 is concerned with inheriting column alignment settings.
Wow, 10 years and this still isn't implemented and is still listed as NEW?!  Is there any hope for this being worked on?
(In reply to comment #65)
> This is not a duplicate of 915.
> This is concerned with a particular kind of column alignment that is missing.
> 915 is concerned with inheriting column alignment settings.

Bug 915 addresses the inheritance of align="char", too. As such, I've marked bug 2212 (this bug) as blocking bug 915.
Assignee: layout.tables → nobody
QA Contact: ian → layout.tables
No longer blocks: col-align-inherit
A note from bug 69795 comment 14, from the spec

" User agents are not required to support this attribute. "

Not to say it wouldn't have some use, but no one supports it so there's no impetus for someone to use it if we added it, and there's no "compliance" win to implementing it.
(In reply to comment #68)
> Not to say it wouldn't have some use, but no one supports it so there's no
> impetus for someone to use it if we added it, and there's no "compliance"
> win to implementing it.

|text-align: <string>| continues to be defined in CSS3 Text [1], so there /is/ a "compliance" win.

And, while it's probably not necessary to support the HTML4/XHTML1 attributes, it seems that they may as well be supported given that the corresponding DOM2 HTML properties [2] are already supported.

Blocks: css3test
No longer blocks: css3test
Blocks: 980595
There's a spec for this at that actually defines most of the obvious previously-undefined issues, except for the one it explicitly leaves undefined at the end: " If width constraints on the cell contents prevent full alignment throughout the column, the resulting alignment is undefined." (which really should be defined, since it will be quite common).

The hard part of implementing this is the table with stuff (as I mentioned in comment 61).  The main work of implementing this is splitting table column max-content widths into three parts:  the max-content width of a cell without an alignment character, the max-content width of the part before the alignment point, and the max-content width of the part after the alignment point.  I presume that it doesn't affect min-content widths (I think!?), and that it also doesn't affect any intrinsic width handling of cells that specify percentage widths.

The other interesting case that I'm not sure how to deal with off the top of my head is a cell with a specified non-percentage width that has a character alignment point.  I think that splits into three cases:
 (a) specified width >= max-content width
 (b) max-content width > specified width >= min-content width
 (c) min-content width > specified width
First of all, (c) works by just bumping the specified width to the min-content width and then reducing it to (b).  The interesting part, then, is whether there's a distinction between (b) and (a), and in both cases, what contributions are made to the non-alignment-point max-content width of the column and to the before-alignment-point and after-alignment-point max-content widths of the columns.
On second thought, maybe the right thing to do is to split both max-content *and* min-content widths that way.  This would increase min-content widths when char alignment is used, and make it more likely to work as expected, at the cost of crunching the other columns in the table more when there's a space shortage.
Severity: normal → S3
Flags: needinfo?(100ald0417)

The severity field for this bug is relatively low, S3. However, the bug has 10 duplicates, 104 votes and 74 CCs.
:dholbert, could you consider increasing the bug severity?

For more information, please visit auto_nag documentation.

Flags: needinfo?(dholbert)

The last needinfo from me was triggered in error by recent activity on the bug. I'm clearing the needinfo since this is a very old bug and I don't know if it's still relevant.

Flags: needinfo?(dholbert)
Flags: needinfo?(100ald0417)
You need to log in before you can comment on or make changes to this bug.