Noob Question: Can you change the color of the text in a markdown block?

18,430 views
Skip to first unread message

Gordon Brown

unread,
Sep 12, 2013, 10:38:35 PM9/12/13
to elm-d...@googlegroups.com
As I asked above, can you change the text of a markdown element?

I tried color gray [markdown| Stuff |] but that changes the color of the background, not of the text.  I ask because I'm trying to make a website with a light-on-dark color scheme and markdown text defaults to black, which makes that rather impossible if I want to use markdown.  I know I can do it otherwise, but markdown makes things so much easier.

Max Goldstein

unread,
Sep 12, 2013, 11:23:55 PM9/12/13
to elm-d...@googlegroups.com
Last I checked, Markdown itself does not support colors. There may be a way around this in Elm, or it may not be implemented. I'm not sure.

Alex Neslusan

unread,
Sep 12, 2013, 11:31:33 PM9/12/13
to elm-d...@googlegroups.com
I think the idea with Markdown in general is that you style it with CSS. Although, I thought it was one of Elm's design goals to sort of replace traditional HTML/CSS development. If you look at some of Evan's sites and pages he's written in Elm, he does include a little CSS I think.

Gordon Brown

unread,
Sep 13, 2013, 12:04:08 AM9/13/13
to elm-d...@googlegroups.com
Thanks.  I was hoping to avoid having to muck around with CSS directly but oh well.

Maybe I'll even get off my butt and learn enough Haskell to write some patch to let you do it, although that would probably take a while.

Evan Czaplicki

unread,
Sep 13, 2013, 12:42:37 AM9/13/13
to elm-d...@googlegroups.com
I'll sometimes add a bit of CSS to do text styling, like so. This is something that I have fairly mixed feelings about, and for that reason, I have never mentioned it on the lists. I still consider this an area for exploration that is in need of more formal design decisions.

My reasoning at the moment is that HTML (Hyper-Text Markup Language) is somewhat acceptable as a text markup language (it's original reason for existence, and the motivation for its design). It became out of control terrible when people just kept adding and adding features one at a time to solve all sorts of unrelated problems in a seemingly ad-hoc fashion with little to no foresight or concern for abstractions (sorry to any spec-writers who may read this, I do think this process has gotten better in the last couple years).

Sometimes those problems (vertical centering) really could not fit in a language designed for text markup. Microsoft Word does not have vertical centering for the same reason, it's not really a meaningful operation on text itself. You need to have a meaningful notion of a container, and at that point you probably would design things totally different (cough, Elm, cough). This is also why setting the color of a div sets the text color, not the color of the div! Text color came first because it is a text markup language. Fun fact, the original version of HTML did not even have an <img> tag because it's kind of nonsense to put images in text. This is also why inline-text images were (are?) the default. It was a very controversial feature at the time and ended up getting added by Netscape as a non-spec feature that just caught on. I suspect there are many other shitty parts of CSS that can be explained by this tension between being a language for text and a language for layout.

So overall, I use some CSS on text and I don't feel bad about it. It was designed for this, and it is alright. I have no temptation to do other stuff with it because it's always much easier to work with layout in Elm.

As it is, there are definite limitations on this, so I would rely on this as lightly as possible. One example is asynchronously loading fonts. Since Elm always knows the dimensions of elements, having a font load and change the size of something can mess things up. I think this means that the fonts need to be known before rendering can commence, which is the default when fonts are loaded from the user's system. I think the solution here may be to register this font information with the code or runtime or something. This is one of the design uncertainties that has led me to not talk about this feature. 

And before people go wild talking about inconsistency, sell-out, etc. etc. remember that I am doing my best and am happy to have a civil discussion to try to find a better, more consistent way. There is nothing more frustrating than being talked down to on a topic that I understand well, and one that already bothers me. I have some thoughts in the direction of markdown interpolation and embedding Elm in HTML that may actually unify this stuff in a reasonable way.


--
You received this message because you are subscribed to the Google Groups "Elm Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to elm-discuss...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Alex Neslusan

unread,
Sep 13, 2013, 12:53:36 AM9/13/13
to elm-d...@googlegroups.com
This is an interesting post. I figured you've thought about this sort of thing before but I never saw you talk about it. Everything you said makes sense to me.

Tim hobbs

unread,
Sep 13, 2013, 12:35:05 PM9/13/13
to elm-d...@googlegroups.com
It seems to me that the proposed {{}} things will help with coloring text in markdown.  If one wants some colored text in markdown, in the future one could use {{}} to insert some colored Text.

Did you ever try making it so that element size was NOT known? Aka, that it would be a signal?  size : Element -> Signal Int.  It seems elm will never have support for text zooming if this problem isn't solved.  I'm thinking that hotswaping may turn out to be handy here, but I would like to see a compelling reason why element sizes cannot be expressed as a signal first.

Tim
Reply all
Reply to author
Forward
0 new messages