Martin's summary does seem to cover things - ekr is wording along these lines sufficient to address your concerns?
Alexis On Thu, Jun 12, 2025 at 8:25 AM Martin Thomson <[email protected]> wrote: > I think that we generally have good alignment here. The resizing and dark > mode are technically part of the same "reactive" part of the SVG > featureset, but on the specifics, I think we have good alignment. > > I would add that there are some adaptive features that could be relevant > for accessibility across display technology: adjustments to font size and > stroke weight. Adjustment of positioning. > > All of this is stuff that I would leave out of this document. What we > want is to say that: > > SVGs must not include animation or interactive features. > SVGs should include only limited reactive design elements (scaling, > dark/light mode, and perhaps minor adjustments to allow for variations in > display technology). The intent being to ensure that how something is > displayed does not substantially alter what is seen. > > That's a lot more words, but I think that it matches expectations. > > Technically, if we were doing what we did in the past, this would be nigh > impossible to specify in terms of SVG and CSS syntax that is > permitted/denied. Now, we have an RPC that can exercise good judgment, so > I'm not at all concerned about this being feasible. > > On Wed, Jun 11, 2025, at 21:50, Jean Mahoney wrote: > > Hi all, > > > > On 6/11/25 12:13 PM, Eric Rescorla wrote: > >> > >> > >> On Wed, Jun 11, 2025 at 9:49 AM Alexis Rossi <[email protected] > >> <mailto:[email protected]>> wrote: > >> > >> > >> > >> On Wed, Jun 11, 2025 at 2:34 AM Eric Rescorla <[email protected] > >> <mailto:[email protected]>> wrote: > >> > >> TBH, all of this wordsmithing seems premature, because it's > >> still not clear to me what the text is trying to say. There are > >> a set of concrete features one might imagine implementing > >> here, and I don't see that we have come to agreement about > >> which ones we are trying to rule in or out: > >> > >> - Scaling: Yes (probably?) > >> > >> > >> Yes > > > > [JM] yes, scaling helps make diagrams accessible. > > > >> > >> - Rearrangement : Maybe? ISTR some said no, Alexis said yes? > >> > >> > >> I don't care, happy to leave it up to RPC > > > > [JM] No, I think this would make creating PDFs hard, and would be hard > > for authors to create and the RPC to validate. > > > >> > >> - Hiding and showing elements based on size: Probably not? > >> > >> > >> No > > > > [JM] no > > > >> > >> - Dark mode: Maybe? MT was arguing yes, but I just heard Jean > >> say maybe not? > >> > >> > >> I don't care, happy to leave it up to RPC > > > > [JM] Yes, I want to support dark mode, and the new rfc-editor.org > > website will be able to support dark mode. If I sounded uncertain, it's > > because I don't know the best way to construct an SVG to support it > > (e.g., use inline SVG and currentColor?). Our current SVG profile works > > just fine with dark mode so I'm guessing nothing too fancy is needed. > > > >> > >> - Animation: No > >> > >> > >> No > > > > [JM] no > > > >> > >> - Direct interaction with the image: No > >> > >> > >> No > > > > [JM] no > > > > Best regards, > > Jean > > > >> > >> > >> We should resolve these questions -- or at least the question of > >> the principle > >> which is trying to guide them prior to trying to write text. > >> > >> If the intent is just to defer all of these questions to the > >> RPC, then the text > >> should actually say so (I would probably object to this, but > >> perhaps I'm > >> in the minority on that). However, I don't think it's helpful to > >> just have > >> vague text that doesn't actually provide the answer without an > >> explicit > >> delegation to the RPC. > >> > >> > >> This document specifically hands technical implementation decisions > >> to the RPC. The intro says, "The RFC Publication Center (RPC) is > >> responsible for making SVG tooling and implementation decisions." > >> Why would we need to specify it again in this bullet point as well? > >> > >> > >> This is neither a tooling nor an implementation decision. It is a > policy > >> decision > >> about what types of SVG are allowed (hence its appearance in the section > >> entitled "Policy Requirements"). > >> > >> -Ekr > >> > >> > >> -Ekr > >> > >> > >> On Tue, Jun 10, 2025 at 8:58 PM Brian E Carpenter > >> <[email protected] > >> <mailto:[email protected]>> wrote: > >> > >> On 11-Jun-25 14:17, Alexis Rossi wrote: > >> > Okay, in an earlier email in this thread [1] Paul Hoffman > >> (I think) suggested wording like > >> > > >> > * SVG diagrams may not be interactive or have multimedia > >> or other similar elements. > >> > > >> > What about that for new wording? > >> > >> That WFM too. > >> > >> Brian > >> > >> > > >> > Alexis > >> > > >> > [1] > https://mailarchive.ietf.org/arch/msg/rswg/iqz2v05Wt- > >> ncTJUsEvITw_50RGY/ <https://mailarchive.ietf.org/arch/msg/ > >> rswg/iqz2v05Wt-ncTJUsEvITw_50RGY/> <https:// > >> mailarchive.ietf.org/arch/msg/rswg/iqz2v05Wt- > >> ncTJUsEvITw_50RGY/ <https://mailarchive.ietf.org/arch/msg/ > >> rswg/iqz2v05Wt-ncTJUsEvITw_50RGY/>> > >> > > >> > On Tue, Jun 10, 2025 at 5:37 PM Jean Mahoney > >> <[email protected] <mailto:[email protected] > >> editor.org> <mailto:[email protected] > >> <mailto:[email protected]>>> wrote: > >> > > >> > > >> > > >> > On 6/10/25 4:55 PM, Alexis Rossi wrote: > >> > > > >> > > > >> > > On Tue, Jun 10, 2025 at 2:24 PM Brian Carpenter > >> > > <[email protected] > >> <mailto:[email protected]> > >> <mailto:[email protected] > >> <mailto:[email protected]>> > >> <mailto:[email protected] > >> <mailto:[email protected]> > >> <mailto:[email protected] > >> <mailto:[email protected]>>>> wrote: > >> > > > >> > > Make the policy "generally not allowed" and > >> that would leave the RPC > >> > > free to apply common sense. > >> > > > >> > > (via tiny screen & keyboard) > >> > > Regards, > >> > > Brian Carpenter > >> > > > >> > > > >> > > Okay so like this perhaps? > >> > > > >> > > OLD > >> > > "SVGs must render in a single static configuration > >> without dynamic > >> > > elements or responsive design features." > >> > > > >> > > NEW > >> > > "The content of SVGs should be static. Dynamic > >> elements or responsive > >> > > design features are generally not allowed." > >> > > >> > [JM] We should emphasize which responsive design > >> features we don't want > >> > to support, like animation, because we do want to > >> allow scaling, which > >> > also falls into responsive design. Other responsive > >> design concepts, > >> > such as including CSS to support dark mode, don't > >> appear to be necessary > >> > (SVGs in current RFCs look okay in dark mode). I > >> would need to more info > >> > to determine if SVG CSS should be disallowed > >> generally. It seems like it > >> > would be helpful for improving accessibility, but > >> maybe that can all be > >> > inherited from the HTML CSS? > >> > > >> > NEW > >> > The content of SVGs should be static. Dynamic > >> elements or responsive > >> > design features that support animation are > >> generally not allowed. > >> > > >> > Best regards, > >> > Jean > >> > > >> > > >> > > >> > > > >> > > Alexis > >> > > > >> > > > >> > > On Wed, 11 Jun 2025, 09:17 Eliot Lear, > >> <[email protected] <mailto:[email protected]> <mailto:[email protected] > >> <mailto:[email protected]>> > >> > > <mailto:[email protected] <mailto:[email protected]> > >> <mailto:[email protected] <mailto:[email protected]>>>> wrote: > >> > > > >> > > __ > >> > > > >> > > I would suggest that the proscriptions of > >> video, audio, and > >> > > animations are not controversial. The > >> only aspect of responsive > >> > > design I really think we're talking about > >> is dark mode, in that > >> > > if it is supported it must be done in a > >> way that is legible. > >> > > Maybe that is a bit TOO prescriptive, tho. > >> > > > >> > > > >> > > -- > >> > > rswg mailing list -- [email protected] > >> <mailto:[email protected]> <mailto:[email protected] > >> <mailto:[email protected]>> <mailto:rswg@rfc- > >> <mailto:rswg@rfc-> <mailto:rswg@rfc- <mailto:rswg@rfc->> > >> > > editor.org <http://editor.org> <http://editor.org > >> <http://editor.org>>> > >> > > To unsubscribe send an email to rswg- > >> [email protected] <mailto:[email protected]> > >> <mailto:[email protected] <mailto:rswg-leave@rfc- > >> editor.org>> > >> > > <mailto:[email protected] > >> <mailto:[email protected]> <mailto:rswg-leave@rfc- > >> editor.org <mailto:[email protected]>>> > >> > > > >> > > > >> > > >> > > > > -- > > rswg mailing list -- [email protected] > > To unsubscribe send an email to [email protected] > > -- > rswg mailing list -- [email protected] > To unsubscribe send an email to [email protected] >
-- rswg mailing list -- [email protected] To unsubscribe send an email to [email protected]
