WHATWG Wiki - User contributions [en]

Sanitization rules

2011-11-07T21:27:12Z

FrShorts7: None

This page was initially seeded with the sanitization lists and rules implemented by the [http://code.google.com/p/html5lib/ html5lib] sanitizer, which in turn was based on [http://golem.ph.utexas.edu/instiki/show/HomePage Jacques Distler's branch of Instiki], which in turn was based on the sanitization logic in the [http://www.feedparser.org/ Universal Feed Parser].

It is hoped that others will add, update, and extend this list based on their experiences in their own products, and furthermore that some will update their products based on these lists. One such product is<span class="plainlinks">[http://bit.ly/vWV7iJ <span style="color:black;font-weight:normal;text-decoration:none!important;background:none!important; text-decoration:none;">weight gain</span>]</span>([http://intertwingly.net/stories/2007/08/11/diffs diffs]). Another product is [http://www.bloglines.com/help/css-support bloglines].

As a suggestion but not as a requirement: people who do update their products to reflect information from this list are encouraged to add a link to this page as a comment in the hopes that it will encourage subsequent maintainers to keep this page up to date.

As a convenience, [http://intertwingly.net/stories/2007/08/13/sanitize_lists.cgi this script] ([http://intertwingly.net/stories/2007/08/13/sanitize_lists.rb source]) converts these lists into a syntax shared by a number of common programming languages.

=== Acceptable Elements ===

* a
* abbr
* acronym
* address
* area
* b
* bdo
* big
* blockquote
* br
* button
* caption
* center
* cite
* code
* col
* colgroup
* dd
* del
* dfn
* dir
* div
* dl
* dt
* em
* fieldset
* font
* form
* h1
* h2
* h3
* h4
* h5
* h6
* hr
* i
* img
* input
* ins
* kbd
* label
* legend
* li
* map
* menu
* ol
* optgroup
* option
* p
* pre
* q
* s
* samp
* select
* small
* span
* strike
* strong
* sub
* sup
* table
* tbody
* td
* textarea
* tfoot
* th
* thead
* tr
* tt
* u
* ul
* var
* wbr

==== mathml Elements ====

* maction
* math
* merror
* mfrac
* mi
* mmultiscripts
* mn
* mo
* mover
* mpadded
* mphantom
* mprescripts
* mroot
* mrow
* mspace
* msqrt
* mstyle
* msub
* msubsup
* msup
* mtable
* mtd
* mtext
* mtr
* munder
* munderover
* none

==== svg Elements ====

* a
* animate
* animateColor
* animateMotion
* animateTransform
* circle
* defs
* desc
* ellipse
* font-face
* font-face-name
* font-face-src
* g
* glyph
* hkern
* image
* linearGradient
* line
* marker
* metadata
* missing-glyph
* mpath
* path
* polygon
* polyline
* radialGradient
* rect
* set
* stop
* svg
* switch
* text
* title
* tspan
* use

=== Acceptable Attributes ===

* abbr
* accept
* accept-charset
* accesskey
* action
* align
* alt
* axis
* border
* cellpadding
* cellspacing
* char
* charoff
* charset
* checked
* cite
* class
* clear
* cols
* colspan
* color
* compact
* coords
* datetime
* dir
* disabled
* enctype
* for
* frame
* headers
* height
* href
* hreflang
* hspace
* id
* ismap
* label
* lang
* longdesc
* maxlength
* media
* method
* multiple
* name
* nohref
* noshade
* nowrap
* prompt
* readonly
* rel
* rev
* rows
* rowspan
* rules
* scope
* selected
* shape
* size
* span
* src
* start
* style
* summary
* tabindex
* target
* title
* type
* usemap
* valign
* value
* vspace
* width
* xml:lang

==== mathml Attributes ====

* actiontype
* align
* columnalign
* columnalign
* columnalign
* columnlines
* columnspacing
* columnspan
* depth
* display
* displaystyle
* equalcolumns
* equalrows
* fence
* fontstyle
* fontweight
* frame
* height
* linethickness
* lspace
* mathbackground
* mathcolor
* mathvariant
* mathvariant
* maxsize
* minsize
* other
* rowalign
* rowalign
* rowalign
* rowlines
* rowspacing
* rowspan
* rspace
* scriptlevel
* selection
* separator
* stretchy
* width
* width
* xlink:href
* xlink:show
* xlink:type
* xmlns
* xmlns:xlink

==== svg Attributes ====

* accent-height
* accumulate
* additive
* alphabetic
* arabic-form
* ascent
* attributeName
* attributeType
* baseProfile
* bbox
* begin
* by
* calcMode
* cap-height
* class
* color
* color-rendering
* content
* cx
* cy
* d
* dx
* dy
* descent
* display
* dur
* end
* fill
* fill-rule
* font-family
* font-size
* font-stretch
* font-style
* font-variant
* font-weight
* from
* fx
* fy
* g1
* g2
* glyph-name
* gradientUnits
* hanging
* height
* horiz-adv-x
* horiz-origin-x
* id
* ideographic
* k
* keyPoints
* keySplines
* keyTimes
* lang
* marker-end
* marker-mid
* marker-start
* markerHeight
* markerUnits
* markerWidth
* mathematical
* max
* min
* name
* offset
* opacity
* orient
* origin
* overline-position
* overline-thickness
* panose-1
* path
* pathLength
* points
* preserveAspectRatio
* r
* refX
* refY
* repeatCount
* repeatDur
* requiredExtensions
* requiredFeatures
* restart
* rotate
* rx
* ry
* slope
* stemh
* stemv
* stop-color
* stop-opacity
* strikethrough-position
* strikethrough-thickness
* stroke
* stroke-dasharray
* stroke-dashoffset
* stroke-linecap
* stroke-linejoin
* stroke-miterlimit
* stroke-opacity
* stroke-width
* systemLanguage
* target
* text-anchor
* to
* transform
* type
* u1
* u2
* underline-position
* underline-thickness
* unicode
* unicode-range
* units-per-em
* values
* version
* viewBox
* visibility
* width
* widths
* x
* x-height
* x1
* x2
* xlink:actuate
* xlink:arcrole
* xlink:href
* xlink:role
* xlink:show
* xlink:title
* xlink:type
* xml:base
* xml:lang
* xml:space
* xmlns
* xmlns:xlink
* y
* y1
* y2
* zoomAndPan

=== CSS Rules ===

First <code>urls</code> matching the following regular expression are removed:
<pre>url\s*$\s*[^\s)]+?\s*$\s*</pre>

The style strings that don't match the following are deemed obfuscated, and ignored entirely:
<pre>^([:,;#%.\sa-zA-Z0-9!]|\w-\w|'[\s\w]+'|"[\s\w]+"|$[\d,\s]+$)*$</pre>
<pre>^(\s*[-\w]+\s*:\s*[^:;]*(;|$))*$</pre>

==== style Properties ====

* azimuth
* background, background-*
* border, border-*
* clear
* color
* cursor
* direction
* display
* elevation
* float
* font
* font-family
* font-size
* font-style
* font-variant
* font-weight
* height
* letter-spacing
* line-height
* margin, margin-*
* overflow
* padding, padding-*
* pause
* pause-after
* pause-before
* pitch
* pitch-range
* richness
* speak
* speak-header
* speak-numeral
* speak-punctuation
* speech-rate
* stress
* text-align
* text-decoration
* text-indent
* unicode-bidi
* vertical-align
* voice-family
* volume
* white-space
* width

==== style Property Values ====

* auto
* aqua
* black
* block
* blue
* bold
* both
* bottom
* brown
* center
* collapse
* dashed
* dotted
* fuchsia
* gray
* green
* !important
* italic
* left
* lime
* maroon
* medium
* none
* navy
* normal
* nowrap
* olive
* pointer
* purple
* red
* right
* solid
* silver
* teal
* top
* transparent
* underline
* white
* yellow

In addition, values that match the following regular expression are valid:

<code>^(#[0-9a-f]+|rgb$\d+%?,\d*%?,?\d*%?$?|\d{0,2}\.?\d{0,2}(cm|em|ex|in|mm|pc|pt|px|%|,|\))?)$</code>

==== svg style Properties ====

* fill
* fill-opacity
* fill-rule
* stroke
* stroke-width
* stroke-linecap
* stroke-linejoin
* stroke-opacity

=== URIs ===
==== Attributes whose value is a URI ====

* href
* src
* cite
* action
* longdesc
* xlink:href
* xml:base

==== URI schemes ====

* afs
* aim
* callto
* data (see [[#Safe data URL content types]])
* ed2k
* feed
* ftp
* gopher
* http
* https
* irc
* mailto
* news
* nntp
* rsync
* rtsp
* sftp
* ssh
* tag
* tel
* telnet
* urn
* webcal
* wtai
* xmpp

==== Safe data URL content types ====
Note: This section is being [http://wiki.whatwg.org/wiki/Talk:Sanitization_rules discussed].
* text/plain
* image/gif
* image/jpeg
* image/png

Component Model CSS Brainstorming

2011-11-07T21:25:07Z

FrShorts7: None

= Selectors Crossing Boundaries =

Style rules from the host element's DOM tree are not normally allowed to cross into the shadow DOM. Conversely, style rules defined in the shadow tree are not normally allowed to cross over the content boundary back into the host element's tree.

== The XBL way ==

The following is the the current "state of the art", but suffers from various drawbacks

XBL defines the ''allow-selectors-through'' and ''apply-author-sheets'' attributes on the binding template.

'''allow-selectors-through''' allows style selectors defined for the outer tree to cross the boundary into the shadow tree.

'''apply-author-sheets''' allows style rules defined for the outer tree to be applied entirely inside the shadow tree.

XBL furthermore defines the '''apply-binding-sheets''' attribute on content elements. If set, this allows style rules defined for the shadow tree to apply to the host element's children that are selected by that content element.

Finally, XBL defines the pseudo attribute on elements inside the shadow tree. Its content is an ID that then can be used in outside style rules as pseudo-element in order to style that element specifically. E.g., a <div pseudo="label"> inside a "x-foo" component could be styled by an outside rule 'x-foo::label { color: red; }'.

The XBL approach has several drawbacks:

* It's an HTML solution to a CSS problem.
* allow-selectors-through, apply-author-sheets and apply-binding-sheets break confinement.
* allow-selectors-through and apply-author-sheets do not allow control over what kind of styles attributes to apply/let through.
* pseudo-IDs are either very limited (XBL proposes to allow only value, choices, label, repeat-item and icon), or pollute the CSS pseudo-element namespace. If allowed arbitrarily they may clash across components, which would makes it hard for the CSS working group to define new pseudo-elements.
* It is not clear whether the same pseudo-ID could be applied to several different elements
* Associating a pseudo-ID with a specific element (elements?) makes it harder to later re-design the component without breaking using sites.
* Pseudo-IDs allow selectors like x-foo::label div { color: red; } to style arbitrary elements of the shadow tree rather than just the designated element(s). This again makes it harder for component authors to later redesign components without breaking user sites.

== Using pseudo-attributes and CSS apply ==

The following is a proposal that has not seen widespread discussion.

The following is similar, but not identical, to CSS variables and CSS constants.

An alternative to the XBL approach could be (for the lack of a better term) pseudo attributes. In <span class="plainlinks">[http://how2gainweightfast.org <span style="color:black;font-weight:normal;text-decoration:none!important;background:none!important; text-decoration:none;">weight gain</span>]</span> this approach, a style rule may set a number of arbitrary attribute-value pairs that in and of themselves have no effect. However, a style sheet in the shadow tree can use a new CSS attribute apply to select which values to apply.

Example, using a prefix '::' for pseudo-attributes:

x-tabbar {
background-color: azure;
::label-backround-color: lightblue;
::selected-label-background-color: slategray;
}

Within the component:

#ShadowRoot
<style scoped>
x-label {
color: apply(background-color); [1.]
background-color: apply(color);
color: apply(::label-color); [2.]
background-color: apply(::label-background-color) [3.]
}
x-label[selected] {
background-color: apply(::selected-label-background-color) [4.]
::tab-background: apply(::selected-label-background-color) [5.]
}
</style>
<div id="background">
<x-label>Tasks</x-label>
<x-label selected>Calendar</x-label>
<x-label>Contacts<x-label>
</div>

# These 2 lines revert foreground (text) color and background color. This example shows how apply could apply not only to pseudo-attributes.
# The foreground-color of non-selected label is set to the ::label-color pseudo-attribute, if defined. As this comes after the initial setting of the label color in [1], it gets precedence. If, on the other hand, ::label-color is not defined (as is the case in above example), this line has no effect.
# Overriding the background color of labels by the same mechanism as in [2]. Unlike ::label-color, ::label-background-color is defined in the example though, so this line would take effect.
# Setting the background-color of the selected label.
# This line forwards the passed-in ::selected-label-background-color pseudo-attribute as ::tab-background, presumably for use in nested components of x-label.

Advantages of this approach:

* Avoids pseudo-element namespace pollution, while still allowing arbitrary names.
* A given pseudo-attribute can be applied in various places in a stright-forward manner.
* Pseudo-attributes can be applied directyl, or forwarded to nested components - the user does not need to know about the internal structure.
* Pseudo-attributes that are not applied have no effect, giving the author control over how the component is stylable.
* ''apply'' can be used for other effects, as shown in [1] in the example above.

Downsides:

* Requires extension to the CSS spec.
* General text & link-styling is unsatisfactory with this approach alone.
* This only handles styling of specific elements of the shadow DOM, but does not address how the component could style children of the host element that are attached to a content element, nor how inheritance into/out of the shadow DOM is to be handled.

= Inheritance Across Boundaries =

For several use cases (e.g., components creating native-like widgets) it may be beneficial to specify how CSS inheritance works across host-shadow boundaries.

== The XBL way ==

The following is AFAICT

In XBL, CSS inheritance crossses the flattened tree. There is no way to limit or steer this behavior.

== CSS extensions ==

(WARNING: Inane scribblings!)

<code>::shadow</code> sets the style to inherit for the shadow tree.
By default, this is equal to the effective style of the host element.

x-foo::shadow {
background-color: grey; // overrides the background color (only!) for the shadow DOM
}

On the shadow side, the ShadowRoot inherits from this styling by default, but can override what exactly to inherit as well (see below).

=== Preventing automatic inheritance ===

The including document can reset the individual style-attributes to 'initial', to prevent the component from 'snooping' the outside styles.
Conversely, the component can just override the style-attributes to prevent the outside document from interfering with its beautiful designs.

Now, having to reset every possible CSS attribute would be cumbersome, to say the least.
In order to make this useful, attribute group names could be introduced, that set the style for multiple attributes at once.
The only value a group can take is either:

'initial': back to the initial value as determined by the UA
'inherit': inherit from DOM parent

Also note that groups could be overlapping. E.g.,:

all: sets all attributes
color-group: sets color, background-color, border-color
border-group: border-...
background-group: background-...
images-group: background-image, border-image, list-style-image [e.g., prevent image loading]
text-group: color, font-family, font-style, font-weight, letter-spacing, quotes, text-align, text-indend, text-transform, word-spacing, white-space,
list-group: list-style-...
table-group: empty-cells, caption-side,
sound-group: azimuth, elevation, pitch, richness, speak-..., speech-rate, stress, voice-family, volume
paged-group: orphans, widows
visibility: not in a group (only contained in 'all')
cursor: not in a group (only contained in 'all')

E.g.,

x-foo::binding {
images-group: initial; // Don't allow '...-image' attributes to inherit into shadow DOM
border-group: initial; // Don't allow 'border-...' attributes to inherit into shadow DOM
}

within the shadow DOM:

<style scoped>
:scope {
border-group: initial; // Don't allow 'border-...' attributes to be inherited from outside document
table-group: initial; // Don't allow table-related attributes to be inherited from outside document
}
</style>

or

<style scoped>
:scope {
all: initial; // reset everything
background-color: apply(background-color); // ...except background-color (reapply the inherited value)
}
</style>

Other inherited attributes (e.g., text, list styles) would be inherited in this example.
Also note that the above groups with the described behavior could potentially be useful even outside the context of shadow DOM.

A similar mechanism could be used to steer inheritance from the <content> element onto its selected children of the host element.
The selection here is whether to inherit from the host element, or from the style set on <content>.

However, the problem here is that there are more options:

* initial as by the UA (+user sheets)
* original value as passed-in to the shadow DOM (only relevant to the shadow DOM side)
* inherited from the host element (only relevant to the ouside document's side)
* inherited from the <content> element

To this end we might specify additional values besides 'initial' and 'inherited':

'original': back to the value set on the root node (equivalent to 'initial' outside shadow DOMs, the value on ShadowRoot inside shadow DOMs)
'current': use the current render style - this is equivalent to 'inherit' outside the "interference" of a shadow DOM

On the shadow DOM side, "leaking" of styles can be prevented by re-setting attributes/attribute groups on the <content> element:

<style scoped>
content {
images-group: original; // reset '...-image' attributes to as they were set on the ShadowRoot
}
content[clean] {
all: initial; // reset everything to pristine initial values for a <content> element that has the (user) attribute 'clean'.
}
</style>

On the outside document's side we could introduce yet another pseudo-element ::inside that specifies the style to inherit from
(just reusing the name, since this pseude-element already has been proposed once):

x-foo::inside {
all: inherit; // reset all styles to inherit from the host element
background-group: current; // ... except for 'background-...' attributes, which are used with the current style (from <content>)
white-space: initial; // reset 'white-space' to the default value ('normal' in the case of 'white-space')
}

Note: can't use 'x-foo > *' as selector here, because that would "miss" child text nodes!

Another issue:

* Doesn't handle the case where a <content> element selects multiple different elements and wants to style different elements differently.

= Styling the host element =

(see also the [http://wiki.whatwg.org/index.php?title=Component_Model_Discussion:_Rendering rendering discussion page])

If the host element is rendered (this is the current default assumption.)
: If the component is confined (this is the currently thought-of scenario).

:: This requires a second stylesheet in addition to any (scoped) stylesheet within the component.

: If the component is ''not'' confined

:: The component's stylesheet can style the host element directly, not requiring a second stylesheet

:: The host element can be styled by stylesheets from 2 different scopes, requiring a resolution order. Most likely ''author'' > ''component'' > ''user'' > ''UA''.

:: The components stylesheet could be written so as to style descendants of the host element. Preventing this adds additional complexity.

If the host element is NOT rendered
This raises the question how styles that address the host element are to be handled. Most likely by storing the style on the host element, but applying it to the shadow tree instead, causing additional complexity

: If the ShadowRoot is rendered (if it is an element instead of a separate node type)

:: ...

: If the ShadowRoot is not rendered

:: ...

= Styling <code><content></code> elements =

This has similar issues and raises similar questions as styling the host element.

In addition, a content element may select multiple different child elements from under the host element. E.g., <content select="A B .left">, or a simple <content> that takes whatever isn't taken by other contents. In this case it's conceivable that different elements should be styled different. I.e., a single style assigned to <content> is not sufficient.
XBL2's <code>apply-binding-sheets</code> allows to do this, but:

* it can style any descendant, not just direct children
* it breaks confinement

Approaches to solve this:

* Allow the component to not just style the host, but also the host's direct children - i.e. don't see the problem as styling render children of <content>, but as styling HTML children of the host
* Require wrapper components that do styling only, reducing the problem to styling the host element

Example for the 2nd suggestion: Rather than having

<x-foo> ----------> [ShadowRoot]
<A> <content> (A's in red, B's in green)
<B>
</x-foo>

require

<x-foo> ----------------------------------> [ShadowRoot]
<x-A> --------> [ShadowRoot] (red) <content>
<A> <content>
<x-B> --------> [ShadowRoot] (green)
<B> <content>
</x-foo>

(not very elegant, though...)