Text Block Options

[patrickheeney]

It would be great to add left, center, right, justify formatting options to the text block. Perhaps the unlink button could only show up when you are highlighting a link. In the future it would also be great to change the link dialog to a model window or something a little more flexible.

[cjbell]

Few things here:

• I agree with changing the link window to a dialog and not the awful prompt it is now. We should definitely take a look at this for a future version.
• Unlink only show when a link is active is also a great suggestion and would be a nice usability win
• As for the left, right, center justify options for the text, it's a great suggestion but something that Markdown doesn't support so we'd have to start adding HTML + CSS to do this for the text. Perhaps a better way might be to start storing custom metadata along with a block, so that you could add a CSS class to style it on the rendering of the block.

[patrickheeney]

All good points. Totally agree with you on the markdown front, and I think the metadata would be perfect. I think it should be stored in json along with the content so the frontend implementation you use could handle the display of it. For example leaving in markdown format would simply ignore the fact that it has those alignment tags. When displayed as html+css you could apply the tags of your choosing. I imagine the editor would apply some styles to handle the display in the editor.

It reminds me of this: http://interior.substance.io/modules/document.html (scroll to annotations part on the bottom, sorry can't anchor you there).

[andflett]

I've been meaning to write a little about the formatting bar for a while now, so apologies for coming in half way through a discussion.

As a principle, ST isn't intended as a "formatting" tool in the same way as other editors, the only reason Bold and Italic exist is that they are valid HTML tags with true semantic meaning (although one could argue there is no difference in their meaning!)

ST is about storing structured, clean, standards-based content from user input, so formatting should take place at time of render. So it's less about what Markdown supports, and more that we agree with its philosophy.

I realise this sounds a little hardline, but staying true to these sorts of principles is what makes ST such a clean and flexible tool for user input.

That said, is there a particular use case you have in mind? Maybe we can help find another solution.

[cjbell]

I think metadata on a block is the cleanest way to do this. We could have a button to toggle some kind of UI on and off, doesn't have to be enabled by default but could be a nice extension.

Following this approach keeps to the convention of content and presentation separate. What do you think?

Christopher Bell Developer

+44 (0) 7817 971924 http://cjbell.co chris@cjbell.co

On 14 Nov 2013, at 07:50, Andrew Sprinz notifications@github.com wrote:

I've been meaning to write a little about the formatting bar for a while now, so apologies for coming in half way through a discussion.

As a principle, ST isn't intended as a "formatting" tool in the same way as other editors, the only reason Bold and Italic exist is that they are valid HTML tags with true semantic meaning (although one could argue there is no difference in their meaning!)

ST is about storing structured, clean, standards-based content from user input, so formatting should take place at time of render. So it's less about what Markdown supports, and more that we agree with its philosophy.

I realise this sounds a little hardline, but staying true to these sorts of principles is what makes ST such a clean and flexible tool for user input.

That said, is there a particular use case you have in mind? Maybe we can help find another solution.

— Reply to this email directly or view it on GitHub.

[andflett]

Thar be dragons, and hellish regex.

If we do this, then there is no reason why we shouldn't add font options, and colours.

Separation of content and presentation is cleanest when you treat input as content, and rendering as presentation. If you muddle the two, you begin to set the expectation that what-you-see-is-what-you-get... you give control of presentation over to your end users - and, I think, this is why so many websites look like crap :)

ST is a content editor, not a content formatting tool.

[ghost]

egy blokk a legtisztább módja ennek. Lehetne egy gomb megnyomásával tudunk valamilyen UI -- "formázás" eszköz ugyanúgy, mint más szerkesztők, az egyetlen ok, félkövér és dőlt --úgy bánsz bemenet a tartalom, és a renderelés például egy -

[higgis]

I fully agree with @andrewsprinz on this.

Alignment might differ based on the capabilities of the device that is being used to render the content. A design for mobile might mandate left alignment, but one that produces PDFs might use justified alignment, for example.

What happens when your front-end design changes? You've embedded presentation information in your content rather in your presentation layer, and you either have to put up with it or write logic to undo what has been stored in the content. Neither option is good.

For me this is definitely an underlying philosophical principle of Sir Trevor that would be extremely damaging to ignore.

[ghost]

