tumblr / docs

Tumblr's public platform documentation.
Apache License 2.0
108 stars 26 forks source link

NPF `indent_level` – a no longer supported feature? #115

Open James-Ansley opened 1 year ago

James-Ansley commented 1 year ago

I have been making my own client (tumblrdotcom) and have noticed posts with any non-zero indent_level do not render correctly when posted. I have also noticed that even if I manually construct a post in the tumblr UI with any indented blocks, they do not render correctly and sometimes break the editor. Is this feature no longer supported?

For example, using the API to post the following content taken from the text block subtype docs:

{"content": [{"type": "text",
              "text": "Sward's Shopping List",
              "subtype": "heading1"},
             {"type": "text",
              "text": "First level: Fruit",
              "subtype": "ordered-list-item"},
             {"type": "text",
              "text": "Second level: Apples",
              "subtype": "unordered-list-item",
              "indent_level": 1},
             {"type": "text",
              "text": "Third level: Green",
              "subtype": "ordered-list-item",
              "indent_level": 2},
             {"type": "text",
              "text": "Second level: Pears",
              "subtype": "unordered-list-item",
              "indent_level": 1},
             {"type": "text",
              "text": "First level: Vegetables",
              "subtype": "ordered-list-item"}],
 "layout": [{"type": "rows",
             "display": [{"blocks": [0]},
                         {"blocks": [1]},
                         {"blocks": [2]},
                         {"blocks": [3]},
                         {"blocks": [4]},
                         {"blocks": [5]}]}],
 "tags": ""}

Will post successfully:

{
    "meta": {"msg": "Created", "status": 201},
    "response": {
        "display_text": "Posted to tinygamebot",
        "id": "726856993513652224",
        "state": "published"
    }
}

When I get this post, again with the API, the indent levels are in the received NPF content as above. However, the post does not render correctly:

image

Unless it is being edited (however, it seems to get confused between ordered and unordered lists):

image

Another example using the Tumblr UI, again taken from the docs:

image

Produces the same output:

image

Again, unless in edit mode. When getting this post with the API, it still has the indent levels as above.

This actually breaks the editor in some cases, such as lists inside of blockquotes.

All this is to ask, is the indent_level a no longer supported feature for Tumblr posts, or is this a bug?

marcustyphoon commented 1 year ago

I think this has been the case since NPF came out. I would also like confirmation if it's officially a bug or officially just unsupported/abandoned/whatever.

nightpool commented 1 year ago

my understanding is that indent level is supported inconsistently across clients, it was a feature that was specced but hasn't been prioritized to be implemented.Probably the blog network (username.tumblr.com) pages will render it correctly?

On Sun, Aug 27, 2023 at 8:39 PM marcustyphoon @.***> wrote:

I think this has been the case since NPF came out. I would also like confirmation if it's officially a bug or officially just unsupported/abandoned/whatever.

— Reply to this email directly, view it on GitHub https://github.com/tumblr/docs/issues/115#issuecomment-1694869408, or unsubscribe https://github.com/notifications/unsubscribe-auth/AABZCV4L4LWGDIV55L5M2UDXXPZFDANCNFSM6AAAAAA4AWB55A . You are receiving this because you are subscribed to this thread.Message ID: @.***>

cyle commented 1 year ago

Hello! This looks like a bug to me. At least on web, the indent_level should be respected and rendered as expected. I'm not sure if we built support in the iOS and Android clients, though, as @nightpool guessed. The usage of indent_level was mainly added to be backwards-compatible with legacy posts, but you can/should be able to use it if you want via the API directly, as you are here.

I've filed a bug ticket for this internally, hopefully we can get an answer/fix for this out soon.