From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp0.migadu.com ([2001:41d0:403:58f0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms1.migadu.com with LMTPS id 2F0EGxcuHGauBAAAqHPOHw:P1 (envelope-from ) for ; Sun, 14 Apr 2024 21:27:19 +0200 Received: from aspmx1.migadu.com ([2001:41d0:403:58f0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp0.migadu.com with LMTPS id 2F0EGxcuHGauBAAAqHPOHw (envelope-from ) for ; Sun, 14 Apr 2024 21:27:19 +0200 X-Envelope-To: larch@yhetil.org Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=posteo.net header.s=2017 header.b="OQK/rObq"; dmarc=pass (policy=none) header.from=posteo.net; spf=pass (aspmx1.migadu.com: domain of "emacs-orgmode-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="emacs-orgmode-bounces+larch=yhetil.org@gnu.org" ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1713122839; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:in-reply-to:in-reply-to: references:references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:dkim-signature; bh=GLMXfCJm7q170VuoX4kxVYUeVnik0oRFIgB3ExDnFcc=; b=D2L7oz+ajE3ISkwTqPEGjJ4Ye3fj46CVX7pewsVE/zDd0vWWRrKt6tgMzqQgJquB0p+lPl rISEhIRLVdXScHgUq2mJOeCepphmqL/qNI9UmYSy3EI33/6i/XAngfmNhxrV+BJr1duVzE iql59Jr8V4xdOhdbdPDhh+pHy1P2W+u9Q4TZ+7aeIfzyHQh6nmdYi4EecdyoPi+j5+S/Ml MXCdGEGncZg7VhK2cppC0Nq2LqFQknAMtI1SHV+CoREHIVHnTO1SPLCDwj40djKIcrMeoh 1/1pEHq9xBdvvZxWBjTkvUphRaZmciMEw+/u9jQXXsjvI4jQY4Y0vUnGlvKmFg== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=posteo.net header.s=2017 header.b="OQK/rObq"; dmarc=pass (policy=none) header.from=posteo.net; spf=pass (aspmx1.migadu.com: domain of "emacs-orgmode-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="emacs-orgmode-bounces+larch=yhetil.org@gnu.org" ARC-Seal: i=1; s=key1; d=yhetil.org; t=1713122839; a=rsa-sha256; cv=none; b=WopXSb+aesfnNZKVGEmn6Tuapb7fZGwM2pDRcXB/9XllwPEjMZgnY82t6H9GoRHESnPGWL eB0XcoPNpaZLcSOB0/zQUDz6vqd+OLf4qtyzTKmNHvhwAk9Cfrcapk9W0uTChchnf3YnI3 iAwgHEVs9oGYB03r1Jg1dyG+gCQCAw1Lb+UXCDdlbLAp6Y5+vJphOhbMlQCOC2HjFNu1lm sptegWWElCXY1stBN3HBNvO/IMcop+efV01qS3GTYPohlm2aR46BVlm/VbCosu8OoiTGI5 jOdm0MHLyqgXLbIdJcTxCdE8zE04T1GfyAXZPab9suT55UZ1Dt5at7gKTnVMVw== Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id 1E556C35D for ; Sun, 14 Apr 2024 21:27:19 +0200 (CEST) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rw5Un-0006d4-2Z; Sun, 14 Apr 2024 15:26:33 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rw5Ul-0006cg-34 for emacs-orgmode@gnu.org; Sun, 14 Apr 2024 15:26:31 -0400 Received: from mout01.posteo.de ([185.67.36.65]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rw5Ui-0008Ch-2A for emacs-orgmode@gnu.org; Sun, 14 Apr 2024 15:26:30 -0400 Received: from submission (posteo.de [185.67.36.169]) by mout01.posteo.de (Postfix) with ESMTPS id 97866240027 for ; Sun, 14 Apr 2024 21:26:23 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1713122783; bh=rDcoNjTP4jxLkVUHVdKX5JCd+TKqUnZNkVX7ZskNwWU=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:Content-Type: From; b=OQK/rObq1WWSlVC5mvyWUgq5BzDvPo7s1kfHSELfkXwD0hGXL/ON/Bw7L+Nj1MFB4 tMWLCwGLwH7RMcJCm5ZnMBjO7/pXzWeO4zvYiDxWC9kXnIHhGIQaCTCZhKq4qX6TZc bPiwpdQTWtit3TW+hguTm+71aHcjBXVaQrsW/4GkASzFe1Hj4oQk2waMjnCJJ/NfaF pn+WvCM8M+qnJKh4w3jyxOKtlsWH5bDwY4UJr9z1nQi8qqvLPYUzpUI6CvUM54NOZp IWJcC9ri8UCe7XaGFD9+kF+pls0are+CHqARKimeZIgxs1+K3BMcCBwAbwIu5n5XQz zO/BnLa17XrCQ== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4VHgJt6Nskz9rxM; Sun, 14 Apr 2024 21:26:22 +0200 (CEST) From: Ihor Radchenko To: Rick Lupton Cc: Juan Manuel =?utf-8?Q?Mac=C3=ADas?= , "Y. E." Subject: Re: Attributes on images (was:: Experimental public branch for inline special blocks) In-Reply-To: References: <87wmql6690.fsf@posteo.net> <875xwqj4tl.fsf@localhost> Date: Sun, 14 Apr 2024 19:26:53 +0000 Message-ID: <87seznrbia.fsf@localhost> MIME-Version: 1.0 Content-Type: text/plain Received-SPF: pass client-ip=185.67.36.65; envelope-from=yantar92@posteo.net; helo=mout01.posteo.de X-Spam_score_int: -43 X-Spam_score: -4.4 X-Spam_bar: ---- X-Spam_report: (-4.4 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-orgmode@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+larch=yhetil.org@gnu.org Sender: emacs-orgmode-bounces+larch=yhetil.org@gnu.org X-Migadu-Flow: FLOW_IN X-Migadu-Country: US X-Migadu-Spam-Score: -9.58 X-Migadu-Scanner: mx11.migadu.com X-Spam-Score: -9.58 X-Migadu-Queue-Id: 1E556C35D X-TUID: /gUJkj8aP6Vt "Rick Lupton" writes: >> #+attr_html: :height 300 >> [[file:image.png]] has a height of 300, but what if we want a >> different height in @@[:html-height 300]{[[file:another-image.png]]}? >> >> Note how @@{...} markup assigns attributes to objects inside - the >> attributes should be somehow inherited. > > This way of assigning a height to the image seems odd to me. Mostly, the attributes specified by the inline block apply to the block, not the contents, so wouldn't this case be potentially surprising? We already have #+attr_html: :height 300 that applies to the whole paragraph and it is not going anywhere. So, my idea is natural given the existing convention. And I explicitly suggested that attributes of anonymous inline blocks @@[...]{...} will be inherited by all other markup. This is not just for images, but in case if we want some extra configuration for other traditional Org markup: @@[:weight semi-bold]{All the *bold text here* will *be* semi-bold.} Also, one may do something like @@[:html-height 300]{This [[file:image.png]] and that [[file:other-image.png]]}, but not third [[file:yet-another-image.png]]. > Both of these examples mean different things in HTML, and it seems like you might want to create either -- how would you control which was produced using the "@@[:html-height 300]{[[file:another-image.png]]}" syntax? > > > > Anonymous inline markup will not at all be exported by itself. Its purpose is to provide attributes or serve as back escape sequence. So, I envision your examples as @span{@@[:html-height 300]{}} @span[:html-style height: 300]{} > Instead, I wonder if the problem is that the way of inserting an image using a link itself. If you need more control, could there be a special "img" inline special block which can handle additional attributes? > > For example: > > Or, if using the original syntax, perhaps the attribute should be explicitly :img-attr or :img-height to resolve the ambiguity about which element is being targetted? I do not have much of an opinion about the attribute names. If we need to make them unique, that's totally fine and does not affect the overall syntax design. I used image height simply as an illustration of the idea of attribute inheritance. The above example with attributes for *bold* is illustrating the same idea. > @img[:height 300]{image.png} has a height of 300, and we can also have images with different heights and attributes like @img[:height 400 :alt "An image"]{another-image.png}. This is also an option, although it allows setting attributes only for a single image. Maybe we can modify the anonymous markup to make its attributes be inherited by a subset of the markup inside: @@[:parent-of link :height 300]{Only [[file:link.png]] inherits :height attribute, but not @bold{other markup}} This way, we can have some interesting options for ad-hoc markup like #+inline_attr:tall: :parent-of link, latex-fragment :height 1000 @tall{All the images and latex inside will be tall: \(x^2\)} Another aspect of your example is that you implicitly suggested an alternative link markup, which raises a more general question - should we allow making the inline markup an alias of an existing markup? This may require two alternative approaches: a. Special treatment of certain inline markup names, like @code{verbatim code} @verbatim{...} @bold{...} @italic{...} @underline{...} @strikethrough{...} @link[...]{path}{description} (we need such special treatment to make sure that, for example, @bold{...} in Org files can still be correctly exported by export backends not aware about the new inline markup) b. In addition to :export_template idea I proposed that would define custom *per-backend* export rules, we will need some way to define ad-hoc markup in terms of the more traditional Org markup: @code{...} == ~code~ @bold{...} == *bold* or even @alert{...} == @bold{@italic{...}} I personally feel that b is more powerful, but it is getting so close to the idea of {{{macros}}} that we may confuse users. -- Ihor Radchenko // yantar92, Org mode contributor, Learn more about Org mode at . Support Org development at , or support my work at