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.

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

Add support for raw HTML nodes. #11

Merged
merged 2 commits into from Jun 17, 2015

Conversation

Projects
None yet
3 participants
@tomdale
Collaborator

tomdale commented Jun 15, 2015

In XML, CDATA nodes can be used to include portions of unescaped text. HTML does not have any facility for this because it is typically not required.

However, in the case of SimpleDOM (and specifically Ember’s FastBoot), the DOM tree is just an intermediate representation of the final serialized HTML output. In some cases, users may want to put snippets of unescaped HTML into that DOM tree for delivery to the user.

One option is to parse the unescaped HTML provided by the user and turn that into DOM nodes in the intermediate DOM tree. However, this incurs a performance cost for little gain, as we parse the provided HTML, store it as a tree of nodes, then reserialize that tree immediately afterwards when the entire document is being serialized.

By providing a CDATA mechanism, we can allow consumers of SimpleDOM to “stash” unparsed HTML in the tree, which is then re-emitted without parsing when that tree is serialized.

Add support for CDATA nodes.
In XML, CDATA nodes can be used to include portions of unescaped text.
HTML does not have any facility for this because it is typically not
required.

However, in the case of SimpleDOM (and specifically Ember’s FastBoot),
the DOM tree is just an intermediate representation of the final
serialized HTML output. In some cases, users may want to put snippets
of unescaped HTML into that DOM tree for delivery to the user.

One option is to parse the unescaped HTML provided by the user and turn
that into DOM nodes in the intermediate DOM tree. However, this incurs
a performance cost for little gain, as we parse the provided HTML,
store it as a tree of nodes, then reserialize that tree immediately
afterwards when the entire document is being serialized.

By providing a CDATA mechanism, we can allow consumers of SimpleDOM to
“stash” unparsed HTML in the tree, which is then re-emitted without
parsing when that tree is serialized.
@tomdale

This comment has been minimized.

Show comment
Hide comment
@tomdale

tomdale Jun 17, 2015

Collaborator

I've reconsidered whether trying to use the CDATA API is a good idea. For now, let's create a custom extension that avoids the uncanny valley problem and makes the use case more explicit. This is also less likely to conflict with potential future use cases that want to legitimately use CDATA (although I doubt that day will ever come to pass).

Collaborator

tomdale commented Jun 17, 2015

I've reconsidered whether trying to use the CDATA API is a good idea. For now, let's create a custom extension that avoids the uncanny valley problem and makes the use case more explicit. This is also less likely to conflict with potential future use cases that want to legitimately use CDATA (although I doubt that day will ever come to pass).

@tomdale tomdale changed the title from Add support for CDATA nodes. to Add support for raw HTML nodes. Jun 17, 2015

@tomdale

This comment has been minimized.

Show comment
Hide comment
@tomdale

tomdale Jun 17, 2015

Collaborator

I changed the name of the PR to reflect the above change. ⬆️

Collaborator

tomdale commented Jun 17, 2015

I changed the name of the PR to reflect the above change. ⬆️

@krisselden

This comment has been minimized.

Show comment
Hide comment
@krisselden

krisselden Jun 17, 2015

Collaborator

Can you change the remaining cdata bits to raw?

Collaborator

krisselden commented Jun 17, 2015

Can you change the remaining cdata bits to raw?

@krisselden

This comment has been minimized.

Show comment
Hide comment
@krisselden

krisselden Jun 17, 2015

Collaborator

Otherwise looks good to me

Collaborator

krisselden commented Jun 17, 2015

Otherwise looks good to me

@tomdale

This comment has been minimized.

Show comment
Hide comment
@tomdale

tomdale Jun 17, 2015

Collaborator

@krisselden I force-pushed a commit that should remove all references to CDATA, did I miss any?

Collaborator

tomdale commented Jun 17, 2015

@krisselden I force-pushed a commit that should remove all references to CDATA, did I miss any?

@tomdale

This comment has been minimized.

Show comment
Hide comment
@tomdale

tomdale Jun 17, 2015

Collaborator

Oops, forgot to push.

Collaborator

tomdale commented Jun 17, 2015

Oops, forgot to push.

Create custom API rather than reusing CDATA
This commit introduces a custom extension to the document API rather
than trying to re-use the existing XML CDATA API.

After considering it further, using an existing API in a similar but
somewhat different way could be an uncanny valley that hurts more than
it hinders.

Instead, I have introduced the ability to create `RawHTMLSection` nodes,
which are similar to CDATA in that they contain arbitrary, unparsed
HTML data, but make the intent more clear.

tomdale added a commit that referenced this pull request Jun 17, 2015

@tomdale tomdale merged commit 86787b6 into master Jun 17, 2015

2 checks passed

continuous-integration/travis-ci/pr The Travis CI build passed
Details
continuous-integration/travis-ci/push The Travis CI build passed
Details

@krisselden krisselden deleted the support-cdata-nodes branch Feb 26, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment