textpath startoffset attribute does not behave correctly
janwillemtulp opened this issue · comments
the startOffset attribute for a textPath should remain startOffset, and not be transformed to start-offset
I'll add a note in the docs for this - do you think there's another fix besides a whitelist?
what about a blacklist?
I mean, a list of the relatively few exceptions from the rule
allowReorder attributeName attributeType autoReverse baseFrequency baseProfile calcMode clipPathUnits contentScriptType contentStyleType diffuseConstant edgeMode externalResourcesRequired filterRes filterUnits glyphRef gradientTransform gradientUnits kernelMatrix kernelUnitLength keyPoints keySplines keyTimes limitingConeAngle markerHeight markerUnits markerWidth maskContentUnits maskUnits numOctaves patternContentUnits patternTransform patternUnits pointsAtX pointsAtY pointsAtZ preserveAlpha preserveAspectRatio primitiveUnits repeatCount repeatDur requiredExtensions requiredFeatures specularConstant specularExponent spreadMethod startOffset stdDeviation stitchTiles surfaceScale systemLanguage tableValues targetX targetY textLength viewBox viewTarget X xChannelSelector Y yChannelSelector Z zoomAndPan
didn't know it was that many camel case attributes! but still better than a whitelist?
fixed by #64