Hi, Regarding "SVGs must render in a single static configuration without dynamic elements or responsive design features", this wording was changed per the suggestion by ekr in this email [1] if it's helpful for remembering what the intentions were.
The original version of that bullet point was "SVGs must remain static after publication of the RFC, so there may be interactive, multimedia, or other elements that cannot be included in SVG diagrams." My intent was to exclude things like: * interactive features like things changing color on mouseover or upon clicking an element within the SVG * animations * audio * video I did not intend to imply that an SVG couldn't resize based on the sizing of the viewing screen/paper (I'd prefer to leave the parameters of that up to the RPC because they have more experience than I do with the constraints of our publishing system). Also for further reference, RFC 7996 section 2 [2] specifically disallowed the following for the purpose of creating "simple diagrams that do not change once the RFC is published" : 12 Multimedia 13 Interactivity 15 Scripting 16 Animation 18 Metadata 19 Extensibility If it seems like we're on the same page about what we're trying to accomplish, how about this wording: OLD "SVGs must render in a single static configuration without dynamic elements or responsive design features." NEW "The content of the SVGs must be static. For example, SVGs cannot contain interactive elements, animation, or multimedia elements." Alexis [1] https://mailarchive.ietf.org/arch/msg/rswg/T8CrBXBnPFmLOMCnWfvuw3COFm0/ [2] https://www.rfc-editor.org/rfc/rfc7996.html#section-2 On Tue, Jun 10, 2025 at 1:04 AM Carsten Bormann <c...@tzi.org> wrote: > On Jun 5, 2025, at 22:22, Brian E Carpenter <brian.e.carpen...@gmail.com> > wrote: > > > > without […] responsive design features > > Shouldn’t we then also remove the responsive features of the HTML that is > carrying that SVG? > > I think we need to spend a little more time in figuring out what exactly > we are trying to disallow here, and I wouldn’t mind if we also could > articulate why. > > Grüße, Carsten > > -- > rswg mailing list -- rswg@rfc-editor.org > To unsubscribe send an email to rswg-le...@rfc-editor.org >
-- rswg mailing list -- rswg@rfc-editor.org To unsubscribe send an email to rswg-le...@rfc-editor.org
