

Slash: A markup language for styling text on iOS - chrisdevereux
https://github.com/chrisdevereux/Slash

======
onedognight
An alternative is to use AttributedMarkdown which also takes a dictionary of
attributes per element type and returns an NSAttributedString.
<https://github.com/dreamwieber/AttributedMarkdown>

------
algal000
Another alternative is FTCoreText (
<https://github.com/FuerteInternational/FTCoreText> ), which I've had good
experience with. Like AttributedMarkdown or Slash, you define
NSAttributedString text styles in code. But there are (I believe) two
differences which might be significant advantages in some cases.

First, FTCoreText doesn't predefine the tag vocabulary. You just associate
your styles with tag names you define, and write your text in a pseudo-XML
syntax using those tags. This is good for defining tags with semantics suited
to your particular domain.

Second, FTCoreText doesn't use UIKit's NSAttributedString attributes. It uses
the more powerful CoreText NSAttributedString attributes, which have been
present since iOS5 at least. They are more powerful in one important way: only
the CoreText string attributes support defining tab stops. This might seem
like an irrelevant corner case, except that (as far as I know) this is the
only way to properly define correct text indentation of text in bulleted list
items.

~~~
chrisdevereux
Couple of corrections about Slash:

The tag vocabulary isn't really predefined. There is a default vocabulary, but
it can be easily changed by passing in a different dictionary of tags.

Also, the attributes aren't restricted to UIKit's NSAttributedString
attributes (or not by Slash, anyway). You can provide whatever attributes you
want, so long as the view you pass the attributed string to understands them.

~~~
algal000
Chris, thanks for the correction. That's very good to know. Sorry if I
misrepresented the project!

~~~
chrisdevereux
Ah, no problem. It's helpful to know that the readme gives that impression.

------
taylorfausak
Why make the markup HTML-esque and then provide an _emph_ tag instead of _em_?

~~~
chrisdevereux
Good point! <em> would make a lot more sense.

------
mistercow
Wait, why doesn't iOS have the equivalent of the
-initWithHTML:documentAttributes method from the AppKit additions? That's been
around since, let me check... always. Why would Apple leave it off on the
iPhone?

~~~
chrisdevereux
Or initWithRTF:documentAttributes:... No idea.

~~~
mistercow
At least with RTF, that seems to be functionality that is _generally_ missing
from UIKit. HTML parsing, on the other hand, is already there in WebKit.

The sense I get is that Apple didn't really know what they were doing when
they first released the iPhone, didn't actually intend to release an API for
it (after all, the initial message to developers was "just build an HTML 5
app") and then rushed one out without properly thinking through its design.
And I guess they've been filling the gaps ever sense.

~~~
chrisdevereux
Interesting... I sort of agree. But the strange thing is to start supporting
rich text in UIKit controls without providing a sane API for manipulating rich
text. That's not problem introduced with v1.0, it's a problem introduced at
v6.0.

The problems I run into tend to be quite circumscribed deficiencies that are
more like oversights than deep design flaws. I'd attribute that to the
pressure to rapidly improve the API rather than the framework never have being
thought through (In general, I find UIKit better thought out than AppKit).

Whether it was the official policy or not, I'd imagine that the UIKit team
probably wanted UIKit to be an API... Wouldn't a private api that looked like
that just be completely over-engineered?

~~~
mistercow
>Whether it was the official policy or not, I'd imagine that the UIKit team
probably wanted UIKit to be an API... Wouldn't a private api that looked like
that just be completely over-engineered?

Yes probably, but API design is hard, and when the API is for something that
big, it's even harder. My gut hypothesis is that Apple didn't initially put
anyone with that particular expertise on the team because the people in charge
thought HTML5 would be good enough. The people on the team, being UI
developers, knew that that was silly and that the API would eventually need to
be public, so they made a valiant effort to prepare for the inevitable.

------
gurkendoktor
DTCoreText was not mentioned yet - we've used it with mattt's
TTTAttributedLabel and it worked okay on iOS5.

<https://github.com/Cocoanetics/DTCoreText>

------
peterhajas
Interesting. I personally find NSAttributedStrung raw to be pretty easy to
use, but I understand how this is appealing for web developers.

~~~
MaxGabriel
I think the strongest argument for a markup language/translator for
NSAttributedString is ease of localizing other languages. A translator can
learn the basic markdown, and that can be passed along in a .strings file.

