idnits 2.17.1 draft-ietf-html-tables-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-26) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing document type: Expected "INTERNET-DRAFT" in the upper left hand corner of the first page ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 27 longer pages, the longest (page 2) being 59 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack an Authors' Addresses Section. ** There are 125 instances of too long lines in the document, the longest one being 10 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 12 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 HTML Tables 23 Jan 96 4 INTERNET DRAFT Dave Raggett, W3C 5 Expires in six months email: 7 HTML Tables 9 11 Status of this Memo 13 This document is an Internet draft. Internet drafts are working 14 documents of the Internet Engineering Task Force (IETF), its areas 15 and its working groups. Note that other groups may also distribute 16 working information as Internet drafts. 18 Internet Drafts are draft documents valid for a maximum of six 19 months and can be updated, replaced or obsoleted by other documents 20 at any time. It is inappropriate to use Internet drafts as reference 21 material or to cite them as other than as "work in progress". 23 To learn the current status of any Internet draft please check the 24 "lid-abstracts.txt" listing contained in the Internet drafts shadow 25 directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 26 munnari.oz.au (Pacific Rim), ds.internic.net (US East coast) or 27 ftp.isi.edu (US West coast). Further information about the IETF can 28 be found at URL: http://www.ietf.org/ 30 Distribution of this document is unlimited. Please send comments to 31 the HTML working group (HTML-WG) of the Internet Engineering Task 32 Force (IETF) at . Discussions of this group are 33 archived at URL: http://www.acl.lanl.gov/HTML-WG/archives.html. 35 This specification is also available via the Web in hypertext form 36 as a Working Draft of the World Wide Web Consortium, see: 37 http://www.w3.org/pub/WWW/TR 39 Abstract 41 The HyperText Markup Language (HTML) is a simple markup language 42 used to create hypertext documents that are portable from one 43 platform to another. HTML documents are SGML documents with generic 44 semantics that are appropriate for representing information from a 45 wide range of applications. This specification extends HTML to 46 support a wide variety of tables. The model is designed to work well 47 with associated style sheets, but does not require them. It also 48 supports rendering to braille, or speech, and exchange of tabular 49 data with databases and spreadsheets. The HTML table model embodies 50 certain aspects of the CALS table model, e.g. the ability to group 51 table rows into thead, tbody and tfoot sections, plus the ability to 52 specify cell alignment compactly for sets of cells according to the 53 context. 55 ------------------------------------------------------------------------------ 56 HTML Tables 23 Jan 96 58 Contents 60 * Recent Changes .................................................... 2 62 * Brief Introduction ................................................ 3 64 * Design Rationale .................................................. 5 66 * Walkthrough of the Table DTD ...................................... 7 68 * Recommended Layout Algorithms .................................... 22 70 * The Table DTD .................................................... 25 72 * References ....................................................... 28 74 Recent Changes 76 This specification extends HTML to support tables. The table model 77 has grown out of early work on HTML+ and the initial draft of HTML3. 78 The earlier model has been been extended in response to requests 79 from information providers for improved control over the 80 presentation of tabular information: 82 * alignment on designated characters such as "." and ":" 83 e.g. aligning a column of numbers on the decimal point 85 * more flexibility in specifying table frames and rules 87 * incremental display for large tables as data is received 89 * the ability to support scrollable tables with fixed headers plus 90 better support for breaking tables across pages for printing 92 * optional column based defaults for alignment properties 94 In addition, a major goal has been to provide backwards 95 compatibility with the widely deployed Netscape implementation of 96 tables. A subsidiary goal has been to simplify importing tables 97 conforming to the SGML CALS model. The latest draft makes the ALIGN 98 attribute compatible with the latest Netscape and Microsoft 99 browsers. Some clarifications have been made to the role of the DIR 100 attribute and recommended behaviour when absolute and relative 101 column widths are mixed. 103 A new element COLGROUP has been introduced to allow sets of columns 104 be grouped with different width and alignment properties specified 105 by one or more COL elements. The semantics of COLGROUP have been 106 clarified over previous drafts, and RULES=BASIC replaced by 107 RULES=GROUPS. 109 The STYLE attribute is included as a means for extending the 110 properties associated with edges and interiors of groups of cells. 112 HTML Tables 23 Jan 96 114 For instance, the line style: dotted, double, thin/thick etc; the 115 colour/pattern fill for the interior; cell margins and font info. 116 This will be the subject for a companion specification on style 117 sheets. 119 The FRAME and RULES attributes have been modified to avoid SGML name 120 clashes with each other, and to avoid clashes with the ALIGN and 121 VALIGN attributes. These changes were additionally motivated by the 122 desire to avoid future problems if this specification is extended to 123 allow FRAME and RULES attributes with other table elements. 125 ------------------------------------------------------------------------------ 126 A Brief Introduction to HTML Tables 128 Tables start with an optional caption followed by one or more rows. 129 Each row is formed by one or more cells, which are differentiated 130 into header and data cells. Cells can be merged across rows and 131 columns, and include attributes assisting rendering to speech and 132 braille, or for exporting table data into databases. The model 133 provides limited support for control over appearence, for example 134 horizontal and vertical alignment of cell contents, border styles 135 and cell margins. You can further affect this by grouping rows and 136 columns together. Tables can contain a wide range of content, such 137 as headers, lists, paragraphs, forms, figures, preformatted text and 138 even nested tables. 140 Example 142 143 144
A test table with merged cells
Average 145 other
category
Misc 146
heightweight 147
males1.90.003 148
females1.70.002 149
151 On a dumb terminal, this would be rendered something like: 153 A test table with merged cells 154 /--------------------------------------------------\ 155 | | Average | other | Misc | 156 | |-------------------| category |--------| 157 | | height | weight | | | 158 |-----------------------------------------|--------| 159 | males | 1.9 | 0.003 | | | 160 |-----------------------------------------|--------| 161 | females | 1.7 | 0.002 | | | 162 \--------------------------------------------------/ 164 HTML Tables 23 Jan 96 166 Next, a richer example with grouped rows and columns (adapted from 167 "Developing International Software" by Nadine Kano). First here is 168 what the table looks like on paper: 170 CODE-PAGE SUPPORT IN MICROSOFT WINDOWS 171 =============================================================================== 172 Code-Page | Name | ACP OEMCP | Windows Windows Windows 173 ID | | | NT 3.1 NT 3.51 95 174 ------------------------------------------------------------------------------- 175 1200 | Unicode (BMP of ISO 10646) | | X X * 176 1250 | Windows 3.1 Eastern European | X | X X X 177 1251 | Windows 3.1 Cyrillic | X | X X X 178 1252 | Windows 3.1 US (ANSI) | X | X X X 179 1253 | Windows 3.1 Greek | X | X X X 180 1254 | Windows 3.1 Turkish | X | X X X 181 1255 | Hebrew | X | X 182 1256 | Arabic | X | X 183 1257 | Baltic | X | X 184 1361 | Korean (Johab) | X | ** X 185 ------------------------------------------------------------------------------- 186 437 | MS-DOS United States | X | X X X 187 708 | Arabic (ASMO 708) | X | X 188 709 | Arabic (ASMO 449+, BCON V4) | X | X 189 710 | Arabic (Transparent Arabic) | X | X 190 720 | Arabic (Transparent ASMO) | X | X 191 =============================================================================== 193 The markup for this uses COLGROUP elements to group columns and to 194 set default column alignment. TBODY elements are used to group rows. 195 The FRAME and RULES attributes are used to select which borders to 196 render. 198 199 200 201 202 203 204 205 206 214 228
CODE-PAGE SUPPORT IN MICROSOFT WINDOWS
Code-Page
ID 207
Name 208 ACP 209 OEMCP 210 Windows
NT 3.1 211
Windows
NT 3.51 212
Windows
95 213
1200Unicode (BMP of ISO 10646)XX* 215
1250Windows 3.1 Eastern EuropeanXXXX 217 HTML Tables 23 Jan 96 219
1251Windows 3.1 CyrillicXXXX 220
1252Windows 3.1 US (ANSI)XXXX 221
1253Windows 3.1 GreekXXXX 222
1254Windows 3.1 TurkishXXXX 223
1255HebrewXX 224
1256ArabicXX 225
1257BalticXX 226
1361Korean (Johab)X**X 227
437MS-DOS United StatesXXXX 229
708Arabic (ASMO 708)XX 230
709Arabic (ASMO 449+, BCON V4)XX 231
710Arabic (Transparent Arabic)XX 232
720Arabic (Transparent ASMO)XX 233
235 ------------------------------------------------------------------------------ 236 Design Rationale 238 The HTML table model has evolved from studies of existing SGML 239 tables models, the treatment of tables in common word processing 240 packages, and looking at a wide range of tabular layout in 241 magazines, books and other paper-based documents. The model was 242 chosen to allow simple tables to be expressed simply with extra 243 complexity only when needed. This makes it practical to create the 244 markup for HTML tables with everyday text editors and reduces the 245 learning curve for getting started. This feature has been very 246 important to the success of HTML to date. 248 Increasingly people are using filters from other document formats or 249 direct wysiwyg editors for HTML. It is important that the HTML table 250 model fits well with these routes for authoring HTML. This affects 251 how the representation handles cells which span multiple rows or 252 columns, and how alignment and other presentation properties are 253 associated with groups of cells. 255 A major consideration for the HTML table model is that the fonts and 256 window sizes etc. in use with browsers are not under the author's 257 control. This makes it risky to rely on column widths specified in 258 terms of absolute units such as picas or pixels. Instead, tables can 259 be dynamically sized to match the current window size and fonts. 260 Authors can provide guidance as to the relative widths of columns, 261 but user agents should to ensure that columns are wide enough to 262 render the width of the largest single element of the cell's 263 content. If the author's specification must be overridden, it is 264 preferred that the relative widths of individual columns are not 265 changed drastically. 267 For large tables or slow network connections, it is desirable to be 268 able to start displaying the table before all of the data has been 269 received. The default window width for most user agents shows about 270 80 characters, and the graphics for many HTML pages are designed 272 HTML Tables 23 Jan 96 274 with these defaults in mind. Authors can provide a hint to user 275 agents to activate incremental display of table contents. This 276 feature requires the author to specify the number of columns, and 277 includes provision for control of table width and the widths of 278 different columns in relative or absolute terms. 280 For incremental display, the browser needs the number of columns and 281 their widths. The default width of the table is the current window 282 size (width="100%"). This can be altered by including a WIDTH 283 attribute in the TABLE start tag. By default all columns have the 284 same width, but you can specify column widths with one or more COL 285 elements before the table data starts. 287 The remaining issue is the number of columns. Some people have 288 suggested waiting until the first row of the table has been 289 received, but this could take a long time if the cells have a lot of 290 content. On the whole it makes more sense, when incremental display 291 is desired, to get authors to explicitly specify the number of 292 columns in the TABLE start tag. 294 Authors still need a way of informing the browser whether to use 295 incremental display or to automatically size the table to match the 296 cell contents. For the two pass auto sizing mode, the number of 297 columns is determined by the first pass, while for the incremental 298 mode, the number of columns needs to be stated up front. So it seems 299 to that COLS=_nn_ would be better for this purpose than a LAYOUT 300 attribute such as LAYOUT=FIXED or LAYOUT=AUTO. 302 It is generally held useful to consider documents from two 303 perspectives: Structural idioms such as headers, paragraphs, lists, 304 tables, and figures; and rendering idioms such as margins, leading, 305 font names and sizes. The wisdom of past experience encourages us to 306 separate the structural information in documents from rendering 307 information. Mixing them together ends up causing increased cost of 308 ownership for maintaining documents, and reduced portability between 309 applications and media. 311 For tables, the alignment of text within table cells, and the 312 borders between cells are, from the purist's point of view, 313 rendering information. In practice, though, it is useful to group 314 these with the structural information, as these features are highly 315 portable from one application to the next. The HTML table model 316 leaves most rendering information to associated style sheets. The 317 model is designed to take advantage of such style sheets but not to 318 require them. 320 This specification provides a superset of the simpler model 321 presented in earlier work on HTML+. Tables are considered as being 322 formed from an optional caption together with a sequence of rows, 323 which in turn consist of a sequence of table cells. The model 324 further differentiates header and data cells, and allows cells to 325 span multiple rows and columns. 327 HTML Tables 23 Jan 96 329 Following the CALS table model, this specification allows table rows 330 to be grouped into head and body and foot sections. This simplifies 331 the representation of rendering information and can be used to 332 repeat table head and foot rows when breaking tables across page 333 boundaries, or to provide fixed headers above a scrollable body 334 panel. In the markup, the foot section is placed before the body 335 sections. This is an optimization shared with CALS for dealing with 336 very long tables. It allows the foot to be rendered without having 337 to wait for the entire table to be processed. 339 For the visually impaired, HTML offers the hope of setting to rights 340 the damage caused by the adoption of windows based graphical user 341 interfaces. The HTML table model includes attributes for labeling 342 each cell, to support high quality text to speech conversion. The 343 same attributes can also be used to support automated import and 344 export of table data to databases or spreadsheets. 346 Current desktop publishing packages provide very rich control over 347 the rendering of tables, and it would be impractical to reproduce 348 this in HTML, without making HTML into a bulky rich text format like 349 RTF or MIF. This specification does, however, offer authors the 350 ability to choose from a set of commonly used classes of border 351 styles. The FRAME attribute controls the appearence of the border 352 frame around the table while the RULES attribute determines the 353 choice of rulings within the table. A finer level of control will be 354 supported via rendering annotations. The STYLE attribute can be used 355 for including rendering information with individual elements. 356 Further rendering information can be given with the STYLE element in 357 the document head or via linked style sheets. 359 During the development of this specification, a number of avenues 360 were investigated for specifying the ruling patterns for tables. One 361 issue concerns the kinds of statements that can be made. Including 362 support for edge subtraction as well as edge addition leads to 363 relatively complex algorithms. For instance work on allowing the 364 full set of table elements to include the FRAME and RULES attributes 365 led to an algorithm involving some 24 steps to determine whether a 366 particular edge of a cell should be ruled or not. Even this 367 additional complexity doesn't provide enough rendering control to 368 meet the full range of needs for tables. The current specification 369 deliberately sticks to a simple intuitive model, sufficient for most 370 purposes. Further experimental work is needed before a more complex 371 approach is standardized. 373 ------------------------------------------------------------------------------ 374 A walk through the table DTD 376 The table document type definition provides the formal definition of 377 the allowed syntax for html tables. The following is an annotated 378 listing of the DTD. The complete listing appears at the end of this 379 document. 381 HTML Tables 23 Jan 96 383 Note that the TABLE element is a block-like element rather a 384 character-level element. As such it is a peer of other HTML 385 block-like elements such as paragraphs, lists and headers. 387 Common Attributes 389 The following attributes occur in several of the elements and are 390 defined here for brevity. In general, all attribute names and values 391 in this specification are case insensitive, except where noted 392 otherwise. The ID, CLASS and STYLE attributes are required for use 393 with style sheets, while LANG and DIR are needed for 394 internationalization. 396 403 ID 404 Used to define a document-wide identifier. This can be used for 405 naming positions within documents as the destination of a 406 hypertext link. It may also be used by style sheets for 407 rendering an element in a unique style. An ID attribute value is 408 an SGML NAME token. NAME tokens are formed by an initial letter 409 followed by letters, digits, "-" and "." characters. The letters 410 are restricted to A-Z and a-z. 412 CLASS 413 A space separated list of SGML NAME tokens. CLASS names specify 414 that the element belongs to the corresponding named classes. 415 These may be used by style sheets to provide class dependent 416 renderings. 418 STYLE 419 A text string providing rendering information specific to this 420 element in a notation independent of HTML. The mechanism for 421 associating rendering information is described in a separate 422 specification. 424 LANG 425 A LANG attribute identifies the natural language used by the 426 content of the associated element.The syntax and registry of 427 language values are defined by RFC 1766. In summary the language 428 is given as a primary tag followed by zero or more subtags, 429 separated by "-". White space is not allowed and all tags are 430 case insensitive. The name space of tags is administered by 431 IANA. The two letter primary tag is an ISO 639 language 432 abbreviation, while the initial subtag is a two letter ISO 3166 433 country code. Example values for LANG include: 435 HTML Tables 23 Jan 96 437 en, en-US, en-uk, i-cherokee, x-pig-latin. 439 DIR 440 Human writing systems are grouped into scripts, which determine 441 amongst other things, the direction the characters are written. 442 Elements of the Latin script are nominally left to right, while 443 those of the Arabic script are nominally right to left. These 444 characters have what is called strong directionality. Other 445 characters can be directionally neutral (spaces) or weak 446 (punctuation). 448 The DIR attribute specifies an encapsulation boundary which 449 governs the interpretation of neutral and weakly directional 450 characters. It does not override the directionality of strongly 451 directional characters. The DIR attribute value is one of LTR 452 for left to right, or RTL for right to left, e.g. DIR=RTL. 454 When applied to TABLE, it indicates the geometric layout of rows 455 (i.e. row 1 is on right if DIR=RTL, but on the left if DIR=LTR) 456 and it indicates a default base directionality for any text in 457 the table's content if no other DIR attribute applies to that 458 text. 460 ------------------------------------------------------------------------------ 461 Horizontal and Vertical Alignment Attributes 463 The alignment of cell contents can be specified on a cell by cell 464 basis, or inherited from enclosing elements, such as the row, column 465 or the table element itself. 467 ALIGN 468 This specifies the horizontal alignment of cell contents. 470 471 477 The attribute value should be one of LEFT, CENTER, RIGHT, 478 JUSTIFY and CHAR. User agents may treat JUSTIFY as left 479 alignment if they lack support for text justification. 480 ALIGN=CHAR is used for aligning cell contents on a particular 481 character. 483 For cells spanning multiple rows or columns, where the alignment 484 property is inherited from the row or column, the initial row 485 and column for the cell determines the appropriate alignment 486 property to use. 488 HTML Tables 23 Jan 96 490 Note that an alignment attribute on elements within the cell, 491 e.g. on a P element, overrides the normal alignment value for 492 the cell. 494 CHAR 495 This is used to specify an alignment character for use with 496 align=char, e.g. char=":". The default character is the decimal 497 point for the current language, as set by the LANG attribute. 498 The CHAR attribute value is case sensitive. 500 CHAROFF 501 Specifies the offset to the first occurrence of the alignment 502 character on each line. If a line doesn't include the alignment 503 character, it should be horizontally shifted to end at the 504 alignment position. The resolved direction of the cell, as 505 determined by the inheritance of the DIR attribute, is used to 506 set whether the offset is from the left or right margin of the 507 cell. For Latin scripts, the offset will be from the left 508 margin, while for Arabic scripts, it will be from the right 509 margin. In addition to standard units, the "%" sign may be used 510 to indicate that the value specifies the alignment position as a 511 percentage offset of the current cell, e.g. CHAROFF="30%" 512 indicates the alignment character should be positioned 30% 513 through the cell. 515 When using the two pass layout algorithm, the default alignment 516 position in the absence of an explicit or inherited CHAROFF 517 attribute can be determined by choosing the position that would 518 center lines for which the width before and after the alignment 519 character are at the maximum values for any of the lines in the 520 column for which ALIGN=CHAR. For incremental table layout the 521 suggested default is CHAROFF="50%". If several cells in 522 different rows for the same column use character alignment, then 523 by default, all such cells should line up, regardless of which 524 character is used for alignment. Rules for handling objects too 525 large for column apply when the explicit or implied alignment 526 results in a situation where the data exceeds the assigned width 527 of the column. 529 VALIGN 530 Defines whether the cell contents are aligned with the top, 531 middle or bottom of the cell. 533 534 538 HTML Tables 23 Jan 96 540 If present, the value of the attribute should be one of: TOP, 541 MIDDLE, BOTTOM or BASELINE. All cells in the same row with 542 valign=baseline should be vertically positioned so that the 543 first text line in each such cell occur on a common baseline. 544 This constraint does not apply to subsequent text lines in these 545 cells. 547 Inheritance Order 549 Alignment properties can be included with most of the table 550 elements: COL, THEAD, TBODY, TFOOT, TR, TH and TD. When rendering 551 cells, horizontal alignment is determined by columns in preference 552 to rows, while for vertical alignment, the rows are more important 553 than the columns. The following table gives the detailed precedence 554 order for each attribute, where X > Y denotes that X takes 555 precedence over Y: 557 ALIGN, CHAR and CHAROFF: 559 cells > columns > column groups > rows > row groups > default 561 VALIGN, LANG, DIR and STYLE: 563 cells > rows > row groups > columns > column groups > table > default 565 Where cells are defined by TH and TD elements; rows by TR elements; 566 row groups by THEAD, TBODY and TFOOT elements, columns by COL 567 elements; and column groups by COLGROUP and COL elements. Note that 568 there is no inheritance mechanism for the CLASS attribute. 570 Properties defined on cells take precedence over inherited 571 properties, but are in turn over-ridden by alignment properties on 572 elements within cells. In the absence of an ALIGN attribute along 573 the inheritance path, the recommended default alignment for table 574 cell contents is ALIGN=LEFT for table data and ALIGN=CENTER for 575 table headers. The recommended default for vertical alignment is 576 VALIGN=MIDDLE. These defaults are chosen to match the behaviour of 577 the widely deployed Netscape implementation. 579 ------------------------------------------------------------------------------ 580 Standard Units for Widths 582 Several attributes specify widths as a number followed by an 583 optional suffix. The units for widths are specified by the suffix: 584 pt denotes points, pi denotes picas, in denotes inches, cm denotes 585 centimeters, mm denotes millimeters, em denotes em units (equal to 586 the height of the default font), and px denotes screen pixels. The 587 default units are screen pixels (chosen for backwards 588 compatibility). The number is an integer value or a real valued 589 number such as "2.5". Exponents, as in "1.2e2", are not allowed. 590 White space is not allowed between the number and the suffix. 592 HTML Tables 23 Jan 96 594 The above set of suffices is augmented for certain elements: "%" is 595 used for the WIDTH attribute for the TABLE element. It indicates 596 that the attribute specifies the percentage width of the space 597 between the current left and right margins, e.g. width="50%". For 598 the COL element, "*" is used with the WIDTH attribute to specify 599 relative column widths, e.g. width="3*", using the same 600 representation as the CALS table model. 602 ------------------------------------------------------------------------------ 603 The TABLE element 605 607 609 621 The TABLE element requires both start and end tags. Table elements 622 start with an optional CAPTION element, optionally followed by 623 either one or more COL elements, or one or more COLGROUP elements, 624 then an optional THEAD, an optional TFOOT, and finally one or more 625 TBODY elements. 627 ------------------------------------------------------------------------------ 628 ID, CLASS, STYLE, LANG and DIR 629 See earlier description of common attributes. 631 ALIGN 632 Defines the horizontal position of the table relative to the 633 current left and right margins. ALIGN=CENTER centers the table 634 midway between the left and right margins. To allow text to flow 635 around the table, use ALIGN=LEFT to position the table at the 636 left margin, with text flowing around its right handside, or use 637 ALIGN=RIGHT to position the table at the right margin, with text 638 flowing around its left handside. 640 Note you can use
after the table element if you 641 want to avoid text flowing along side the table when you have 642 specified ALIGN=LEFT, or
for a right aligned 643 table. Greater control over textflow is possible using style 644 sheets. 646 HTML Tables 23 Jan 96 648 WIDTH 649 Specifies the desired width of the table. In addition to the 650 standard units, the "%" sign may used to indicate that the width 651 specifies the percentage width of the space between the current 652 left and right margins, e.g. width="50%". In the absence of this 653 attribute, the table width can be determined by the layout 654 algorithm given later on. 656 It is recommended that the table width be increased beyond the 657 value indicated by the WIDTH attribute as needed to avoid any 658 overflow of cell contents. Such increases should try to avoid 659 drastic changes to relative column widths specified by the 660 author. To avoid the need for excessive horizontal scrolling, or 661 when such scrolling is impractical or undesired, it may be 662 appropriate to split words across lines. 664 COLS 665 Specifies the number of columns for the table. If present the 666 user agent may render the table dynamically as data is received 667 from the network without waiting for the complete table to be 668 received. If the WIDTH attribute is missing, a default of "100%" 669 may be assumed for this purpose. If the COLS attribute is 670 absent, a prepass through the table's contents is needed to 671 determine the number of columns together with suitable values 672 for the widths of each column. 674 BORDER 675 Specifies the width of the border framing the table, see 676 standard units. 678 FRAME 679 Specifies which sides of the frame to render. 681 684 VOID 685 Don't render any sides of the frame. 687 ABOVE 688 The top side of the frame 690 BELOW 691 The bottom side of the frame 693 HSIDES 694 The top and bottom sides of the frame 696 LHS 697 The left hand side of the frame 699 RHS 700 The right hand side of the frame 702 HTML Tables 23 Jan 96 704 VSIDES 705 The left and right sides of the frame 707 BOX 708 All four sides of the frame 710 BORDER 711 All four sides of the frame 713 The value "Border" is included for backwards compatibility with 714 deployed browsers. If a document includes the 715 user agent will see FRAME=BORDER and BORDER=_implied_. If the 716 document includes
then the user agent should 717 treat this as FRAME=BORDER except if _n=0_ for which FRAME=VOID 718 is appropriate. 720 _Note: it would have been preferable to choose values for FRAME 721 consistent with the RULES attribute and the values used for 722 alignment. For instance: none, top, bottom, topbot, left, right, 723 leftright, all. Unfortunately, SGML requires enumerated 724 attribute values to be unique for each element, independent of 725 the attribute name. This causes immediate problems for "none", 726 "left", "right" and "all". The values for FRAME have been chosen 727 to avoid clashes with the RULES, ALIGN and VALIGN attributes. 728 This provides a measure of future proofing, as it is anticipated 729 that that the FRAME and RULES attributes will be added to other 730 table elements in future revisions to this specification. An 731 alternative would be to make FRAME a CDATA attribute. The 732 consensus of the HTML-WG was that the benefits of being able to 733 use SGML validation tools to check attributes based on 734 enumerated values outweighs the need for consistent names._ 736 RULES 737 Specifies where to draw rules within the table interior. 739 741 NONE 742 Suppresses internal rulings. 744 GROUPS 745 The THEAD, TFOOT and TBODY elements divide the table into 746 groups of rows, while COLGROUP elements divide the table 747 into groups of columns. This choice places a horizontal rule 748 between each row group and a vertical rule between each 749 column group. Note that every table has at least one row and 750 one column group. 752 ROWS 753 As RULES=GROUPS plus horizontal rules between all rows. User 754 agents may choose to use a heavier rule between groups of 755 rows and columns for emphasis. 757 HTML Tables 23 Jan 96 759 COLS 760 As RULES=GROUPS plus vertical rules between all columns. 761 User agents may choose to use a heavier rule between groups 762 of rows and columns for emphasis. 764 ALL 765 Place rules between all rows and all columns. User agents 766 may choose to use a heavier rule between groups of rows and 767 columns for emphasis. 769 If a document includes
or
then 770 the default for the table element is RULES=ALL, except if _n=0_ 771 for which RULES=NONE is appropriate. 773 CELLSPACING 774 This attribute is intended for backwards compatibility with 775 deployed user agents. It specifies the space between the table 776 frame and the first or last cell border for each row or column, 777 and between other cells in the table. See standard units. 778 Greater control will be possible using style sheet languages. 780 CELLPADDING 781 This attribute is intended for backwards compatibility with 782 deployed user agents. It specifies the amount of space between 783 the border of the cell and its contents both above/below, and 784 left//right. See standard units. Greater control will be 785 possible using style sheet languages. 787 If a fixed width is set for the table or column, the CELLSPACING and 788 CELLPADDING may demand more space than assigned. Current practice is 789 for the latter to take precedence over WIDTH attributes when a 790 conflict occurs, although this isn't required by this specification. 792 ------------------------------------------------------------------------------ 793 Table Captions 795 797 799 804 The optional CAPTION element is used to provide a caption for the 805 table. Both start and end tags are required. 807 ID, CLASS, STYLE, LANG and DIR 808 See earlier description of common attributes. 810 HTML Tables 23 Jan 96 812 ALIGN 813 This may be used to control the placement of captions relative 814 to the table. When present, the ALIGN attribute should have one 815 of the values: TOP, BOTTOM, LEFT and RIGHT. It is recommended 816 that the caption is made to fit within the width or height of 817 the table as appropriate. The default position of the caption is 818 deliberately unspecified. 820 _Note the ALIGN attribute is overused in HTML, but is retained 821 here for compatibility with currently deployed browsers._ 823 ------------------------------------------------------------------------------ 824 The COLGROUP Element 826 828 836 The COLGROUP element acts as a container for a group of columns, and 837 allows you to set default properties for these columns. In the 838 absence of a COLGROUP element, all columns in the table are assumed 839 to belong to a single column group. Each COLGROUP element can 840 contain zero or more COL elements. COLGROUP requires a start tag, 841 but the end tag may be omitted. This is useful when defining a 842 sequence of COLGROUP elements, e.g. 844
845 846 847 848 849 850 851 852 ... 853
855 COLGROUP elements can be used with the following attributes: 857 ID, CLASS, STYLE, LANG and DIR 858 See earlier description of common attributes. 860 HTML Tables 23 Jan 96 862 SPAN 863 A positive integer value that specifies a default for how many 864 columns are in this group. This attribute should be ignored if 865 the COLGROUP element contains one or more COL elements. It 866 provides a convenient way of grouping columns without the need 867 to supply COL elements. 869 WIDTH 870 Specifies a default width for each of the grouped columns, see 871 standard units. In addition, the "*" suffix denotes relative 872 widths, e.g. 874 width=64 width in screen pixels 875 width=0.5* a relative width of 0.5 877 Relative widths act as constraints on the relative widths of 878 different columns. If a COLGROUP element specifies a relative 879 width of zero, all of the columns in the group should be set to 880 their minimum widths, unless they are associated with a COL 881 element with an overriding WIDTH attribute. When widths are 882 given in absolute units, the user agent can use these to 883 constrain the width of the table. The "*" suffix is used to 884 simplify importing tables from the CALS representation. 886 ALIGN, CHAR, CHAROFF and VALIGN 887 Specify values for horizontal and vertical alignment within 888 table cells. See inheritance order of alignment properties. 890 ------------------------------------------------------------------------------ 891 The COL Element 893 895 903 This optional element is used to specify column based defaults for 904 table properties. It is an empty element, and as such has no 905 content, and shouldn't be given an end tag. Several COL elements may 906 be given in succession. COL attributes override those of the parent 907 COLGROUP element. 909 ID, CLASS, STYLE, LANG and DIR 910 See earlier description of common attributes. 912 SPAN 913 A positive integer value that specifies how many columns this 914 element applies to, defaulting to one. In the absence of SPAN 916 HTML Tables 23 Jan 96 918 attributes the first COL element applies to the first column, 919 the second COL element to the second column and so on. If the 920 second COL element had SPAN=2, it would apply to the second and 921 third column. The next COL element would then apply to the 922 fourth column and so on. SPAN=0 has a special significance and 923 implies that the COL element spans all columns from the current 924 column up to and including the last column. Note that a COL SPAN 925 does not define a group. It is merely a way to share attribute 926 definitions. 928 WIDTH 929 Specifies the width of the columns, see standard units. If the 930 element spans several columns then the WIDTH attribute specifies 931 the width for each of the individual columns - not the width of 932 the span. In addition, the "*" suffix denotes relative widths, 933 e.g. 935 width=64 width in screen pixels 936 width=0.5* a relative width of 0.5 938 Relative widths act as constraints on the relative widths of 939 different columns. If a COL element specifies a relative width 940 of zero, the column should always be set to its minimum width. 941 When widths are given in absolute units, the user agent can use 942 these to constrain the width of the table. The "*" suffix is 943 used to simplify importing tables from the CALS representation. 945 ALIGN, CHAR, CHAROFF and VALIGN 946 Specify values for horizontal and vertical alignment within 947 table cells. See inheritance order of alignment properties. 949 ------------------------------------------------------------------------------ 950 Table Head, Foot and Body Elements 952 953 954 956 962 Tables may be divided up into head and body sections. The THEAD and 963 TFOOT elements are optional, but one or more TBODY elements are 964 always required. If the table only consists of a TBODY section, the 965 TBODY start and end tags may be omitted, as the parser can infer 966 them. If a THEAD element is present, the THEAD start tag is 967 required, but the end tag can be omitted, provided a TFOOT or TBODY 968 start tag follows. The same applies to TFOOT. 970 HTML Tables 23 Jan 96 972 _Note: This definition provides compatibility with tables created 973 for the older model, as well as allowing the end tags for THEAD, 974 TFOOT and TBODY to be omitted._ 976 The THEAD, TFOOT and TBODY elements provide a convenient means for 977 controlling rendering. If the table has a large number of rows in 978 the body, user agents may choose to use a scrolling region for the 979 table body sections. When rendering to a paged device, tables will 980 often have to be broken across page boundaries. The THEAD, TFOOT and 981 TBODY elements allow the user agent to repeat the table foot at the 982 bottom of the current page, and then the table head at the top of 983 the new page before continuing on with the table body. 985 TFOOT is placed before the TBODY in the markup sequence, so that 986 browsers can render the foot before receiving all of the table data. 987 This is useful when very long tables are rendered with scrolling 988 body sections, or for paged output, involving breaking the table 989 over many pages. 991 Each THEAD, TFOOT and TBODY element must contain one or more TR 992 elements. 994 ID, CLASS, STYLE, LANG and DIR 995 See earlier description of common attributes. 997 ALIGN, CHAR, CHAROFF and VALIGN 998 Specify values for horizontal and vertical alignment within 999 table cells. See inheritance order of alignment properties. 1001 ------------------------------------------------------------------------------ 1002 Table Row (TR) elements 1004 1006 1012 The TR or table row element acts as a container for a row of table 1013 cells. The end tag may be omitted. 1015 ID, CLASS, STYLE, LANG and DIR 1016 See earlier description of common attributes. 1018 ALIGN, CHAR, CHAROFF and VALIGN 1019 Specify values for horizontal and vertical alignment within 1020 table cells. See inheritance order of alignment properties. 1022 ------------------------------------------------------------------------------ 1023 HTML Tables 23 Jan 96 1025 Table Cells: TH and TD 1027 1029 1040 TH elements are used to represent header cells, while TD elements 1041 are used to represent data cells. This allows user agents to render 1042 header and data cells distinctly, even in the absence of style 1043 sheets. 1045 Cells can span multiple rows and columns, and may be empty. Cells 1046 spanning rows contribute to the column count on each of the spanned 1047 rows, but only appear in the markup once (in the first row spanned). 1048 The row count is determined by the number of TR elements. Any rows 1049 implied by cells spanning rows beyond this should be ignored. 1051 If the column count for the table is greater than the number of 1052 cells for a given row (after including cells for spanned rows), the 1053 missing cells are treated as occurring on the right hand side of the 1054 table and rendered as empty cells. If the language context indicates 1055 a right to left writing order, then the missing cells should be 1056 placed on the left hand side. 1058 It is possible to create tables with overlapping cells, for 1059 instance: 1061 1062
123 1063
4 1064
56 1065
1067 which might look something like: 1069 /-----------\ 1070 | 1 | 2 | 3 | 1071 | |-------| 1072 | | 4 | | 1073 |---|...|---| 1074 | 5 : | 6 | 1075 \-----------/ 1077 HTML Tables 23 Jan 96 1079 In this example, the cells labelled 4 and 5 overlap. In such cases, 1080 the rendering is implementation dependent. 1082 The AXIS and AXES attributes for cells provide a means for defining 1083 concise labels for cells. When rendering to speech, these attributes 1084 may be used to provide abbreviated names for the headers relevant to 1085 each cell. Another application is when you want to be able to later 1086 process table contents to enter them into a database. These 1087 attributes are then used to give database field names. The table's 1088 class attribute should be used to let the software recognize which 1089 tables can be treated in this way. 1091 ID, CLASS, STYLE, LANG and DIR 1092 See earlier description of common attributes. 1094 AXIS 1095 This defines an abbreviated name for a header cell, e.g. which 1096 can be used when rendering to speech. It defaults to the cell's 1097 content. 1099 AXES 1100 This is a comma separated list of axis names which together 1101 identify the row and column headers that pertain to this cell. 1102 It is used for example when rendering to speech to identify the 1103 cell's position in the table. If missing the user agent can try 1104 to follow up columns and left along rows (right for some 1105 languages) to find the corresponding header cells. 1107 NOWRAP, e.g. 1108 The presence of this attribute disables automatic wrapping of 1109 text lines for this cell. If used uncautiously, it may result in 1110 excessively wide cells. This attribute is defined for backwards 1111 compatibility with deployed user agents. Greater control is 1112 possible with associated style sheet languages (for example for 1113 control over overflow handling). 1115 ROWSPAN, e.g. 1116 A positive integer value that defines how may rows this cell 1117 spans. The default ROWSPAN is 1. ROWSPAN=0 has a special 1118 significance and implies that the cell spans all rows from the 1119 current row up to the last row of the table. 1121 COLSPAN, e.g. 1122 A positive integer value that defines how may columns this cell 1123 spans. The default COLSPAN is 1. COLSPAN=0 has a special 1124 significance and implies that the cell spans all columns from 1125 the current column up to the last column of the table. 1127 ALIGN, CHAR, CHAROFF and VALIGN 1128 Specify values for horizontal and vertical alignment within 1129 table cells. See inheritance order of alignment properties. 1131 HTML Tables 23 Jan 96 1133 Note: It is recommended that implementors provide support for the 1134 Netscape 1.1 WIDTH attribute for TH and TD, although this isn't part 1135 of the current specification. Document authors are advised to use 1136 the width attribute for the COL element instead. 1138 ------------------------------------------------------------------------------ 1139 Recommended Layout Algorithms 1141 If the COLS attribute on the TABLE element specifies the number of 1142 columns, then the table may be rendered using a fixed layout, 1143 otherwise the autolayout algorithm described below should be used. 1145 Fixed Layout Algorithm 1147 For this algorithm, it is assumed that the number of columns is 1148 known. The column widths by default should be set to the same size. 1149 Authors may override this by specifying relative or absolute column 1150 widths, using the COLGROUP or COL elements. The default table width 1151 is the space between the current left and right margins, but may be 1152 overridden by the WIDTH attribute on the TABLE element, or 1153 determined from absolute column widths. To deal with mixtures of 1154 absolute and relative column widths, the first step is to allocate 1155 space from the table width to columns with absolute widths. After 1156 this, the space remaining is divided up between the columns with 1157 relative widths. 1159 The table syntax alone is insufficient to guarantee the consistency 1160 of attribute values. For instance, the number of columns specified 1161 by the COLS attribute may be inconsistent with the number of columns 1162 implied by the COL elements. This in turn, may be inconsistent with 1163 the number of columns implied by the table cells. A further problem 1164 occurs when the columns are too narrow to avoid overflow of cell 1165 contents. The width of the table as specified by the TABLE element 1166 or COL elements may result in overflow of cell contents. It is 1167 recommended that user agents attempt to recover gracefully from 1168 these situations, e.g. by hyphenating words and resorting to 1169 splitting words if hyphenation points are unknown. 1171 In the event that an indivisible element causes cell overflow, the 1172 user agent may consider adjusting column widths and re-rendering the 1173 table. In the worst case clipping may be considered if column width 1174 adjustments and/or scrollable cell content are not feasible. In any 1175 case if cell content is split or clipped this should be indicated to 1176 the user in an appropriate manner. 1178 Autolayout Algorithm 1180 If the COLS attribute is missing from the table start tag, then the 1181 user agent should use the following autolayout algorithm. It uses 1182 two passes through the table data and scales linearly with the size 1183 of the table. 1185 HTML Tables 23 Jan 96 1187 In the first pass, line wrapping is disabled, and the user agent 1188 keeps track of the minimum and maximum width of each cell. The 1189 maximum width is given by the widest line. As line wrap has been 1190 disabled, paragraphs are treated as long lines unless broken by
1191 elements. The minimum width is given by the widest word or image 1192 etc. taking into account leading indents and list bullets etc. In 1193 other words, if you were to format the cell's content in a window of 1194 its own, determine the minimum width you could make the window 1195 before the cell begins to overflow. Allowing user agents to split 1196 words will minimize the need for horizontal scrolling or in the 1197 worst case clipping of cell contents. 1199 This process also applies to any nested tables occuring in cell 1200 content. The minimum and maximum widths for cells in nested tables 1201 are used to determine the minimum and maximum widths for these 1202 tables and hence for the parent table cell itself. The algorithm is 1203 linear with aggregate cell content, and broadly speaking independent 1204 of the depth of nesting. 1206 To cope with character alignment of cell contents, the algorithm 1207 keeps three running min/max totals for each column: Left of align 1208 char, right of align char and un-aligned. The minimum width for a 1209 column is then: max(min_left + min_right, min_non-aligned). 1211 The minimum and maximum cell widths are then used to determine the 1212 corresponding minimum and maximum widths for the columns. These in 1213 turn, are used to find the minimum and maximum width for the table. 1214 Note that cells can contain nested tables, but this doesn't 1215 complicate the code significantly. The next step is to assign column 1216 widths according to the available space (i.e. the space between the 1217 current left and right margins). 1219 For cells which span multiple columns, a simple approach, as used by 1220 Arena, is to evenly apportion the min/max widths to each of the 1221 constituent columns. A slightly more complex approach is to use the 1222 min/max widths of unspanned cells to weight how spanned widths are 1223 apportioned. Experimental study suggests a blend of the two 1224 approaches will give good results for a wide range of tables. 1226 The table borders and intercell margins need to be included in 1227 assigning column widths. There are three cases: 1229 1. The minimum table width is equal to or wider than the available 1230 space. In this case, assign the minimum widths and allow the 1231 user to scroll horizontally. For conversion to braille, it will 1232 be necessary to replace the cells by references to notes 1233 containing their full content. By convention these appear before 1234 the table. 1236 2. The maximum table width fits within the available space. In this 1237 case, set the columns to their maximum widths. 1239 HTML Tables 23 Jan 96 1241 3. The maximum width of the table is greater than the available 1242 space, but the minimum table width is smaller. In this case, 1243 find the difference between the available space and the minimum 1244 table width, lets call it W. Lets also call D the difference 1245 between maximum and minimum width of the table. 1247 For each column, let d be the difference between maximum and 1248 minimum width of that column. Now set the column's width to the 1249 minimum width plus d times W over D. This makes columns with 1250 large differences between minimum and maximum widths wider than 1251 columns with smaller differences. 1253 This assignment step is then repeated for nested tables using the 1254 minimum and maximum widths derived for all such tables in the first 1255 pass. In this case, the width of the parent (i.e. enclosing) table 1256 cell plays the role of the current window size in the above 1257 description. This process is repeated recursively for all nested 1258 tables. The topmost table is then rendered using the assigned 1259 widths. Nested tables are subsequently rendered as part of the 1260 parent table's cell contents. 1262 If the table width is specified with the WIDTH attribute, the user 1263 agent attempts to set column widths to match. The WIDTH attribute is 1264 not binding if this results in columns having less than their 1265 minimum (i.e. indivisible) widths. 1267 If relative widths are specified with the COL element, the algorithm 1268 is modified to increase column widths over the minimum width to meet 1269 the relative width constraints. The COL elements should be taken as 1270 hints only, so columns shouldn't be set to less than their minimum 1271 width. Similarly, columns shouldn't be made so wide that the table 1272 stretches well beyond the extent of the window. If a COL element 1273 specifies a relative width of zero, the column should always be set 1274 to its minimum width. 1276 ------------------------------------------------------------------------------ 1277 HTML Tables 23 Jan 96 1279 HTML Table DTD 1281 The DTD or document type definition provides the formal definition 1282 of the allowed syntax for HTML tables. 1284 1293 1300 1315 1317 1324 1326 1327 1329 HTML Tables 23 Jan 96 1331 1332 1338 1339 1343 1344 1345 1346 1347 1348 1349 1350 1351 1353 1365 1366 1368 1373 1377 1385 HTML Tables 23 Jan 96 1387 1396 1404 1416 1422 1428 1439 HTML Tables 23 Jan 96 1441 ------------------------------------------------------------------------------ 1442 References 1444 Arena 1445 W3C's HTML3 browser, see "http://www.w3.org/pub/WWW/Arena/". 1446 Arena was originally created as a proof of concept demo for 1447 ideas in the HTML+ specification that preceded HTML3. The 1448 browser is now being re-implemented to provide a reference 1449 implementation of HTML3 along with support for style sheets and 1450 client-side scripting. 1452 CALS 1453 Continuous Acquisition and Life-Cycle Support (formerly 1454 Computer-aided Acquisition and Logistics Support) (CALS) is a 1455 Department of Defense (DoD) strategy for achieving effective 1456 creation, exchange, and use of digital data for weapon systems 1457 and equipment. More information can be found from the US Navy 1458 CALS home page at http://navysgml.dt.navy.mil/cals.html 1460 HTML 3.0 1461 HyperText Markup Language Specification Version 3.0. This is the 1462 initial draft specification as published in March 1995. Work on 1463 refining HTML3 is proceeding piecemeal with the new table 1464 specification as one of the pieces. For W3C related work on 1465 HTML, see "http://www.w3.org/pub/WWW/MarkUp/". 1467 RFC 1766 1468 "Tags for the Identification of Languages", by H. Alvestrand, 1469 UNINETT, March 1995. This document can be downloaded from 1470 "ftp://ds.internic.net/rfc/rfc1766.txt". 1472 HTML and Style Sheets 1473 Associating HTML3 documents with Rendering Information, by Bert 1474 Bos, Dave Raggett and Hakon Lie. This document can be downloaded 1475 from: "http://www.w3.org/pub/WWW/TR/WD-style.html" 1477 ----------------------------------------------------------------------- 1478 The World Wide Web Consortium: http://www.w3.org/