I have moved the problem of styling to the browsers, like NAVI in my case. The browser is the only part that understands the limitation of the device and knows how to best render each widget so it makes sense for it to handle all the styling instead of having styling intertwined with the data itself like HTML does. CSS doesnt solve the problem of mixed data and styling either, it just hides it better.
The lack of styling I do understand can make it feel as if your site lacks personality when all sites look kinda the same so I see your point here. I might later allow some minor themeing, like say allowing you to select a color scheme, with the understanding that this might be ignored by the user. I will have to think about this more. What you will never get to decide are things lika margins and paddings and things like that.
I don't think you can compare Markdown with ALFI like that exactly. Markdown will generate HTML in the end and it is the resulting HTML that you need to compare with because that is what the browsers understands. Also, Markdown only solves the trivial cases and that is why it can be kept simple and readable but how do you for instance create a three column layout in Markdown with an image in the middle column? I don't know, maybe there are extensions for that these days too.
It would be interesting to have a Markdown to ALFI generator, but I suspect that when you are used to reading ALFI code you might find it to be a bit overkill because even though I am a bit biased of course I do think ALFI is pretty readable.
Also, there is no intentional OOP or funcional aspects, I did not quite understand what you wanted to convey there.
