On Wed, Jan 08, 2025 at 06:44:43PM +0000, Gavin Smith wrote: > On Tue, Jan 07, 2025 at 09:18:13PM +0100, Patrice Dumas wrote: > > > I prefer to allow this kind of customization, especially for functionality > > > that is of a wide interest, through options or variables, rather than the > > > customization API, as the former would be easier for users and also less > > > likely to break. > > > > It is always better indeed. But it also gets easily complicated to > > cater with all the possibilities. For this specific example, there > > should be two different options node/href, replacing an existing button > > or adding another with the same name should be distinguished, the user > > may want to have the button prepended or postpended, only for headers > > and not footers, only if split at nodes... Also, to do the same in the > > default case for global directions, you need to specify description, > > accesskey, rel... I think that it would be better to make it easier to > > do it with init files rather than try to have an interface for all the > > possibilities. > > Good point. Perhaps we should provide a stable customization API > for navigation buttons only and document it well, as it seems like a fairly > common thing that people want to customize.
I fully agree. The current possibilities offered by the HTML customization API for buttons are too low-level. We can aim for a stable API, but I am a bit skeptical that we can do a perfect API in one try... -- Pat
