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

Status: NEW

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

Description

[karnaze (gone)]

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]

Setting all current Open/Normal to M4.

Comment 2

[karnaze (gone)]

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)]

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

Comment 4

[Christine Hoffman]

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)]

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]

py8ieh=[e-mail] 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]

Pushing off non-beta 1 issues

Comment 8

[Pierre Saslawsky]

Reassigning peterl's bugs to myself.

Comment 9

[Pierre Saslawsky]

Accepting peterl's bugs that have a Target Milestone

Comment 10

[Pierre Saslawsky]

Pushing my M15 bugs to M16

Comment 11

[Hixie (not reading bugmail)]

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]

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

Comment 13

[Pierre Saslawsky]

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)]

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]

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]

Since Mozilla is *supposed to* to support HTML 100 %, I don't think this bug 
should be marked as 'Future'.

Comment 17

[Marc Attinasi]

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)]

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]

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]

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]

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]

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]

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]

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]

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-4, no longer working on Mozilla)]

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)]

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)]

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

Comment 29

[Hixie (not reading bugmail)]

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

Comment 30

[Hixie (not reading bugmail)]

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

Comment 31

[Hixie (not reading bugmail)]

eek, the Bugzilla Mid-Air Collision bug rears it's head once more.
Sorry about that.

Comment 32

[Hixie (not reading bugmail)]

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

Comment 33

[Hixie (not reading bugmail)]

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

Comment 34

[Hixie (not reading bugmail)]

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

Comment 35

[Hixie (not reading bugmail)]

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

Comment 36

[NextVision]

Adding to CC, sorry for the spam

Comment 37

[Charles Manske]

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]

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]

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]

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]

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]

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)]

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]

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]

Nominating this bug for the next netscape release because this is needed for the 
feature complete..

Comment 46

[Brian McCloud]

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]

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

Comment 48

[rubydoo123]

reduced to P4 added testcase keyword

Comment 49

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

->tables

Comment 50

[Madhur Bhatia]

Attachment: (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]

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]

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]

Attachment: Slightly modified version of attachment #91020

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 [:bzbarsky]]

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

Comment 55

[Boris Zbarsky [:bzbarsky]]

Filed bug 197771 on the CSS parsing issue.

Comment 56

[karnaze (gone)]

->default owner

Comment 57

[karnaze (gone)]

mass reassign to default owner

Comment 58

[Boris Zbarsky [:bzbarsky]]

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

Comment 59

[Max Kanat-Alexander]

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

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

Comment 61

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

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]

Nothing new here... still no support???

Comment 63

[Xavier Mouton-Dubosc]

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]

This bug is a duplicate with #915.
I'm really surprised nobody noticied this before.

Comment 65

[Tony Smith]

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

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

(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] (needinfo me)]

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]

(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-4, no longer working on Mozilla)]

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-4, no longer working on Mozilla)]

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.

Comment 73

[BugBot [:suhaib / :marco/ :calixte]]

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.

Comment 74

[BugBot (nomail) [:suhaib / :marco/ :calixte]]

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.