~bptato/chawan#28: Gemini layout is missing some line breaks

bptato a month ago · edit

Thanks for reporting.

Strange, both pages look fine to me. You don't have a text/gemini entry in ~/.mailcap, right?

Also, what does this print?
$ printf '=> about:blank test\n=> about:blank test\n' | cha -dT text/gemini

~skejg a month ago

I found the culprit, it's buffer.styling, when set to true everything looks fine, and your test returns two lines (and when set to false, it's one line, 'testtest').

As a workaround, it can be toggled with a siteconf option, of course. But in general, unless I'm very wrong, Gemini sites don't really have styles, and buffer.styling probably shouldn't apply to them?

bptato a month ago · edit

~skejg wrote:

I found the culprit, it's buffer.styling, when set to true everything looks fine, and your test returns two lines (and when set to false, it's one line, 'testtest').

As a workaround, it can be toggled with a siteconf option, of course. But in general, unless I'm very wrong, Gemini sites don't really have styles, and buffer.styling probably shouldn't apply to them?

Oh.

Well, intuitively they don't have styles. But in the background, gemtext gets converted to HTML, and then <body> gets white-space: pre-line to match the spec-mandated formatting style.

That does make styling as a global parameter somewhat unusable. Maybe it shouldn't affect x-htmloutput's inline styles at all?

Or, better: we could add a mailcap extension field like x-needsstyle and set it only on formats that output built-in styles, so that styling can still affect HTML dialects like Markdown where author styles exist.

~skejg a month ago

Or, better: we could add a mailcap extension field like x-needsstyle and set it only on formats that output built-in styles, so that styling can still affect HTML dialects like Markdown where author styles exist.

That would require a user to learn and do something new and non-standard about the mailcap, or am I mistaken? My point is, people rarely read the documentation in general -- and especially about the things they think they already know and use :)

I personally would just put a guard in the code to ignore certain configuration values on certain occasions. But maybe it's a bad practice or would have some caveats...

bptato a month ago · edit

Or, better: we could add a mailcap extension field like x-needsstyle and set it only on formats that output built-in styles, so that styling can still affect HTML dialects like Markdown where author styles exist.

That would require a user to learn and do something new and non-standard about the mailcap, or am I mistaken?

No, res/mailcap includes the default gemtext entry, and x-needsstyle would be added there. So in your case you wouldn't have to do anything.

Users would have to learn about x-needsstyle only if they set styling=false and added a custom x-htmloutput mailcap entry and wished to use CSS in that entry. Probably not too much of a burden to read the docs at that point :P

I personally would just put a guard in the code to ignore certain configuration values on certain occasions. But maybe it's a bad practice or would have some caveats...

If you mean "just ignore the styling option on x-htmloutput", the caveat is that this is valid markdown (or at least accepted as such):
<style>p { text-decoration: blink }</style>

blink
and then it would blink even with styling=false, since md2html also uses x-htmloutput. Same thing applies for e.g. user-defined xhtml or epub x-htmloutput entries.

~skejg a month ago

Users would have to learn about x-needsstyle only if they set styling=false and added a custom x-htmloutput mailcap entry and wished to use CSS in that entry. Probably not too much of a burden to read the docs at that point :P

Agreed, that sounds reasonable (both the scheme and the docs reading condition :)

If you mean "just ignore the styling option on x-htmloutput"

I thought more about "just ignore this option for this protocol". But your proposed solution above seems like a way better approach.

bptato a month ago · edit

OK, should be fixed now.

~skejg a month ago

Can confirm, works for me.

Thanks!

~bptato REPORTED FIXED a month ago

Thanks for confirming.

~skejg a month ago

~bptato

Well.... That's not all, it seems :)

I have a cgi script, which wraps the current html page in a table, adding left and right columns to narrow down the reading area. Basically it curls a page and pipes it to awk:
awk '
    BEGIN{
        print "Content-type: text/html\n\n"
    }
    /<body/{
        sub(/<body[^>]*>/, "<body><table><tbody><tr><td width=\"20%\"></td><td>")
    }
    /<\/body>/{
        sub(/<\/body>/, "</td><td width=\"20%\"></td></tr></tbody></table></body>")
    }
    {
        print
    }'
With the commit a68e17b7 (and buffer.styling disabled), it's now broken. Setting buffer.styling to true makes it work. Except there's no style here, I'd say :)

bptato a month ago · edit

Right, that was not intended. Should be fixed now, thanks for reporting.

~skejg a month ago

And thanks again for fixing, everything looks OK now :)