Bug 2212 (character-alignment)

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

NEW
Unassigned

Status

()

Core
Layout: Tables
P3
normal
19 years ago
2 years ago

People

(Reporter: karnaze (gone), Unassigned)

Tracking

(4 keywords)

Trunk
Future
css2, highrisk, html4, testcase
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

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

Attachments

(2 attachments)

(Reporter)

Description

19 years ago
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

19 years ago
Setting all current Open/Normal to M4.
(Reporter)

Comment 2

19 years ago
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.
(Reporter)

Comment 3

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

Updated

19 years ago

Comment 4

19 years ago
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:

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

Updated

18 years ago
Status: NEW → ASSIGNED
Target Milestone: M4 → M7

Updated

18 years ago
Severity: enhancement → normal

Comment 6

18 years ago
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.
Blocks: 7954

Updated

18 years ago
Target Milestone: M10 → M11

Comment 7

18 years ago
Pushing off non-beta 1 issues
Summary: character alignment not implemented → {css2} character alignment not implemented

Comment 8

18 years ago
Reassigning peterl's bugs to myself.

Comment 9

18 years ago
Accepting peterl's bugs that have a Target Milestone

Comment 10

18 years ago
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...

Updated

18 years ago
Summary: {css2} character alignment not implemented → character alignment not implemented

Comment 12

18 years ago
Since this attribute is completely failing, adding beta1 to keywords.
Keywords: beta1

Comment 13

18 years ago
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
Status: ASSIGNED → NEW
(Reporter)

Comment 14

18 years ago
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

Updated

18 years ago
Status: NEW → ASSIGNED

Updated

17 years ago
Target Milestone: M16 → M20

Updated

17 years ago
Priority: P2 → P3

Comment 15

17 years ago
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

Comment 16

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

Comment 17

17 years ago
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).

Comment 19

17 years ago
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

Comment 21

17 years ago
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

17 years ago
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

17 years ago
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

Comment 24

17 years ago
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

17 years ago
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.
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. ***

Comment 36

17 years ago
Adding to CC, sorry for the spam

Comment 37

17 years ago
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

17 years ago
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

Updated

17 years ago
Blocks: 41368

Comment 39

17 years ago
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.
Keywords: highrisk, mozilla0.9, mozilla1.0

Comment 40

17 years ago
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

17 years ago
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

17 years ago
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

Updated

17 years ago
Blocks: 69795

Comment 44

17 years ago
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

Comment 45

16 years ago
Nominating this bug for the next netscape release because this is needed for the 
feature complete..
Keywords: mozilla0.9.1, nsbeta1

Comment 46

16 years ago
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

Updated

16 years ago
Blocks: 104166

Comment 47

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

Comment 48

16 years ago
reduced to P4 added testcase keyword
Keywords: testcase
Priority: P3 → P4
Whiteboard: [bae:20011119]
Whiteboard: [bae:20011119] → [bae:20011119][HTML4-11.3.2]
->tables
Assignee: attinasi → karnaze
Status: ASSIGNED → NEW
Component: Style System → HTMLTables
Priority: P4 → P3
QA Contact: ian → amar

Comment 50

15 years ago
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

15 years ago
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

15 years ago
Peter: I agree! Note that UI for supporting this in Composer, including setting 
the "char" has been ready for many months.

Comment 53

15 years ago
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;
}
*** Bug 197766 has been marked as a duplicate of this bug. ***
Filed bug 197771 on the CSS parsing issue.
(Reporter)

Comment 56

14 years ago
->default owner
Assignee: karnaze → table
QA Contact: amar → madhur
Target Milestone: Future → ---
(Reporter)

Comment 57

14 years ago
mass reassign to default owner

Updated

14 years ago
Target Milestone: --- → Future
*** Bug 7510 has been marked as a duplicate of this bug. ***

Comment 59

14 years ago
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

Updated

13 years ago
Alias: character-alignment
Keywords: mozilla1.0
QA Contact: madhur → ian
Blocks: 226823
No longer blocks: 226823

Comment 60

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

Updated

12 years ago
Blocks: 163993

Updated

12 years ago
No longer blocks: 163993
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

10 years ago
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.

Comment 65

9 years ago
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

8 years ago
Wow, 10 years and this still isn't implemented and is still listed as NEW?!  Is there any hope for this being worked on?
Blocks: 915
(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: 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.

Comment 69

6 years ago
(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

Updated

4 years ago
Blocks: 913153

Updated

4 years ago
No longer blocks: 913153

Updated

3 years ago
Blocks: 980595
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.
You need to log in before you can comment on or make changes to this bug.