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.

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

Feature: allow custom optional closed tags #47

Open
SilentCicero opened this issue Feb 24, 2017 · 5 comments
Open

Feature: allow custom optional closed tags #47

SilentCicero opened this issue Feb 24, 2017 · 5 comments

Comments

@SilentCicero
Copy link

SilentCicero commented Feb 24, 2017

In react a custom component can be notated like this: <MyCustomComponent />, in hyperx you have to notate is like this <MyCustomComponent><MyCustomComponent>.

I would like to notate optionally closable, non-html tags that could or could not be closed at the end.

So I would register with hyperx these in opts, under optionallySelfClosing: []. If they are closed (i.e. ending with />) then they are treated as closed tags. If they are not (i.e. ending in >) then they have children and are not yet closed.

Another way would be to have a loose setting in opts. Where any tag, html or otherwise could be optional open or closed. However, this seems like more work to implement.

@slaskis
Copy link
Collaborator

slaskis commented Feb 24, 2017

This might be related to issue #34

@ghost
Copy link

ghost commented Mar 11, 2017

Perhaps this feature could take an array to explicitly enumerate options but also a function so that people can use conventions such as checking for the presence of a capital letter as is common in react land? I also think we could rework the parser so self-closing tags don't search for a closing element.

@SilentCicero
Copy link
Author

SilentCicero commented Mar 14, 2017

@substack re-work the parser, and make the policy strict: if /> then closed. Dont allow <br> only <br />. I think this would be amazing.

You could then remove all this: 'area', 'base', 'basefont', 'bgsound', 'br', 'col', 'command', 'embed', 'frame', 'hr', 'img', 'input', 'isindex', 'keygen', 'link', 'meta', 'param', 'source', 'track', 'wbr', '!--', // SVG TAGS 'animate', 'animateTransform', 'circle', 'cursor', 'desc', 'ellipse', 'feBlend', 'feColorMatrix', 'feComposite', 'feConvolveMatrix', 'feDiffuseLighting', 'feDisplacementMap', 'feDistantLight', 'feFlood', 'feFuncA', 'feFuncB', 'feFuncG', 'feFuncR', 'feGaussianBlur', 'feImage', 'feMergeNode', 'feMorphology', 'feOffset', 'fePointLight', 'feSpecularLighting', 'feSpotLight', 'feTile', 'feTurbulence', 'font-face-format', 'font-face-name', 'font-face-uri', 'glyph', 'glyphRef', 'hkern', 'image', 'line', 'missing-glyph', 'mpath', 'path', 'polygon', 'polyline', 'rect', 'set', 'stop', 'tref', 'use', 'view', 'vkern'

@SilentCicero
Copy link
Author

@substack this would also speed up parsing times due to not having to test through this large string everytime.

@SilentCicero
Copy link
Author

@substack how would I go about implementing this, any directions, I could do a branch and PR?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants