When attempting to delete a post while offline we show a non-blocking but also non-standard “There is no network available” message that takes an unusually prominent space in front of the post lists.
On top of that the post isn't scheduled for deletion at all.
https://github.com/wordpress-mobile/WordPress-iOS/issues/11425
shows that blocks the UI.
It does not seem to be _blocking the UI_ because I can still tap anywhere else. Still, it should probably be a Snackbar. WDYT, @megsfulton ?

Oh, wait, no. Should the post be marked as deleted locally and we'll update the remote once the app is online?
I've updated the description to account for your questions @shiki . I think the post should be marked for deletion indeed, although we can decide to split it as a separate issue eventually.
I think we should consider this a locally changed post and consider it a part of syncing with remote. I believe how we will go about syncing will make how to handle this issue very clear. I have noted my thoughts on syncing here.
Agree with the points made so far.
On the design side, I think we should use a snack bar to inform the user that the post will be queued for deletion.
A lot of issues seem to be snowballing/falling like dominoes if we follow the proposed approach from #9555
Following the same logic, we would here tell the user that the post _will be_ deleted when they get online again.
Seems in line with the previous conversation here. I know you labelled it so let me know if anything else needs thinking through @yaelirub
Following the same logic, we would here tell the user that the post _will be_ deleted when they get online again.
Ok, so on the dev side we have to:
Looking at the proposal in https://github.com/wordpress-mobile/WordPress-Android/issues/9555#issuecomment-507234326 - I suppose we'll do the same for this ticket, so we'll keep the post in its current state, ie. if it's a draft it will stay in the "Draft" tab, if it's a "published post", it will stay in the "Published" tab, etc.
so we'll keep the post in its current state, ie. if it's a draft it will stay in the "Draft" tab, if it's a "published post", it will stay in the "Published" tab, etc.
I think you're probably right. It would be bad to say that its deleted when it hasn't been deleted yet. Especially if you delete a live/published post. We don't want to reassure someone the job of deleting it is _done_ when its actually still live on their site.
Should we then add a label e.g. "Will be deleted when connection returns" - does that feel weird?
Final design and copy for this issue, solution goes across #9555 and #9949 as well

Closing this one as a decision has been made. Decision and implementation details are captured in this ticket :https://github.com/wordpress-mobile/WordPress-Android/issues/10205.
Most helpful comment
Agree with the points made so far.
On the design side, I think we should use a snack bar to inform the user that the post will be queued for deletion.