From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp10.migadu.com ([2001:41d0:2:bcc0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms5.migadu.com with LMTPS id UH/CJ83FsGLJIQAAbAwnHQ (envelope-from ) for ; Mon, 20 Jun 2022 21:09:01 +0200 Received: from aspmx1.migadu.com ([2001:41d0:2:bcc0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp10.migadu.com with LMTPS id iBG9Js3FsGLp3AAAG6o9tA (envelope-from ) for ; Mon, 20 Jun 2022 21:09:01 +0200 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 DED7C3D21D for ; Mon, 20 Jun 2022 21:09:00 +0200 (CEST) Received: from localhost ([::1]:35986 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1o3Mle-000655-PP for larch@yhetil.org; Mon, 20 Jun 2022 15:08:58 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:57454) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1o3MjR-0004vV-Dg for emacs-orgmode@gnu.org; Mon, 20 Jun 2022 15:06:41 -0400 Received: from mout01.posteo.de ([185.67.36.65]:39041) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1o3MjP-0004dy-1P for emacs-orgmode@gnu.org; Mon, 20 Jun 2022 15:06:41 -0400 Received: from submission (posteo.de [185.67.36.169]) by mout01.posteo.de (Postfix) with ESMTPS id 8CFED240028 for ; Mon, 20 Jun 2022 21:06:29 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1655751989; bh=L9MzbjS4ff9iSXKiLGKin7+6Fmax0E4d/KXQGTv62sc=; h=From:To:Subject:Date:From; b=Jsnu0JExi09KRv7S3qxYmoVMV6x/B6RJ6g1RkElKfLzuptb3CDkawVHd+BLsbj7Gd kVHmd3NNAEE9M9QOLiYQOKFOwlDZ6AS4g4ToNF75+/QIetX3cudzpezU8ImIDJijEU 4PpTiOMj1GVMiiVWU1IwcHuTUa1oXvb1VK7uUalnVoWIRZ7aq+qxM85PCuUGQdWeLI VIy7M79nvnCjCCgyhBzUqK0fbe9deH05bFVXrS6dEl8C2SYj1qVN7QvrnfnkYZL8C9 xZtr7CNuMW6ffCLPIYWcWdeqDlN83p/wDpMsB95GBuez+NZIb89xrKev7ev/29+wQI kXZrLlaGUbjaA== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4LRfJP0dhwz6tmb for ; Mon, 20 Jun 2022 21:06:28 +0200 (CEST) From: =?utf-8?Q?Juan_Manuel_Mac=C3=ADas?= To: orgmode Subject: Re: About 'inline special blocks' References: <87a6b8pbhg.fsf@posteo.net> <875ykwvmz7.fsf@posteo.net> Date: Mon, 20 Jun 2022 19:06:26 +0000 In-Reply-To: (Max Nikulin's message of "Mon, 20 Jun 2022 23:57:12 +0700") Message-ID: <87bkunb1e5.fsf@posteo.net> MIME-Version: 1.0 Content-Type: text/plain Received-SPF: pass client-ip=185.67.36.65; envelope-from=maciaschain@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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 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" X-Migadu-Flow: FLOW_IN X-Migadu-To: larch@yhetil.org X-Migadu-Country: US ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1655752141; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to: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=mFnGMyf8fA1HpuaEze14rc7ju+YPqDtqzabuP7WOgqM=; b=NiT00NLshvKWgoALW52KrPzPdAHPd4H6bvnP2iws1nE9hpxwBTbZbgsN9IMwjQd10V2ATP SRzA1L+wYC/kctqxOS8zcZjlfh+kqS3JkmPAF21pn2W3RJNFyUPYS8luscAwl1rN0K9kVv 5zZlmZZl1kSPWa7RGBIstlxrVuqnSpbQqEta+iS8zJL+bSfU6WQcCSbzs2Cc7/scF9XdLq p8qvwuCRqmC+NN8mMxp7kAKeJX9L2LJA3jXezbGFoClH+0GyBkkPCiECPLlPK0uQfZ3lnT uKdd4SRlvhJJh+jyeo1lEwPcuFKizmosrGNggJFZPj7dp9XIAMaHAnDTfcG6MQ== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1655752141; a=rsa-sha256; cv=none; b=uC9CBbkynlQFbWB2dgKGHvQAH9BptyjnLRk89cEac6TbHiDNDNh14axcYiz3txBUtxgwyz OtlhOwnPnooaDDVwCWQDpC8AWc20Pe3APwvKJCzhu5KylxOn3c1o1I3iNXFNw6CDcWrsTH oRScwePCthdS1WnaD4l7vGk32ibmoqnMzhXD6hC4W2xBCqfY2nWHaBWUtrczFynVSTaY47 5oMBtaKZ9olt6fdal67vNfD+P9PgjnPJIGfYn6OB0uy0flCFkYuz3R5BHm4d/a9FR5DoVg FJ8Ddz4H4+sD60joTCfMkE/lIbX5K+YBqlOEpcm9kleX/g11zKyZYboVPVek9w== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=posteo.net header.s=2017 header.b=Jsnu0JEx; 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" X-Migadu-Spam-Score: -2.67 Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=posteo.net header.s=2017 header.b=Jsnu0JEx; 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" X-Migadu-Queue-Id: DED7C3D21D X-Spam-Score: -2.67 X-Migadu-Scanner: scn1.migadu.com X-TUID: xqINvvOok+pX 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 Description and > attributes that are namely > per-object, not part of style. You are right, but my question is: Could there be a similar use case within inline special blocks? Keep in mind that this (for now, hypothetical) element type would be intended only for very short segments of text within the paragraph. I don't find a scenario where it's worth overloading that with options and attributes, IMHO. I believe that direct formatting (as a rule of composition and not as an exception), which comes ---I suppose--- from the use and abuse of word processors, is the great cancer for the consistency of the documents, where a guiding style and a series of constants must prevail. Of course, I do not deny that it is often necessary to do a post-process and adjust exceptions. There are always exceptions. In the case of LaTeX and ConTeXt, TeX is powerful enough to deal with exceptions also at a high level, due to its high degree of automation. And LuaTeX, even more so. A simple example to automatically adjust the width of the caption in figures with a simple lua function in LuaLaTeX: #+begin_src latex \begin{luacode*} function caption_width ( text ) text = string.gsub ( text, "(\\includegraphics.+)", "\\sbox0{%1}") text = string.gsub ( text, "(\\caption{.+})", "\\begin{minipage}{\\wd0}\\usebox0%1\\end{minipage}") return text end \end{luacode*} \newcommand\CaptionAutoWidth{\directlua{luatexbase.add_to_callback ( "process_input_buffer" , caption_width , "caption_width" )}} \AtBeginDocument{\CaptionAutoWidth} #+end_src However, note that I speak in general terms. It is difficult to get rid of manual intervention one hundred percent. But the question is whether it's worth adding fine-tuning options to an element as "specialized" as inline special blocks. Of course, LaTeX is more flexible and you can always change a variable on the fly. You can do something like: #+begin_src latex \definecolor{foo}{HTML}{FF0000} \definecolor{var}{HTML}{7CFC00} \def\mycolor{foo} \newcommand\mytextcolor[1]{% \textcolor{\mycolor}{#1}} \begin{document} lorem \mytextcolor{ipsum dolor} \def\mycolor{var} lorem \mytextcolor{ipsum dolor} #+end_src html/css seems more rigid and I'm not that familiar with it. Perhaps there is more uses case where the existence of ad hoc attributes and options would be justified? And, in any case, how to implement it without the paragraph becoming unreadable? The solution that Ihor commented on in a past post of using identifiers for each inline block would be fine (and maybe it could be used also for the attributes of the links within the paragraph). >> in html: >> contents> > > Concerning vs. , is it the same for > assistive technologies like screen readers to add > text (or text) and class="strong">text with "font-weight: bolder;" in CSS? "contents>": it was my confusion, sorry. I already explained it here: https://list.orgmode.org/8735g0tnoh.fsf@posteo.net/ Best regards, Juan Manuel