Attachment DOM is messy

[basecamp]

Attachment DOM is messy

[javan]

Can you explain what issue you're having other than considering the DOM structure messy?

Keep in mind that the <trix-editor>'s HTML isn't the same as its <input>s HTML. Trix cleans up much of the "mess" when it serializes.

For example, looking at this document:

This is the <trix-editor>'s HTML (document.querySelector("trix-editor").innerHTML):

<div>
  <!--block-->Here's the logo:
  <br>
  <br>
  <span data-trix-cursor-target="true" data-trix-serialize="false"></span>
  <a href="https://d13txem1unpe48.cloudfront.net/tmp/2015-11-02/1446429236735-basecamp-logo.png" data-trix-attachment="{&quot;contentType&quot;:&quot;image/png&quot;,&quot;filename&quot;:&quot;basecamp-logo.png&quot;,&quot;filesize&quot;:2287,&quot;height&quot;:84,&quot;href&quot;:&quot;https://d13txem1unpe48.cloudfront.net/tmp/2015-11-02/1446429236735-basecamp-logo.png&quot;,&quot;url&quot;:&quot;https://d13txem1unpe48.cloudfront.net/tmp/2015-11-02/1446429236735-basecamp-logo.png&quot;,&quot;width&quot;:100}"
  data-trix-content-type="image/png" data-trix-id="1275" contenteditable="false">
    <figure class="attachment attachment-preview png">
      <img src="https://d13txem1unpe48.cloudfront.net/tmp/2015-11-02/1446429236735-basecamp-logo.png" data-trix-mutable="true" data-trix-store-key="imageElement/1275/1415/https://d13txem1unpe48.cloudfront.net/tmp/2015-11-02/1446429236735-basecamp-logo.png"
      width="100" height="84">
      <figcaption class="caption">basecamp-logo.png
        <span class="size">2.23 KB</span>
      </figcaption>
    </figure>
  </a>
  <span data-trix-cursor-target="true" data-trix-serialize="false"></span>
</div>

And this is its <input>'s HTML that you'd be saving to your database (document.querySelector("input[type=hidden]").value):

<div>Here's the logo:
  <br>
  <br>
  <a href="https://d13txem1unpe48.cloudfront.net/tmp/2015-11-02/1446429236735-basecamp-logo.png" data-trix-attachment="{&quot;contentType&quot;:&quot;image/png&quot;,&quot;filename&quot;:&quot;basecamp-logo.png&quot;,&quot;filesize&quot;:2287,&quot;height&quot;:84,&quot;href&quot;:&quot;https://d13txem1unpe48.cloudfront.net/tmp/2015-11-02/1446429236735-basecamp…tmp/2015-11-02/1446429236735-basecamp-logo.png&quot;,&quot;width&quot;:100}"
  data-trix-content-type="image/png">
    <figure class="attachment attachment-preview png">
      <img src="https://d13txem1unpe48.cloudfront.net/tmp/2015-11-02/1446429236735-basecamp-logo.png" width="100" height="84">
      <figcaption class="caption">basecamp-logo.png
        <span class="size">2.23 KB</span>
      </figcaption>
    </figure>
  </a>
</div>

The data-trix-* attributes aren't absolutely necessary to survive a round trip through your database unless you're adding custom attributes to the Trix.Attachment objects (which is very convenient) so you could sanitize them on your server without breaking anything. You can also configure the CSS class names if you'd like: https://github.com/basecamp/trix/blob/master/src/trix/config/css.coffee

but I would also store JSON serialization of the editor into the database. So when a user wants to edit content again, I load the JSON serialization of the editor.

That can be done by serializing the editor as JSON yourself and then loading it back in.

element = document.querySelector("trix-editor")

// Serialize
myDocument = JSON.stringify(element.editor)

// Load
element.editor.loadJSON(JSON.parse(myDocument))

[mitar]

Trix cleans up much of the "mess" when it serializes.

