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 ms13.migadu.com with LMTPS id KM1qNjWhnmYyhwAAqHPOHw:P1 (envelope-from ) for ; Mon, 22 Jul 2024 18:13:10 +0000 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 KM1qNjWhnmYyhwAAqHPOHw (envelope-from ) for ; Mon, 22 Jul 2024 20:13:09 +0200 X-Envelope-To: larch@yhetil.org Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=posteo.net header.s=2017 header.b=rd+x4evy; 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=1721671989; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:list-id:list-help: list-unsubscribe:list-subscribe:list-post:dkim-signature; bh=O/iGBB6p3WhSSyun0DS03OVv3IFw37pkAn9B0tYOEAU=; b=RdtkTgXBGiI02tLTzIHA1luQ5PJ0rTDDTFwn8Y+JuhyFIoPanbdw/hsbxLgTxPErHjHCnS OXOs5cTF7KyDWarfLU+SkF5Lzn6xW+i0e4Zj5JEiVDKsaNIRYxF1/MbkPMEZOAw4xl2rlf wWBknpFjy1zTbOOYCixGF1L7+dEJqs/V4nvjFmV4eEoizk9SAHXx/EUs06NrdespMChvv/ 0On45HYu8v4KG3BJkbB3YlGyAcQITZnOEy2l9qLLOrvG4509YCdMQU0EKjHZ1czkmSTFIK mvFZ17vpSLPUUk33kwO4y5aVX8N3HhlXtuZS1IPlhwazj59gATle6UjME6aNSg== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1721671989; a=rsa-sha256; cv=none; b=n9033KtkFeyjcCAba/NjKr2VuVR4NQrY1YkKz4a/vZkrxuUAvxIk2+tNFj/8aS9juqJI0U sgpk8KVx4CCdE3DABs24bxfwlDa29iDKJAsnjgYf9bTZGyIAPgqOu/SrElVVdRjYiL2Y5/ rfyQvcJt+OYte7QMhAzGKLPjfP+Q0R65dRctAD+HzreOwq1oD5AgTnIvtAT3oR+IPpldbF 77E+hgbZYi7wC/WGWIBnZ2udYrxieXTjiUu4XkASucEwSYChfe++UzpD5uVj+ZpZOODgoN 4JQiL88+9+W7Jk1zGODMoq5VRcQqhu+SL0HcuXR/5hO/pw6dgZXx9pPCq6QiNQ== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=posteo.net header.s=2017 header.b=rd+x4evy; 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" 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 B1DE672BA6 for ; Mon, 22 Jul 2024 20:13:09 +0200 (CEST) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1sVxW2-0003KR-1B; Mon, 22 Jul 2024 14:12:06 -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 1sVxVz-0003Cw-JW for emacs-orgmode@gnu.org; Mon, 22 Jul 2024 14:12:03 -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 1sVxVu-0005P3-IZ for emacs-orgmode@gnu.org; Mon, 22 Jul 2024 14:12:03 -0400 Received: from submission (posteo.de [185.67.36.169]) by mout01.posteo.de (Postfix) with ESMTPS id E486424002B for ; Mon, 22 Jul 2024 20:11:54 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1721671914; bh=hUJ/A/ds/5xKosmF/eepLukj1JDtzYm7mu20LAEOBQA=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:Content-Type: Content-Transfer-Encoding:From; b=rd+x4evy5HiwaT8fZBZFOv6bIqX5D7NoRAMUyWE2Pz2DZMroWwzEMLwBBnc21L+Xy ZfnoIYiRMw2J0TzfpxbdPRIA0w3+h2zm7xKCyFUOMwAMRzqVldWO/nPf+B2elGcbzO k9BrnFXCBhIrB3lmo3pNoDTC1VhYaRkqFnGYGRaiwreCl4I3v5f5PZJ28Rnl6wXHpM bFVGWyQ1dymBRWb629U8XTI5+mVXqmn/kgWz6X37ZKAf8PUWUEmI8bJD8ijVEExees 9GrU5qnG45T+mKzTpHIC0qP/vfj1v6EFVQPGw9X7eubbTezPnm93oSxNK+YEzzIFag GjcmfUQG14vRQ== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4WSSzG25Gkz9rxQ; Mon, 22 Jul 2024 20:11:54 +0200 (CEST) From: Ihor Radchenko To: Suhail Singh Cc: TEC , Org mailing list Subject: Re: [PATCH] [BUG] Support attr_html in source code and fixed-width blocks In-Reply-To: <87r0bl2vyv.fsf@gmail.com> References: <87v8277ye7.fsf@gmail.com> <877cems1t4.fsf@localhost> <8734o5v1sg.fsf@gmail.com> <87le1tmt8w.fsf@localhost> <87r0bl2vyv.fsf@gmail.com> Date: Mon, 22 Jul 2024 18:13:22 +0000 Message-ID: <87a5i9mh19.fsf@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable 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.001, RCVD_IN_MSPIKE_WL=0.001, 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: -6.64 X-Spam-Score: -6.64 X-Migadu-Queue-Id: B1DE672BA6 X-Migadu-Scanner: mx11.migadu.com X-TUID: vHyvFPortbdi Suhail Singh writes: >> Please address my concern about :textarea attribute. I do not see why >> we should ignore it here. > > I don't understand your concern. Could you please elaborate on what you > mean by "why we should ignore it here"? What is the "it" and what is > the "here"? Your request, in its core, is asking to make treatment of verbatim blocks more regular in ox-html. So, if we start allowing arbitrary attributes in more blocks, may as well include specially handled attributes like :textarea. As a bonus, it will be possible to factor out common code handling attributes (including :textarea) into a new internal function that can then be reused. >> I am not sure if we want to add all the attributes to every transcoded >> element. At least in some cases, we do discard them >> (`org-html--textarea-block'). > > From the manual: > > #+CAPTION: [[info:org#Text areas in HTML export][org#Text areas in HTML e= xport]] > #+begin_quote > The HTML export backend can create such text areas. It requires an > =E2=80=98#+ATTR_HTML=E2=80=99 line as shown in the example below with t= he =E2=80=98:textarea=E2=80=99 > option. This must be followed by either an example or a source code > block. Other Org block types do not honor the =E2=80=98:textarea=E2=80= =99 option. > #+end_quote > > The current processing of :textarea does special handling for width and > height attributes and discards the rest (based on my understanding of > the code in `org-html--textarea-block'). Said support for :textarea > attribute exists in `org-html-src-block' and `org-html-example-block' > which is consistent with the manual. Yup. But since you are asking to add new features to ox-html, we may as well do it in full (support all attributes, including special attributes). > In order to make the code more robust, one may wish to remove :textarea > from the list of attributes (or issue a user-error or warning if it's > present) in blocks that were never intended to support it (such as > `org-html-fixed-width'). I do not have any opinion on this matter. My opinion here is not to remove :textarea, but to treat it as we do in other places. > There is an open question regarding what attributes to support in > `org-html--textarea-block' (i.e., in the presence of `:textarea' > option). I believe the "correct" thing would be to filter out `:width' > and `:height' (since, if present, they are translated into `rows' and > `cols' attributes in the generated HTML) and include the rest "as is" in > the generated HTML +1 > Regardless of the specifics above regd. :textarea, I believe support for > #+ATTR_HTML ought to be added for most blocks to allow for CSS class > and/or inline style to be specified when exporting to HTML. +1 > Additionally, I consider the absence of such support to be a bug. Since we do not promise it anywhere, it is not necessarily a bug. But it would make sense to support setting arbitrary attributes, yes. --=20 Ihor Radchenko // yantar92, Org mode contributor, Learn more about Org mode at . Support Org development at , or support my work at