Thanks for the patch, and sorry for delay, it took me a while to
investigate this properly. Unfortunately, there is an issue with this,
at least as far as I can tell.
I do think the approach of adding dir=auto to templates would be
preferrable, but it is unfortunately not fully addressed in your patchset.
If you look closely at the injection, you will see that it not only sets
dir=auto for inputs, but, crucially, for _every element which has text
that contains a unicode character with inherent directionality_ (as
determined by unicodeclass.bidirectional[1]).
You can easily test this: if you put some RTL content in your bio, it
will correctly render RTL, because even though the bio is just a <p>, it
will get a dir=auto slapped onto it. This, AFAICT, is not addressed in
your patches.
What this means is that we'd have to put dir=auto into _every_ element
that displays user generated content, including, I guess, files. I am
not even sure how feasible that is?
[1]
https://docs.python.org/3/library/unicodedata.html#unicodedata.bidirectional
Cheers,
Conrad
I'll go and send v2 patches for those eventually (after break). As for
the files, that's certainly going to be interesting. I think that the
files should remain as LTR? If we use dir=auto on the file display view,
then it would mess with the column limit bar.
I don't think there's an elegant way to do this, as W3C didn't envision
a way to have dir=auto propagate to every element. Running the auto
direction code would be best done client-side, but I doubt that is in
line with Sourcehut's ethos.
I'll have to identify all elements in the templates that render
user-controlled text and insert dir=auto for those. As for the files, I
think they should remain LTR for now until a solution can be found for
the column limits.
Either that, or we can preserve previous processes and pass dir=auto to
the <pre> file rendering element as well.
Happy holidays,
Ersei