I was looking at the input value when I was describing the mess. ;-) So:

<a href="https://d13txem1unpe48.cloudfront.net/tmp/2015-11-02/1446429236735-basecamp-logo.png" data-trix-attachment="{&quot;contentType&quot;:&quot;image/png&quot;,&quot;filename&quot;:&quot;basecamp-logo.png&quot;,&quot;filesize&quot;:2287,&quot;height&quot;:84,&quot;href&quot;:&quot;https://d13txem1unpe48.cloudfront.net/tmp/2015-11-02/1446429236735-basecamp…tmp/2015-11-02/1446429236735-basecamp-logo.png&quot;,&quot;width&quot;:100}" data-trix-content-type="image/png">

Pretty messy. ;-)

The issue is that my simple sanitizer (which tags and which attributes are allowed for each tag) would have issues sanitizing this. Because it is more like, you should clean stuff, except inside attachment element, where you should do something else, based on the structure.

It would be really great if attachment would be just <trix-attachment href="https://d13txem1unpe48.cloudfront.net/tmp/2015-11-02/1446429236735-basecamp-logo.png" src="https://d13txem1unpe48.cloudfront.net/tmp/2015-11-02/1446429236735-basecamp-logo.png" width="100" height="84" />. :-)

necessary to survive a round trip through your database unless you're adding custom attributes to the Trix.Attachment objects

Oh, I am doing that. I was just looking into how to make this work. At the moment I was setting a property to the event.attachment.attachment. You are saying that it would be better to use setAttributes for this?

That can be done by serializing the editor as JSON yourself and then loading it back in.

Yes, that was what I had in mind. Sorry if it was not clear. The question is if this is a good pattern to do? So to remove all custom tags for attachments and instead use serialized editor to pass extra data through editing sessions?

Is there an easy way to make Trix not put those data attributes into input's value in the first place?

[mitar]

Also, is there way to disable attaching CSS classes altogether for attachments? I am considering styling them through structure-based selectors.

[javan]

Personally, I don't consider putting data in a data attribute that messy.

The issue is that my simple sanitizer (which tags and which attributes are allowed for each tag) would have issues sanitizing this.

The simplest solution here is to whitelist Trix's attributes in your sanitizer.

You are saying that it would be better to use setAttributes for this?

Yes, all of the attributes set that way will be serialized and round trip successfully.

Is there an easy way to make Trix not put those data attributes into input's value in the first place?

No, not currently. Trix's priority is round-tripping and producing consistent output.

Also, is there way to disable attaching CSS classes altogether for attachments? I am considering styling them through structure-based selectors.

No, but you're free to ignore them and specify your CSS as you please.

[mitar]

The simplest solution here is to whitelist Trix's attributes in your sanitizer.

But then they can be added everywhere.

No, not currently. Trix's priority is round-tripping and producing consistent output.

Can I make maybe a pull request making this somehow optional? Or maybe I can just override this by monkey-patching stuff somehow.

No, but you're free to ignore them and specify your CSS as you please.

Can I make a pull request that if Trix.config.css values are set to null, those classes are not added?

[javan]

Another option might be to set your own text/html serializer. See https://github.com/basecamp/trix/blob/master/src/trix/config/serialization.coffee#L20-L44

Perhaps allowing adding additional serializers so you can add to Trix's rather than replacing it. Is that something you'd like to explore?

[mitar]

Maybe. But I think it would be even easier if I could simply make attachments be rendered with <trix-attachment> and then I define my own custom attribute. Or I can instruct/configure Trix how to define it. So the default of <trix-attachment> could be what is currently used by Trix, with all serialization and everything.

[mitar]

I think what I have the biggest issue with is that those data attributes are needed only when editing the content again. But they are provided when rendering the content every time, even when not editing. This is why it is messy. I can now store two copies, one when I want to edit, and when for displaying. But then why to store anything into data and why not just store the state of the editor as JSON into the database?