- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Mon, 8 Nov 2021 12:07:03 -0500
- To: spec-prod@w3.org
On 11/7/21 6:48 PM, Marcos Caceres wrote: > > We could take up the discussion there, along with what we want to see/do to make this less painful. > > For example: > > * where should we gather the list of candidate corrections/additions? In the SoTD? In their own section? In their own section. The point is that people reading a particular section of the spec can know what change is being proposed to that spec. If candidate amendments are kept in a separate place, it's got the same cross-referencing problems as our previous "solution" of maintaining an errata page. (Mainly, that people forget to cross-reference the errata when looking things up.) > * What do we do about inline corrections? base.css doesn't say it supports "span" elements, for instance. Not sure I understand what you're asking for. INS and DEL are inline elements, they can easily be used to mark up inline changes? https://www.w3.org/StyleSheets/TR/2016/README#amendment > * Should people be using ins/del for these? Yes, that is required, see https://www.w3.org/StyleSheets/TR/2016/README#amendment > Apparently, from a discussion elsewhere, those elements are not accessible. If that's the case, then it's a problem with all HTML diff formatting, not just candidate amendments, and the best you can do is write a proper description of the changes to accompany the diffs. ~fantasai
Received on Monday, 8 November 2021 17:07:21 UTC