text:
This document is also available in these non-normative formats: Single XHTML file , PostScript version , PDF version , ZIP archive , and Gzip'd TAR archive .
Copyright ©2002 W3C ® ( MIT , INRIA , Keio ), All Rights Reserved. W3C liability , trademark , document use and software licensing rules apply.
This Working Draft specifies the XHTML 2.0 markup language and a variety of XHTML-conforming modules that support that language.
This section describes the status of this document at the time of its publication. Other documents may supersede this document. The latest status of this document series is maintained at the W3C.
This document is the third public Working Draft of this specification. It was released very soon after the second public Working Draft because of production errors, and does not reflect any major changes from that draft. It should in no way be considered stable, and should not be referenced for any purposes whatsoever. This version does not include the implementations of XHTML 2.0 in either DTD or XML Schema form. Those will be included in subsequent versions, once the contents of this language stabilizes. This version also does not address the issues revolving around the use of [ XLINK ] by XHTML 2. Those issues are being worked independent of the evolution of this specification. Those issues should, of course, be resolved as quickly as possible, and the resolution will be reflected in a future draft.
This document has been produced by the W3C HTML Working Group ( members only ) as part of the W3C HTML Activity . The goals of the HTML Working Group are discussed in the HTML Working Group charter .
Public discussion of XHTML takes place on email@example.com ( archive ). To subscribe send an email to firstname.lastname@example.com with the word subscribe in the subject line.
Please report errors in this document to firstname.lastname@example.com ( archive ).
At the time of publication, the Working Group believed there were no patent disclosures relevant to this specification. A current list of patent disclosures relevant to this specification may be found on the Working Group's patent disclosure page .
A list of current W3C Recommendations and other technical documents can be found at http://www.w3.org/TR.
This section is informative .
XHTML 2 is a markup language intended for rich, portable web-based applications. While the ancestry of XHTML 2 comes from HTML 4, XHTML 1.0, and XHTML 1.1, it is not intended to be backward compatible with its earlier versions. Application developers familiar with its earlier ancestors will be comfortable working with XHTML 2. Appendix A describes the ways in which XHTML 2 differs from previous versions and what application developers need to know to convert existing applications to XHTML 2.
XHTML 2 is a member of the XHTML Family of markup languages. It is an XHTML Host Language as defined in XHTML Modularization. As such, it is made up of a set of XHTML Modules that together describe the elements and attributes of the language, and their content model. XHTML 2 updates many of the modules defined in XHTML Modularization 1.0 [ XHTMLMOD ], and includes the updated versions of all those modules and their semantics. XHTML 2 also uses modules from Ruby [ RUBY ], XML Events [ XMLEVENTS ], and XForms [ XFORMS ].
The modules defined in this specification are largely extensions of the modules defined in XHTML Modularization 1.0. This specification also defines the semantics of the modules it includes. So, that means that unlike earlier versions of XHTML that relied upon the semantics defined in HTML 4, all of the semantics for XHTML 2 are defined either in this specification or in the specifications that it normatively references.
Even though the XHTML 2 modules are defined in this specification, they are available for use in other XHTML family markup languages. Over time, it is possible that the modules defined in this specification will migrate into the XHTML Modularization specification.
This section is informative .
While some terms are defined in place, the following definitions are used throughout this document. Familiarity with the W3C XML 1.0 Recommendation [ XML ] is highly recommended.
This section is normative .
The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [ RFC2119 ].
DTD Bias
This section has a distinct DTD bias. We need to make it clear that either the DTD or the Schema can be used to validate XHTML 2.0 documents.
A strictly conforming XHTML 2.0 document is a document that requires only the facilities described as mandatory in this specification. Such a document must meet all the following criteria:
The document must conform to the constraints expressed in Appendix B - XHTML 2.0 Schema or Appendix D - XHTML 2.0 Document Type Definition .
The root element of the document must be
html .
The root element of the document must contain an
xmlns declaration for the XHTML 2.0 namespace [ XMLNAMES ]. The namespace for XHTML
is defined to be
http://www.w3.org/2002/06/xhtml2 . An
example root element might look like:

There must be a DOCTYPE declaration in the document prior to the root element. If present, the public identifier included in the DOCTYPE declaration must reference the DTD found in Appendix E using its Formal Public Identifier. The system identifier may be modified appropriately.
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 2.0//EN" "TBD">
Here is an example of an XHTML 2.0 document.
<?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 2.0//EN" "TBD">   <title>Virtual Library</title>
Moved to vlib.org.

