The HTML table model allows authors to arrange data -- text, preformatted text, images, links, forms, form fields, other tables, etc. -- into rows and columns of cells. Show
Each table may have an associated caption (see the element) that provides a short description of the table's purpose. A longer description may also be provided (via the attribute) for the benefit of people using speech or Braille-based user agents. may be grouped into a head, foot, and body sections, (via the , and elements, respectively). Row groups convey additional structural information and may be rendered by user agents in ways that emphasize this structure. User agents may exploit the head/body/foot division to support scrolling of body sections independently of the head and foot sections. When long tables are printed, the head and foot information may be repeated on each page that contains table data. Authors may also to provide additional structural information that may be exploited by user agents. Furthermore, authors may declare column properties at the start of a table definition (via the and elements) in a way that enables user agents to render the table incrementally rather than having to wait for all the table data to arrive before rendering. may either contain "header" information (see the element) or "data" (see the element). Cells may span multiple rows and columns. The HTML 4.0 table model allows authors to label each cell so that may more easily communicate heading information about the cell to the user. Not only do these mechanisms greatly assist users with visual disabilities, they make it possible for multi-modal wireless browsers with limited display capabilities (e.g., Web-enabled pagers and phones) to handle tables. Tables should not be used purely as a means to layout document content as this may present problems when rendering to non-visual media. Additionally, when used with graphics, these tables may force users to scroll horizontally to view a table designed on a system with a larger display. To minimize these problems, authors should use style sheets to control layout rather than tables. Here's a simple table that illustrates some of the features of the HTML table model. The following table definition:
might be rendered something like this on a tty device: A test table with merged cells /-----------------------------------------\ | | Average | Red | | |-------------------| eyes | | | height | weight | | |-----------------------------------------| | Males | 1.9 | 0.003 | 40% | |-----------------------------------------| | Females | 1.7 | 0.002 | 43% | \-----------------------------------------/ or like this by a graphical user agent: 11.2 Elements for constructing tablesStart tag: required, End tag: required Attribute definitions summary = This attribute provides a summary of the table's purpose and structure for user agents rendering to non-visual media such as speech and Braille.align = left|center|right This attribute specifies the position of the table with respect to the document. Permitted values:
Attributes defined elsewhere The element contains all other elements that specify caption, rows, content, and formatting. The following informative list describes what operations user agents may carry out when rendering a table:
The HTML table model has been designed so that, with author assistance, user agents may render tables incrementally (i.e., as table rows arrive) rather than having to wait for all the data before beginning to render. In order for a user agent to format a table in one pass, authors must tell the user agent: More precisely, a user agent may render a table in a single pass when the column widths are specified using a combination of and elements. If any of the columns are specified in relative or percentage terms (see the section on ), authors must also specify the width of the table itself. Table directionalityThe directionality of a table is either the inherited directionality (the default is left-to-right) or that specified by the attribute for the element. For a left-to-right table, column zero is on the left side and row zero is at the top. For a right-to-left table, column zero is on the right side and row zero is at the top. When a user agent allots extra cells to a row (see the section on ), extra row cells are added to the right of the table for left-to-right tables and to the left side for right-to-left tables. Note that is the only element on which reverses the visual order of the columns; a single table row () or a group of columns () cannot be independently reversed. When set for the element, the attribute also affects the direction of text within table cells (since the attribute is inherited by block-level elements). To specify a right-to-left table, set the attribute as follows: ...the rest of the table... The direction of text in individual cells can be changed by setting the attribute in an element that defines the cell. Please consult the section on for more information on text direction issues. Start tag: required, End tag: required Attribute definitions align = top|bottom|left|right For visual user agents, this attribute specifies the position of the caption with respect to the table. Possible values:
Attributes defined elsewhere When present, the element's text should describe the nature of the table. The element is only permitted immediately after the start tag. A element may only contain one element. Visual user agents allow sighted people to quickly grasp the structure of the table from the headings as well as the caption. A consequence of this is that captions will often be inadequate as a summary of the purpose and structure of the table from the perspective of people relying on non-visual user agents. Authors should therefore take care to provide additional information summarizing the purpose and structure of the table using the attribute of the element. This is especially important for tables without captions. Examples below illustrate the use of the attribute. Visual user agents should avoid clipping any part of the table including the caption, unless a means is provided to access all parts, e.g., by horizontal or vertical scrolling. We recommend that the caption text be wrapped to the same width as the table. (See also the section on .) THEAD - O (TR)+ -- table header --> TFOOT - O (TR)+ -- table footer --> Start tag: required, End tag: optional TBODY O O (TR)+ -- table body --> Start tag: optional, End tag: optional Attributes defined elsewhere Table rows may be grouped into a table head, table foot, and one or more table body sections, using the , and elements, respectively. This division enables user agents to support scrolling of table bodies independently of the table head and foot. When long tables are printed, the table head and foot information may be repeated on each page that contains table data. The table head and table foot should contain information about the table's columns. The table body should contain rows of table data. When present, each , , and contains a row group. Each row group must contain at least one row, defined by the element. This example illustrates the order and structure of table heads, feet, and bodies. ...header information......footer information......first row of block one data......second row of block one data......first row of block two data......second row of block two data......third row of block two data... must appear before within a definition so that user agents can render the foot before receiving all of the (potentially numerous) rows of data. The following summarizes which tags are required and which may be omitted:
Conforming user agent parsers must obey these rules for reasons of backward compatibility. The table of the previous example could be shortened by removing certain end tags, as in: ...header information......footer information......first row of block one data......second row of block one data......first row of block two data......second row of block two data......third row of block two data... The , , and sections must contain the same number of columns. Column groups allow authors to create structural divisions within a table. Authors may highlight this structure through style sheets or HTML attributes (e.g., the attribute for the element). For an example of the visual presentation of column groups, please consult the . A table may either contain a single implicit column group (no element delimits the columns) or any number of explicit column groups (each delimited by an instance of the element). The element allows authors to share attributes among several columns without implying any structural grouping. The "span" of the element is the number of columns that will share the element's attributes. The COLGROUP elementStart tag: required, End tag: optional Attribute definitions span = This attribute, which must be an integer > 0, specifies the number of columns in a column group. Values mean the following:
User agents must ignore this attribute if the element contains one or more elements. width =This attribute specifies a default width for each column in the current column group. In addition to the standard pixel, percentage, and relative values, this attribute allows the special form "0*" (zero asterisk) which means that the width of the each column in the group should be the minimum width necessary to hold the column's contents. This implies that a column's entire contents must be known before its width may be correctly computed. Authors should be aware that specifying "0*" will prevent visual user agents from rendering a table incrementally. This attribute is overridden for any column in the column group whose is specified via a element. Attributes defined elsewhere The element creates an explicit column group. The number of columns in the column group may be specified in two, mutually exclusive ways:
The advantage of using the attribute is that authors may group together information about column widths. Thus, if a table contains forty columns, all of which have a width of 20 pixels, it is easier to write: than: ...a total of forty COL elements... When it is necessary to single out a column (e.g., for style information, to specify width information, etc.) within a group, authors must identify that column with a element. Thus, to apply special style information to the last column of the previous table, we single it out as follows: The attribute of the element is inherited by all 40 columns. The first element refers to the first 39 columns (doing nothing special to them) and the second one assigns an value to the fortieth columns so that style sheets may refer to it. The table in the following example contains two column groups. The first column group contains 10 columns and the second contains 5 columns. The default width for each column in the first column group is 50 pixels. The width of each column in the second column group will be the minimum required for that column. A test table with merged cells /-----------------------------------------\ | | Average | Red | | |-------------------| eyes | | | height | weight | | |-----------------------------------------| | Males | 1.9 | 0.003 | 40% | |-----------------------------------------| | Females | 1.7 | 0.002 | 43% | \-----------------------------------------/0 The COL elementStart tag: required, End tag: forbidden Attribute definitions span = This attribute, whose value must be an integer > 0, specifies the number of columns "spanned" by the element; the element shares its attributes with all the columns it spans. The default value for this attribute is 1 (i.e., the element refers to a single column). If the attribute is set to N > 1, the current element shares its attributes with the next N-1 columns.width = This attribute specifies a default width for each column spanned by the current element. It has the same meaning as the attribute for the element and overrides it.Attributes defined elsewhere The element allows authors to group together attribute specifications for table columns. The does not group columns together structurally -- that is the role of the element. elements are empty and serve only as a support for attributes. They may appear inside or outside an explicit column group (i.e., element). The attribute for refers to the width of each column in the element's span. Calculating the number of columns in a tableThere are two ways to determine the number of columns in a table (in order of precedence):
It is an error if a table contains or elements and the two calculations do not result in the same number of columns. Once the user agent has calculated the number of columns in the table, it may group them into For example, for each of the following tables, the two column calculation methods should result in three columns. The first three tables may be rendered incrementally. A test table with merged cells /-----------------------------------------\ | | Average | Red | | |-------------------| eyes | | | height | weight | | |-----------------------------------------| | Males | 1.9 | 0.003 | 40% | |-----------------------------------------| | Females | 1.7 | 0.002 | 43% | \-----------------------------------------/1 Calculating the width of columnsAuthors may specify column widths in three ways: FixedA fixed width specification is given in pixels (e.g., width="30"). A fixed-width specification enables incremental rendering.PercentageA percentage specification (e.g., width="20%") is based on the percentage of the horizontal space available to the table (between the current left and right margins, including floats). Note that this space does not depend on the table itself, and thus percentage specifications enable incremental rendering.ProportionalProportional specifications (e.g., width="3*") refer to portions of the horizontal space required by a table. If the table width is given a fixed value via the width attribute of the element, user agents may render the table incrementally even with proportional columns.However, if the table does not have a fixed width, user agents must receive all table data before they can determine the horizontal space required by the table. Only then may this space be allotted to proportional columns. If an author specifies no width information for a column, a user agent may not be able to incrementally format the table since it must wait for the entire column of data to arrive in order to allot an appropriate width. If column widths prove to be too narrow for the contents of a particular table cell, user agents may choose to reflow the table. The table in this example contains six columns. The first one does not belong to an explicit column group. The next three belong to the first explicit column group and the last two belong to the second explicit column group. This table cannot be formatted incrementally since it contains proportional column width specifications and no value for the attribute for the element. Once the (visual) user agent has received the table's data: the available horizontal space will be alloted by the user agent as follows: First the user agent will allot 30 pixels to columns one and two. Then, the minimal space required for the third column will be reserved. The remaining horizontal space will be divided into six equal portions (since 2* + 1* + 3* = 6 portions). Column four (2*) will receive two of these portions, column five (1*) will receive one, and column six (3*) will receive three. A test table with merged cells /-----------------------------------------\ | | Average | Red | | |-------------------| eyes | | | height | weight | | |-----------------------------------------| | Males | 1.9 | 0.003 | 40% | |-----------------------------------------| | Females | 1.7 | 0.002 | 43% | \-----------------------------------------/2 We have set the value of the attribute in the second column group to "center". All cells in every column in this group will inherit this value, but may override it. In fact, the final does just that, by specifying that every cell in the column it governs will be aligned along the ":" character. In the following table, the column width specifications allow the user agent to format the table incrementally: A test table with merged cells /-----------------------------------------\ | | Average | Red | | |-------------------| eyes | | | height | weight | | |-----------------------------------------| | Males | 1.9 | 0.003 | 40% | |-----------------------------------------| | Females | 1.7 | 0.002 | 43% | \-----------------------------------------/3 The first ten columns will be 15 pixels wide each. The last two columns will each receive half of the remaining 50 pixels. Note that the elements appear only so that an value may be specified for the last two columns. Note. Although the attribute on the element is not deprecated, authors are encouraged to use style sheets to specify table widths. Start tag: required, End tag: optional Attributes defined elsewhere The elements acts as a container for a row of table cells. The end tag may be omitted. This sample table contains three rows, each begun by the element: A test table with merged cells /-----------------------------------------\ | | Average | Red | | |-------------------| eyes | | | height | weight | | |-----------------------------------------| | Males | 1.9 | 0.003 | 40% | |-----------------------------------------| | Females | 1.7 | 0.002 | 43% | \-----------------------------------------/4 A test table with merged cells /-----------------------------------------\ | | Average | Red | | |-------------------| eyes | | | height | weight | | |-----------------------------------------| | Males | 1.9 | 0.003 | 40% | |-----------------------------------------| | Females | 1.7 | 0.002 | 43% | \-----------------------------------------/5 Start tag: required, End tag: optional Attribute definitions headers = This attribute specifies the list of header cells that provide header information for the current data cell. The value of this attribute is a space-separated list of cell names; those cells must be named by setting their attribute. Authors generally use the attribute to help non-visual user agents render header information about data cells (e.g., header information is spoken prior to the cell data), but the attribute may also be used in conjunction with style sheets. See also the attribute.scope = scope-name This attribute specifies the set of data cells for which the current header cell provides header information. This attribute may be used in place of the attribute, particularly for simple tables. When specified, this attribute must have one of the following values:
Attributes defined elsewhere Table cells may contain two types of information: header information and data. This distinction enables user agents to render header and data cells distinctly, even in the absence of style sheets. For example, visual user agents may present header cell text with a bold font. Speech synthesizers may render header information with a distinct voice inflection. The element defines a cell that contains header information. User agents have two pieces of header information available: the contents of the element and the value of the attribute. User agents must render either the contents of the cell or the value of the attribute. For visual media, the latter may be appropriate when there is insufficient space to render the full contents of the cell. For non-visual media may be used as an abbreviation for table headers when these are rendered along with the contents of the cells to which they apply. The and attributes also allow authors to help non-visual user agents process header information. Please consult the section on for information and examples. The element defines a cell that contains data. Cells may be empty (i.e., contain no data). For example, the following table contains four columns of data, each headed by a column description. A test table with merged cells /-----------------------------------------\ | | Average | Red | | |-------------------| eyes | | | height | weight | | |-----------------------------------------| | Males | 1.9 | 0.003 | 40% | |-----------------------------------------| | Females | 1.7 | 0.002 | 43% | \-----------------------------------------/6 A user agent rendering to a tty device might display this as follows: A test table with merged cells /-----------------------------------------\ | | Average | Red | | |-------------------| eyes | | | height | weight | | |-----------------------------------------| | Males | 1.9 | 0.003 | 40% | |-----------------------------------------| | Females | 1.7 | 0.002 | 43% | \-----------------------------------------/7 Cells that span several rows or columnsCells may span several rows or columns. The number of rows or columns spanned by a cell is set by the and attributes for the and elements. In this table definition, we specify that the cell in row four, column two should span a total of three columns, including the current row. A test table with merged cells /-----------------------------------------\ | | Average | Red | | |-------------------| eyes | | | height | weight | | |-----------------------------------------| | Males | 1.9 | 0.003 | 40% | |-----------------------------------------| | Females | 1.7 | 0.002 | 43% | \-----------------------------------------/8 This table might be rendered on a tty device by a visual user agent as follows: A test table with merged cells /-----------------------------------------\ | | Average | Red | | |-------------------| eyes | | | height | weight | | |-----------------------------------------| | Males | 1.9 | 0.003 | 40% | |-----------------------------------------| | Females | 1.7 | 0.002 | 43% | \-----------------------------------------/9 The next example illustrates (with the help of table borders) how cell definitions that span more than one row or column affect the definition of later cells. Consider the following table definition: ...the rest of the table... As cell "2" spans the first and second rows, the definition of the second row will take it into account. Thus, the second in row two actually defines the row's third cell. Visually, the table might be rendered to a tty device as: ...the rest of the table... while a graphical user agent might render this as: Note that if the defining cell "6" had been omitted, an extra empty cell would have been added by the user agent to complete the row. Similarly, in the following table definition: ...the rest of the table... cell "4" spans two columns, so the second in the row actually defines the third cell ("6"): ...the rest of the table... A graphical user agent might render this as: Defining overlapping cells is an error. User agents may vary in how they handle this error (e.g., rendering may vary). The following illegal example illustrates how one might create overlapping cells. In this table, cell "5" spans two rows and cell "7" spans two columns, so there is overlap in the cell between "7" and "9": ...the rest of the table... Note.The following sections describe the HTML table attributes that concern visual formatting. Although style sheets will offer better control of visual table formatting, at the writing of this specification, did not offer mechanisms to control all aspects of visual table formatting. HTML 4.0 includes mechanisms to control: The following attributes affect a table's external frame and internal rules. Attribute definitions frame = void|above|below|hsides|lhs|rhs|vsides|box|border This attribute specifies which sides of the frame that surrounds a table will be visible. Possible values:
To help distinguish the cells of a table, we can set the attribute of the element. Consider a previous example: A test table with merged cells /-----------------------------------------\ | | Average | Red | | |-------------------| eyes | | | height | weight | | |-----------------------------------------| | Males | 1.9 | 0.003 | 40% | |-----------------------------------------| | Females | 1.7 | 0.002 | 43% | \-----------------------------------------/6 In the following example, the user agent should show borders five pixels thick on the left-hand and right-hand sides of the table, with rules drawn between each column. ...the rest of the table... The following settings should be observed by user agents for backwards compatibility.
For example, the following definitions are equivalent: ...the rest of the table...
Attribute definitions align = left|center|right|justify|char This attribute specifies the alignment of data and the justification of text in a cell. Possible values:
When is used to set the offset of an alignment character, the direction of offset is determined by the current text direction (set by the attribute). In left-to-right texts (the default), offset is from the left margin. In right-to-left texts, offset is from the right margin. User agents are not required to support this attribute.
The table in this example aligns a row of currency values along a decimal point. We set the alignment character to "." explicitly. Vegetable Cost per kilo Lettuce $1 Silver carrots $10.50 Golden turnips $100.30The formatted table may resemble the following: ...the rest of the table... When the contents of a cell contain more than one instance of the alignment character specified by and the contents wrap, user agent behavior is undefined. Authors should therefore be attentive in their use of . Note. Visual user agents typically render elements vertically and horizontally centered within the cell and with a bold font weight. Inheritance of alignment specificationsThe alignment of cell contents can be specified on a cell by cell basis, or inherited from enclosing elements, such as the row, column or the table itself. The order of precedence (from highest to lowest) for the attributes , , and is the following:
The order of precedence (from highest to lowest) for the attribute (as well as the other inherited attributes , , and ) is the following:
Furthermore, when rendering cells, horizontal alignment is determined by columns in preference to rows, while for vertical alignment, rows are given preference over columns. The default alignment for cells depends on the user agent. However, user agents should substitute the default attribute for the current directionality (i.e., not just "left" in all cases). User agents that do not support the "justify" value of the attribute should use the value of the inherited directionality in its place. Note. Note that a cell may inherit an attribute not from its parent but from the first cell in a span. This is an exception to the general attribute inheritance rules. Attribute definitions These two attributes control spacing between and within cells. The following illustration explains how they relate: In the following example, the attribute specifies that cells should be separated from each other and from the table frame by twenty pixels. The attribute specifies that the top margin of the cell and the bottom margin of the cell will each be separated from the cell's contents by 10% of the available vertical space (the total being 20%). Similarly, the left margin of the cell and the right margin of the cell will each be separated from the cell's contents by 10% of the available horizontal space (the total being 20%). ...the rest of the table... If a table or given column has a fixed width, and may demand more space than assigned. User agents may give these attributes precedence over the attribute when a conflict occurs, but are not required to. Non-visual user agents such as speech synthesizers and Braille-based devices may use the following and element attributes to render table cells more intuitively:
In the following example, we assign header information to cells by setting the attribute. Each cell in the same column refers to the same header cell (via the attribute). A test table with merged cells /-----------------------------------------\ | | Average | Red | | |-------------------| eyes | | | height | weight | | |-----------------------------------------| | Males | 1.9 | 0.003 | 40% | |-----------------------------------------| | Females | 1.7 | 0.002 | 43% | \-----------------------------------------/6 A speech synthesizer might render this table as follows: THEAD - O (TR)+ -- table header --> TFOOT - O (TR)+ -- table footer -->1 Note how the header "Type of Coffee" is abbreviated to "Type" using the attribute. Here is the same example substituting the attribute for the attribute. Note the value "col" for the attribute, meaning "all cells in the current column": A test table with merged cells /-----------------------------------------\ | | Average | Red | | |-------------------| eyes | | | height | weight | | |-----------------------------------------| | Males | 1.9 | 0.003 | 40% | |-----------------------------------------| | Females | 1.7 | 0.002 | 43% | \-----------------------------------------/6 Here's a somewhat more complex example illustrating other values for the attribute: THEAD - O (TR)+ -- table header --> TFOOT - O (TR)+ -- table footer -->3 A graphical user agent might render this as: Note the use of the attribute with the "row" value. Although the first cell in each row contains data, not header information, the attribute makes the data cell behave like a row header cell. This allows speech synthesizers to provide the relevant course name upon request or to state it immediately before each cell's content. Users browsing a table with a speech-based user agent may wish to hear an explanation of a cell's contents in addition to the contents themselves. One way the user might provide an explanation is by speaking associated header information before speaking the data cell's contents (see the section on ). Users may also want information about more than one cell, in which case header information provided at the cell level (by , , and ) may not provide adequate context. Consider the following table, which classifies expenses for meals, hotels, and transport in two locations (San Jose and Seattle) over several days: Users might want to extract information from the table in the form of queries:
Each query involves a computation by the user agent that may involve zero or more cells. In order to determine, for example, the costs of meals on 25 August, the user agent must know which table cells refer to "Meals" (all of them) and which refer to "Dates" (specifically, 25 August), and find the intersection of the two sets. To accommodate this type of query, the HTML 4.0 table model allows authors to place cell headers and data into categories. For example, for the travel expense table, an author could group the header cells "San Jose" and "Seattle" into the category "Location", the headers "Meals", "Hotels", and "Transport" in the category "Expenses", and the four days into the category "Date". The previous three questions would then have the following meanings:
Authors categorize a header or data cell by setting the attribute for the cell. For instance, in the travel expense table, the cell containing the information "San Jose" could be placed in the "Location" category as follows: THEAD - O (TR)+ -- table header --> TFOOT - O (TR)+ -- table footer -->4 Any cell containing information related to "San Jose" should refer to this header cell via either the or the attribute. Thus, meal expenses for 25-Aug-1997 should be marked up to refer to attribute (whose value here is "a6") of the "San Jose" header cell: THEAD - O (TR)+ -- table header --> TFOOT - O (TR)+ -- table footer -->5 Each attribute provides a list of references. Authors may thus categorize a given cell in any number of ways (or, along any number of "headers", hence the name). Below we mark up the travel expense table with category information: THEAD - O (TR)+ -- table header --> TFOOT - O (TR)+ -- table footer -->6 Note that marking up the table this way also allows user agents to avoid confusing the user with unwanted information. For instance, if a speech synthesizer were to speak all of the figures in the "Meals" column of this table in response to the query "What were all my meal expenses?", a user would not be able to distinguish a day's expenses from subtotals or totals. By carefully categorizing cell data, authors allow user agents to make important semantic distinctions when rendering. Of course, there is no limit to how authors may categorize information in a table. In the travel expense table, for example, we could add the additional categories "subtotals" and "totals". This specification does not require user agents to handle information provided by the attribute, nor does it make any recommendations about how user agents may present information to users or how users may query the user agent about this information. However, user agents, particularly speech synthesizers, may want to factor out information common to several cells that are the result of a query. For instance, if the user asks "What did I spend for meals in San Jose?", the user agent would first determine the cells in question (25-Aug-1997: 37.74, 26-Aug-1997:27.28), then render this information. A user agent speaking this information might read it: THEAD - O (TR)+ -- table header --> TFOOT - O (TR)+ -- table footer -->7 or, more compactly: THEAD - O (TR)+ -- table header --> TFOOT - O (TR)+ -- table footer -->8 An even more economical rendering would factor the common information and reorder it: THEAD - O (TR)+ -- table header --> TFOOT - O (TR)+ -- table footer -->9 User agents that support this type of rendering should allow user agents a means to customize rendering (e.g., through style sheets). In the absence of header information from either the or attribute, user agents may construct header information according to the following algorithm. The goal of the algorithm is to find an ordered list of headers. (In the following description of the algorithm the is assumed to be left-to-right.)
This sample illustrates grouped rows and columns. The example is adapted from "Developing International Software", by Nadine Kano. In "ascii art", the following table: TBODY O O (TR)+ -- table body -->0 would be rendered something like this: TBODY O O (TR)+ -- table body -->1 A graphical user agent might render this as: This example illustrates how can be used to group columns and set the default column alignment. Similarly, is used to group rows. The and attributes tell the user agent which borders and rules to render. Which command would you use to fit columns to the text?In "Table Tools" click the [Layout] tab > locate the "Cell Size" group and choose from of the following options: To fit the columns to the text (or page margins if cells are empty), click [AutoFit] > select "AutoFit Contents."
What Layout tool would you use to create an indentation at a desired location?WPS special paragraph layout tool is a distinctive feature in Writer. You can adjust paragraphs in seconds just by dragging them. The Paragraph Layout tool provides the functions of paragraph spacing, line spacing, and indentations.
How to specify the distance of a paragraph from the left margin?Select Page Layout and notice the Indent left and right and Spacing before and after options. Place your cursor at the beginning of the paragraph you want to adjust. To indent the paragraph, type the distance you want in the Left or Right box under Page Layout.
When you clear formatting from a selection of text which of the following is applied to the text?CTRL-SPACE removes character-level formatting from the selected text (fonts, italics/bold, font size, etc.)
|