ISSUE-3: conformance of element level style attributes

style-attribute

conformance of element level style attributes

State:
CLOSED
Product:
HTML 5 spec
Raised by:
Shawn Medero
Opened on:
2007-11-05
Description:
Originally posted by Dannii Willis on the ESW HTML Issues wiki: http://esw.w3.org/topic/HTML/StyleAttribute

## Research

### Use Cases

#### WYSIWYG editors
WYSIWYG editors need to save the styles the user decided to choose, without any information about the intentions for such styling.

#### Non-WYSIWYG editors
Non-WYSIWYG editors (forums, blogs and wikis) offer only a limited set of HTML features to users. But often users want to use arbitrary styles, that can't be predefined by application.

#### Computer-generated HTML versions of other document formats
Programs that convert documents in other formats to HTML often don't have the semantical information about the meaning of styles in the convertable document. While <style scoped> support *should* work for these applications, it would generate a lot of additional and unecessary markup compared to element level style attributes.

#### Styling of external material (e.g. advertisements)
External content providers need to ensure, that the styles will remain the same in the context of any other page.

#### Very specific small adjustments to a page
If you only want to adjust one single place in one single page, adding style element and new class or id is too complicated.

#### Serialization of DOM
When serializing DOM the dynamically set styles need also to be serialized.

#### HTML embedded to other applications
Transmission of fragments of HTML with their styles preserved.

#### Debugging & Rapid Prototyping
There is a need for a standards-based way of settings styles for individual elements.

#### Graphs and diagrams
In dynamically created graphs and diagrams many elements need really varying styling.

### Misc