Note that in this example, the XML declaration is included. An XML declaration like the one above is not required in all XML documents. XHTML document authors are strongly encouraged to use XML declarations in all their documents. Such a declaration is required when the character encoding of the document is other than the default UTF-8 or UTF-16 and no encoding was determined by a higher-level protocol.
A conforming user agent must meet all user agent conformance requirements defined in [ XHTMLMOD ].
This section is normative .
The XHTML 2.0 document type is a fully functional document type with rich semantics. It is a collection of XHTML-conforming modules (most of which are defined in this specification). The Modules and their elements are listed here for information purposes, but the definitions in their base documents should be considered authoritative. In the on-line version of this document, the module names in the list below link into the definitions of the modules within the relevant version of the authoritative specification.
Need XHTML 2.0 Definition Table
We need a table that defines the modules that are in XHTML 2.0 and links them into this document. Currently, that will be a bunch of modules that are in this document, and modules from XML Events, Ruby, and XForms. The table below is largely correct, but is still just a place holder.
body, head, html, title
abbr, address, blockquote, code, dfn, div, em, h, h1, h2,
h3, h4, h5, h6, kbd, l, p, pre, quote, samp, section, span, strong,
dl, dt, dd, name, nl, ol, ul, li
area, map
object, param
hr, sub, sup
noscript, script
style element
target attribute
caption, col, colgroup, table, tbody, td, tfoot, th,
thead, tr
XHTML 2.0 also uses the following externally defined modules:
ruby, rbc, rtc, rb, rt, rp
There are no additional definitions required by this document type. An implementation of this document type as an XML Schema is defined in Appendix B , and as a DTD in Appendix D .
This section is normative .
This document defines a variety of XHTML modules and the semantics of those modules. This section describes the conventions used in those module definitions.
Each module in this document is structured in the following way:
Note that attributes are fully defined only the first time they are used in each module. After that, only a brief description of the attribute is provided, along with a link back to the primary definition.
An abstract module is a definition of an XHTML module using prose text and some informal markup conventions. While such a definition is not generally useful in the machine processing of document types, it is critical in helping people understand what is contained in a module. This section defines the way in which XHTML abstract modules are defined. An XHTML-conforming module is not required to provide an abstract module definition. However, anyone developing an XHTML module is encouraged to provide an abstraction to ease in the use of that module.
The abstract modules are not defined in a formal grammar. However, the definitions do adhere to the following syntactic conventions. These conventions are similar to those of XML DTDs, and should be familiar to XML DTD authors. Each discrete syntactic element can be combined with others to make more complex expressions that conform to the algebra defined here.
expr ?
expr +
expr *
a , b
a is required, followed by expression
b .
a | b
a - b
& ).
* ).
| ), inside of
parentheses following the attribute name. If the attribute has a
default value, that value is followed by an asterisk (
* ). If the attribute has a fixed value, the attribute name
is followed by an equals sign (
= ) and the fixed
value enclosed in quotation marks.
Abstract module definitions define minimal, atomic content models for each module. These minimal content models reference the elements in the module itself. They may also reference elements in other modules upon which the abstract module depends. Finally, the content model in many cases requires that text be permitted as content to one or more elements. In these cases, the symbol used for text is PCDATA . This is a term, defined in the XML 1.0 Recommendation, that refers to processed character data. A content type can also be defined as EMPTY , meaning the element has no content in its minimal content model.
In some instances, it is necessary to define the types of attribute values or the explicit set of permitted values for attributes. The following attribute types (defined in the XML 1.0 Recommendation) are used in the definitions of the abstract modules:
|Attribute Type
|Character data
|A document-unique identifier
|A reference to a document-unique identifier
|A space-separated list of references to document-unique identifiers
|A name with the same character constraints as ID above
|A name composed of only name tokens as defined in XML 1.0 [ XML ].
|One or more white space separated NMTOKEN values
|Processed character data
In addition to these pre-defined data types, XHTML Modularization defines the following data types and their semantics (as appropriate):
|Data type
|A single character, as per section 2.2 of [ XML ].
|A character encoding, as per [ RFC2045 ].
|A space-separated list of character encodings, as per [ RFC2045 ].
|Used by the class attribute, ClassNames are tokens that identify an element as being a member of the set named by the value of the class attribute. ClassName attribute tokens must begin with a letter ([A-Za-z]) and may be followed by any number of letters, digits ([0-9]), hyphens ("-"), underscores ("_"), colons (":"), and periods (".").
|A list of media ranges with optional accept parameters, as defined in section 14.1 of [ RFC2616 ] as the field value of the accept request header.
|Comma separated list of Length s used in defining areas.
|Date and time information.
|A character string representing an SGML Formal Public Identifier.
|Window name used as destination for results of certain actions.
|A language code, as per [ RFC3066 ].
|The value may be either in pixels or a percentage of the available horizontal or vertical space. Thus, the value "50%" means half of the available space.
|Authors may use the following recognized link types, listed
here with their conventional interpretations. A LinkTypes value
refers to a space-separated list of link types. White space
characters are not permitted within link types.
These link types are case-insensitive, i.e., "Alternate" has the same meaning as "alternate".
User agents, search engines, etc. may interpret these link types in a variety of ways. For example, user agents may provide access to linked documents through a navigation bar.
Linktype 'required'Linktype 'required'
Linktype 'prefetch'Linktype 'prefetch'
A comma-separated list of media descriptors as described by [ CSS2 ]. The default is
|One or more digits
|The shape of a region.
|Arbitrary textual data, likely meant to be human-readable.
|A Uniform Resource Identifier Reference, as defined by the type
anyURI in [
XMLSCHEMA ] (called IRI in some other specifications).
|A space-separated list of URIs as defined above.
|URI List
|A comma-separated list of URIs as defined above.
This section is normative .
Many of the abstract modules in this document define the required attributes for their elements. The table below defines some collections of attributes that are referenced throughout the modules. These expressions should in no way be considered normative or mandatory. They are an editorial convenience for this document. When used in the remainder of this section, it is the expansion of the term that is normative, not the term itself.
The following basic attribute sets are used on many elements. In each case where they are used, their use is identified via their collection name.
The class attribute can be used for different purposes in XHTML, for instance as a style sheet selector (when an author wishes to assign style information to a set of elements), and for general purpose processing by user agents.
For instance in the following example, the p element is used in conjunction with the class attribute to identify a particular type of paragraph.

 These programs are only available if you have purchased the advanced professional suite.

Style sheet rules can then be used to render the paragraph appropriately, for instance by putting a border around it, giving it a different background colour, or where necessary by not displaying it at all.
The id attribute has several roles in XHTML:
As an example, the following headings are distinguished by their id values:
<h id="introduction">Introduction</h>
...
 <h id="events">The Events Module</h>
...

Values of the title attribute may be rendered by user agents in a variety of ways. For instance, visual browsers should display the title as a "tool tip" (a short message that appears when the pointing device pauses over an object). Audio user agents may speak the title information in a similar context.
Example of the use of title :
Jakob Nielsen's Alertbox for January 11, 1998
The title attribute has an additional role when used with the link element to designate an external style sheet. See the section on links and style sheets for details.
'root'A 'root of word' attribute for common
An element inherits language code information according to the following order of precedence (highest to lowest):
In this example, the primary language of the document is French ("fr"). One paragraph is declared to be in US English ("en-us"), after which the primary language returns to French. The following paragraph includes an embedded Japanese ("ja") phrase, after which the primary language returns to French.
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 2.0//EN" "TBD">   <title>Un document multilingue</title>
...Interpreted as French...

...Interpreted as US English...

...Interpreted as French again...

...French text interrupted bysome JapaneseFrench begins here again...

*[dir="ltr"] { unicode-bidi: normal; direction: ltr}
*[dir="rtl"] { unicode-bidi: normal; direction: rtl}
*[dir="lro"] { unicode-bidi: bidi-override; direction: ltr}
*[dir="rlo"] { unicode-bidi: bidi-override; direction: rtl}
improve bidi example

 I received the following email: <l dir="lro">english werbeh english</l> <l dir="lro">werbeh english werbeh</l>

This collection allows elements to carry information indicating how, when and why content has changed.
inserted and
The default presentation for an element with
edit="deleted" is
display: none (in other
words, it is not displayed) although an alternate style might
display it as crossed through. The other three values cause no
special presentation by default, though an alternate style might
use background colors or other text decoration to indicate the
changed text.
I will do it next week month .
This collection allows an element to be the start point of a hypertext link to a remote resource.
WWW
contents
 Amsterdam <quote href="hamlet.xhtml#p2435">To be or not to be</quote> <var href="#index_ninc">ninc</var>
WWW
This specification does not define how this attribute gets used, since that is defined by the environment that the hyperlink is actuated in. See for instance XFrames [ XFRAMES ].
Home
Pressing an access key assigned to an element gives focus to the element. The action that occurs when an element receives focus depends on the element. For example, when a user activates a link defined by the a element, the user agent generally follows the link. When a user activates a radio button, the user agent changes the value of the radio button. When the user activates a text field, it allows input, etc.
In this example, we assign the access key "C" to a link. Typing this access key takes the user to another document, in this case, a table of contents.

 Table of Contents

The invocation of access keys depends on the underlying system. For instance, on machines running MS Windows, one generally has to press the "alt" key in addition to the access key. On Apple systems, one generally has to press the "cmd" key in addition to the access key.
The rendering of access keys depends on the user agent. We recommend that authors include the access key in label text or wherever the access key is to apply. User agents should render the value of an access key in such a way as to emphasize its role and to distinguish it from other characters (e.g., by underlining it).
AccesskeyActuation of elements with accesskey
The navigation order defines the order in which elements will receive focus when navigated by the user via the keyboard. The navigation order may include elements nested within other elements.
Elements that may receive focus should be navigated by user agents according to the following rules:
When a document is loaded using a URL that includes a fragment
reference (such as
book.html#chapter5 ) navigation
begins at the point the fragment begins. If the user has moved away
from that point (for instance using page up or page down), the
navigation starting point is undefined.
The following example would allow the links to be navigated in
column order (without the use of
navindex they would
be navigated in document, i.e. row, order):

NW	 NE

SW	 SE

Navigation keys. The actual key sequence that causes navigation or element activation depends on the configuration of the user agent (e.g., the "tab" key might be used for navigation and the "enter" key or "space" key used to activate a selected element).
User agents may also define key sequences to navigate the navigation order in reverse. When the end (or beginning) of the navigation order is reached, user agents may circle back to the beginning (or end).
An element inherits URI base information according to the following order of precedence (highest to lowest):

The W3C home page

The W3C Technical Reports page

The HTML home page

The XForms home page

This collection causes the contents of a remote resource to be embedded in the document in place of the element's content. If accessing the remote resource fails, for whatever reason (network unavailable, no resource available at the URI given, inability of the user agent to process the type of resource) the content of the element must be processed instead.

  An image of us on holiday.

This attribute specifies the allowable content types of the relevant src URI. At its most general, it is a comma-separated list of media ranges with optional accept parameters, as defined in section 14.1 of [ RFC2616 ] as the field value of the accept request header.
In its simplest case, this is just a media type, such as "image/png" or "application/xml", but it may also contain asterisks, such as "image/*" or "*/*", or lists of acceptable media types, such as "image/png, image/gif, image/jpeg".
The user agent must take this list, and combine it with its own list of acceptable media types by taking the intersection, and then use the resulting list as the field value of the accept request header when requesting the resource.
For instance, if the attribute specifies the value "image/png, image/gif, image/jpeg", but the user agent does not accept images of type "image/gif" then the resultant accept header would contain "image/png, image/jpeg".
If this attribute is not present, "*/*" is used for its value.
For the current list of registered content types, please consult [ MIMETYPES ].

The script element places a script within a document. This element may appear any number of times in the head or body of an XHTML document.
The script may be defined within the contents of the script element or in an external file. If the src attribute is not set, user agents must interpret the contents of the element as the script. If the src has a URI value, user agents must ignore the element's contents and retrieve the script via the URI. Note that the charset attribute refers to the character encoding of the script designated by the src attribute; it does not concern the content of the script element.
Scripts are evaluated by script engines that must be known to a user agent.
A user agent must interpret a script element according to the following precedence rules:
The syntax of script data depends on the scripting language.
As XHTML does not rely on a specific scripting language, document authors must explicitly tell user agents the language of each script. This may be done either through a default declaration or a local declaration.
The type attribute must be specified for each script element instance in a document.
In this example, we include one script in the header, whose script is located in an external file and is in the scripting language "text/vbscript". The JavaScript code contained in the inner script will be evaluated if and only if the user agent isn't evaluating the outer script . We also include one script in the body, which contains its own script written in "text/x-perl".
  <title>A document with script</title>  </script>    ...
will produce the following document after evaluation:
... <title>Test Document</title> ...
Hello World!
 ...
This section is normative .
The Style Sheet Module defines an element to be used when declaring internal style sheets. The element and attributes defined by this module are:
|Minimal Content Model
|Common , media ( MediaDesc )
When this module is used, it adds the style element to the content model of the head element of the Structure Module.
Implementation: DTD
The style element allows an author to put style sheet rules in the head of the document. XHTML permits any number of style elements in the head section of a document.
User agents that don't support style sheets, or don't support the specific style sheet language used by a style element, must hide the contents of the style element. It is an error to render the content as part of the document's text.
The syntax of style data depends on the style sheet language.
Rules for style rule precedences and inheritance depend on the style sheet language.
The following CSS style declaration puts a border around every h1 element in the document and centers it on the page.

To specify that this style information should only apply to h1 elements of a specific class, we modify it as follows:

 This h1 is affected by our style

 This one is not affected by our style

Finally, to limit the scope of the style information to a single instance of h1 , set the id attribute:

 This h1 is not affected

 This h1 is affected by style

 This h1 is not affected

Although style information may be set for almost every XHTML element, two elements, div and span , are particularly useful in that they do not impose any presentation semantics (besides block-level vs. inline). When combined with style sheets, these elements allow users to extend XHTML indefinitely, particularly when used with the class and id attributes.
In the following example, we use the span element to set the font style of the first few words of a paragraph to small caps.

The first few words of this paragraph are in small-caps.

In the following example, we use div and the class attribute to set the text justification for a series of paragraphs that make up the abstract section of a scientific article. This style information could be reused for other abstract sections by setting the class attribute elsewhere in the document.

The Chieftain product range is our market winner for the coming year. This report sets out how to position Chieftain against competing products.

Chieftain replaces the Commander range, which will remain on the price list until further notice.

Authors may separate style sheets from XHTML documents. This offers several benefits:
XHTML allows authors to associate any number of external style sheets with a document. The style sheet language defines how multiple external style sheets interact (for example, the CSS "cascade" rules).
Authors may specify a number of mutually exclusive style sheets called alternate style sheets. Users may select their favorite among these depending on their preferences. For instance, an author may specify one style sheet designed for small screens and another for users with weak vision (e.g., large fonts). User agents should allow users to select from alternate style sheets.
The author may specify that one of the alternates is a preferred style sheet. User agents should apply the author's preferred style sheet unless the user has selected a different alternate.
Authors may group several alternate style sheets (including the author's preferred style sheets) under a single style name . When a user selects a named style, the user agent must apply all style sheets with that name. User agents must not apply alternate style sheets with a different style name. The section on specifying external style sheets explains how to name a group of style sheets.
Authors may also specify persistent style sheets that user agents must apply in addition to any alternate style sheet.
User agents must respect media descriptors when applying any style sheet.
User agents should also allow users to disable the author's style sheets entirely, in which case the user agent must not apply any persistent or alternate style sheets.
Authors specify external style sheets with the following attributes of the link element:
User agents should provide a means for users to view and pick from the list of alternate styles. The value of the title attribute is recommended as the name of each choice.
In this example, we first specify a persistent style sheet located in the file mystyle.css :
<link href="mystyle.css" rel="stylesheet" type="text/css"/>
Setting the title attribute makes this the author's preferred style sheet:
<link href="mystyle.css" title="compact" rel="stylesheet" type="text/css"/>
Adding the keyword "alternate" to the rel attribute makes it an alternate style sheet:
<link href="mystyle.css" title="Medium" rel="alternate stylesheet" type="text/css"/>
For more information on external style sheets, please consult the section on links and external style sheets.
If two or more link elements specify a preferred style sheet, the first one takes precedence.
This section is normative .
As its name suggests, the Tables Module provides table-related elements that are updated to enable access by non-visual user agents. Specifically, the Tables Module supports the following elements, attributes, and content model:
|Minimal Content Model
|Common , summary ( Text )
|caption ?, ( col * | colgroup * ), (( thead ?, tfoot ?, tbody + ) | ( tr + ))
|(PCDATA | Inline)*
|Common , span ( Number )
|Common , span ( Number )
|col *
|tr +
|tr +
|tr +
|( td | th )+
|Common , abbr ( Text ), axis ( CDATA ), colspan ( Number ), headers ( IDREFS ), rowspan ( Number ), scope ("row", "col", "rowgroup", "colgroup")
|(PCDATA | Flow )*
|Common , abbr ( Text ), axis ( CDATA ), colspan ( Number ), headers ( IDREFS ), rowspan ( Number ), scope ("row", "col", "rowgroup", "colgroup")
|(PCDATA | Flow )*
When this module is used, it adds the table element to the Block content set of the Text Module.
Implementation: DTD
When present, the caption element's text should describe the nature of the table. The caption element is only permitted immediately after the table start tag. A table element may only contain one caption 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 summary attribute of the table element. This is especially important for tables without captions. The example below illustrates the use of the summary attribute.
User agents must provide access to the content of the summary attribute. As an example, access could be provided through a menu option, a mouse-over function, or through a dialog.
The following example demonstrates the difference between a table caption and a table summary.

Student Class Roster
 ...the rest of the table...

Visual user agents must 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.
Values mean the following:
User agents must ignore this attribute if the colgroup element contains one or more col elements.
The colgroup element allows authors to create structural divisions within a table. Authors may highlight this structure through style sheets. For example, the author may wish to divide the columns into logical groups such as the student's permanent address, phone number and emergency contact information. And group the student's local address, phone and email address into another logical group.
A table may either contain a single implicit column group (no colgroup element delimits the columns) or any number of explicit column groups (each delimited by an instance of the colgroup element).
The col element allows authors to share attributes among several columns without implying any structural grouping. The "span" of the col element is the number of columns that will share the element's attributes. For example, the author may wish to apply a specific style to the student's permanent data and apply a different style to the student's local data.
The colgroup 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 colgroup element is that authors may logically group multiple columns. By grouping columns, the author can apply rules across the entire group. The author can also apply column width balancing across the group of columns. For example, if the author has a table with five columns and the author divides the table into two column groups, one with three columns and the other with two columns. The author could define the first column group to consume 300 pixels and the second column group to consume 100 pixels. Each column within the first column group would be 100 pixels wide and the remaining two columns would be 50 pixels wide. If the author added embedded col elements, she could force one or more columns to be a specific width and the remaining columns within the group would be evenly divided within the remaining allotted width.
For example, the following table defines a column group and embedded columns with differing widths.
 ...
 <colgroup id="colgrp1"> <col id="col1" span="3"> <col id="col2" span="2"> </colgroup> ...the rest of the table...

In this example, the defined width for the colgroup constrains all of the columns to fit within that value regardless of the of the defined values within the col eleemnts. In this example, the width of the columns within the column group must be constrained to fit the defined width of the column group.
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 col element.
The col element allows authors to group together attribute specifications for table columns. The col does not group columns together structurally -- that is the role of the colgroup element. col elements are empty and serve only as a support for attributes. They may appear inside or outside an explicit column group (i.e., colgroup element).
There are two ways to determine the number of columns in a table (in order of precedence):
It is an error if a table contains colgroup or col 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 a colgroup .
The table element contains all other elements that specify the caption, column groups, columns, rows, and content for a table.
The following informative list describes what operations visual user agents may carry out when rendering a table:
The XHTML 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 colgroup and col elements. If any of the columns are specified in relative or percentage terms, authors must also specify the width of the table itself.
The directionality of a table is either the inherited directionality (the default is left-to-right) or that specified by the dir attribute for the table 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, 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 table is the only element on which dir reverses the visual order of the columns; a single table row ( tr ) or a group of columns ( colgroup ) cannot be independently reversed.
When set for the table element, the dir attribute also affects the direction of text within table cells (since the dir attribute is inherited by block-level elements).
To specify a right-to-left table, set the dir attribute as follows:

 ...the rest of the table...

The direction of text in individual cells can be changed by setting the dir attribute in an element that defines the cell.
This section provides more detailed discussion on cell header data and how non-visual agents may utilize that information.
Non-visual user agents such as speech synthesizers and Braille-based devices may use the following td and th element attributes to render table cells more intuitively:
In the following example, we assign header information to cells by setting the headers attribute. Each cell in the same column refers to the same header cell (via the id attribute).

Cups of coffee consumed by each senator

 Name	 Cups	 Type of Coffee	 Sugar?

 T. Sexton	 10	 Espresso	 No

 J. Dinnen	 5	 Decaf	 Yes

A speech synthesizer might render this table as follows:
Caption: Cups of coffee consumed by each senator Summary: This table charts the number of cups of coffee consumed by each senator, the type of coffee (decaf or regular), and whether taken with sugar. Name: T. Sexton, Cups: 10, Type: Espresso, Sugar: No Name: J. Dinnen, Cups: 5, Type: Decaf, Sugar: Yes
Note how the header "Type of Coffee" is abbreviated to "Type" using the abbr attribute.
Here is the same example substituting the scope attribute for the headers attribute. Note the value "col" for the scope attribute, meaning "all cells in the current column":

Cups of coffee consumed by each senator

 Name	 Cups	 Type of Coffee	 Sugar?

 T. Sexton	 10	 Espresso	 No

 J. Dinnen	 5	 Decaf	 Yes

Here's a somewhat more complex example illustrating other values for the scope attribute:

 Community Courses -- Bath Autumn 1997

 Course Name	 Course Tutor	 Summary	 Code	 Fee

 After the Civil War	 Dr. John Wroughton	  The course will examine the turbulent years in England after 1646. 6 weekly meetings starting Monday 13th October. 	 H27	 £32

 An Introduction to Anglo-Saxon England	 Mark Cottle	  One day course introducing the early medieval period reconstruction the Anglo-Saxons and their society. Saturday 18th October. 	 H28	 £18

 The Glory that was Greece	 Valerie Lorenz	  Birthplace of democracy, philosophy, heartland of theater, home of argument. The Romans may have done it but the Greeks did it first. Saturday day school 25th October 1997 	 H30	 £18

A graphical user agent might render this as:
Note the use of the scope attribute with the "row" value. Although the first cell in each row contains data, not header information, the scope 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 associating header information with data cells ).
Users may also want information about more than one cell, in which case header information provided at the cell level (by headers , scope , and abbr ) 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 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 axis 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:
San Jose
Any cell containing information related to "San Jose" should refer to this header cell via either the headers or the scope attribute. Thus, meal expenses for 25-Aug-1997 should be marked up to refer to id attribute (whose value here is "a6") of the "San Jose" header cell:
37.74
Each headers attribute provides a list of id 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:

Travel Expense Report

 	 Meals	 Hotels	 Transport	 subtotals

 San Jose

 25-Aug-97	 37.74	 112.00	 45.00

 26-Aug-97	 27.28	 112.00	 45.00

 subtotals	 65.02	 224.00	 90.00	 379.02

 Seattle

 27-Aug-97	 96.25	 109.00	 36.00

 28-Aug-97	 35.00	 109.00	 36.00

 subtotals	 131.25	 218.00	 72.00	 421.25

 Totals	 196.27	 442.00	 162.00	 800.27

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 axis attribute, nor does it make any recommendations about how user agents may present axis 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:
Location: San Jose. Date: 25-Aug-1997. Expenses, Meals: 37.74 Location: San Jose. Date: 26-Aug-1997. Expenses, Meals: 27.28
or, more compactly:
San Jose, 25-Aug-1997, Meals: 37.74 San Jose, 26-Aug-1997, Meals: 27.28
An even more economical rendering would factor the common information and reorder it:
San Jose, Meals, 25-Aug-1997: 37.74 26-Aug-1997: 27.28
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 scope or headers 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 table directionality is assumed to be left-to-right.)
This sample illustrates grouped rows and columns.

Calendar for 2002
 <colgroup span="7"> <colgroup span="7"> <colgroup span="7">

 January	 February	 March

 S	M	T	W	T	F	S	 S	M	T	W	T	F	S	 S	M	T	W	T	F	S

 		1	2	3	4	5	 					1	2	 					1	2

 6	7	8	9	10	11	12	 3	4	5	6	7	8	9	 3	4	5	6	7	8	9

 13	14	15	16	17	18	19	 10	11	12	13	14	15	16	 10	11	12	13	14	15	16

 20	21	22	23	24	25	26	 17	18	19	20	21	22	23	 17	18	19	20	21	22	23

 27	28	29	30	31			 24	25	26	27	28			 24	25	26	27	28	29	30

 							 							 31

would be rendered something like this:
Calendar for 2002 =================================================================== January | February | March S M T W T F S | S M T W T F S | S M T W T F S ------------------------------------------------------------------- 1 2 3 4 5 | 1 2 | 1 2 6 7 8 9 10 11 12 | 3 4 5 6 7 8 9 | 3 4 5 6 7 8 9 13 14 15 16 17 18 19 | 10 11 12 13 14 15 16| 10 11 12 13 14 15 16 20 21 22 23 24 25 26 | 17 18 19 20 21 22 23| 17 18 19 20 21 22 23 27 28 29 30 31 | 24 25 26 27 28 | 24 25 26 27 28 29 30 | | 31 ====================================================================
A graphical user agent might render this as:
This example illustrates how colgroup can be used to group columns and set the default column alignment. Similarly, tbody is used to group rows.
The tbody element contains rows of table data. In tables that also contain thead or tfoot elements, all of these sections must contain the same number of columns.
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 th element defines a cell that contains header information. User agents have two pieces of header information available: the contents of the th element and the value of the abbr attribute. User agents must render either the contents of the cell or the value of the abbr 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 abbr 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 headers and scope attributes also allow authors to help non-visual user agents process header information. Please consult the section on labeling cells for non-visual user agents for information and examples.
The td 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.

Cups of coffee consumed by each senator

 Name	 Cups	 Type of Coffee	 Sugar?

 T. Sexton	 10	 Espresso	 No

 J. Dinnen	 5	 Decaf	 Yes

A user agent rendering to a tty device might display this as follows:
Name Cups Type of Coffee Sugar? T. Sexton 10 Espresso No J. Dinnen 5 Decaf Yes
Cells may span several rows or columns. The number of rows or columns spanned by a cell is set by the rowspan and colspan attributes for the th and td 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 column.

Cups of coffee consumed by each senator

 Name	 Cups	 Type of Coffee	 Sugar?

 T. Sexton	 10	 Espresso	 No

 J. Dinnen	 5	 Decaf	 Yes

 A. Soria	 Not available

This table might be rendered on a tty device by a visual user agent as follows:
Cups of coffee consumed by each senator -------------------------------------- | Name |Cups|Type of Coffee|Sugar?| -------------------------------------- |T. Sexton|10 |Espresso |No | -------------------------------------- |J. Dinnen|5 |Decaf |Yes | -------------------------------------- |A. Soria |Not available | --------------------------------------
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:

 1	 2	 3

 4 6

 7	 8	 9

As cell "2" spans the first and second rows, the definition of the second row will take it into account. Thus, the second td in row two actually defines the row's third cell. Visually, the table might be rendered to a tty device as:
------------- | 1 | 2 | 3 | ----| |---- | 4 | | 6 | ----|---|---- | 7 | 8 | 9 | -------------
while a graphical user agent might render this as:
Note that if the td 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:

 1	 2	 3

 4	 6

 7	 8	 9

cell "4" spans two columns, so the second td in the row actually defines the third cell ("6"):
------------- | 1 | 2 | 3 | --------|---- | 4 | 6 | --------|---- | 7 | 8 | 9 | -------------
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":

 1	 2	 3

 4	 5	 6

 7	 9

Table rows may be grouped into a table head, table foot, and one or more table body sections, using the thead , tfoot and tbody 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 thead , tfoot , and tbody contains a row group . Each row group must contain at least one row, defined by the tr element.
If the thead , tfoot , and tbody elements are used, and a rowspan attriubte is used within a group, the rowspan must remain within the group boundaries of which it is defined.
This example illustrates the order and structure of the table head, foot, 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...

tfoot must appear before tbody within a table definition so that user agents can render the foot before receiving all of the (potentially numerous) rows of data.
The tr elements acts as a container for a row of table cells.
This sample table contains three rows, each begun by the tr element:

Cups of coffee consumed by each senator

 ...A header row...

 ...First row of data...

 ...Second row of data...
 ...the rest of the table...

This appendix is informative .
This Appendix describes the differences between XHTML 2.0 and XHTML 1.1.
Change summary needed
This section needs a table that illustrates elements removed and added, and changes made to elements that were kept.
This appendix is normative .
This appendix will contain the implementation of the XHTML 2.0 Schema driver file and content model file.
XHTML 2.0 Schema Needed
The XHTML 2.0 Schema driver and content model files need to be built.
This appendix is normative .
This appendix will contain implementations of the modules defined in this specification via XML Schema [ XMLSCHEMA ] when XML Schema becomes a W3C Recommendation.
This appendix is normative .
This appendix will contain the implementation of the XHTML 2.0 DTD driver file and content model file.
XHTML 2.0 DTD Needed
The XHTML 2.0 DTD driver and content model files need to be built. There is an open issue about how to integrate the XForms instance data into such a DTD.
This appendix is normative .
This appendix will contain implementations of the modules defined in this specification. These module implementations can be used in other XHTML Family Document Types.
In order to take advantage of the XHTML DTD Modules, DTD authors need to define the content model for their DTD. XHTML provides a variety of tools to ease this effort. They are defined in a set of support modules, instantiated by a main Framework module:
Module DTD/xhtml-framework-2.mod not found!
Note that the module above references a content model module. This module is defined on a per-document type basis in addition to the document type driver file. The Modular framework also relies upon the following component modules:
DTD Module XHTML Base Architecture needed
The DTD Module DTD Module XHTML Base Architecture needed referenced as DTD/xhtml-arch-2.mod needs to be defined. It will be defined before publication of a last call draft.
DTD Module XHTML Notations needed
The DTD Module DTD Module XHTML Notations needed referenced as DTD/xhtml-notations-2.mod needs to be defined. It will be defined before publication of a last call draft.
DTD Module XHTML Datatypes needed
The DTD Module DTD Module XHTML Datatypes needed referenced as DTD/xhtml-datatypes-2.mod needs to be defined. It will be defined before publication of a last call draft.
DTD Module XHTML Common Attribute Definitions needed
The DTD Module DTD Module XHTML Common Attribute Definitions needed referenced as DTD/xhtml-attribs-2.mod needs to be defined. It will be defined before publication of a last call draft.
DTD Module XHTML Qualified Names needed
The DTD Module DTD Module XHTML Qualified Names needed referenced as DTD/xhtml-qname-2.mod needs to be defined. It will be defined before publication of a last call draft.
DTD Module XHTML Character Entities needed
The DTD Module DTD Module XHTML Character Entities needed referenced as DTD/xhtml-charent-1.mod needs to be defined. It will be defined before publication of a last call draft.
This section contains the formal definition of each of the XHTML Abstract Modules as a DTD module.
DTD Module Structure needed
The DTD Module DTD Module Structure needed referenced as DTD/xhtml-struct-1.mod needs to be defined. It will be defined before publication of a last call draft.
DTD Module Text needed
The DTD Module DTD Module Text needed referenced as DTD/xhtml-text-1.mod needs to be defined. It will be defined before publication of a last call draft.
DTD Module Hypertext needed
The DTD Module DTD Module Hypertext needed referenced as DTD/xhtml-hypertext-1.mod needs to be defined. It will be defined before publication of a last call draft.
DTD Module Lists needed
The DTD Module DTD Module Lists needed referenced as DTD/xhtml-list-1.mod needs to be defined. It will be defined before publication of a last call draft.
DTD Module Bi-directional Text needed
The DTD Module DTD Module Bi-directional Text needed referenced as DTD/xhtml-bdo-1.mod needs to be defined. It will be defined before publication of a last call draft.
DTD Module Client-side Image Map needed
The DTD Module DTD Module Client-side Image Map needed referenced as DTD/xhtml-csismap-1.mod needs to be defined. It will be defined before publication of a last call draft.
DTD Module Edit needed
The DTD Module DTD Module Edit needed referenced as DTD/xhtml-edit-1.mod needs to be defined. It will be defined before publication of a last call draft.
DTD Module Link needed
The DTD Module DTD Module Link needed referenced as DTD/xhtml-link-1.mod needs to be defined. It will be defined before publication of a last call draft.
DTD Module Metainformation needed
The DTD Module DTD Module Metainformation needed referenced as DTD/xhtml-meta-1.mod needs to be defined. It will be defined before publication of a last call draft.
DTD Module Object needed
The DTD Module DTD Module Object needed referenced as DTD/xhtml-object-1.mod needs to be defined. It will be defined before publication of a last call draft.
DTD Module Presentation needed
The DTD Module DTD Module Presentation needed referenced as DTD/xhtml-pres-1.mod needs to be defined. It will be defined before publication of a last call draft.
DTD Module Scripting needed
The DTD Module DTD Module Scripting needed referenced as DTD/xhtml-script-1.mod needs to be defined. It will be defined before publication of a last call draft.
DTD Module Server-side Image Map needed
The DTD Module DTD Module Server-side Image Map needed referenced as DTD/xhtml-ssismap-1.mod needs to be defined. It will be defined before publication of a last call draft.
DTD Module Style Sheet needed
The DTD Module DTD Module Style Sheet needed referenced as DTD/xhtml-style-1.mod needs to be defined. It will be defined before publication of a last call draft.
DTD Module Tables needed
The DTD Module DTD Module Tables needed referenced as DTD/xhtml-table-1.mod needs to be defined. It will be defined before publication of a last call draft.
DTD Module Target needed
The DTD Module DTD Module Target needed referenced as DTD/xhtml-target-1.mod needs to be defined. It will be defined before publication of a last call draft.
The modules in this section are elements of the XHTML DTD implementation that, while hidden from casual users, are important to understand when creating derivative markup languages using the Modularization architecture.
DTD Module Block Phrasal needed
The DTD Module DTD Module Block Phrasal needed referenced as DTD/xhtml-blkphras-1.mod needs to be defined. It will be defined before publication of a last call draft.
DTD Module Block Presentational needed
The DTD Module DTD Module Block Presentational needed referenced as DTD/xhtml-blkpres-1.mod needs to be defined. It will be defined before publication of a last call draft.
DTD Module Block Structural needed
The DTD Module DTD Module Block Structural needed referenced as DTD/xhtml-blkstruct-1.mod needs to be defined. It will be defined before publication of a last call draft.
DTD Module Inline Phrasal needed
The DTD Module DTD Module Inline Phrasal needed referenced as DTD/xhtml-inlphras-1.mod needs to be defined. It will be defined before publication of a last call draft.
DTD Module Inline Presentational needed
The DTD Module DTD Module Inline Presentational needed referenced as DTD/xhtml-inlpres-1.mod needs to be defined. It will be defined before publication of a last call draft.
DTD Module Inline Structural needed
The DTD Module DTD Module Inline Structural needed referenced as DTD/xhtml-inlstruct-1.mod needs to be defined. It will be defined before publication of a last call draft.
DTD Module Param needed
The DTD Module DTD Module Param needed referenced as DTD/xhtml-param-1.mod needs to be defined. It will be defined before publication of a last call draft.
DTD Module Legacy Redeclarations needed
The DTD Module DTD Module Legacy Redeclarations needed referenced as DTD/xhtml-legacy-redecl-1.mod needs to be defined. It will be defined before publication of a last call draft.
This appendix is normative .
This appendix is informative .
This specification was prepared by the W3C HTML Working Group. The members at the time of publication were:
This section will be updated at publication time.


