Hello all, This is in response to the various alt-text / content type suggestions floating around. I'm uncomfortable with inventing a new syntax to combine these two pieces of data for two reasons. First, new syntax complicates the spec. Second, any ambiguity will reduce the usefulness both to a client. Ideally, the two would be separate. Most suggestions I've seen so far were to follow the opening ``` of a preformatted block with a mix of this data. However, there is also the option of adding data after the closing ``` marker, keeping the two separate. My suggestion would be to place type information after the opening ```, and alt-text after the closing ```, for the following reasons: 1. Even for accessibility, I suspect knowing the content type is more practically useful to the client in the majority of existing cases. Most ASCII art is purely decoration, and knowing the content type is text/x-ascii (or similar) upfront is important so the screen reader can simply skip it. 2. Knowing the content type upfront would allow clients to present streaming data correctly using appropriate colours and escape codes for code highlighting, for example. 3. Placing the content type after the opening ``` line is familar to markdown authors, which is not a reason in itself, but a welcome bonus nonetheless. 4. Placing the alt text after the closing ```, at the end of the preformatted block has a nice symmetry with links which place the human-friendly text at the end too. For now, I have no opinion on the format of content type labels. Caolan
On 28-Feb-2021 14:32, Caolan McMahon wrote: > Hello all, > > This is in response to the various alt-text / content type suggestions floating around. > > I'm uncomfortable with inventing a new syntax to combine these two pieces of data for two reasons. First, new syntax complicates the spec. Second, any ambiguity will reduce the usefulness both to a client. > > Ideally, the two would be separate. Most suggestions I've seen so far were to follow the opening ``` of a preformatted block with a mix of this data. However, there is also the option of adding data after the closing
I think this is a sensible way to disentangle these two concerns that
are covered by the spec. At present these two aspects are merged
together which means it is hard to write any client code to reliably
provide any UI to assist the user beyond all or nothing, or a text label.
We had some discussion on this list a while back on some of this, and it
seems making use of the opening and closing marker was already proposed
by Sean Conner
https://lists.orbitalfox.eu/archives/gemini/2020/002671.html
linking on to:
gemini://gemini.conman.org/test/preformat.gemini
and
gemini://gemini.conman.org/test/preformat-2.gemini
My suggestion would be to place type information after the opening ```,
and alt-text after the closing ```, for the following reasons:
1. Even for accessibility, I suspect knowing the content type is more
practically useful to the client in the majority of existing cases. Most
ASCII art is purely decoration, and knowing the content type is
text/x-ascii (or similar) upfront is important so the screen reader can simply skip it.
2. Knowing the content type upfront would allow clients to present
streaming data correctly using appropriate colours and escape codes for
code highlighting, for example.
3. Placing the content type after the opening ``` line is familar to
markdown authors, which is not a reason in itself, but a welcome bonus nonetheless.
4. Placing the alt text after the closing ```, at the end of the
preformatted block has a nice symmetry with links which place the
human-friendly text at the end too.
Something very close to this was the scheme proposed by Sean in the
preformat-2 example:
I don't have a strong view on which should be used for the top and which
for the bottom, I'd just be glad to see the roles clearly separated to
support both use cases presented in the spec.
From a parsing point of view I see the benefits in putting the text
type first as you indicate. There is an argument perhaps to put the alt
text first which is perhaps that so far the use of this label is mostly
free form so legacy content would map better to the human alt text
accessibility label.
For now, I have no opinion on the format of content type labels.
Given the label is of a text area, we could simply say one can use any
"sub type" of text media type, so a single word would be text/*
javascript (means text/javascript)
csv (means text/csv)
lua (means text/lua)
and so on. This would be my preference.
Or optionally provide a proper media type if you want (e.g.
application/atom+xml)
?- Luke
=> messages/005741.gmi Link to individual message. ## Oliver Simmons <oliversimmo (a) gmail.com>
On Sun, 28 Feb 2021, 14:32 Caolan McMahon, <caolan at caolan.uk> wrote:
Hello all,
This is in response to the various alt-text / content type suggestions
floating around.
I'm uncomfortable with inventing a new syntax to combine these two pieces
of data for two reasons. First, new syntax complicates the spec. Second,
any ambiguity will reduce the usefulness both to a client.
The spec dosent have any sytax as of current, it's free form text.
Adding syntax to it it would only remove ambiguity.
Ideally, the two would be separate.
+1
Most suggestions I've seen so far were to follow the opening ``` of a
preformatted block with a mix of this data. However, there is also the
option of adding data after the closing ``` marker, keeping the two
separate.
My suggestion would be to place type information after the opening ```,
and alt-text after the closing ```, for the following reasons:
Gemtext is designed so it can be read line-by-line, top-to-bottom and be
completely understood.
Sticking text after the closing ``` that affects content would break this -
I presume that's why it's explicitly disallowed in the spec.
1. Even for accessibility, I suspect knowing the content type is more
practically useful to the client in the majority of existing cases. Most
ASCII art is purely decoration, and knowing the content type is
text/x-ascii (or similar) upfront is important so the screen reader can
simply skip it.
2. Knowing the content type upfront would allow clients to present
streaming data correctly using appropriate colours and escape codes for
code highlighting, for example.
Code highlighting is a good use case for this - but it would also ~sorta
allow for putting other content inline if we aren't careful on what's
allowed.
3. Placing the content type after the opening ``` line is familar to
markdown authors, which is not a reason in itself, but a welcome bonus
nonetheless.
4. Placing the alt text after the closing ```, at the end of the
preformatted block has a nice symmetry with links which place the
human-friendly text at the end too.
I like the ordering of content type first and alt text last, as Gemtext
works line-by-line top-to-bottom, knowing the content type first is good,
as it may affect following stuff.
But I think using the opening/closing toggles like this may cause
confusion, if you look at the line in isolation, you can't tell what the
text following it is. You're supposed to be able to tell how a line would
be structured/it's meaning by only looking at the first three lines.
-Oliver Simmons
=> messages/005751.gmi Link to individual message. ## Alex // nytpu <alex (a) nytpu.com>
On 2021-02-28 10:57PM, Oliver Simmons wrote:
Gemtext is designed so it can be read line-by-line, top-to-bottom and
be completely understood.
...
I like the ordering of content type first and alt text last
So the sighted people with fancy syntax highlighting get to trivially
read it line-by-line, but the people writing accessible software have to
1) seek forward to find the end of the preformatted text block; 2) read
the alt text; then, if the user wants to display the preformatted block
3) jump backwards to the beginning of the preformatted text block and
read it; then 4) skip past the last line of the preformatted text block
so it isn't read again; then 5) continue parsing.
I think syntax highlighting deserves an easier implementation than
accessibility too, so I'm fine with this situation, I'm glad someone
else finally agrees with me on this.
I mean seriously, I like syntax highlighting as much as anyone but
advanced syntax highlighting has to be context-sensitive and possibly
requires looking back in the code block anyways, so might as well put it
at the end, if you have it at all. But let's just look at the concept
at all for a second: if you really have such a massive block of code
that you need syntax highlighting, just put it in its own file and let
either the browser color it via MIME type or the user can just open it
in their editor. If your short snippet of code can't be understood
without syntax highlighting then it's probably a problem with your code
rather than the presentation...
~nytpu
--
Alex // nytpu
alex at nytpu.com
GPG Key: https://www.nytpu.com/files/pubkey.asc
Key fingerprint: 43A5 890C EE85 EA1F 8C88 9492 ECCD C07B 337B 8F5B
https://useplaintext.email/
=> messages/005757.gmi Link to individual message. ## Alexis <flexibeast (a) gmail.com>
Alex // nytpu <alex at nytpu.com> writes:
I mean seriously, I like syntax highlighting as much as anyone
but
advanced syntax highlighting has to be context-sensitive and
possibly
requires looking back in the code block anyways, so might as
well put it
at the end, if you have it at all. But let's just look at the
concept
at all for a second: if you really have such a massive block of
code
that you need syntax highlighting, just put it in its own file
and let
either the browser color it via MIME type or the user can just
open it
in their editor. If your short snippet of code can't be
understood
without syntax highlighting then it's probably a problem with
your code
rather than the presentation...
Agreed, as someone who isn't vision-impaired, who likes syntax
highlighting, and who has implemented an Emacs mode that does such
highlighting.
i feel it's important that accessibility for the vision-impaired
be easier to support in clients than syntax highlighting. More
generally, my preference is for gemtext documents to be reasonably
accessible by default, rather than requiring special efforts to be
made accessible (as on the Web, where accessibility often plays
second fiddle to resource-gobbling bling).
Alexis.
=> messages/005758.gmi Link to individual message. ## Caolan McMahon <caolan (a) caolan.uk>
Code highlighting is a good use case for this - but it would also
~sorta allow for putting other content inline if we aren't careful on
what's allowed.
To be honest, code highlighting is probably not that important but it's an
easy to understand presentation choice that a client might make. It's
probably more important that a client implementing accessibility features
understands what type of content is in the block so it can read or
navigate it appropriately. E.g. a table or a poem might be handled
differently to ascii art.
As for other content inline - I agree. Preformatted text blocks have
always been the biggest extensibility risk in my opinion. They were
already the most likely place to put custom client features and this makes
it very slightly easier. In the end, our best defence is culture and a
plethora of popular clients. Keeping things easy to parse is important for
that reason, and I believe an argument for either denying extra data for
preformatted blocks, having only one type, or keeping them separate,
instead of attempting to combine them with new syntax.
But I think using the opening/closing toggles like this may cause
confusion, if you look at the line in isolation, you can't tell what
the text following it is. You're supposed to be able to tell how a line
would be structured/it's meaning by only looking at the first three
lines.
That's not quite true - to know what a line containing ``` will do, you
need to know whether your client is in preformatted mode, and this
proposal makes no change to the state required.
=> messages/005768.gmi Link to individual message. ## Caolan McMahon <caolan (a) caolan.uk>
> I like the ordering of content type first and alt text last
So the sighted people with fancy syntax highlighting get to trivially
read it line-by-line, but the people writing accessible software have to
1) seek forward to find the end of the preformatted text block; 2) read
the alt text; then, if the user wants to display the preformatted block
3) jump backwards to the beginning of the preformatted text block and
read it; then 4) skip past the last line of the preformatted text block
so it isn't read again; then 5) continue parsing.
I agree that the most important principle is that a client choosing to
implement accessibility features knows what to do with the following
content. That's why I'm proposing content type first.
You might prefer to use the more ambiguous optional alt text and ask the
user how to present the data each time. I have no idea if that is correct,
someone who relies on a screen reader will have to enlighten me. But don't
assume my motives. So far as I can tell, our priorities are the same.
=> messages/005769.gmi Link to individual message. ## Caolan McMahon <caolan (a) caolan.uk>
i feel it's important that accessibility for the vision-impaired
be easier to support in clients than syntax highlighting. More
generally, my preference is for gemtext documents to be reasonably
accessible by default, rather than requiring special efforts to be
made accessible (as on the Web, where accessibility often plays
second fiddle to resource-gobbling bling).
On the web, it is considered good practice to use alt text for images, and
there is pressure from the web development community in this regard.
Unfortunately, most web users don't actually see alt text in normal use.
So it's always going to be a bit of a second class citizen.
One way I think gemini got this right was in using links for images. It
requires a textual description of the image, and it's shown to all users.
There's no split in the presentation, everyone is treated that same. I like that.
Unfortunately, alt text for preformatted blocks does introduce content
only likely to be seen by a minority of users. The only way I can see
around that would be a practice of repeating any visual content in prose
descriptions in the surrounding paragraphs. This gives reinforcing content
that everyone can see. Unfortunately, I don't know how practical that
would be in all cases.
But if anyone has an idea to make preformatted blocks more accessible
without hidden content for the visually impared, and instead using content
shared by everyone, I'd be keen to hear it.
=> messages/005772.gmi Link to individual message. ## Oliver Simmons <oliversimmo (a) gmail.com>
On Mon, 1 Mar 2021 at 03:47, Alex // nytpu <alex at nytpu.com> wrote:
So the sighted people with fancy syntax highlighting get to trivially
read it line-by-line, but the people writing accessible software have to
1) seek forward to find the end of the preformatted text block; 2) read
the alt text; then, if the user wants to display the preformatted block
3) jump backwards to the beginning of the preformatted text block and
read it; then 4) skip past the last line of the preformatted text block
so it isn't read again; then 5) continue parsing.
I assumed that the content type would be used to decide whether it
would be read.
Anyways, my point was that using the closing ``` is not going to work,
as Gemtext is meant to be read line-by-line.
Whether it's the alt text or content type, having either of them last is flawed.
I think syntax highlighting deserves an easier implementation than
accessibility too, so I'm fine with this situation, I'm glad someone
else finally agrees with me on this.
I mean seriously, I like syntax highlighting as much as anyone but
advanced syntax highlighting has to be context-sensitive and possibly
requires looking back in the code block anyways, so might as well put it
at the end, if you have it at all. But let's just look at the concept
at all for a second: if you really have such a massive block of code
that you need syntax highlighting, just put it in its own file and let
either the browser color it via MIME type or the user can just open it
in their editor. If your short snippet of code can't be understood
without syntax highlighting then it's probably a problem with your code
rather than the presentation...
Agreed.
- Oliver Simmons
=> messages/005776.gmi Link to individual message. ## Philip Linde <linde.philip (a) gmail.com>
On 2/28/21, Caolan McMahon <caolan at caolan.uk> wrote:
Ideally, the two would be separate. Most suggestions I've seen so far were
to follow the opening ``` of a preformatted block with a mix of this data.
However, there is also the option of adding data after the closing ```
marker, keeping the two separate.
My suggestion would be to place type information after the opening ```, and
alt-text after the closing ```, for the following reasons:
Existing documents that use alt text as per the current spec will be
broken. Existing clients which MUST ignore any text following the
terminating ``` won't be able to access the alt text on new documents
following this suggestion. Seems like we'd be getting the worst of
both worlds.
1. Even for accessibility, I suspect knowing the content type is more
practically useful to the client in the majority of existing cases. Most
ASCII art is purely decoration, and knowing the content type is text/x-ascii
(or similar) upfront is important so the screen reader can simply skip it.
How is the type more useful for accessibility than a general
description of its content? Would knowing in an art gallery whether
you're standing in front of an oil painting or an aquarelle be more
useful than knowing what the painting depicts? Need help browsing a
photo album? I'll help! I'll just read "photo, photo, photo, photo,
photo..." to you until you've had enough.
I also object to the idea that the purely decorational should simply
be skipped over. If it's not there for a reason, the author should be
the one skipping over it. Presumably it *is* there for some
informational purpose in which case there's no reason that the
information it communicates should be available to some users but not
others when alt text can be used to describe it to people who can't
see it directly.
2. Knowing the content type upfront would allow clients to present streaming
data correctly using appropriate colours and escape codes for code
highlighting, for example.
A solution to a problem of its own making.
--
Philip
=> messages/005777.gmi Link to individual message. ## text@sdfeu.org <text (a) sdfeu.org>
On Mon, 01 Mar 2021 09:20:42 +0000, Caolan McMahon wrote:
One way I think gemini got this right was in using links for images. It
requires a textual description of the image, and it's shown to all
users. There's no split in the presentation, everyone is treated that
same. I like that.
Unfortunately, alt text for preformatted blocks does introduce content
only likely to be seen by a minority of users.
One solution lies within your comment: remove preformatted blocks from
text/gemini so that we have to link to resources of text/plain or text/
whatever. Just like we do with images etc.
Probably unpopular but simple, right? Is there a mime type for ascii-art?
Clients would probably load these inline which would result in multiple
requests, though.
=> messages/005778.gmi Link to individual message. ## Petite Abeille <petite.abeille (a) gmail.com>
On Mar 1, 2021, at 11:05, text at sdfeu.org wrote:
Probably unpopular but simple, right? Is there a mime type for ascii-art?
https://www.iana.org/assignments/media-types/text/vnd.ascii-art
!!!
?0?
=> messages/005779.gmi Link to individual message. ## Petite Abeille <petite.abeille (a) gmail.com>
On Mar 1, 2021, at 11:05, text at sdfeu.org wrote:
Clients would probably load these inline which would result in multiple
requests, though.
embed them as data: URI?
?0?
=> messages/005780.gmi Link to individual message. ## Caolan McMahon <caolan (a) caolan.uk>
> My suggestion would be to place type information after the opening ```, and
> alt-text after the closing ```, for the following reasons:
Existing documents that use alt text as per the current spec will be
broken. Existing clients which MUST ignore any text following the
terminating ``` won't be able to access the alt text on new documents
following this suggestion. Seems like we'd be getting the worst of
both worlds.
From a backwards compatibility perspective, yes, I agree. Alt text was
allowed after the initial ``` so we are probably stuck with it.
How is the type more useful for accessibility than a general
description of its content? Would knowing in an art gallery whether
you're standing in front of an oil painting or an aquarelle be more
useful than knowing what the painting depicts?
No, but knowing whether the picture contained text or art would tell you
whether to use assistive technology to read it or describe it.
It seems most the disagreement here is whether the client should
automatically make some sensible choices for the user (content type
first), or the user should process the alt text and make their own call (alt text first)?
> 2. Knowing the content type upfront would allow clients to present streaming
> data correctly using appropriate colours and escape codes for code
> highlighting, for example.
A solution to a problem of its own making.
Sorry, I don't follow this point.
=> messages/005781.gmi Link to individual message. ## Caolan McMahon <caolan (a) caolan.uk>
> One way I think gemini got this right was in using links for images. It
> requires a textual description of the image, and it's shown to all
> users. There's no split in the presentation, everyone is treated that
> same. I like that.
>
> Unfortunately, alt text for preformatted blocks does introduce content
> only likely to be seen by a minority of users.
One solution lies within your comment: remove preformatted blocks from
text/gemini so that we have to link to resources of text/plain or text/
whatever. Just like we do with images etc.
Probably unpopular but simple, right? Is there a mime type for ascii-art?
Clients would probably load these inline which would result in multiple
requests, though.
I like this suggestion.
Personally, if I could choose a client that displayed these inline when
clicked I'd be happy. Those preferring simpler clients could simply follow the link.
It would provide both content type and alt text by removing features - the
feature that happens to be greatest extensibility risk in gemtext. Ideal.
=> messages/005782.gmi Link to individual message. ## text@sdfeu.org <text (a) sdfeu.org>
> > One way I think gemini got this right was in using links for images.
> >
> > Unfortunately, alt text for preformatted blocks does introduce
> > content only likely to be seen by a minority of users.
>
> One solution lies within your comment: remove preformatted blocks from
> text/gemini so that we have to link to resources of text/plain or text/
> whatever.
I like this suggestion.
Personally, if I could choose a client that displayed these inline when
clicked I'd be happy.
Thanks! Me too.
It would provide both content type and alt text by removing features -
the feature that happens to be greatest extensibility risk in gemtext.
Ideal.
Reminds me of some threads discussing sophisticated table syntax within
gemtext vs. linking to such resources, e. g.
https://lists.orbitalfox.eu/archives/gemini/2021/004718.html
The question isn't "is it useful?" The question is "can we do without?"
=> messages/005784.gmi Link to individual message. ## Petite Abeille <petite.abeille (a) gmail.com>
On Mar 1, 2021, at 11:05, text at sdfeu.org wrote:
Probably unpopular but simple, right?
Not only right, but technically correct. The best kind of correct.
All build-in text/gemini particularities could be removed all at once ? if
only Gemini accepted to actually make use of its link construct in more progressive ways.
Of course, this is never going to happen ? too much ideology, and sunk cost already ?.
Perhaps Gemini is already its very own Big Ball Of Mud:
http://www.laputan.org/mud/
Oh well.
?0?
? https://en.wikipedia.org/wiki/Sunk_cost
=> messages/005789.gmi Link to individual message. ## Philip Linde <linde.philip (a) gmail.com>
On Mon, 01 Mar 2021 10:12:18 +0000
"Caolan McMahon" <caolan at caolan.uk> wrote:
> How is the type more useful for accessibility than a general
> description of its content? Would knowing in an art gallery whether
> you're standing in front of an oil painting or an aquarelle be more
> useful than knowing what the painting depicts?
No, but knowing whether the picture contained text or art would tell you
whether to use assistive technology to read it or describe it.
Similarly, describing it would tell me whether to read it or skip it
and additionally allow an author to give me the gist of its content.
Read me
```C source code
or
```ASCII art depicting sleeping, happy cat
and I simultaneously have an indicator of whether I can comprehend the
content and a description of it in case I can not. Then I can
consciously navigate past it or dive into it with my client. The
problem with accessibility for now, from what I understand, is that
most clients don't have the navigational tools necessary to allow this,
and screen readers will happily burst out long sequences of nonsense if
that's what's presented to them. This is orthogonal.
It seems most the disagreement here is whether the client should
automatically make some sensible choices for the user (content type
first), or the user should process the alt text and make their own call (alt text first)?
Most of my disagreement is with the breaking spec change, further
objections being with the assumptions underlying the definition of the
supposed problem with the spec as-is, but first and foremost that it
suggests a breaking change that is likely to hurt accessibility when a
breaking change isn't at all necessary in the first place.
See my suggestion at the end of the mail for how this can be
implemented without breaking the spec.
> > 2. Knowing the content type upfront would allow clients to present streaming
> > data correctly using appropriate colours and escape codes for code
> > highlighting, for example.
>
> A solution to a problem of its own making.
Sorry, I don't follow this point.
What you've suggested here (different lines before and after the
block content contain alt text and type information) creates a problem:
if the type information is after the content, the client can't know in
advance how to e.g. highlight source code. This problem doesn't exist
with the spec in its current form. By saying that the type information
should then be first, you propose to have solved that problem.
In one mail you have both created and solved a problem, and you list
having solved the problem you've created as an advantage of the approach
your suggestion. In that sense it's a solution to a problem of its own
making.
---
My suggestion: if for whatever reason you want to include machine
readable content information, do it on the alt text line as you already
MAY according to the current spec. Do this in a manner that's both
unambiguously separate from alt text to the computer and sensible as
natural plain text and unlikely to appear to mean anything other than
the machine interpretations, e.g. "(MIME: text/x-art)". Define this
format in a companion spec.
It doesn't immediately invalidate any existing pages, it's gracefully
forwards- and backwards compatible and it's already specified to an
extent. Clients that don't want to deal with this time waster can
ignore it, and people who are interested can decide on the color of
their bikeshed (maybe it should be "[MIME: ...]"?!) without constantly
pushing for completely unnecessary breaking spec changes.
--
Philip
=> messages/005794.gmi Link to individual message. ## Thomas Frohwein <tfrohwein (a) fastmail.com>
On Mon, Mar 01, 2021 at 10:12:18AM +0000, Caolan McMahon wrote:
[...]
> > 2. Knowing the content type upfront would allow clients to present streaming
> > data correctly using appropriate colours and escape codes for code
> > highlighting, for example.
>
> A solution to a problem of its own making.
Sorry, I don't follow this point.
IMO escape codes are a hack, and universal client support can't be
expected. In fact, those may break different terminal/client types.
I think color escape codes should not be considered expected with
clients. In fact, there should probably a discussion if this should be
discouraged in the spec.
=> messages/005795.gmi Link to individual message. ## Katarina Eriksson <gmym (a) coopdot.com>
On Monday, March 1, 2021 10:20 AM, Caolan McMahon <caolan at caolan.uk> wrote:
One way I think gemini got this right was in using links for images. It
requires a textual description of the image, and it's shown to all users.
There's no split in the presentation, everyone is treated that same. I like that.
Unfortunately, alt text for preformatted blocks does introduce content
only likely to be seen by a minority of users. The only way I can see
around that would be a practice of repeating any visual content in prose
descriptions in the surrounding paragraphs. This gives reinforcing content
that everyone can see. Unfortunately, I don't know how practical that
would be in all cases.
But if anyone has an idea to make preformatted blocks more accessible
without hidden content for the visually impared, and instead using content
shared by everyone, I'd be keen to hear it.
These are the signals I want the documentation to send:
(The exact wording can be improved upon.)
1. Write a caption for everyone to see. It should include all information
needed for a reader to decide if they want to see the preformated lines or not.
2. The toggle line with free form alt-text.
3. Preformatted lines. Hopefully not too many.
4. End of file or another toggle line followed by more gemtext.
Consider making configuration items for "always show", "always ask" or
"ask if it has alt-text, otherwise show" when preformated lines are encountered.
If the reader wants to see the preformated lines, show them. Otherwise,
show the alt-text if it exists.
Put some kind of marker or boundary at the end so that you can skip to it
past the rest of the preformated lines.
Ideas taken from: https://lists.orbitalfox.eu/archives/gemini/2021/005758.html
--
Katarina
=> messages/005797.gmi Link to individual message. ## Devin Prater <r.d.t.prater (a) gmail.com>
On 3/1/21 3:10 AM, Caolan McMahon wrote:
You might prefer to use the more ambiguous optional alt text and ask the
user how to present the data each time. I have no idea if that is correct,
someone who relies on a screen reader will have to enlighten me. But don't
assume my motives. So far as I can tell, our priorities are the same.
If I had to answer yes/no (or please y/n in Terminal browsers) if I want
to see code blocks every time, that'd quickly get annoying. I'd rather
just hide them all, Alt-text or not, and expand them with a key press
when I reach one I want to read. This key press would expand the
currently focused block, not all of them, of course.
=> messages/005800.gmi Link to individual message. ## Sean Conner <sean (a) conman.org>
It was thus said that the Great Thomas Frohwein once stated:
On Mon, Mar 01, 2021 at 10:12:18AM +0000, Caolan McMahon wrote:
[...]
> > > 2. Knowing the content type upfront would allow clients to present streaming
> > > data correctly using appropriate colours and escape codes for code
> > > highlighting, for example.
> >
> > A solution to a problem of its own making.
>
> Sorry, I don't follow this point.
IMO escape codes are a hack, and universal client support can't be
expected. In fact, those may break different terminal/client types.
I think color escape codes should not be considered expected with
clients. In fact, there should probably a discussion if this should be
discouraged in the spec.
I've talked on this before (several times in fact) and my stance is that
controls codes aside from HTAB, CR and LF should not be used in text/gemini.
There's the issue that "color escape codes" are an artifact or side effect
of a terminal-based Gemini browser and it can't be relied to even exist in
the graphical browsers that are popping up. Then there's the security
issue---there are escape codes that can reprogram the keyboard, and although
the usage is rare, it is possible. There are also escape codes that can
resize the window and reposition the window, and there's no telling what
state the terminal can end in.
While I would like to disallow control codes in the specification, that
might be too big of a change, and *will* affect some sites, but adding
verbiage that discourages it can be added.
-spc
=> messages/005815.gmi Link to individual message. ## Nathan Galt <mailinglists (a) ngalt.com>
On Mon, Mar 1, 2021, at 1:24 PM, Sean Conner wrote:
It was thus said that the Great Thomas Frohwein once stated:
> On Mon, Mar 01, 2021 at 10:12:18AM +0000, Caolan McMahon wrote:
> [...]
> > > > 2. Knowing the content type upfront would allow clients to present streaming
> > > > data correctly using appropriate colours and escape codes for code
> > > > highlighting, for example.
> > >
> > > A solution to a problem of its own making.
> >
> > Sorry, I don't follow this point.
>
> IMO escape codes are a hack, and universal client support can't be
> expected. In fact, those may break different terminal/client types.
>
> I think color escape codes should not be considered expected with
> clients. In fact, there should probably a discussion if this should be
> discouraged in the spec.
I've talked on this before (several times in fact) and my stance is that
controls codes aside from HTAB, CR and LF should not be used in text/gemini.
There's the issue that "color escape codes" are an artifact or side effect
of a terminal-based Gemini browser and it can't be relied to even exist in
the graphical browsers that are popping up. Then there's the security
issue---there are escape codes that can reprogram the keyboard, and although
the usage is rare, it is possible. There are also escape codes that can
resize the window and reposition the window, and there's no telling what
state the terminal can end in.
While I would like to disallow control codes in the specification, that
might be too big of a change, and *will* affect some sites, but adding
verbiage that discourages it can be added.
-spc
Perhaps this is the wrong way to frame this, but you're prioritizing
backwards compatibility on a pre-1.0-spec to support an unintended hack
that has security issues?
If I had control codes on my capsule, I'd grumble a bit, sure, but I'd
remove them. I'm not sure it's worth it to shield the tiny handful of
all the future client implementors who'll face at least some pressure to
implement color support (and, if they're actual terminal applications,
open their users to keyboard-reset exploits).
=> messages/005818.gmi Link to individual message. ## Sean Conner <sean (a) conman.org>
It was thus said that the Great Nathan Galt once stated:
On Mon, Mar 1, 2021, at 1:24 PM, Sean Conner wrote:
>
> While I would like to disallow control codes in the specification, that
> might be too big of a change, and *will* affect some sites, but adding
> verbiage that discourages it can be added.
Perhaps this is the wrong way to frame this, but you're prioritizing
backwards compatibility on a pre-1.0-spec to support an unintended hack
that has security issues?
If I recall, escape codes where *never* in any of the specifications, just
an oversight when documenting the format (aka "loophole").
If I had control codes on my capsule, I'd grumble a bit, sure, but I'd
remove them. I'm not sure it's worth it to shield the tiny handful of
**current** capsule operators from some search-and-delete work compared to
all the future client implementors who'll face at least some pressure to
implement color support (and, if they're actual terminal applications,
open their users to keyboard-reset exploits).
I'd ban control codes in a heartbeat (except for HTAB, CR and LF as
stated), but I'm not sure how popular that decision would be.
-spc
=> messages/005821.gmi Link to individual message. ## Thomas Frohwein <tfrohwein (a) fastmail.com>
On Mon, Mar 01, 2021 at 07:48:56PM -0500, Sean Conner wrote:
It was thus said that the Great Nathan Galt once stated:
>
>
> On Mon, Mar 1, 2021, at 1:24 PM, Sean Conner wrote:
> >
> > While I would like to disallow control codes in the specification, that
> > might be too big of a change, and *will* affect some sites, but adding
> > verbiage that discourages it can be added.
>
> Perhaps this is the wrong way to frame this, but you're prioritizing
> backwards compatibility on a pre-1.0-spec to support an unintended hack
> that has security issues?
If I recall, escape codes where *never* in any of the specifications, just
an oversight when documenting the format (aka "loophole").
> If I had control codes on my capsule, I'd grumble a bit, sure, but I'd
> remove them. I'm not sure it's worth it to shield the tiny handful of
> **current** capsule operators from some search-and-delete work compared to
> all the future client implementors who'll face at least some pressure to
> implement color support (and, if they're actual terminal applications,
> open their users to keyboard-reset exploits).
I'd ban control codes in a heartbeat (except for HTAB, CR and LF as
stated), but I'm not sure how popular that decision would be.
I would support it. I think this step would work best if coupled with
best practices or code example for clients to identify and ideally
remove or warn/error if encountered. The client that I'm working on is
ncurses-based and doesn't support escape codes for that reason. But
maybe a visible difference to text without escape code would be enough
to weed out existing escape code hacks. A simple way would be to guide
clients to how to print the escape codes as plain text rather than
processing them. Could probably come up with a simple regex/tr to get
started...
=> messages/005824.gmi Link to individual message. ## Sean Conner <sean (a) conman.org>
It was thus said that the Great Thomas Frohwein once stated:
On Mon, Mar 01, 2021 at 07:48:56PM -0500, Sean Conner wrote:
> It was thus said that the Great Nathan Galt once stated:
> >
> >
> > On Mon, Mar 1, 2021, at 1:24 PM, Sean Conner wrote:
> > >
> > > While I would like to disallow control codes in the specification, that
> > > might be too big of a change, and *will* affect some sites, but adding
> > > verbiage that discourages it can be added.
> >
> > Perhaps this is the wrong way to frame this, but you're prioritizing
> > backwards compatibility on a pre-1.0-spec to support an unintended hack
> > that has security issues?
>
> If I recall, escape codes where *never* in any of the specifications, just
> an oversight when documenting the format (aka "loophole").
>
> > If I had control codes on my capsule, I'd grumble a bit, sure, but I'd
> > remove them. I'm not sure it's worth it to shield the tiny handful of
> > **current** capsule operators from some search-and-delete work compared to
> > all the future client implementors who'll face at least some pressure to
> > implement color support (and, if they're actual terminal applications,
> > open their users to keyboard-reset exploits).
>
> I'd ban control codes in a heartbeat (except for HTAB, CR and LF as
> stated), but I'm not sure how popular that decision would be.
I would support it. I think this step would work best if coupled with
best practices or code example for clients to identify and ideally
remove or warn/error if encountered. The client that I'm working on is
ncurses-based and doesn't support escape codes for that reason. But
maybe a visible difference to text without escape code would be enough
to weed out existing escape code hacks. A simple way would be to guide
clients to how to print the escape codes as plain text rather than
processing them. Could probably come up with a simple regex/tr to get
started...
I posted a BNF format for the C1 control codes here:
https://lists.orbitalfox.eu/archives/gemini/2020/000390.html
For the C0 set, just filter out anything between character 0 and 31, with
the exception of HTAB (9), LF (10) and CR (13).
-spc
=> messages/005826.gmi Link to individual message. --- => 000760.gmi Previous Thread: [announce] Delegation of responsibility for spec finalisation => 000762.gmi Next Thread: [spec] Clarify purpose of alt-text