space

From IndieWeb

This article is a stub. You can help the IndieWeb wiki by expanding it.


space (also negative space or empty space) is typically used in IndieWeb contexts to refer to presentational blank space(s) on web pages, and the space between words and lines of text, including line-breaks, sometimes used to format note posts, like to indent lines, or with specific meaning like text lists without markup.

If you need to use a term in an ambiguous context and want to specifically refer to presentational or layout empty spaces, please use either "empty space" or "negative space", and avoid using "white space" (unless you literally have to refer to the CSS 'white-space' property).

Space characters in text

Text often has plenty of inline space characters (e.g. " ") and vertical space characters (e.g. CR, LF).

Typical silo notes posts display most space characters entered in their posting interfaces. IndieWeb implementations should preserve space characters also.

Why preserve space characters

There are some interesting use-cases for preserving space characters, in particular line breaks.

emoji game state

Wordle allows sharing of game state / results using emoji squares and line breaks that line-up in a nice grid.

E.g. https://twitter.com/caro/status/1485881863142924293

  • "look if I’m gonna stay up late…

    Wordle 220 5/6

    ⬜⬜⬜⬜⬜
    ⬜🟨⬜🟨⬜
    ⬜🟨🟨⬜🟨
    🟩⬜🟨🟨⬜
    🟩🟩🟩🟩🟩" @caro January 25, 2022

chess game use-case

Besides the obvious use-cases of poetry, paragraphs, and lists, there are for example, chess games (and moves!)

This leads us to the use case of indieweb spectator correspondence chess. That is, two players could play a chess game just by posting moves on their own indieweb sites as replies to each others' moves.

Perhaps chess moves (and resulting board state) could be posted as a special kind of note post type (a game-move or game-turn?) and then POSSE'd to Twitter with space characters intact.

If the move is response to a move on another indiewebsite, then in addition to using webmention for move completion notification, the POSSE'd response move could also indicate with Twitter's in-reply-to-status-id the POSSE'd tweet of the previous move. See how to POSSE a comment/in-reply-to/u-syndication for details of how to do this.

Such public posting of moves would also allow for anyone to jump in and attempt to play a next move by posting a reply move. The player of the previous move would then receive multiple webmentions and could decided which move (or both) to reply to in turn.

Indieweb space characters thinking

Due to the expectations set by dominant silo implementations, any note authoring/composing UI should preserve line-breaks, blank lines, and multiple inline space characters when writing/authoring, displaying/presenting, and ideally, when syndicating (POSSEing, e.g. space characters preserved by POSSE via Twitter API, Twitter->FB cross-posting / downstream-POSSEing, and Bridgy Publish).

Especially now that even Twitter has set consistent expectations from its posting UI, there's a strong case that a user switching from Twitter to an indieweb note posting UI would expect space characters (including line breaks) to "just work".

Summary, two options for publishers:

  1. Use p-content if you expect only the plain text of your post to be retrieved, and then (preferably, but possibly only optionally) have its space characters preserved.
  2. Use e-content if you publish fully marked up links, embeds, and spacing (e.g. with <br/>,   etc.) and expect space characters in source to be collapsed per HTML parsing rules.

More analysis:

Obviously indieweb implementations would have to preserve space characters in posting UI to storage to display round-trips. In the presentation they could either:

  • a. <br/> substitutions - Indieweb implementations could (are any already?) automatically insert <br> tags for linebreak space characters (a kind of auto-space, similarly to auto-linking URLs in notes). In addition, there would need to be an approach to handling multiple sequential space characters, and leading spaces on a line.
    • Substitute multiple sequential inline space characters to &nbsp; if that behavior is really desired (I've never needed/wanted to preserve multiple spaces in a note) Kylewm.com 18:14, 20 August 2015 (PDT)
    • Two more auto-space cases (pretty sure this should take care of mimicking pre-wrap behavior - Tantek)
      1. line-break then inline space: turn the inline space into an &nbsp;
      2. sequence of inline spaces: turn every adjacent pair into _&nbsp; (where _ represents a space)
    • Update: CASSIS auto_space() now implements this, and live on tantek.com
  • b. white-space:pre-wrap - Alternatively indieweb implementations should use white-space:pre-wrap similar to how Twitter does.
    • As of 2015-08-24 tweet permalinks (e.g. [1]) have markup for hyperlinks, but use &#10; for linebreaks, instead of <br/>.
    • -1 This is a strange divergence from expected HTML with the big disadvantage that consumers need to implement post-type detection to check if a post is a note and/or heuristics to infer whether the space characters in a post are meaningful. As an implementer of a reader that consumes lots of different posts from different sources, I would much prefer that e-content space characters be consistent between sources and post types. Kylewm.com 18:14, 20 August 2015 (PDT)
      • e-content consistency is a good argument. perhaps space characters preservation with white-space:pre-wrap should only be applied to a plain p-content "value", and if there is any e-content, even if just via auto-linking, it should auto-space as well. - Tantek 16:41, 24 August 2015 (PDT)

History:

  • b. white-space:pre-wrap seemed to be the logical choice for indieweb implementations
    • However, it became clear that doing just "some" auto-markup (e.g. autolink and autoembed but not autospace) was too (unnecessarily) hard for consuming code (e.g. readers, other sites) to have a chance at getting right.
    • After more brainstorming, autospace algorithms and code were figured out and seem to be working fine, thus the approach documented in a) made more sense.

IndieWeb Examples

  • ...

Silo Examples

Facebook

Facebook status updates are notes (no post title) that preserve sequential inline space characters and line breaks.

Twitter

Twitter now has multiple implementations that preserve space characters in presentation:

  • Twitter.com (as of ~2013-03-13)[2][3][4][5][6]
    • e.g. https://twitter.com/hotdogsladies/status/4809602603
    • based on a test ( Tantek 18:13, 15 April 2013 (PDT) ), when posting to Twitter.com, Twitter's server
      • preserves simple linebreaks
      • preserves multiple spaces between words
      • preserves spaces at the start of a line
      • but collapses multiple linebreaks into a maximum of one blank line between lines.
  • Twitter iOS client (previously: Tweetie)

Encoding - analysis of the above tweet:

  • View Source: The linebreaks are encoded as &#10; character entitites, without any visible line breaks in the code.
  • View Selection Source (FF) and Inspect Element (FF, Safari): The linebreaks appear to be simple "carriage return" characters (\r, ASCII 13), showing visible line breaks in the code.
  • In either case, the visual presentation of the space characters is achieved using CSS:

    .js-tweet-text { white-space: pre-wrap; }

Old Examples

Google

Google+ posts are similarly just notes (no post title) that also preserve sequential inline space characters and line breaks.

See Also

Retrieved from "https://indieweb.org/wiki/index.php?title=space&oldid=79432"