Last Comment Bug 2212 - (character-alignment) character alignment not implemented (align=char, charoff=, text-align:<string>)
(character-alignment)
: character alignment not implemented (align=char, charoff=, text-align:<string>)
Status: NEW
[bae:20011119][HTML4-11.3.2]
: css2, highrisk, html4, testcase
Product: Core
Classification: Components
Component: Layout: Tables (show other bugs)
: Trunk
: All All
: P3 normal with 104 votes (vote)
: Future
Assigned To: Nobody; OK to take it and work on it
:
:
Mentors:
http://www.hixie.ch/tests/evil/mixed/...
: 2752 7510 50000 50021 50087 50096 50101 85830 197766 246015 (view as bug list)
Depends on:
Blocks: html4.01 robin's 104166 980595
  Show dependency treegraph
 
Reported: 1999-01-06 16:54 PST by karnaze (gone)
Modified: 2015-09-25 13:26 PDT (History)
67 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
(css2) text-align:<string> testcase (862 bytes, text/html)
2002-07-11 15:51 PDT, Madhur Bhatia
no flags Details
Slightly modified version of attachment #91020 (893 bytes, text/html)
2002-12-05 08:37 PST, Christian Schmidt
no flags Details

Description karnaze (gone) 1999-01-06 16:54:48 PST
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
Comment 1 leger 1999-02-03 08:07:59 PST
Setting all current Open/Normal to M4.
Comment 2 karnaze (gone) 1999-03-01 21:23:59 PST
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.
Comment 3 karnaze (gone) 1999-03-01 21:24:59 PST
*** Bug 2752 has been marked as a duplicate of this bug. ***
Comment 4 Christine Hoffman 1999-03-02 10:23:59 PST
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.
Comment 5 Hixie (not reading bugmail) 1999-03-26 19:57:59 PST
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'. ]
Comment 6 Christine Hoffman 1999-04-20 18:00:59 PDT
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.
Comment 7 Peter Linss 1999-09-07 17:45:59 PDT
Pushing off non-beta 1 issues
Comment 8 Pierre Saslawsky 1999-10-21 01:06:59 PDT
Reassigning peterl's bugs to myself.
Comment 9 Pierre Saslawsky 1999-10-21 01:12:59 PDT
Accepting peterl's bugs that have a Target Milestone
Comment 10 Pierre Saslawsky 1999-12-20 21:10:59 PST
Pushing my M15 bugs to M16
Comment 11 Hixie (not reading bugmail) 2000-01-13 16:06:59 PST
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...
Comment 12 Chris Petersen 2000-02-24 17:35:31 PST
Since this attribute is completely failing, adding beta1 to keywords.
Comment 13 Pierre Saslawsky 2000-02-24 17:47:53 PST
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.

Comment 14 karnaze (gone) 2000-02-24 18:10:40 PST
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.
Comment 15 Marc Attinasi 2000-06-06 13:34:59 PDT
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.
Comment 16 Karl Ove Hufthammer 2000-06-07 08:51:02 PDT
Since Mozilla is *supposed to* to support HTML 100 %, I don't think this bug 
should be marked as 'Future'.
Comment 17 Marc Attinasi 2000-06-07 09:39:46 PDT
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.
Comment 18 Hixie (not reading bugmail) 2000-06-07 09:58:11 PDT
That's fair enough, but we CANNOT claim 100% HTML4 compliance unless we support
this (and all the other bugs blocking bug 7954).
Comment 19 Marc Attinasi 2000-06-07 10:22:59 PDT
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...
Comment 20 Henrik Lynggaard Hansen 2000-06-15 00:33:34 PDT
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
Comment 21 Pierre Saslawsky 2000-06-15 05:09:47 PDT
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."
Comment 22 Jason Eager 2000-08-07 20:15:47 PDT
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.
Comment 23 Marc Attinasi 2000-08-11 11:01:54 PDT
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...
Comment 24 Jason Eager 2000-08-11 17:41:50 PDT
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.
Comment 25 Marc Attinasi 2000-08-14 14:10:48 PDT
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!
Comment 26 David Baron :dbaron: ⌚️UTC-7 2000-08-14 14:26:15 PDT
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.
Comment 27 Hixie (not reading bugmail) 2000-08-23 13:02:41 PDT
Replacing testcase with a public one. For reference, the original was:
   http://slip/projects/marvin/bugs/tbody_char.html
Comment 28 Hixie (not reading bugmail) 2000-08-23 13:05:22 PDT
*** Bug 50000 has been marked as a duplicate of this bug. ***
Comment 29 Hixie (not reading bugmail) 2000-08-23 13:05:47 PDT
*** Bug 50000 has been marked as a duplicate of this bug. ***
Comment 30 Hixie (not reading bugmail) 2000-08-23 13:06:51 PDT
*** Bug 50000 has been marked as a duplicate of this bug. ***
Comment 31 Hixie (not reading bugmail) 2000-08-23 13:07:52 PDT
eek, the Bugzilla Mid-Air Collision bug rears it's head once more.
Sorry about that.
Comment 32 Hixie (not reading bugmail) 2000-08-23 21:43:57 PDT
*** Bug 50096 has been marked as a duplicate of this bug. ***
Comment 33 Hixie (not reading bugmail) 2000-08-23 21:44:02 PDT
*** Bug 50087 has been marked as a duplicate of this bug. ***
Comment 34 Hixie (not reading bugmail) 2000-08-23 21:44:10 PDT
*** Bug 50101 has been marked as a duplicate of this bug. ***
Comment 35 Hixie (not reading bugmail) 2000-08-23 22:04:14 PDT
*** Bug 50021 has been marked as a duplicate of this bug. ***
Comment 36 NextVision 2000-09-08 11:08:19 PDT
Adding to CC, sorry for the spam
Comment 37 Charles Manske 2000-09-13 23:01:01 PDT
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?

Comment 38 buster 2000-09-13 23:22:53 PDT
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.
Comment 39 Jason Eager 2000-12-21 14:34:50 PST
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.
Comment 40 buster 2000-12-27 14:19:26 PST
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.
Comment 41 Jason Eager 2000-12-27 17:09:04 PST
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?
Comment 42 Marc Attinasi 2001-01-02 14:40:34 PST
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.
Comment 43 Hixie (not reading bugmail) 2001-02-12 16:24:40 PST
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...
Comment 44 Charles Manske 2001-02-26 09:49:22 PST
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.
Comment 45 Amarendra Hanumanula 2001-04-30 18:25:45 PDT
Nominating this bug for the next netscape release because this is needed for the 
feature complete..
Comment 46 Brian McCloud 2001-09-01 10:26:03 PDT
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
Comment 47 Fabian Guisset 2001-11-11 15:28:57 PST
*** Bug 85830 has been marked as a duplicate of this bug. ***
Comment 48 rubydoo123 2001-11-20 16:39:25 PST
reduced to P4 added testcase keyword
Comment 49 David Baron :dbaron: ⌚️UTC-7 2002-06-29 20:40:52 PDT
->tables
Comment 50 Madhur Bhatia 2002-07-11 15:51:53 PDT
Created attachment 91020 [details]
(css2) text-align:<string> testcase

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
Comment 51 Peter K. Sheerin 2002-07-16 14:46:28 PDT
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
Comment 52 Charles Manske 2002-07-16 16:53:47 PDT
Peter: I agree! Note that UI for supporting this in Composer, including setting 
the "char" has been ready for many months.
Comment 53 Christian Schmidt 2002-12-05 08:37:56 PST
Created attachment 108368 [details]
Slightly modified version of attachment #91020 [details]

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;
}
Comment 54 Boris Zbarsky [:bz] (still a bit busy) 2003-03-16 22:26:44 PST
*** Bug 197766 has been marked as a duplicate of this bug. ***
Comment 55 Boris Zbarsky [:bz] (still a bit busy) 2003-03-16 22:35:16 PST
Filed bug 197771 on the CSS parsing issue.
Comment 56 karnaze (gone) 2003-03-31 10:28:27 PST
->default owner
Comment 57 karnaze (gone) 2003-03-31 11:18:40 PST
mass reassign to default owner
Comment 58 Boris Zbarsky [:bz] (still a bit busy) 2003-04-22 23:49:06 PDT
*** Bug 7510 has been marked as a duplicate of this bug. ***
Comment 59 Max Kanat-Alexander 2003-07-18 00:11:10 PDT
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
Comment 60 David Tenser [:djst] 2004-06-09 06:11:51 PDT
*** Bug 246015 has been marked as a duplicate of this bug. ***
Comment 61 David Baron :dbaron: ⌚️UTC-7 2006-09-26 18:59:54 PDT
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).
Comment 62 Maxx 2007-11-07 07:02:35 PST
Nothing new here... still no support???
Comment 63 Xavier Mouton-Dubosc 2008-09-19 11:27:23 PDT
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,...)
Comment 64 Xavier Mouton-Dubosc 2008-09-21 03:28:38 PDT
This bug is a duplicate with #915.
I'm really surprised nobody noticied this before.
Comment 65 Tony Smith 2008-09-21 04:18:02 PDT
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.
Comment 66 Kyle K. 2009-03-11 10:31:15 PDT
Wow, 10 years and this still isn't implemented and is still listed as NEW?!  Is there any hope for this being worked on?
Comment 67 Gordon P. Hemsley [:GPHemsley] 2009-03-11 16:40:32 PDT
(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.
Comment 68 Randell Jesup [:jesup] 2011-05-20 12:16:49 PDT
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.
Comment 69 Patrick Dark 2011-05-23 22:25:53 PDT
(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
Comment 70 David Baron :dbaron: ⌚️UTC-7 2015-09-24 21:58:04 PDT
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.
Comment 71 David Baron :dbaron: ⌚️UTC-7 2015-09-25 09:47:35 PDT
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.

Note You need to log in before you can comment on or make changes to this bug.