-
Notifications
You must be signed in to change notification settings - Fork 418
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 request: add an option to allow inline elements inside a span #461
Comments
@jznf, thank you for bringing this here... As discussed, off list, this has been the behavior of tidy for a long time, thus any change should be subject to a new option, to Very much welcome any thoughts on this... thanks... |
As we are about to I have constructed a sample in_461.html which passes W3C validation, so certainly think this feature should be added, even as the default... As always further comments, patches or a PR very welcome... thanks... |
Ah this is just a difference in the HTML5 spec. Previously I'll send a PR for this. |
HTML 5 restricts the children of <button> elements to only phrasing content. HTML 4 also allowed block elements. In particular, this change allows code such as <span><button>OK</button></span> to be left as-is, since the <span> does not need duplication for crossing a block boundary. Fixes htacg#461.
This change adds the InsertInlineTags flag (default=off) that propagates inline elements across block boundaries. This causes <span><div>OK</div></span> to become <span><div><span>OK</span></div></span> This fixes issue htacg#461.
HTML 5 restricts the children of <button> elements to only phrasing content. HTML 4 also allowed block elements. In particular, this change allows code such as <span><button>OK</button></span> to be left as-is, since the <span> does not need duplication for crossing a block boundary. Mitigates htacg#461.
@lhchavez as stated. thank you for your PR #531... While this works fine, I have now proposed an alternative fix, PR #540, that not only addresses this I have been delaying merging #540 hoping you would get a chance to pull and test the And now there is also a branch I understand RL must come first, but you say closing your #531, and/or adding a I am also holding off on a few other PRs to get #540 in place first... which will bump us to 5.5.15... thanks... |
oh, sorry i've been in the critical path. please go ahead and merge that other change since it's clearly better for everyone! if i end up seeing other issues, i'll send further PRs. i'll close this one. |
(and by "this one" i mean the one i sent) |
@lhchavez thanks for the quick reply... sorry to push when there may be other critical RL items...no apology needed... It's a bit late in my working day today, to get into merges, etc, but will get to it tomorrow, or soonest... thanks... |
Should I merge everything we've both okayed? I'm still GMT-5, so might be able to get to it tonight. |
Issue #461 - alternative patch for this issue
THANK YOU!!! |
current behaviour is that:
throws:
and the final result is:
It might be handy to have an option to prevent this behaviour and let the original markup unchanged as it is valid and it's a part of quite common pattern.
The text was updated successfully, but these errors were encountered: