How often do you use inline images? <p> wrapper is really useful?

[bowerbird]

tom said:

>   I definitely do! Tell me more …

>   or point me at it, or something.


my stuff is in a bit of a jumble right now.

probably best to e-mail me, and tell me
exactly what your interests are, so i can
point you to the piece of my puzzle that
will be of the greatest interest to you now.

a big cut is if you wanna do development
or just use some system to make e-books.

i'm streamlining a process to explain it all,
and will have it within the next few weeks,
so if you'd prefer to wait for that, that's fine.

but i'm more than willing to help people now,
if you wanna get started right away; e-mail me.


nancy said:

>   Softcover looks like a dream-come-true. I hope.

>   Hope springs eternal, I think, as I finally

>   open up the terminal window. Sounds drastic.


do please note that softcover.io is a newcomer now.

if you want the proven player, choose leanup.com.


***

tom said:

>   StrapdownJS (for those unafraid of the CapsKey)

>   is just mind-boggling. I became an instant adopter.

>   Thanks for your insight (as always).


strapdown _is_ mind-boggling.

moreover, it's one of those things that is mind-boggling
precisely because it is _not_ mind-boggling, but instead
is quite straightforward, easy, and obvious.  in retrospect.

of course, in retrospect, _everything_ is obvious.

but yeah, i've been talking about serving light-markup
(rather than .html), and having the client-end convert it
for several years now, including here in these archives.

***

ali said:

>   One step ahead is probably browser adoption.

>   A firefox extension for this:

>   https://addons.mozilla.org/en-US/firefox/addon/markdown-viewer/


well, yeah, having the browser-makers do this "voluntarily"
would be the best way to proceed, because that would give
the methodology reach and legitimacy, plus ensure its future.

and it's indeed what i have wished for in the past, because
-- weighed against the bloatware that browsers are today --
including the 20k-40k of code for a conversion routine is tiny.

and it'd solve the chicken/egg problem that nobody wants
to serve light-markup if the browser will not convert it, but
they won't put in a converter if nobody serves light-markup.

my thought: "if you would convert it, they would serve it."

but i think the browser-makers are reluctant to include such
a light-markup conversion routine themselves, because they
don't want to suffer the backlash from users who'd then realize
that much of the .html pain which has been heaped on us was
_totally_unnecessary_ and could have been _easily_avoided_.

"you mean we could have been serving light-markup all along?
well, gee, thanks for not telling us that, you sadistic bastards."

i mean, seriously, it's some kind of sick joke that we're forcing
humans to mark up text "for the computer", when the machine
can do mark-up a _lot_ faster and more efficiently than we can.

the machine is supposed to work for us, not make work for us.

but even once they _do_ finally decide to include a converter,
browser-makers have shown they move agonizingly slowly...

no matter...

because now that we've become comfortable with javascript
(albeit fairly uneasy and queasy, for many very good reasons),
we can include a conversion routine ourselves, along with our
light-markup original file, and have the client-machine run it...

so...

how does that javascript-converter-bundled-with-light-markup
approach differ from the firefox extension "markdown-viewer"?

well, in a few small ways, that end up being extremely important.

first off, you'll notice that i've been saying "light-markup", and
_not_ "markdown".  well... there's a very good reason for that.

and it boils down to the 3 million different flavors of markdown.

the nightmare is that the flavor of markdown which i am serving
is _not_ the same flavor that you have in your viewer-extension.
so the rendering is flawed, in ways neither you nor i might know.

and another nightmare is that there are 87 different extensions,
and they all use different flavors, so i'm now in a no-win position,
and thus no matter what flavor i serve, it'll crap out for someone.

(no sooner do i write this than tom points to other extensions.
yes, there are many of them out there, with more on the way.)

and note that this scenario will also hold if the browser-makers
include converter-routines themselves, but use different flavors;
that would be the absolute worst-case version of this nightmare.

as long as you are using markdown as your light-markup format,
the obvious resolution of this nightmare is to serve the converter
you've tested with, and thus _know_ treats your input correctly...

hopefully, when the world decides to go "all-in" on light-markup,
we will discard markdown and choose a non-fragmented format.
(i would rather say "naturally" than "hopefully", but, regrettably,
we rarely do the right thing when we make this kind of decision.)

-bowerbird