On Thu, Feb 13, 2025, at 08:25, Alexis Rossi wrote:
> I don't think I'm quite comfortable with the "any constraints exist to
> ensure..." language specifically (it feels like it could be interpreted
> in an overly strict manner) but I'm fine with grouping these if that
> reads better.
>
> Maybe text like:
>
> * Images and diagrams in RFCs should be successfully rendered and
> understood by the widest audience possible. To that end, the RPC may
> prohibit the use of SVG features that are known to lack support on
> common devices, that do not render on small or low-resolution screens,
> or that could make them less comprehensible for any significant
> readership. This includes:
> ** SVGs must not contain pointers to external resources.
> ** SVGs must not contain executable script.
> ** SVGs should be as accessible as possible to people with visual
> disabilities, including those who have color blindness, those who need
> to scale or change fonts, and those who use screen reading software.
> The RPC will refer to the W3C Accessibility Guidelines {{WAI}} when
> making decisions regarding accessibility.
This is much better than mine, thanks. (I just struggled to pick the right
angle for presenting this block.)
> Okay, updated the draft to this:
>
> * Authors may include multiple versions of images or diagrams in
> rfcxml. Publication formats should present the version that is best
> suited to each format. In many cases, that will be an SVG.
👌
> I'm fine with leaving out discussion of links entirely. The thought
> behind the conversions language was to give leeway to RPC to make new
> image formats in case we adopt any new publication formats (epub is the
> one I hear about the most from people). However, I think we could leave
> that out and just cover this in a future RFC that introduces a new
> format.
Agreed. Very sensible. (We'll cross that bridge sooner than later, I suspect
with the Math discussion, but I think this establishes a good pattern for us to
follow.)
>> 1. The implementation might change over time.
>> 2. What, if any, policy we set about backwards compatibility.
>>
>> From my perspective, I would say yes to (1), but say something different
>> about (2). I would prefer to allow the RPC to make changes that are not
>> backwards-compatible (policy), but to encourage them to provide it where
>> possible (suggestion).
>>
>
> Okay, I left this in the policy section and updated the draft to say:
>
> * SVG vocabulary and implementation may change over time. Changes are
> not required to remain backwards-compatible, although maintaining
> compatibility where possible is encouraged.
Perfect, thanks Alexis.
--
rswg mailing list -- rswg@rfc-editor.org
To unsubscribe send an email to rswg-le...@rfc-editor.org
