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.

There is a very simple test case for this bug outside the netscape firewall at: http://www.bath.ac.uk/%7Epy8ieh/internet/eviltests/tables.html 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'. ]

py8ieh=bugzilla@bath.ac.uk 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.

Pushing off non-beta 1 issues

Reassigning peterl's bugs to myself.

Accepting peterl's bugs that have a Target Milestone

Pushing my M15 bugs to M16

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...

Since this attribute is completely failing, adding beta1 to keywords.

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.

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.

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.

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

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...

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 first.

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 http://www.people.fas.harvard.edu/~dbaron/css/test/sec170504 for an exploration of some of the issues.

Replacing testcase with a public one. For reference, the original was: http://slip/projects/marvin/bugs/tbody_char.html

*** 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.

*** 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.

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...

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.

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 http://members.home.net/mauvecloud/tables.html

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

reduced to P4 added testcase keyword

->tables

in this testcase, the text-align style has the value <string>. It does not work as desired. see http://www.w3.org/TR/REC-CSS2/tables.html#column-alignment

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). http://www.cadenceweb.com:8080/newsletter/sheerin/test/Prototype6a.html

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 text-align:left. 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. td.one { text-align: right; text-align: "."; } Mozilla acts as if the style sheet were td.one { text-align: left; } though it should act (assuming that text-align:<string> is still not implemented) as if it were td.one { text-align: right; }

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

Filed bug 197771 on the CSS parsing issue.

->default owner

mass reassign to default owner

*** 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. -M

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

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.

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. [1] http://dev.w3.org/csswg/css3-text/#text-align [1] http://www.w3.org/TR/css3-text/#text-align [2] http://www.w3.org/TR/DOM-Level-2-HTML/html.html#ID-84150186

There's a spec for this at https://drafts.csswg.org/css-text-4/#character-alignment 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.