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 request - configurable options for HTMLSerializer #129

Closed
jvanasco opened this issue Jun 10, 2014 · 1 comment
Closed

feature request - configurable options for HTMLSerializer #129

jvanasco opened this issue Jun 10, 2014 · 1 comment

Comments

@jvanasco
Copy link
Contributor

I ran into a weird issue. It would seem that running something through the bleach multiple times will result in different output. here's a testcase - https://gist.github.com/jvanasco/2cda35740de8afc0a003

what happens is that the underlying HTMLSerializer will build the serialize the text differently, depending on the output

pay attention to the order of the attributes here:

<button class="navbar-toggle collapsed" data-target=".navbar-collapse" data-toggle="collapse" type="button">

and here:

<button data-target=".navbar-collapse" class="navbar-toggle collapsed" data-toggle="collapse" type="button">

html5lib seems to order the attributes "not randomly" based on their initial ordering. they re-order endlessly between the two .

in our case, we "bleach" user content on input.

on certain screens, if something had to be bleached, we present the bleached result to the user to approve. because of this behavior, bleaching the content a second time will result in a document that doesn't match the input document.

there are workarounds that we employ for now, but it's messy. we just patched bleach to pass alphabetical_attributes=True into HTMLSerializer

it would be great if bleach either had some more default options for HTMLSerialize ( in _serialize ) or allowed for some configuration of defaults.

@willkg
Copy link
Member

willkg commented Apr 18, 2016

The initial issue here is also covered in issue #121. I'm going to close this out since that issue is fixed now.

@willkg willkg closed this as completed Apr 18, 2016
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