According to the Google Web Authoring Stats the style attribute is used on ~ 13.5% of <a> elements, 10.9% of <p> elements and 10.6% of <img> elements. (http://code.google.com/webstats/)

## Proposals

(SPM: Where possible I've tried match the pros and cons of each proposal to a corresponding HTML Design Principle.)

### The style attribute

Pros:
* Markup is short and concise in simple cases ("Avoid Needless Complexity")
* Part of the HTML4 spec - well understood by authors ("Well-defined Behavior")
* Works in existing UAs ("Support Existing Content")

Cons:
* Does not allow media-specific styles ("Media Independence")
* Embeds presentationl markup ("Separation of Concerns")
* May encourage authors to use inline style where not appropriate

### Style attribute with extended syntax

Pros:
* Markup is short and concise in simple cases ("Avoid Needless Complexity")
* Is a CSS WG working draft ("Do not Reinvent the Wheel")
* Partly works in existing UAs
* Allows per-media styles ("Media Independence")

Cons:
* May encourage authors to use inline style where not appropriate

### <font style=""> with WYSIWYG signature

Pros:
* Works in existing UAs
* May encourage authors to use style attribute less often

Cons:
* Does not allow styling of replaced content (e.g. size of image, but there are width= and height= attributes already) or non-inherited style properties (e.g. borders)
* Markup is more verbose than just using the style attribute directly ("Avoid Needless Complexity")
* Promotes presentational information to the level of an element (negative impact on source readability?)
* Does not allow media-specific styles (probably not a needed feature, considering the WYSIWYG signature) ("Media Independence")
* Not better for WYSIWYG editors than global style="" attribute ("Solve Real Problems")
* WYSIWYG signature might become the new Transitional doctype
* Does not resolve: External material, Small adjustments, Serialization of DOM, embedded HTML, Debugging, Graphs and diagrams. (Assuming, that WYSIWYG signature applies to wider range of applications, not just WYSIWYG editors.)

### <style scoped>

Pros:
* Allows per-media styles ("Media Independence")

Cons:
* Incorrect rendering in existig UAs
* Markup is verbose in simple (one element) case ("Avoid Needless Complexity")
* Does not allow styling of void elements
* Does not resolve: Serialization of DOM, Debugging.


### <localstyle> element

Pros:
* Does not render incorrect in existing UAs
* Allows per-media styles ("Media Independence")

Cons:
* Markup is verbose in simple (one element) case ("Avoid Needless Complexity")
* Does not allow styling of void elements
* Stylesheet content has to be hidden to existing UAs using comment marks and/or CDATA marks (when in XML serialization)
* Does not resolve: Serialization of DOM, Debugging.

### <style> in <head> + selectors

Pros:
* Works in existing UAs
* Allows per-media styles ("Media Independence")

Cons:
* Requires access to the <head>
* Markup is verbose in single element case ("Avoid Needless Complexity")
* Does not resolve: External material, Serialization of DOM, Embedding, Debugging.

### Individual presentation-oriented attributes

Pros:
* Works in existing UAs
* Possible to limit attributes to those which make sense in the context of a specific element

Cons:
* No way to reuse information across multiple elements ("Separation of Concerns")
* Requires tight coupling of style and HTML; no possibility to use extra CSS properties as they are introduced without updating HTML ("Separation of Concerns")
* Many attributes needed on a single element; reduces source readability, increases bandwith ("Avoid Needless Complexity")
* No way of providing media-specific style ("Media Independence")

## Email, IRC, other Links

(Emails highlighted have come straight from the wiki and I didn't take the time to extract any other discussions. The ones cited on the wiki gave an acceptable entry point to many views surroudning this topic and I've decided to stick with them.)

* Many raised concerns with the WYSIWYG signature when the issue was discussed this summer but the current HTML 5 draft suggest that the entire section will be dropped - http://www.whatwg.org/specs/web-apps/current-work/multipage/section-presentational.html#presentational

* Ian Hickson notes that this issue is far from decided on IRC in March 2007 - http://krijnhoetmer.nl/irc-logs/html-wg/20070330#l-991

* Syntax of CSS rules in HTML's "style" attribute (W3C Working Draft) - http://www.w3.org/TR/2002/WD-css-style-attr-20020515

* The idea of making style="" only apply to <font> was that we could attach the stigma of <font> to style="" - http://krijnhoetmer.nl/irc-logs/whatwg/20070503#l-494

* About Dropping the style attribute - http://lists.w3.org/Archives/Public/public-html/2007Jun/0616.html
* Re: http://lists.w3.org/Archives/Public/public-html/2007Jun/0624.html
* Re: http://lists.w3.org/Archives/Public/public-html/2007Jun/0774.html
* Re: http://lists.w3.org/Archives/Public/public-html/2007Jun/0753.html
* Re: http://lists.w3.org/Archives/Public/public-html/2007Jun/0816.html

* Why the style attribute shouldn't be abandoned - http://lists.w3.org/Archives/Public/public-html/2007Jun/1043.html
* re: http://lists.w3.org/Archives/Public/public-html/2007Jun/1062.html
* re: http://lists.w3.org/Archives/Public/public-html/2007Jun/1078.html

* Proposal for a new element instead of <style scoped> - http://lists.w3.org/Archives/Public/public-html/2007Jul/0232.html

* [whatwg] style='' on every element - http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2007-May/011181.html

* Via the wiki: Most stylesheets included with non-scoped <style> or with <link> do not set media-scoped styles. @media rules are rare, and <link rel="stylesheet"> rarely specifies a media attribute. Given this, there is little evidence that authors will be more likely to scope their styles to particular media just because they have a mechanism that allows it. And indeed, for many styles, doing so is not needed to achieve media-independent styling. For instance, property definitions like "font-weight: bold" or "font-size: 2em" don't really need to be set differently between different visual media and are irrelevant to non-visual media. Including both style="" and <style scoped> would allow a convenient way to set local styles that degrades gracefully, as well as a less backwards compatible but more powerful mechanism that allows media selection and full rules with selectors. - Maciej Stachowiak, Mon, 2 Jul 2007 - http://esw.w3.org/topic/HTML/StyleAttribute#discuss-style-attribute-has-no-media
Related Actions Items:
No related actions
Related emails:
  1. RE: {minutes} HTML WG telecon 2011-03-03: Issues, Decisions, Task Force Reports, and Other Business (from adrianba@microsoft.com on 2011-03-03)
  2. [Bug 10692] New: Fix coercion to Infoset for HTML5 to correctly preserve xmlns attributes (from bugzilla@jessica.w3.org on 2010-09-23)
  3. {minutes} HTML WG issue-tracking telcon 2008-06-26 (from mike@w3.org on 2008-07-09)
  4. {minutes} HTML WG issue-tracking telcon 2008-04-10/11 (from mike@w3.org on 2008-04-11)
  5. Re: style attribute, only on font? (from jonbarnett@gmail.com on 2007-11-28)
  6. ISSUE-3 (style-attribute): conformance of element level style attributes [HTML 5 spec] (from sysbot+tracker@w3.org on 2007-11-05)

Related notes:

Resolved in 2nd Working Draft by making the style attribute global (except on <font>): http://www.w3.org/TR/2008/NOTE-html5-pubnotes-20080610/#global

Shawn Medero, 12 Jun 2008, 17:28:17

needs test case

Dan Connolly, 13 Jun 2008, 18:12:37

discussed this on this week's telcon, seems that this issue can be dropped now that the style attribute is global

Michael[tm] Smith, 26 Jun 2008, 16:40:19

Accepted resolution of style allowed globally. If proposals for scoped style are to go forward, they should be listed in a separate issue.

Chris Wilson, 26 Jun 2008, 16:42:23

Changelog:

Created issue 'conformance of element level style attributes' nickname style-attribute owned by Shawn Medero on product HTML 5 spec, description 'Originally posted by Dannii Willis on the ESW HTML Issues wiki: http://esw.w3.org/topic/HTML/StyleAttribute

## Research

### Use Cases

#### WYSIWYG editors
WYSIWYG editors need to save the styles the user decided to choose, without any information about the intentions for such styling.

#### Non-WYSIWYG editors
Non-WYSIWYG editors (forums, blogs and wikis) offer only a limited set of HTML features to users. But often users want to use arbitrary styles, that can't be predefined by application.

#### Computer-generated HTML versions of other document formats
Programs that convert documents in other formats to HTML often don't have the semantical information about the meaning of styles in the convertable document. While <style scoped> support *should* work for these applications, it would generate a lot of additional and unecessary markup compared to element level style attributes.

#### Styling of external material (e.g. advertisements)
External content providers need to ensure, that the styles will remain the same in the context of any other page.

#### Very specific small adjustments to a page
If you only want to adjust one single place in one single page, adding style element and new class or id is too complicated.

#### Serialization of DOM
When serializing DOM the dynamically set styles need also to be serialized.

#### HTML embedded to other applications
Transmission of fragments of HTML with their styles preserved.

#### Debugging & Rapid Prototyping
There is a need for a standards-based way of settings styles for individual elements.

#### Graphs and diagrams
In dynamically created graphs and diagrams many elements need really varying styling.

### Misc

According to the Google Web Authoring Stats the style attribute is used on ~ 13.5% of <a> elements, 10.9% of <p> elements and 10.6% of <img> elements. (http://code.google.com/webstats/)

## Proposals

(SPM: Where possible I've tried match the pros and cons of each proposal to a corresponding HTML Design Principle.)

### The style attribute

Pros:
* Markup is short and concise in simple cases ("Avoid Needless Complexity")
* Part of the HTML4 spec - well understood by authors ("Well-defined Behavior")
* Works in existing UAs ("Support Existing Content")

Cons:
* Does not allow media-specific styles ("Media Independence")
* Embeds presentationl markup ("Separation of Concerns")
* May encourage authors to use inline style where not appropriate

### Style attribute with extended syntax

Pros:
* Markup is short and concise in simple cases ("Avoid Needless Complexity")
* Is a CSS WG working draft ("Do not Reinvent the Wheel")
* Partly works in existing UAs
* Allows per-media styles ("Media Independence")

Cons:
* May encourage authors to use inline style where not appropriate

### <font style=""> with WYSIWYG signature

Pros:
* Works in existing UAs
* May encourage authors to use style attribute less often

Cons:
* Does not allow styling of replaced content (e.g. size of image, but there are width= and height= attributes already) or non-inherited style properties (e.g. borders)
* Markup is more verbose than just using the style attribute directly ("Avoid Needless Complexity")
* Promotes presentational information to the level of an element (negative impact on source readability?)
* Does not allow media-specific styles (probably not a needed feature, considering the WYSIWYG signature) ("Media Independence")
* Not better for WYSIWYG editors than global style="" attribute ("Solve Real Problems")
* WYSIWYG signature might become the new Transitional doctype
* Does not resolve: External material, Small adjustments, Serialization of DOM, embedded HTML, Debugging, Graphs and diagrams. (Assuming, that WYSIWYG signature applies to wider range of applications, not just WYSIWYG editors.)

### <style scoped>

Pros:
* Allows per-media styles ("Media Independence")

Cons:
* Incorrect rendering in existig UAs
* Markup is verbose in simple (one element) case ("Avoid Needless Complexity")
* Does not allow styling of void elements
* Does not resolve: Serialization of DOM, Debugging.

### <localstyle> element

Pros:
* Does not render incorrect in existing UAs
* Allows per-media styles ("Media Independence")

Cons:
* Markup is verbose in simple (one element) case ("Avoid Needless Complexity")
* Does not allow styling of void elements
* Stylesheet content has to be hidden to existing UAs using comment marks and/or CDATA marks (when in XML serialization)
* Does not resolve: Serialization of DOM, Debugging.

### <style> in <head> + selectors

Pros:
* Works in existing UAs
* Allows per-media styles ("Media Independence")

Cons:
* Requires access to the <head>
* Markup is verbose in single element case ("Avoid Needless Complexity")
* Does not resolve: External material, Serialization of DOM, Embedding, Debugging.

### Individual presentation-oriented attributes

Pros:
* Works in existing UAs
* Possible to limit attributes to those which make sense in the context of a specific element

Cons:
* No way to reuse information across multiple elements ("Separation of Concerns")
* Requires tight coupling of style and HTML; no possibility to use extra CSS properties as they are introduced without updating HTML ("Separation of Concerns")
* Many attributes needed on a single element; reduces source readability, increases bandwith ("Avoid Needless Complexity")
* No way of providing media-specific style ("Media Independence")

## Email, IRC, other Links

(Emails highlighted have come straight from the wiki and I didn't take the time to extract any other discussions. The ones cited on the wiki gave an acceptable entry point to many views surroudning this topic and I've decided to stick with them.)

* Many raised concerns with the WYSIWYG signature when the issue was discussed this summer but the current HTML 5 draft suggest that the entire section will be dropped - http://www.whatwg.org/specs/web-apps/current-work/multipage/section-presentational.html#presentational

* Ian Hickson notes that this issue is far from decided on IRC in March 2007 - http://krijnhoetmer.nl/irc-logs/html-wg/20070330#l-991

* Syntax of CSS rules in HTML's "style" attribute (W3C Working Draft) - http://www.w3.org/TR/2002/WD-css-style-attr-20020515

* The idea of making style="" only apply to <font> was that we could attach the stigma of <font> to style="" - http://krijnhoetmer.nl/irc-logs/whatwg/20070503#l-494

* About Dropping the style attribute - http://lists.w3.org/Archives/Public/public-html/2007Jun/0616.html
* Re: http://lists.w3.org/Archives/Public/public-html/2007Jun/0624.html
* Re: http://lists.w3.org/Archives/Public/public-html/2007Jun/0774.html
* Re: http://lists.w3.org/Archives/Public/public-html/2007Jun/0753.html
* Re: http://lists.w3.org/Archives/Public/public-html/2007Jun/0816.html

* Why the style attribute shouldn't be abandoned - http://lists.w3.org/Archives/Public/public-html/2007Jun/1043.html
* re: http://lists.w3.org/Archives/Public/public-html/2007Jun/1062.html
* re: http://lists.w3.org/Archives/Public/public-html/2007Jun/1078.html

* Proposal for a new element instead of <style scoped> - http://lists.w3.org/Archives/Public/public-html/2007Jul/0232.html

* [whatwg] style='' on every element - http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2007-May/011181.html

* Via the wiki: Most stylesheets included with non-scoped <style> or with <link> do not set media-scoped styles. @media rules are rare, and <link rel="stylesheet"> rarely specifies a media attribute. Given this, there is little evidence that authors will be more likely to scope their styles to particular media just because they have a mechanism that allows it. And indeed, for many styles, doing so is not needed to achieve media-independent styling. For instance, property definitions like "font-weight: bold" or "font-size: 2em" don't really need to be set differently between different visual media and are irrelevant to non-visual media. Including both style="" and <style scoped> would allow a convenient way to set local styles that degrades gracefully, as well as a less backwards compatible but more powerful mechanism that allows media selection and full rules with selectors. - Maciej Stachowiak, Mon, 2 Jul 2007 - http://esw.w3.org/topic/HTML/StyleAttribute#discuss-style-attribute-has-no-media
' non-public

Shawn Medero, 5 Nov 2007, 02:07:08

Status changed to 'raised'

10 Apr 2008, 22:30:07

Description changed to 'Originally posted by Dannii Willis on the ESW HTML Issues wiki: http://esw.w3.org/topic/HTML/StyleAttribute

## Research

### Use Cases

#### WYSIWYG editors
WYSIWYG editors need to save the styles the user decided to choose, without any information about the intentions for such styling.

#### Non-WYSIWYG editors
Non-WYSIWYG editors (forums, blogs and wikis) offer only a limited set of HTML features to users. But often users want to use arbitrary styles, that can't be predefined by application.

#### Computer-generated HTML versions of other document formats
Programs that convert documents in other formats to HTML often don't have the semantical information about the meaning of styles in the convertable document. While <style scoped> support *should* work for these applications, it would generate a lot of additional and unecessary markup compared to element level style attributes.

#### Styling of external material (e.g. advertisements)
External content providers need to ensure, that the styles will remain the same in the context of any other page.

#### Very specific small adjustments to a page
If you only want to adjust one single place in one single page, adding style element and new class or id is too complicated.

#### Serialization of DOM
When serializing DOM the dynamically set styles need also to be serialized.

#### HTML embedded to other applications
Transmission of fragments of HTML with their styles preserved.

#### Debugging & Rapid Prototyping
There is a need for a standards-based way of settings styles for individual elements.

#### Graphs and diagrams
In dynamically created graphs and diagrams many elements need really varying styling.

### Misc

According to the Google Web Authoring Stats the style attribute is used on ~ 13.5% of <a> elements, 10.9% of <p> elements and 10.6% of <img> elements. (http://code.google.com/webstats/)

## Proposals

(SPM: Where possible I've tried match the pros and cons of each proposal to a corresponding HTML Design Principle.)

### The style attribute

Pros:
* Markup is short and concise in simple cases ("Avoid Needless Complexity")
* Part of the HTML4 spec - well understood by authors ("Well-defined Behavior")
* Works in existing UAs ("Support Existing Content")

Cons:
* Does not allow media-specific styles ("Media Independence")
* Embeds presentationl markup ("Separation of Concerns")
* May encourage authors to use inline style where not appropriate

### Style attribute with extended syntax

Pros:
* Markup is short and concise in simple cases ("Avoid Needless Complexity")
* Is a CSS WG working draft ("Do not Reinvent the Wheel")
* Partly works in existing UAs
* Allows per-media styles ("Media Independence")

Cons:
* May encourage authors to use inline style where not appropriate

### <font style=""> with WYSIWYG signature

Pros:
* Works in existing UAs
* May encourage authors to use style attribute less often

Cons:
* Does not allow styling of replaced content (e.g. size of image, but there are width= and height= attributes already) or non-inherited style properties (e.g. borders)
* Markup is more verbose than just using the style attribute directly ("Avoid Needless Complexity")
* Promotes presentational information to the level of an element (negative impact on source readability?)
* Does not allow media-specific styles (probably not a needed feature, considering the WYSIWYG signature) ("Media Independence")
* Not better for WYSIWYG editors than global style="" attribute ("Solve Real Problems")
* WYSIWYG signature might become the new Transitional doctype
* Does not resolve: External material, Small adjustments, Serialization of DOM, embedded HTML, Debugging, Graphs and diagrams. (Assuming, that WYSIWYG signature applies to wider range of applications, not just WYSIWYG editors.)

### <style scoped>

Pros:
* Allows per-media styles ("Media Independence")

Cons:
* Incorrect rendering in existig UAs
* Markup is verbose in simple (one element) case ("Avoid Needless Complexity")
* Does not allow styling of void elements
* Does not resolve: Serialization of DOM, Debugging.


### <localstyle> element

Pros:
* Does not render incorrect in existing UAs
* Allows per-media styles ("Media Independence")

Cons:
* Markup is verbose in simple (one element) case ("Avoid Needless Complexity")
* Does not allow styling of void elements
* Stylesheet content has to be hidden to existing UAs using comment marks and/or CDATA marks (when in XML serialization)
* Does not resolve: Serialization of DOM, Debugging.

### <style> in <head> + selectors

Pros:
* Works in existing UAs
* Allows per-media styles ("Media Independence")

Cons:
* Requires access to the <head>
* Markup is verbose in single element case ("Avoid Needless Complexity")
* Does not resolve: External material, Serialization of DOM, Embedding, Debugging.

### Individual presentation-oriented attributes

Pros:
* Works in existing UAs
* Possible to limit attributes to those which make sense in the context of a specific element

Cons:
* No way to reuse information across multiple elements ("Separation of Concerns")
* Requires tight coupling of style and HTML; no possibility to use extra CSS properties as they are introduced without updating HTML ("Separation of Concerns")
* Many attributes needed on a single element; reduces source readability, increases bandwith ("Avoid Needless Complexity")
* No way of providing media-specific style ("Media Independence")

## Email, IRC, other Links

(Emails highlighted have come straight from the wiki and I didn't take the time to extract any other discussions. The ones cited on the wiki gave an acceptable entry point to many views surroudning this topic and I've decided to stick with them.)

* Many raised concerns with the WYSIWYG signature when the issue was discussed this summer but the current HTML 5 draft suggest that the entire section will be dropped - http://www.whatwg.org/specs/web-apps/current-work/multipage/section-presentational.html#presentational

* Ian Hickson notes that this issue is far from decided on IRC in March 2007 - http://krijnhoetmer.nl/irc-logs/html-wg/20070330#l-991

* Syntax of CSS rules in HTML's "style" attribute (W3C Working Draft) - http://www.w3.org/TR/2002/WD-css-style-attr-20020515

* The idea of making style="" only apply to <font> was that we could attach the stigma of <font> to style="" - http://krijnhoetmer.nl/irc-logs/whatwg/20070503#l-494

* About Dropping the style attribute - http://lists.w3.org/Archives/Public/public-html/2007Jun/0616.html
* Re: http://lists.w3.org/Archives/Public/public-html/2007Jun/0624.html
* Re: http://lists.w3.org/Archives/Public/public-html/2007Jun/0774.html
* Re: http://lists.w3.org/Archives/Public/public-html/2007Jun/0753.html
* Re: http://lists.w3.org/Archives/Public/public-html/2007Jun/0816.html

* Why the style attribute shouldn't be abandoned - http://lists.w3.org/Archives/Public/public-html/2007Jun/1043.html
* re: http://lists.w3.org/Archives/Public/public-html/2007Jun/1062.html
* re: http://lists.w3.org/Archives/Public/public-html/2007Jun/1078.html

* Proposal for a new element instead of <style scoped> - http://lists.w3.org/Archives/Public/public-html/2007Jul/0232.html

* [whatwg] style='' on every element - http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2007-May/011181.html

* Via the wiki: Most stylesheets included with non-scoped <style> or with <link> do not set media-scoped styles. @media rules are rare, and <link rel="stylesheet"> rarely specifies a media attribute. Given this, there is little evidence that authors will be more likely to scope their styles to particular media just because they have a mechanism that allows it. And indeed, for many styles, doing so is not needed to achieve media-independent styling. For instance, property definitions like "font-weight: bold" or "font-size: 2em" don't really need to be set differently between different visual media and are irrelevant to non-visual media. Including both style="" and <style scoped> would allow a convenient way to set local styles that degrades gracefully, as well as a less backwards compatible but more powerful mechanism that allows media selection and full rules with selectors. - Maciej Stachowiak, Mon, 2 Jul 2007 - http://esw.w3.org/topic/HTML/StyleAttribute#discuss-style-attribute-has-no-media
'

12 Jun 2008, 17:28:16

Status changed to 'closed'

12 Jun 2008, 17:28:17

Status changed to 'pending review'

Dan Connolly, 13 Jun 2008, 18:12:37

Status changed to 'closed'

Chris Wilson, 26 Jun 2008, 16:42:23


Paul Cotton <Paul.Cotton@microsoft.com>, Maciej Stachowiak <mjs@apple.com>, Sam Ruby <rubys@intertwingly.net>, Chairs, Michael[tm] Smith <mike@w3.org>, Staff Contact
Tracker: documentation, (configuration for this group), originally developed by Dean Jackson, is developed and maintained by the Systems Team <w3t-sys@w3.org>.
$Id: index.php,v 1.323 2013-12-19 14:47:09 dom Exp $