Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

HTML tags in image alt text causes formatting issues for the following block #8779

Closed
Clorith opened this issue Aug 9, 2018 · 3 comments · Fixed by #9963
Closed

HTML tags in image alt text causes formatting issues for the following block #8779

Clorith opened this issue Aug 9, 2018 · 3 comments · Fixed by #9963
Labels
[Feature] Blocks Overall functionality of blocks [Type] Bug An existing feature does not function as intended

Comments

@Clorith
Copy link
Member

Clorith commented Aug 9, 2018

When an image block has an alternative text with HTML markup (or anything resembling it) in it, the following block loses its styling.

Replication:

  • Add an image block
  • Add any alt text, with a HTML tag, My<br>text, but My<awesome-tag>text for example
  • Add a paragraph block after it
  • Add colors to the paragraph text

When viewing the page now, you will see that the image is there, but the paragraph block does not have its styles.

Images:

Without markup:
image

With markup:
image

There appears to be something funky going on with escaping values or something here. Sure markup isn't supported in alt texts, but users write strange things and we obviously need to get the escaping/sanitizing right.
@danielbachhuber danielbachhuber added [Type] Bug An existing feature does not function as intended [Feature] Blocks Overall functionality of blocks labels Aug 9, 2018
@davewarfel
Copy link

I experienced the same issue today and wanted to add my test case, especially since it just includes a special character, but I wasn't writing HTML markup.

  • Added an image block (center aligned)
  • Added Users > All Users into Alt Text
  • Upon previewing the page, the following <ol> element was displaying as a <ul> element, and the entire rest of the content was center-aligned. The <figure> element was not closed properly, presumably because of the > sign in the alt text.

Here's how it looked in Chrome Dev Tools:

screenshot 2018-08-12 23 07 10

This was referenced Sep 14, 2018
Closed
Merged
@westonruter
Copy link
Member

I just encountered this issue today myself. I was going to report an issue, but then I found this one, so I'll put my drafted description here.

There seems to be an issue with how Gutenberg serializes HTML attributes that contain tags inside of them (e.g. for developer docs).

For example, given this post_content:

<!-- wp:list -->
<ul><li>The result of the parsed styles is then <strong>minified, serialized, and stored in a <a rel="noreferrer noopener" aria-label="Collects inline styles and outputs them in the <amp-custom> stylesheet. &nbsp;
Fetch all external stylesheets (except for whitelisted fonts), collect all style elements in the document, and create style rules from inline style attributes
Parse/process the collected styles to ensure that:
There are no invalid at-rules and no disallowed CSS properties
Relative paths for background images are absolute
Any !important qualifier is transformed into style rules with higher-specificity selectors
If the result is larger than AMP’s 50KB limit, as CSS tree-shaking algorithm is applied
If after tree-shaking there is still more than 50KB, then any stylesheet that takes the total over 50KB will be omitted.
The result of the parsed styles is then minified, serialized, and stored in a transient, which are a simple and standardized way in WordPress for storing cached data in the database, temporarily by giving it a custom name and a timeframe after which it will expire and be deleted
Construct the&nbsp;style[custom]&nbsp;element to be added to the <head> (opens in a new tab)" href="https://codex.wordpress.org/Transients_API" target="_blank">transient</a></strong>, which are a simple and standardized way in WordPress for storing cached data in the database, temporarily by giving it a custom name and a timeframe after which it will expire and be deleted</li></ul>
<!-- /wp:list -->

The aria-label attribute contains a reference to <head>. Note that even though I enter &lt;head&gt; into the attribute value, when I click out of the code editor in Gutenberg it gets converted into <head>.

In visual editing mode, the block looks fine:

image

But as soon as I look at the post on the frontend, it is clear that all is not fine:

image

In looking at the HTML rendered on the frontend, it seems that Gutenberg's HTML serializer fails by continuing to encode attribute double quotes as &#8221; when it should have left them alone:

image

Expected behavior

The edit function and save function should serialize HTML consistently.

Tested against master at 46f789a, with WordPress on 4.9 branch.

@aduth aduth mentioned this issue Dec 11, 2018
Closed
@magadanskiuchen
Copy link

I've experienced the same issue. I've tried describing some hierarchy in the "alt" textarea for an image entering the ">" character, which broke my layout.

This should get escaped as an html entity when added to the markup.

@ellatrix ellatrix mentioned this issue Mar 7, 2019
Closed
This was referenced May 13, 2019
Closed
Open
@ShedFlu ShedFlu mentioned this issue Nov 28, 2023
Open
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
[Feature] Blocks Overall functionality of blocks [Type] Bug An existing feature does not function as intended
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Add greater than symbol to attribute escaping WordPress/gutenberg
5 participants
@danielbachhuber @westonruter @Clorith @magadanskiuchen @davewarfel