Mi történik, amikor a front-end design változásokat? Már beágyazott bemutató információkat a tartalom helyett a megjelenítési réteg, és meg sem kell beletörődik, vagy írjon a logika, hogy vonja vissza, amit már tárolt tartalmat. Számomra ez mindenképpen egy alapvető filozófiai elv Sir Trevor, ami rendkívül káros figyelmen kívül hagyni.@ Szürke sötétebb: # 222222;@ Brand-figyelmeztetés: # f25d18;@ Padding-nagy vízszintes: 16px

[patrickheeney]

First of all, let me state I am in agreement with all of what you have mentioned about the philosophical principle of Sir Trevor. However, I think what I am proposing can be accomplished without violating what it stands for and increases the power of the editor in the process.

Firstly, I think even if is ultimately decided that this is not something you want core Sir Trevor to do then at least a way to add meta data and extend the format options should be available for someone to maintain a fork that does it.

Secondly, I think the implication that this leads to font options and colors is a stretch. Having content in the center of the page "could" be content editing and not a formatting tool. I have seen centered text and even right aligned text in books and other mediums as well. One could argue that centering something enhances the content or the message they are trying to get across. In any case I agree that perhaps Sir Trevor isn't the best tool to push the limits of what content editing is, but I do think having an extendable way for others is a good middle ground.

Lastly, the fact that Mardown Extra and GitHub Flavored Markdown exists is an example that sometimes plain Markdown isn't enough and everyone has a different vision of what that should be. Where GitHub added task lists, I am looking to add text alignment. I think its possible that Sir Trevor can remain a extremely flexible tool and that I could extend it to easily the functionality I am looking for so that everyone wins.

For example what if extending the toolbar to add 'text_center', 'text_left', 'text_right' was possible. Extending it should allow me to add the buttons, icons, and callback. When that callback is fired it does not add markup at all as suggested above. Instead it gets stored as metadata:

{
type: "heading",
data: "Test",
meta: {
   type: "h1"
}
},
{
type: "text",
data: "Test Content",
meta: {
   text_center:[0, 4], //Range of characters
   emphasis:[5, 11]
},
{
type: "heading",
data: "Test 2",
meta: {
   type: "h2"
}
}
}

A onload event of the block could handle applying st-meta-text_center and st-meta-emphasis span tags that .css loaded on the page should handle formatting.

In no way is the content being marked up. It was also mentioned above that how would you handle the formatting for a PDF or the web, etc. It is not the job of Sir Trevor to be handling the frontend output so worrying about it really isnt necessary IMO. If we are extending to add this functionality then we are responsible for outputting it correctly. In any case its really easy to do.

If I was output to a PDF I would simply ignore the meta column text_center because a PDF does not support that. If I am outputting to the web I would do something like this:

$data = json_decode($data_source);

foreach($data as $d) {
  foreach ((array) $d->meta as $meta_key => $meta) {
    switch ($meta_key) {
      case "text_center":
         $d->data = ''; //Split string and wrap characters with <span class="text-center"></span> or w/e I want to center it in my own code
      break;
    }
  }
}

Which could output in an example implementation:

<h1>Test</h1>
<span class="text-center">Test</span> <em>Content</em>
<h2>Test 2</h2>

If I wanted to output it to a book, I could add the necessary code that would center the text in that medium. But again, this is the responsibility of the frontend implementation.

Having meta functionality does not detract from the core project but yet offers a way for everyone to extend the editor and attach any kind of meta data with a block that can be used to control the presentation on the web, PDFs, or any other medium. It could be an extremely powerful tool and offer a way for someone to accomplish any task even if it differs from the Markdown or Sir Trevor philosophies even though in this implementation it does not.

P.S. No hellish regex needed (I hate it too)

[patrickheeney]

An additional thought; @andrewsprinz, you mentioned the argument about true semantic meaning of valid HTML. I think it brings up a valid point. Marking up the content at all could be a bad thing. If all of this was stored as meta data, then nothing is touching the original content and everyone wins. Example code:

{
type: "text",
data: "Test Content",
meta: {
   text_center:[0, 4], //Range of characters
   emphasis:[5, 11],
   italic:[5, 11],
   link: {
      location: [0, 4],
      href: "http://google.com",
      target: "_blank"
   },
   strikethrough:[5, 11]
},

It would also be easy in the toolbar to check if meta.link exists to toggle the button on the format options toolbar. It would also be easily possible to get the content with no formatting by simply ignoring the implementation of it. Best of all we should avoid all regex when trying populate an edit link model window (when ditching the dialog).

[andflett]

Closed for now, we're working on a clearer roadmap and direction for ST which should help explain ourselves a little better - more on this soon!