Possible bug in the way plaintext cards are treated?+discussion

What is the view on the inclusion? I think default would be :content, vs. :raw or :core which are really expected not to be wrapped in any way.

---

a nest is nothing more than hard-coded text search and replacement via named fields

...well, as Gerry implies, that depends on the view. The default "content" view is more than that – it also includes a wrapper that makes it dynamic. The wrapper is a div by default.

So your options are (a) pick a view without the wrapper (eg core), or (b) tweak the CSS of the wrapper to your liking. In the case of plain text, there's really only one CSS rule that comes standard:

 pre,
.TYPE-plain_text.card-content,
.SELF-Xhead.card-content {
  white-space: pre-wrap;       /* css-3 */
  white-space: -moz-pre-wrap;  /* Mozilla, since 1999 */
  white-space: -pre-wrap;      /* Opera 4-6 */
  white-space: -o-pre-wrap;    /* Opera 7 */
  word-wrap: break-word;       /* Internet Explorer 5.5+ */
}

You might have to tweak those rules to get what you want, but they're useful in getting the whitespace handling that is typically desired in multi-line plaintext.

---

I was thinking that PlainText would be enough but I ran about six other simulations/tests with my content and it's a no go. Essentially I need it to retain (HTML)formatting, still be dynamic so I can double click on it to edit and still be able to surgically break it apart in cards that I need to view together. So I'm back to "Basic" or HTML cards(they render fine but can't be edited WYSIWYG).

 

Is it possible, for me, to use a span wrapper for the content wrapper instead of "The wrapper is a div by default."? Span has no detectable presence unlike div.

 

PS. Also noted that some card types seem to make assumptions about how to display the content but in rather peculiar ways. For example, when creating a Pointer Card and then entering Another Card for it to point to, adding the Pointer Card to other content makes it display a closed, one line description of the card it points to. This seems rather unnecessary to have in the default behavior, since all one wants is for the Pointer Card to point to whatever card it is pointing to and display the default of that whatever that may be. Right now it feel like I find myself overriding Pointer Cards constantly. Is there an assumption I'm missing here?

---

Well, the default view is closed for items, but you can change it if you want. That default is a bit historical, as the main open/closed views were the primary way to represent a referenced card in place. You can give any view options for the items, they go after the second | in include syntax. If you want links to the pointed to cards, {{my pointer| | link}}. Changing div to span in a standard view is only done by code (modules), and I really wouldn't recommend that change anyway.

I think what Ethan is suggesting would change the style of div so that it acts like a span, which is probably the display attribute. I'm pretty sure a few styles is the main difference between div and span. If you just inspect the div element, you'll find the classes you'll want to use that are connected to the Sets the card is in.

The default view is probably a setting now (and the default item view as well), right?

---

Re span, that wouldn't work for *all* card slots, because card slots often have block elements (like divs) inside them, and it's not technically legal in HTML to have block elements inside of inline elements. Different browsers handle code that breaks this rule differently, so it causes all kinds of problems.

We could consider making it so that content nests default to span, but lots of card content has block elements in it, so that's not a great solution either, though this is slightly more appealing now that (in new decks) the default view is titled, not content. Could also do a different view. Worth a conversation. (probably in a separate idea card).

We have also discussed changing the default item view to "link". I think that's been ticketed; there was general agreement on this. But there hasn't really been a good plan for how to migrate old decks yet.