Ihor Radchenko writes:
> Tim Cross writes:
>
>> Sadly, org isn't great from an accessibility perspective. This is
>> something I would like to see improved, but it is a huge and complex
>> task. There are some 'easy' winds we could try. For example, org still
>> defaults to using the and
Tim Cross writes:
> Sadly, org isn't great from an accessibility perspective. This is
> something I would like to see improved, but it is a huge and complex
> task. There are some 'easy' winds we could try. For example, org still
> defaults to using the and tags instead of
> and . Likewise,
Max Nikulin writes:
> If alternative text for images and description of
> links are not convincing [...]
It does convince me, Maxim, that's why I told you in my previous message
that you were right in that example you had put about the alternate
text. And my question was (and still is) if you
On 21/06/2022 02:06, Juan Manuel Macías wrote:
Max Nikulin writes:
I would like to stress that styles can not be a rescue in some
important cases. Let's leave aside ad hoc final tuning of formatting.
In the case of HTML export there are still and
attributes that are namely
per-object, not
Max Nikulin writes:
> On 19/06/2022 19:47, Juan Manuel Macías wrote:
> Concerning vs. , is it the same for assistive
> technologies like screen readers to add text (or text)
> and text with "font-weight: bolder;" in CSS?
First, never use or , only use semantic tags for
accessibility.
The
Max Nikulin writes:
Hi Maxim,
Max Nikulin writes:
> I would like to stress that styles can not be a rescue in some
> important cases. Let's leave aside ad hoc final tuning of formatting.
> In the case of HTML export there are still and
> attributes that are namely
> per-object, not part of
On 19/06/2022 19:47, Juan Manuel Macías wrote:
I am more and more convinced that inline special blocks, by their
nature, should not support fine tune options or anything like
attr_latex, attr_html, etc. like its older brothers, as it would produce
an overly complicated syntax.
I would like to
Juan Manuel Macías writes:
> To add some ideas that have been occurring to me these days...
>
> I am more and more convinced that inline special blocks, by their
> nature, should not support fine tune options or anything like
> attr_latex, attr_html, etc. like its older brothers, as it would
Hi, Christian,
Thanks for your comments.
Christian Moe writes:
> Hi,
>
> This makes sense to me.
>
> Note: For the html output in your example, I expect you don't mean
> contents>, but contents. That
> would give the desired custom style controle of the output, and would
> parallel the behavior
Juan Manuel Macías writes:
> To add some ideas that have been occurring to me these days...
>
Hi,
This makes sense to me.
Note: For the html output in your example, I expect you don't mean
contents>, but contents. That
would give the desired custom style controle of the output, and would
To add some ideas that have been occurring to me these days...
I am more and more convinced that inline special blocks, by their
nature, should not support fine tune options or anything like
attr_latex, attr_html, etc. like its older brothers, as it would produce
an overly complicated syntax. Big
Ihor Radchenko writes:
> While arbitrary markup can indeed be introduced using our current link
> syntax, there is one important limitation of links:
>
> *** link description cannot contain other links ***
>
> If one seriously tries to extend Org syntax with custom markup elements,
> nested
Ihor Radchenko writes:
> Vestibulum convallis, lorem blockname_[<>]{text} a tempus semper, dui
> dui euismod elit, vitae placerat urna tortor vitae lacus.
This thread is possible relevant to the ongoing emacs-devel discussion
where RMS requested support/integration of Org and texinfo.
Richard
Hey Kaushal! Thanks for your insight.
On Thu, May 26 2022 17:22, Kaushal Modi wrote:
> - Issues section is there for a reason. If the repo owner did not like
> people opening Issues, they would disable that section.
I agree with Ihor's response for this point.
> - Conversations and
Kaushal Modi writes:
>> I reached out to him on e-mail, if he doesn't reply there I'll create
>> the issue. Thanks!
>
> Just saying this based on my personal preference. I would rather
> prefer that people directly open an issue on Github than emailing me
> personally.
>
> Reasons:
>
> - Issues
On Thu, May 26, 2022 at 1:36 PM João Pedro wrote:
>
> On Thu, May 26 2022 20:20, Ihor Radchenko wrote:
>
> > I think that you can simply open an issue in his Github repo.
>
> I reached out to him on e-mail, if he doesn't reply there I'll create
> the issue. Thanks!
Just saying this based on my
On Thu, May 26 2022 20:20, Ihor Radchenko wrote:
> I think that you can simply open an issue in his Github repo.
I reached out to him on e-mail, if he doesn't reply there I'll create
the issue. Thanks!
--
João Pedro de Amorim Paula
IT undergraduate at Universidade Federal do Rio Grande do
João Pedro writes:
>> I am not sure if I mentioned this earlier, but org-special-block-extras
>> could be a good addition to Org core.
>
> Has anyone tried reaching out to the author? I think it would be a great
> addition! It is a seemingly simple idea that opens up some many
> possibilities in
On Thu, May 26 2022 12:56, Ihor Radchenko wrote:
> I agree. But it is a known problem on defining new specific command vs.
> running a new generic command with arguments. You can indeed define a
> new command (block in our case), but if you just need to adjust some
> parameter once in the whole
+1
Eric S Fraga writes:
> On Tuesday, 24 May 2022 at 10:51, Timothy wrote:
>> To me, this is another reason for comment and #+attr_X lines not to
>> break paragraphs [...].
>
> And, in fact, if this were true (which I would like), I personally would
> see no reason for having inline special
João Pedro writes:
>> #+attr_latex[name]:
>> Vestibulum convallis, lorem blockname_[<>]{text} a tempus semper, dui
>> dui euismod elit, vitae placerat urna tortor vitae lacus.
>>
>> "<>" will be treated as "" during
>> export/parsing.
>
> Although I do agree that this sort of solves the same
Max Nikulin writes:
>> First line
>> # comment
>> Second line
>>
>> Should we consider a comment as inline object? I suspect that such
>> change will cause unpredictable breakages all around Org and third-party
>> packages.
>
> I believed that comments are stripped before passing to export
On 25/05/2022 14:22, Ihor Radchenko wrote:
Max Nikulin writes:
On 24/05/2022 09:51, Timothy wrote:
To me, this is another reason for comment and #+attr_X lines not to break
paragraphs, as then we can just re-use #+attr_X lines.
I will raise a compatibility issue, but it is bad enough to not
Ihor Radchenko writes:
> I think that we might simply allow to define complex configuration
> before the containing paragraph. Something like:
>
> #+attr_latex[name]:
> Vestibulum convallis, lorem blockname_[<>]{text} a tempus semper, dui
> dui euismod elit, vitae placerat urna tortor vitae
Max Nikulin writes:
> On 24/05/2022 09:51, Timothy wrote:
>>
>> To me, this is another reason for comment and #+attr_X lines not to break
>> paragraphs, as then we can just re-use #+attr_X lines.
>
> I like the idea that comments and attribute lines should not be
> paragraph separators. I
On 24/05/2022 09:51, Timothy wrote:
To me, this is another reason for comment and #+attr_X lines not to break
paragraphs, as then we can just re-use #+attr_X lines.
I like the idea that comments and attribute lines should not be
paragraph separators. I expect, it should alleviate the issue
On Tue, May 24 2022 11:56, Ihor Radchenko wrote:
> I think that we might simply allow to define complex configuration
> before the containing paragraph. Something like:
On that note, I think that allowing for inline special blocks would make
that more readable. It would work wonderfully with
On Tuesday, 24 May 2022 at 10:51, Timothy wrote:
> To me, this is another reason for comment and #+attr_X lines not to
> break paragraphs [...].
And, in fact, if this were true (which I would like), I personally would
see no reason for having inline special blocks.
Just my 2¢.
--
: Eric S
Hi Tim,
Tim Cross writes:
>> But that is an abuse of direct formatting, which I think should always be
>> avoided, especially in a format-agnostic environment like Org, which is
>> more of a logician than a typesetter :-)
>
> I think this is a really important point. Whenever we add formatting
Tim Cross writes:
>> I think a major issue would also be how to properly compact <[options]>
>> so as not to result in too overloaded syntax. Maybe something like:
>>
>> [latex(list of attributes) html(list of attributes)...]
>>
>> ?
>>
>> But that is an abuse of direct formatting, which I think
I've not got a lot to add here. I'm not against the idea, but Juan makes
some points below which I think are particularly important and wanted to
add weight to them!
Juan Manuel Macías writes:
> Hi, Kaushal, thanks for all your interesting comments,
>
> Kaushal Modi writes:
>
>> The
Hi, Kaushal, thanks for all your interesting comments,
Kaushal Modi writes:
> The challenging part will be deciding the syntax so that there are no
> false matches.
>
> May be reserve "inline_" for inline blocks?
>
> e.g. inline_[options]{text} ?
It seems to me the most consistent option, if
On Mon, May 23, 2022 at 10:33 AM Juan Manuel Macías
wrote:
> I think this idea was suggested by Ihor in a thread from a few months
> ago (I don't remember which one), but since other topics were discussed,
> the idea remained a bit in limbo. I still find the idea very
> interesting, and I think
Hi all,
I think this idea was suggested by Ihor in a thread from a few months
ago (I don't remember which one), but since other topics were discussed,
the idea remained a bit in limbo. I still find the idea very
interesting, and I think it would be very productive for Org to have a
multipurpose
34 matches
Mail list logo