text:
Please log in to consult the article in its entirety. If you are a member (student of staff) of a subscribing institution (see List), you should be able to access the LE on campus directly (without the need to log in), and off-campus either via the institutional log in we offer, or via your institution's remote access facilities, or by creating a personal user account with your institutional email address. If you are not a member of a subscribing institution, you will need to purchase a personal subscription. For more information on how to subscribe as an individual user, please see under Individual Subcriptions.
French ship destroyed by the Spanish in Florida
Historical Context Note
Save this article
If you need to create a new bookshelf to save this article in, please make sure that you are logged in, then go to your 'Account' here.

subset: commoncrawl


text:
I feel that I have naturally stopped posting here on blogger and have started using tumblr (the new micro blogging platform of the moment) because it takes so much time posting on all these different platforms. So if you want to keep seeing my illustration blog goodness bookmark my new blog on tumblr, it's what all the kids are using now. Will it be around in a year from now? who knows, but I have to try and stay up to speed. See you on my new blog!
Posted byJason Raish at 12:51 PM 0 comments
Until Next Time, My Paris
Wednesday, November 20, 2013
I realize that some readers may not realize that I have been living around the world for the last 5 years, the last year in Paris. I recently returned to New York.
My last Paris post for a while. I have moved back to New York and am writing this in a cafe, drinking un café as we speak, missing France. Peter Pan is hanging up his tights. 5 years and 4 months and 20 days ago on June 1st, 2008, I left the USA for Beijing and started down a long road that saw me living in Beijing, Tokyo, Seoul, Barcelona, London, and Paris. I am not the same person I was 5 years ago. I have evolved, mostly for the better. Thoreau, Whitman, Emerson all have amazingly true things to say about what traveling does to a person and it has definitely shaped me into a better Jason. Today I am officially back in New York, and I live, guess where, Brookyln, off the Lorimer L stop. There are too many things to say about living abroad in 6 countries for 5 years. So many adventures, triumphs, follies, and experiences. I saw the Olympics in Beijing, traveled the remote southern mountains, cruised down the Yangtze river. I went to Japanese language school in Tokyo everyday for 3.5 hrs for a year. I experienced the big earthquake first hand and fled to Korea. I was hit by a taxi and had a broken skull and woke up a day later in the hospital remembering nothing. I fell in love with Korea again. I hung out with North Korean defectors. I soaked in the Barcelona sun for a whole summer. I got the most drunk I have ever been in my life and may or may not have run with the bulls. I saw the London riots, I drank an uncountable number of pints. I learned Britishisms. I learned how to relax in Paris. I rode all the streets of Paris on my French bike. All food has been ruined for me after eating the finest cheese, bread, meat, misc French cuisine for a year. I made lifetime friends. I have a million crazy stories. I learned 5 languages enough to have basic conversations (all forgotten now, sad isn't it). When I left New York in 2008 it was still unsure if I was going to make it as an Illustrator, but here I am 5 years later having lived off the strength of Illustration. I have explored the world, I have no regrets, I went and did it all. I did it my way more or less, and because of this I have no regrets and will forever be changed for the better. Will this Peter Pan look over longingly at his green tights hanging on the wall from time to time? You bet, but it feels good to be back in New York. Thanks to all my friends and family for humoring Peter Pan all these years and letting him fly around for a while (aka thanks for the support). Just kidding New York, I'm back after that 5 year distraction. Now the question is, what's stopping you from doing what I did? If you're just tuning in you can see all of my misadventures on this here travel blog www.misadventuresofjason.blogspot.com the Best of France/conclusion and afterthoughts post will come soon.
I had this plan to photograph a bunch of cafes on these obtuse angled corners at night with my tripod and timer. Time was running out in Paris so I only had a chance to go out for one night. Only 3 out of these 8 cafes I did manage to shoot are actually on these obtuse angled triangle corners and the other 5 are on normal 90 degree corners. The obtuse corner cafes are a unique thing to Paris and look cool. This is the cafe that sparked the idea, right next to Hemmingway's old apartment, but by the time I got to shoot it they had changed their lighting from green to this. Le Descartes off of Rue Mouffetard. I never actually got the chance to go here.
Le Saint Regis on Ile Saint Louis. Touristy but good for people watching since it's at the foot of the bridge connecting the two islands.
Café Louis Phillipe. They shot gossip girl here if you care about that. I tried this place once.
Chez Julien, is not a café actually and across the street from Café Louis Phillipe. Supposed to be good but didn't get a chance to try it.
Le Conti in St Germain, I've been here a few times. This is the first thing I sketched in Paris from Le Buci, across the street.
Le Buci across the street from Le Conti. Been here a few times as well.
Bar du Maché in Saint Germain. Been here a few times, seems like a mix of tourists and Frenchies, nice people watching spot.
La Palette, the coolest of the cafés featured here in my opinion because the tourists are few and the locals and Frenchies are many and it's off a side street in St Germain that doesn't get as much foot traffic, especially tourist foot traffic.
yet another RATP ad via Publicis Conseil by the awesome Japanese Illustrator Tadahiro Usuegi
Did I post this already? I have to get so many new tubes and a new tire on my bike over the summer. Popped two in one day even.
Will always remember the summer of working and watching the Tour de France, wishing I could be out on my bike. What a summer full of friends visiting and picnics and wine and bike rides!
summer canvas and leather shoes by French brand Shmoove
pretty awesome toy car playground thing in Parc Montsouris. I must say the playgrounds in France a pretty sweet.
My one regret. This is still in Paris. The color comp and sketch is all done it was just waiting to get painted on. My bike is still there too.
brought this back and it was awesome. Their normal Chablis is awesome too
Why? The day before I leave my favorite wine store in our neighborhood tells me about their wine tastings they have every Saturday. It would be interesting to see where I would be in another year in Paris after learning more French. I'm already pretty friendly with people and they in turn are friendly with me. This is the guy's explanation of Burgundy grapes and how the grapes get better as you move up in elevation. The decent grapes are on the plains but the Grand Cru grapes are higher up. I thought Burgundy produced mainly red pinot noir grapes but the Chablis region is in Burgundy also and they make loads of white Chardonnay grapes too.
how many times have I done this in the last 5 years? This is the 7th time packing up my whole life and moving to a different country. But this time the loop is getting closed. The good ship Jason Maru is returning to port (Japanese ships always tack on a maru at the end of their ship names because maru means circle so the boat will always safely return back to port, there will be a pic of that coming up in the future from NY).
last sunday market to pick up a special Opinel folding knife. They sell them in the US for 3x the price
Awesome view of the wing, it's almost like what's the point of having this window? I'll take what I can get though. Flew Air Europa to Madrid then New York, had a 3-4 hour layover so I hopped out of their airport to meet my good pal Marco for one last time. When is the next time I'll see him? When is the next time I'll see anyone? I've already seen people from London, Paris, and Beijing. The world is a small place, and when you live in New York you're gonna see your international friends again. Now world traveling is instilled in me and I will be back to these countries again for sure. So for now, all I can say is à la prochaine, mon Paris. I'll be back (and I have to because I had to leave a bunch of my stuff there because it was going to cost 400 euros to ship it via the post office). Ok readers, I'll see you back in New York!
Posted byJason Raish at 1:36 PM 0 comments
United Airlines First Class In-Flight Magazine Rhapsody
Wednesday, October 23, 2013
Double page spread and a spot for the Inaugural issue of Rhapsody, United Airline's in-flight magazine for First Class. The story is about Amazon CEO Jeff Bezos's battle with Ravi Suria, an analyst that wrote bad things about Amazon and almost made them crash back in the early days when they were mainly a book seller.
Posted byJason Raish at 10:00 AM 0 comments
Les Parisiennes - The Parisians - Gérant de Café
Tuesday, October 22, 2013
Another one for my Parisians project. A café "La Contrescarpe" manager stares into the night. Un gérant du café "La contrescarpe" le regard fixé vers la nuit.
Posted byJason Raish at 10:00 AM 0 comments
|sport for the monthly rules guy column in Golf Magazine. In this installation a squirrel grabs a guys ball and starts gnawing on it.
Posted byJason Raish at 10:00 AM 0 comments
|Spot for Investment News about inheriting assets. Inherited assets need to be evalutated because sometimes they aren't as healthy as they once were or are just not a good fit.
Posted byJason Raish at 10:00 AM 0 comments
Arty Webzine Interview in English and French
Monday, October 14, 2013
I was interviewed by this French art website, Arty Webzine in French and English
Posted byJason Raish at 11:32 AM 0 comments
Medicare Open Enrollment Season for Wall Street Journal
Posted byJason Raish at 10:00 AM 0 comments
Subscribe to: Posts (Atom)


text:
Noted thoracic and cardiovascular surgeon and researcher John C. Norman Jr. was born May 11, 1929, in Charleston, West Virginia. His mother Ruth Stephenson Norman was a longtime educator in Kanawha County; his father John Norman Sr. was an architect and structural engineer. After graduating valedictorian from Garnet High School in 1946, John Norman entered Howard University. He later transferred to Harvard and graduated magna cum laude and Phi Beta Kappa in 1950.
John Norman received his M. D. from Harvard Medical School in 1954. Following an internship and residency in New York, he served aboard the aircraft carrier Saratoga in 1957 and 1958 before completing his cardiac surgical training at the University of Michigan. In 1962, Norman was a National Institutes of Health fellow at the University of Birmingham, England.
Norman became an associate professor of surgery at Harvard Medical School and joined the surgical staff at Boston City Hospital in 1964. In addition to his teaching and surgical duties, Norman undertook several medical research projects involving organ transplants. In 1967, he successfully transplanted the spleen of a healthy dog into a hemophiliac beagle. As a result of their research on the liver, Norman and his associates were able to use a pig's liver to keep a patient alive for eighteen days.
It was while in Boston that Norman also began important research into a left ventricular assist device for cardiac patients. This research took him to the prestigious Texas Heart Institute in 1972. For the next several years, Norman worked on development of the first abdominal left ventricular assist device (ALVAD), which could be implanted temporarily in patients suffering cardiac failure after open-heart surgery. Between 1975 and 1978, Norman and institute founder Dr. Denton Cooley implanted a number of these devices. Norman also researched potential power sources and materials for artificial hearts.
Norman later worked as a surgeon at Newark Beth Israel Medical Center in New Jersey before returning to West Virginia in 1986 to serve for several years as chairman of the surgery department at Marshall University School of Medicine. For his work in medical research, Norman was awarded the 1985 Congressional High Technology Award. He previously was honored as the Charleston Gazette-Mail's West Virginian of the Year for 1971.


text:
Latest Update: Holly Michaels
47:10 | 364 Pictures | 306 Screencaps
Holly is all smiles and good vibes. She's obviously a sheltered girl that got everything she ever wanted. We're going to turn her world upside down, better yet we;re gonna turn her upside down and plow her mouth till she starts to gargle. Then she's gonna get her cooter fucked so hard to the point her eyes crossed!
18 U.S.C. 2257 Record-Keeping Requirements Compliance statement.


text:
Rihanna Has to Catch a Flight in New Emporio Armani Clip
Rihanna is the spokesperson for Emporio Armani's jeans and undies, appearing in all the designer's advertising. In the latest clip, the 'We Found Love' singer is snug in her bed, looking fine in her skimpy bra and panties. She has to get up to catch a 6AM flight – information we glean from the message written on the bathroom mirror fog — but would rather stay in bed. Who wouldn't want to grab a few more minutes of shut eye, while spooning with RiRi?
The black and white short film sees the singer waking up, getting ready in the bathroom, grabbing her plane tickets, looking at her beautiful self in the mirror, stretching in bed and then pouring her lithe frame into her skintight Armani jeans and jacket. She tosses her weekender bag over her shoulder and it's off she goes.
What we got out of the clip, message-wise, is that you can get some extra sleep and not worry about your appearance, even when you have a way-too-early flight, since you can throw on your Armani duds and still look good. You can be stunning even at the crack of dawn, thanks to the relative ease of dressing in your Armani lingerie and denim.
Watch the Latest Rihanna Emporio Armani Video