-
Notifications
You must be signed in to change notification settings - Fork 84
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/map attributes #40
Conversation
Please fix lint issues first. |
…ature is now merged with setTableAttrs to solve complexity issues.
…anyway and shouldn't require another dependency.
Here is it. Sorry about the delay. To elaborate a bit further on this proposal: it's really about being able to use any exotic markup language and still keeping markup and stylesheets separated in the source files when creating email HTML… Which, imho, fits well with this project. |
The tests are good but I would like to see a better explanation of this along with an example in the readme. |
Hi @jonkemp, I didn't have time to take care of this earlier but if you're still interested, I opened up a new repo where I do use this fork to build a series of emails. Hope this helps enough to see if it's revelant or if you're better off without. |
Following up issue #8 this PR proposes to add further rule-to-attribute capability by letting the user to add custom maps to any HTML element.
Use case: dedicated email markups à la MJML try to remove some complexity to improve semantics readability; they're doing so by using custom HTML element which, once compiled, are converted to one or more nested elements optimized to be Email HTML compliant. However, such engines tend to force-remove style attributes.
Inline-CSS may help keep existing pipelines clean (Gulp, etc.) by using its capabilities to keep custom style rules separated from markup, only applying properly declared attribute maps; especially since the said markup may combine both regular HTML.classname and custom markup —MJML, etc.
Example: