Re: [rfc-i] SVG/A specification.

[Phillip Hallam-Baker <[e-mail]>]

On Fri, Jan 24, 2020 at 2:00 PM Leonard Rosenthol <[e-mail]>
wrote:

> >> Style
>
> > It presents a problem for validation and for the aggregation of XML2RFC
> + SVG* to on XML document. Basically, it means that the validator has to
> understand the style sheet language.
>
> >Since the output language is XML2RFC which prohibits style, it seems
> simplest to simply flatten all this out.
>
> >
>
> OK, I’ll buy that for Stylesheet.  But not for style.  Style is simple –
> it’s just ‘key/value’ pairs.
>

Yes, it probably doesn't need to be made a requirement.

Though if style is allowed, it will have to be constrained to the set of
allowed attribute values, we don't get that from schema validation unless
the attributes are converted.


> > But the original reason for this was not actually the archival part but
> the accessibility part.
>
> >It is much easier to restrict attributes to a limited palette of colors
> if there is a single means of expressing them.
>
> >
>
> That may be true for colors **but** style also is where you define things
> like line-width, line-joins. dash patterns, font weight, etc.
>
>
>
> And what about the ID restriction?
>

That was a typo, the tool currently suppresses id, class and style. I meant
to delete id from that list and deleted style instead.

The id is not needed for SVG-Tiny and the easiest way to avoid duplication
was to delete 'em.

> So the only way to make this happen would be to expand the SVG Font
> definitions inside the diagrams. Which isn't going to happen. Pity.
>
> >
>
> No, the correct way to do this is simply to “embed” the font, as I
> recommended.  See
> https://www.htmlgoodies.com/beyond/webmaster/serving-up-base64-encoded-custom-fonts.html
>

Yes but I don't think the group is going to go for that for the same reason
they resist using data: urls for PNG.