Since we can't directly alter many of the core functions from html5_tools this is mostly a placeholder issue until core is patched.

The problem: several core functions hard code HTML tags, protocols and attributes which are then used to filter content, often as a security precaution. Those functions don't currently allow HTML5.

Example problem that occurs as a result: In Drupal-7, Views 3 (also in d6 and views 2) you can chose to 'rewrite the output' of a field, adding your own markup and using tokens. However the the contents of the textarea where you enter code are filtered through a core function filter_xss_admin() which strips out any tags not on the allowed list. So it strips out HTML5 tags. Silently. The workaround is to put your markup in a views tpl file instead.

There are numerous places in core and in many contrib modules that use core sanitization functions, and having full support for HTML5 means updating those functions to allow HTML5. There's a list of sanitization functions at http://api.drupal.org/api/drupal/includes--common.inc/group/sanitization/7
Fortunately only two appear to hard code anything that will need changing

Function Problem Issue
filter_xss() hard codes:
a, em, strong, cite, blockquote, code, ul, ol, li, dl, dt, dd
but no HTML5 tags
None yet (1)
filter_xss_admin() hard codes:
a, abbr, acronym, address, b, bdo, big, blockquote, br, caption, cite, code, col, colgroup, dd, del, dfn, div, dl, dt, em, h1, h2, h3, h4, h5, h6, hr, i, img, ins, kbd, li, ol, p, pre, q, samp, small, span, strong, sub, sup, table, tbody, td, tfoot, th, thead, tr, tt, ul, var
but no HTML5 tags
#732992

drupal_strip_dangerous_protocols() Already uses a configurable variable $allowed_protocols so can be overridden if necessary. As @davereid suggests these two filter_xss functions should also be configurable so that we can override the allowed tags via html5_tools.

(1) We need to decide what, if any HTML5 tags would be useful to add to filter_xss().

Comments

jensimmons’s picture

Issue tags: +html5

subscribe.

Yes, we don't want Drupal sanitizing away people's ability to do HTML5. Drupal core must allow the new stuff to get through the security checks.

adrinux’s picture

Actually they can probably both be dealt with in the same patch, on issue http://drupal.org/node/732992 attempting a first patch...but will wait to do it via git tomorrow =D

adrinux’s picture

ericduran’s picture

Status: Active » Closed (won't fix)

Not really much we could do.