Hello all,
I've uploaded a new version of the draft at
https://datatracker.ietf.org/doc/draft-rossi-svgsinrfcs/ which incorporates
the discussions up to this point. Also I have added Martin as a co-author.
We have seen support for the idea so far, with most of the suggested
changes/discussion being minor. If the chairs agree, I'd like to ask that
we move forward with adoption.
Thanks,
Alexis
On Wed, Feb 12, 2025 at 4:33 PM Martin Thomson <m...@lowentropy.net> wrote:
> 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
