Re: Add id's to various elements in protocol.sgml
| От | Brar Piening |
|---|---|
| Тема | Re: Add id's to various elements in protocol.sgml |
| Дата | |
| Msg-id | e50193ea-ca5c-e178-026a-f3fd8942252d@gmx.de обсуждение исходный текст |
| Ответ на | Re: Add id's to various elements in protocol.sgml (Brar Piening <brar@gmx.de>) |
| Ответы |
Re: Add id's to various elements in protocol.sgml
Re: Add id's to various elements in protocol.sgml |
| Список | pgsql-hackers |
On Mar 01, 2022 at 18:27, Brar Piening wrote: > On Feb 28, 2022 at 21:06, Chapman Flack wrote: >> I think that in other recent examples I've seen, there might be >> (something like a) consensus forming around the Unicode LINK SYMBOL >> 🔗 rather than # as the symbol for such things. > > I intentionally opted for an ASCII character as that definitely won't > cause any display/font/portability issues but changing that is no > problem. TBH I don't like the visual representation of the unicode link symbol (U+1F517) in my browser. It's a bold black fat thing that doesn't inherit colors. I've tried to soften it by decreasing the size but that doesn't really solve it for me. Font support also doesn't seem overwhelming. Anyway, I've changed my patch to use it so that you can judge it yourself. >> ... and now that the concept is proven, how hard would it be to broaden >> that template's pattern to apply to all the other DocBook constructs >> (such as section headings) that emit anchors? > > As long as we stick to manually assigned ids in the same way my patch > does it, it shouldn't be too hard. Patch is attached. I don't think it should get applied this way, though. The fact that you only get links for section headers that have manually assigned ids would be pretty surprising for users of the docs and in some files (e.g. protocol-flow.html) only every other section has a manually assigned id. It would be easy to emit a message (or even fail) whenever the template fails to find an id and then manually assign ids until they are everywhere (currently that means all varlistentries and sections) but that would a) be quite some work and b) make the patch quite heavy, so I wouldn't even start this before there is really consensus that this is the right direction.
Вложения
В списке pgsql-hackers по дате отправления: