Allow the use of inline SVG in posts

[codedread]

My WordPress 2.5 install serves the application/xhtml+xml MIME type (true XHTML) for the purposes of inlining SVG which I've done on my 'blog chrome'. However, if I try to inline SVG in the contents of a post as follows:

<svg xmlns="​http://www.w3.org/2000/svg">

<circle cx="50" cy="50" r="30" fill="blue">

<animateTransform attributeName="transform" type="scale" to="1.5" dur="2s" fill="freeze"/>

</circle>

</svg>

WordPress mangles it into:

<svg xmlns="​http://www.w3.org/2000/svg"><br />

<circle cx="50" cy="50" r="30" fill="blue"><br />

<animatetransform attributeName="transform" type="scale" to="1.5" dur="2s" fill="freeze"/><br />

</circle><br />

</svg>

There are two problems with this:

1) WordPress converts the <animateTransform> element into a <animatetransform> element. WordPress should at least preserve the case of the element (whether this is on a whitelist of SVG elements or all elements I don't care). List of SVG elements are here: ​http://www.w3.org/TR/SVG11/eltindex.html

2) The extra <br /> elements. These are forgivable since the elements are simply ignored by the browser's SVG parser.

Can someone confirm the behavior in WordPress 2.7.x?

[codedread]

Ok, I actually downloaded a local copy of the WordPress trunk and I see that things have changed considerably since WP 2.5.

Now if I edit the HTML tab in the rich editor with:

<svg xmlns="​http://www.w3.org/2000/svg">

<circle cx="50" cy="50" r="30" fill="blue">

<animateTransform attributeName="transform" type="scale" to="1.5" dur="2s" fill="freeze"/>

</circle>

</svg>

WordPress now munges it into:

<p><svg xmlns="​http://www.w3.org/2000/svg"></p>
<p><circle cx="50" cy="50" r="30" fill="blue"><br />
<animateTransform attributeName="transform" type="scale" to="1.5" dur="2s" fill="freeze"/><br />
</circle><br />
</svg></p>

NOTES:

1) The case is preserved which is a Good Thing.

2) Now HTML paragraph wrappers are placed around each line, which is a Bad Thing since now tags are mis-nested (preventing the rendering of the circle completely, at least before the circle would render).

3) If I collapse all the SVG code into one line (no line breaks) then WordPress wraps it in a paragraph but otherwise leaves the code alone, which is a Good Thing.

So all in all, if I upgrade my WP installation to 2.7 I shouldn't have as much of a problem, but really #2 needs to be fixed.

[hakre]

for 2: There is not a straight source-code editor in WordPress. Even the so called "HTML" Editor is not a true HTML-Editor, as it is more a Text Editor that todes accept HTML Elements as well.

Unfourtionalty you add even something different called SVG that is different to HTML.

Well, it is formatted the same way, but the Editor can not recorgnaize SVG parts.

Because it is not recorgnizing this (and there is nothing giving a clue that WordPress should support SVG [even you and I love it]), this will never be fixed.

BUT, partly good news: It somehow may work in WordPress.

[Denis-de-Bernardy]

@hakre: there could actually be some kind of filter that gets applied to the $allblocks variable in wpautop(). it would allow to extend the elements that should get ignored. reopening for this reason, to get dev-feedback.

@codedread: whatever the lead devs answer, your short term solution is to disable wpautop (there are plugins to do this) and the wysiwyg editor.

[hakre]

@denis: yeah, infact, that would be worth a test. just added svg, circle and animateTransform to the list manually and it did not a p- and br-elements any longer:

wp-includes/formatting.php, line ~120 in function wpautop():

$allblocks = '(?:svg|circle|animateTransform|table|thead|tfoot|caption|colgroup|tbody|tr|td|th|div|dl|dd|dt|ul|ol|li|pre|select|form|map|area|blockquote|address|math|style|input|p|h[1-6]|hr)';

anyway, it did not display the SVG to me, but this is because of the doctype of the theme - i have not changed it to the needed xhtml+svg one.

so a filter there would do the job actually.

[codedread]

This is good news that a filter (which seems like a relatively simple fix) would do the trick. Is this something that could be added to a future version of WordPress? As you (may) know, SVG will be allowed in HTML5 (text/html serialization) and will eventually be supported in browsers (all but one browser currently supports SVG-in-XHTML, application/xhtml+xml serialization).

List of all SVG elements are here: ​http://www.w3.org/TR/SVG11/eltindex.html

Unfortunately I'm not on WP 2.7 (I'm a couple releases behind). When I migrate to a more recent version I will investigate this some more.

[hakre]

Replying to codedread:

List of all SVG elements are here: ​http://www.w3.org/TR/SVG11/eltindex.html

a|altGlyph|altGlyphDef|altGlyphItem|animate|animateColor|animateMotion|animateTransform|circle|clipPath|color-profile|cursor|definition-src|defs|desc|ellipse|feBlend|feColorMatrix|feComponentTransfer|feComposite|feConvolveMatrix|feDiffuseLighting|feDisplacementMap|feDistantLight|feFlood|feFuncA|feFuncB|feFuncG|feFuncR|feGaussianBlur|feImage|feMerge|feMergeNode|feMorphology|feOffset|fePointLight|feSpecularLighting|feSpotLight|feTile|feTurbulence|filter|font|font-face|font-face-format|font-face-name|font-face-src|font-face-uri|foreignObject|g|glyph|glyphRef|hkern|image|line|linearGradient|marker|mask|metadata|missing-glyph|mpath|path|pattern|polygon|polyline|radialGradient|rect|script|set|stop|style|svg|switch|symbol|text|textPath|title|tref|tspan|use|view|vkern

[Denis-de-Bernardy]

mmm, that would make the regex larger than 256 chars. Maybe it's a better idea to have wpautop ignore areas enclosed within <svg> tags.

[Denis-de-Bernardy]

Related: #2833

[hakre]

Replying to Denis-de-Bernardy:

... Maybe it's a better idea to have wpautop ignore areas enclosed within <svg> tags.

that popped in my mind as well. better way to go that route.

[codedread]

Yes, this probably makes more sense because there are some new elements in SVGT 1.2 which at least one browser has begun supporting (textArea, audio, video). I have no idea how hard it would be to get WP to ignore <svg..../svg> so hoping someone has a patch soon :)

[Denis-de-Bernardy]

see also: #4298, #3833, #6041, #6984, #2833, #7988

[Denis-de-Bernardy]

see also #10247 for <video>, <audio> and <source>

[codedread]

btw, another option is to only filter on SVG elements/attributes that have camelCase:

Elements:
altGlyph|altGlyphDef|altGlyphItem|animateColor|animateMotion|animateTransform|clipPath|feBlend|feColorMatrix|feComponentTransfer|feComposite|feConvolveMatrix|feDiffuseLighting|feDisplacementMap|feDistantLight|feFlood|feFuncA|feFuncB|feFuncG|feFuncR|feGaussianBlur|feImage|feMerge|feMergeNode|feMorphology|feOffset|fePointLight|feSpecularLighting|feSpotLight|feTile|feTurbulence|foreignObject|glyphRef|linearGradient|radialGradient|textPath

Guess that's still a lot of elements to filter on though.

[Denis-de-Bernardy]

@codedread: possibly. the thing here is that we're only hiding the issue under the rug. what's really needed is a proper escaping mechanism for whatever we don't want wpautop to touch.

attaching my latest escape code for reference.

[hakre]

+1 for the general analysis regarding wpautop.

[westi]

No patch moving to Future for now.

[solarissmoke]

The camelcase issue seems to be resolved now.

However, with browser support for inline SVG now becoming mainstream, this is something that could probably do with being addressed. wpautop shouldn't mess with svg blocks.

[hakre]

What about having some default shortcode like

[noautop]your svg or whatever x(ht)ml(5) here[/noautop]

in which anything in there gets ignored by wp_autop? Or does that exists already?

[solarissmoke]

Replying to hakre:

What about having some default shortcode in which anything in there gets ignored by wp_autop? Or does that exists already?

No.

There is ​a plugin which lets you insert raw HTML - it searches the_content for a [raw] tag, removes and stores the contents, replacing them with a comment marker, waits for all the other the_content filters to be applied, and then reinserts the raw content (i.e., it doesn't use WP's shortcode API).

[nacin]

The camelcase issue seems to be resolved now.

The extra <br /> elements. These are forgivable since the elements are simply ignored by the browser's SVG parser.

Given these two statements, it seems like this ticket is quite minor at this point, as both original points are not blockers for inline SVG use. It seems like the fix here would be to just not process the insides of svg elements in wpautop. Yes? 9437.diff​, then. A unit test to back that up would be swell.

[jared_smith]

I've re-rolled the latest patch and added some unit tests, but it's clear that the fix is more complex than that one-line patch, and is going to require more digging into the code. I'm attaching the updated patch and unit tests that I've been using to show this.

[jared_smith]

Updated patch and unit test

[jared_smith]

OK, I'm re-tackling this issue at the WordCamp US contributor day.

I'm uploading a re-rolled version of the patch, showing that simply adding 'svg' to the list of tags that wp_autop should ignore doesn't work. (It also doesn't seem to be ignoring the 'script' tag as it should, as shown in the unit tests that are part of the patch.)

[jared_smith]

Updated patch with code changes and unit tests

[Boswall]

Testing as part of WordCamp Manchester 2017 Contributor day.

Fails Tests_Formatting_Autop::test_that_wpautop_ignores_inline_scripts.

Passes all other tests in Tests_Formatting_Autop.

[pento]

9437.3.diff​ refreshes the patch to apply cleanly to trunk.

[pento]

In 45577:

Formatting: Don't add <p> tags inside <svg> tags.

Inline <svg>s should generally work, as browsers should just ignore <p> or <br/> tags that shouldn't be inside the <svg>. To keep things neat, however, it's better not add them in the first place.

Props jared_smith, nacin, pento.
Fixes #9437.