SVG Working Group specifications
License: Other
SVG Working Group specifications.
Editor's drafts:
The SVG2 spec draft is automatically rebuilt on pushes to this repository.
SVG-AAM is in the ARIA repository
The SVG working group welcomes contributions to their specifications. These can be made by filing a pull request. Please see CONTRIBUTING.md, LICENSE.md and CODE_OF_CONDUCT.md .
From https://svgwg.org/svg2-draft/struct.html#InterfaceSVGSVGElement
NodeList getIntersectionList(DOMRectReadOnly rect, SVGElement referenceElement);
NodeList getEnclosureList(DOMRectReadOnly rect, SVGElement referenceElement);
The referenceElement arguments should be nullable, as the null case is handled in their definitions.
Source: http://tavmjong.free.fr/SVG/TEXT_SYDNEY_2016/#Wrapped (See 3.3)
The ''wrap-flow' property allows choosing how wrapping flows around an exclusion. It's not clear how this would apply to divided lines from the 'shape-inside'.
Section 2.2 mentions "SYMM Working Groups". Still relevant?
The sentence often termed "Dynamic HTML" is a bit outdated
SVG currently says yes, but this seems odd. These methods are convenience methods because the orient attribute is reflected in two DOM properties (orientType & orientAngle). I would expect them to be equivalent to setting those two properties, not calling setAttribute.
See https://svgwg.org/svg2-draft/painting.html#__svg__SVGMarkerElement__setOrientToAuto:
The setOrientToAuto method is used to set the value of the ‘orient’ attribute to 'auto'. When setOrientToAuto() is called, the ‘orient’ attribute is simply set to 'auto'.
The setOrientToAngle method is used to set the value of the ‘orient’ attribute to a specific angle value. When setOrientToAngle(angle) is called, the ‘orient’ attribute is reserialized using angle as the value.
Test: https://jsfiddle.net/dodgeyhack/bgLe93sw/3/
Implementations are reasonably consistent, except for Chrome:
Chrome: Doesn't set attribute
WebKit: Does set attribute, but has some bugs so this code needs rework anyway
FireFox: Does set attribute, has some bugs
IE11: Does set attribute
The getComputedTextLength method (and by proxy, the getSubStringLength method) only specify returning a number in user units. Current implementations differ: Chrome and WebKit return integers, and Firefox and IE/Edge return floats.
It would be better to return a float; depending on viewport dimensions and transformations, an integer can be very inaccurate.
In SVG 1/1.1, text-on-a-path requires a <textPath> element that links to a separate <path> element. Various attributes on the <textPath> control behavior, some of which are poorly implemented.
For SVG 2, the working group had resolved to:
<textPath> instead of requiring a separate element.<path>.Given the general push to move geometry and layout to CSS properties, it makes sense to move the path geometry declaration to a style property. To do that, the following requirements must be accommodated:
<path> shape. (See Issue #49).startOffset in CSS as well, preferably in a way that is consistent with CSS-ifying x/y/dx/dy on other text elements.No one seems to have implemented the d attribute on <textPath> yet. Therefore, we could replace it with a new property/presentation attribute pair with an appropriately unique name and a CSS-friendly syntax.
d) for the path geometry attribute, but (for now) only make it available as an attribute on <textPath>. I'd suggest something like baseline-shape or baseline-path to reflect the relationship to other text layout properties.side parameter as an additional keyword in the same property rather than as a separate attribute.In other words, something like:
<textPath baseline-shape="circle( calc(50% - 1em) at center) left">Text in a circle</textPath>Then, create a separate text path module to address remaining issues and explore more complex text path features. Some options for the new module:
xlink:)href on <textPath> in favour of a url() value in the presentation attribute.method attribute). This has been available in MS Word since the 90s and has been a long-requested feature for SVG.Paul LeBeau wrote on the mailing list:
Hi all
I noticed while testing an idea the other day that the fragment identifiers spec is now a little deficient, in that it assumes the other SVG is in an external document.
Given that pages containing multiple SVG elements are becoming very common. It might be nice to be able to reference another SVG within the document and supply an SVGViewSpec.
An example use case could be:
<svg id="main-image" width="1000" height="1000" viewBox="0 0 1000 1000"> ... </svg> <svg id="zoomed-detail"> <use xlink:href="#main_image#svgView(viewBox(100,200,20,20))" width="100" height="100"/> </svg>Thoughts? Would it be useful to extend fragment identiers in some way in order to allow an ID plus an SVGViewSpec etc?
Paul
https://svgwg.org/svg2-draft/single-page.html#chapter-idlindex
In https://svgwg.org/svg2-draft/single-page.html#struct-DiscardElement it's made clear that the SVGDiscardElement (without the extra "e") doesn't exist yet.
Export from Photoshop in SVG is currently very difficult because of the lack of layers blendings effects in the SVG format.
SVG is not able to specify all mix-blend mode effects of Photoshop layers because it is limited to the color composition. All other layer blending effects in the image are now lost when saving in SVG format. I'm referring to the following in particular:
Drop Shadow
Adds a shadow that falls behind the contents on the layer.
Inner Shadow
Adds a shadow that falls just inside the edges of the layer’s content, giving the layer a recessed appearance.
Outer Glow and Inner Glow
Add glows that emanate from the outside or inside edges of the layer’s content.
Bevel and Emboss
Add various combinations of highlights and shadows to a layer.
Satin
Applies interior shading that creates a satiny finish.
Gradient and Pattern Overlay Mask
Blend the layer’s content using a patterned or gradient overlay mask.
Stroke
Outlines the object on the current layer using color, a gradient, or a pattern.
Alpha Channel Mask Image
Blend the layer’s content using a custom alpha channel mask image.
Those filters are all already present in the SVG specifications, but only as graphic elements filters. All we need is to be able to also apply those to edges of the layer’s content as blending options. In this way it would be possible to preserve layers effects when saving in SVG from Photoshop and other painting applications.
Suggestion:
Allow the rx and ry attributes of <rect> to accept up to four radius values. If there are 2-4 values specified then they would be handled the same way that CSS border-radius is.
top-left top-right bottom-right bottom-left
As you may already know, the SVG format is now used widely in mobile applications both on Android and on iOS. Due to the device independent quality of SVG, and to the unnumerable varieties of screen dpi, ratios and resolutions in mobile devices, developers are now sistematically dropping bitmaps assets and replacing them with SVG assets. This is happening not only in UIs components, but also in any visual asset. But at the moment SVG is lacking some fundamental features, that should be implemented as soon as possible, because of the growing importance and need of these in app development.
The most important one is 9-slice scaling mode (also known as 9-tiles, 9-patches or 3x3 border tiles). This feature is currently available only on the web, and it requires the developer to use an external CSS sheet where a border-tile scaling matrix is defined for the svg image.
But SVG is not a format used only on the web anymore. It has become the de facto standard for vector graphics, and It is used on mobile even more extensively than on the web. Consequently it cannot delegate anymore such functionalities to a web standard like CSS. It is imperative that SVG could be used effectively also outside of the web browsers world.
For reference, the following links are examples of mobile developers struggling with the lack of a standard 9-slice feature in the SVG format, showing how far they are going and the troubles they have trying develop some ugly hack to do it:
http://blog.twintechs.com/explorations-in-cross-platform-assets-xamarin-forms
A true standard 9-slice option should be a view attribute of any SVG image (or even element or groups) and it should be something that artists can use to draw resizable UI components directly in applications like Inkscape or Illustrator and to export them in SVG in a standard and independent format, consistent in his rendering on all devices and platforms.
If this standard is not defined by the SVG group, there will be a growing multitude of different implementations, all requiring a lot of custom code and the assets would be impossible to create in a graphic app because there is no standard. The process of cutting a vector object and scaling it is something that can be implemented in a variety of different ways. Cutting the bezier in the intersection with the slicing grid lines, for example, or adding a node instead. Or, like some vector software does for 2D mesh deformations, applying a affine transform matrix composed by 9 different transform matrixes. Or creating a mesh grid of curves and cutting it by boolean operations. Or preserving the underlying geometry and just applying a mask to nine views of the same object (but this would mean to loose the advantage of the scaling and deformation of shapes that SVG has on the bitmap assets).
This is an issue that should be defined best in the SVG format specifications, to ensure consistency in the resulting image on all devices and across all software applications both when creating and displaying the SVG image file.
I haven't done a search for how often it shows up, but Dudley Storey just let me know that some of the code examples are using <svg version="2.0">. Since that's no longer part of the spec and would have no effect, we need to do a clean up to remove it.
Source: http://tavmjong.free.fr/SVG/TEXT_SYDNEY_2016/#Baselines (See 2.1.5)
It would be useful to suggest default values for the 'hanging' and 'mathematical' baselines if they cannot be extracted from the font (and are not otherwise clearly defined). Using the top of the 'em' box (as with Firefox) is clearly wrong for writing systems using a hanging baseline. CSS Inline does define a "synthesized" baseline for "hanging": 0.6em. (As referenced from the 'alphabetic' baseline?)
'alphabetic': reference.
'ideographic': bottom of em-box (descent).
'hanging': 0.6 em.
'mathematical': 0.8 ex height?
'central': defined as middle of em-box.
'middle': defined as half of ex-height'
The 'hanging' and 'mathematical' baselines could be measured from the font. One could measure the hanging baseline by measuring the ascent of various glyphs in the the Devanagari, Bengali, Gujarati, etc scripts. The math baseline could be found by finding the middle of the 'minus' character.
In the SVG2 Appendix C: Implementation Requirements document, figure 6.3.1 is not formatting/rendering correctly in Chrome v40.0.2214.111. It does work in Firefox v35.0.1.
I am not sure if this is a problem with the syntax, MathML, MathJax, or Chrome. Should it just be converted to an image like the others?
Figure 6.3.1 was an image in the previous draft
I sent a message to the mailing list before I discovered the SVG WG on GitHub and thought this might be more appropriate.
The edits to make path data a presentation attribute currently use the same d property name for both the shape of a <path> element and the baseline shape of a <textPath>. It is not currently used for other elements (such as <hatchpath> and <stop> elements in a <mesh>) that use path data with the path attribute.
This creates some concerns:
d is not a particularly expressive property name outside the context of a particular element.d property is being used to apply two very different features, with only the element tag name determining how (or if) the property has an effect.points attribute of <polygon>/<polyline> elements, which is a natural equivalent to d on a <path>, is not currently reflected in CSS geometric properties.Main discussion on the www-svg mailing list starts here:
Also relevant is this discussion on the FX mailing list, regarding the path() function syntax, which unfortunately got broken into two threads, only the shorter of which was copied to www-svg:
Source: http://tavmjong.free.fr/SVG/TEXT_SYDNEY_2016/#Baselines (See 2.1.3)
In both SVG 1.1 and XSL the baseline tables are not changed when the font size changes. The tables are only changed when the 'dominant-baseline' has a value of 'reset-size'. It's not clear that this is the prescribed behavior in the CSS Inline spec and browsers don't seem to follow this.
The SVG specs say this regarding conformance:
http://www.w3.org/TR/SVG/conform.html#ConformingSVGViewers
:
"Dynamic document content can be achieved via declarative animation or
by scripts modifying the SVG DOM."
SVG2:
http://www.w3.org/TR/SVG2/conform.html#ConformingSVGViewers
:
"Dynamic document content can be achieved via declarative animation or
by scripts modifying the SVG DOM."
Does the spec text mean that both declarative animation and script animation are required? Or does it mean that one of the two options is required?
IMHO the text should be more clear, eg:
"Dynamic document content can be achieved in two different ways: via declarative animation, or by scripts modifying the SVG DOM. Both must be supported."
When both are required (or in any case), please post that info to blink-dev[at]chromium.org , with subject "Re: [blink-dev] Intent to deprecate: SMIL".
The SVG 1.1 and 2 specs mention that implementations must respect CSS2 (resp. 2.1) pseudo-classes including :visited (https://www.w3.org/TR/SVG2/styling.html#RequiredCSSFeatures).
The default UA style sheet does not specify a :visited rule (https://www.w3.org/TR/SVG/styling.html#DefaultStyleSheetLanguage). There doesn't seem to be an explicit requirement not to have a :visited rule, even though the absence of a requirement could be interpreted as a hint not to do so.
Regardless, Blink has a default :visited rule (or the behavior of one), causing incompatibilities (https://code.google.com/p/chromium/issues/detail?id=352912, see also https://jsbin.com/nixexe/ for example). In Gecko and WebKit,
<g fill="#00ff00"><a xlink:href="http://google.com">Text</a></g>will show as green. In Blink, it will only be green if the link has not been visited, black otherwise, leading to subtle bugs.As stated on the bug report, the Blink authors justify their implementation with the spec's ambiguity:
Yes, it could be argued that the UA style for svg:a should be the same as html:a (although that's not mandated by the spec AFAIK.)
In order to erase that ambiguity and prevent future incompatibilities, we should specify that default UA style rules not present in 6.16 should not be enforced by default by UAs.
What are your opinions?
http://dev.w3.org/csswg/cssom/#the-elementcssinlinestyle-interface
That includes SVGElement implements ElementCSSInlineStyle so the definition in SVGElement is in conflict:
http://www.w3.org/TR/SVG2/types.html#InterfaceSVGElement
From which spec should it be removed? I'm thinking SVG, but if you disagree I can take it to the CSS WG.
Lately the SVG WG expressed the intent to drop SMIL as the main animation method of the SVG format, and to start merging efforts with the CSS group for unifying the animation approach on CSS Animations and WebAnimations.
Doing so would be a sure mistake. CSS, web animations, or any other web standard should NOT be considered when developing the SVG format.
This because it is now clear that SVG has become the de facto standard for vector graphics in a variety of fields OUTSIDE THE WEB SPHERE.
Just a few examples:
The web is not the only focus for SVG anymore. SVG is now an independent and self sufficient vector file format, and it should not rely on external javascript libraries or applications specifications.
Having its own declarative animation format is what allows it to be so successful and independent from the limited scope of the web. SMIL is also very complete and very powerful, and universally regarded as the best animation language in existence.
Even web developers prefer not to have to manually animate SVG elements with javascript. Artists are best suited to do animations, not programmers. Javascript is also not useful for all graphic elements included as IMG elements in the html page, because for security reasons the image tag cannot run scripts or javascript. SMIL is the only safe and efficient way to have a vector animation file working in a web page as an Image element. And it is also much better for artists. No vector or animation artists that I know are proficient in javascript, so they are asking to provide them an SVG format that they can export including the animation defined as SMIL instead of having to pay a javascript programmer to manually code the animation in a script prone to errors and hard to debug.
Animations functionality that are not included in the SVG format itself and dependent of external CSS, javascript or a running browser, are doomed to fail, because they require a programmer to do a graphicians job (bad for both, and with awful results), and because it would never be an universal, independent graphic format usable on every platform, from the web to mobile apps.
Here is an example cartoon animation exported to SVG with the Flash2Svg plugin from Adobe Animate CC:
http://www.tbyrne.org/portfolio/smil/LoveDota.svg
All this thanks to SMIL.
Source: http://tavmjong.free.fr/SVG/TEXT_SYDNEY_2016/#Wrapped (See 3.2)
Possible solutions:
Source: http://tavmjong.free.fr/SVG/TEXT_SYDNEY_2016/#Baselines (See 2.1.4)
The 'auto' value for vertical text when coupled with the obsolete SVG 'glyph-orientation-vertical' values '90deg' and '90' breaks SVG content. This is because these values for 'glyph-orientation-vertical' are mapped to the 'text-orientation' value 'sideways' which dictates that the 'dominant-baseline' has a value of 'alphabetic' where in SVG 1.1 the auto value of 'dominant-baseline' for all vertical text is 'central'. This is important as in SVG, text is positioned so that the dominant baseline is aligned to the 'x' attribute of the element (for vertical text). Using the 'alphabetic' baseline for sideways text will result in shifting the text by the difference between the alphabetic and central baselines.
Source: http://tavmjong.free.fr/SVG/TEXT_SYDNEY_2016/#GenPhil
Mailing list discussion: https://lists.w3.org/Archives/Public/www-svg/2016Jan/0035.html
Apologies if this is not the right venue for this question, but I'm struggling to understand how the spec defines the URL resolution logic when an HTML <base> element exists. Please let me know if there is somewhere else I should ask this question.
In the example HTML page below [1], the <use xlink:href="#MJMAIN-39" element fails to resolve to the <path> element due to the presence of the HTML <base href="https://example.com"> element. This behavior is visible in Chrome 49 [2] and Firefox [3], but is not present in Safari [4].
However, according to my (extremely non-expert) reading of the SVG2 draft spec and XML Base spec, it would appear that this reference should resolve to the local <path> element. In particular, the SVG2 spec says at [5] "If the URL reference is relative, its absolute version must be computed by the method described in XML Base before use [XML-BASE]." The XML Base spec then says at [6] "RFC 3986 defines certain relative URI references, in particular the empty string and those of the form #fragment, as same-document references. Dereferencing of same-document references is handled specially." Taken together, I interpret these as meaning that despite the HTML <base> element, <use xlink:href="#MJMAIN-39" should be considered a same-document reference and therefore should resolve to the <path> element.
Is my reading of the specs correct? If not, could you explain where I've misinterpreted them and whether it's possible to reference an element in the same document despite the presence of the HTML <base> element? Thanks!
[1]
<!DOCTYPE html>
<html>
<head>
<base href="https://example.com">
<meta charset="utf-8">
<title>Math Test</title>
</head>
<body>
<svg xmlns:xlink="http://www.w3.org/1999/xlink" viewBox="0 -1035.6284324052635 9227.414882379479 1501.846702397534">
<defs>
<path id="MJMAIN-39" stroke-width="10" d="M352 287Q304 211 232 211Q154 211 104 270T44 396Q42 412 42 436V444Q42 537 111 606Q171 666 243 666Q245 666 249 666T257 665H261Q273 665 286 663T323 651T370 619T413 560Q456 472 456 334Q456 194 396 97Q361 41 312 10T208 -22Q147 -22 108 7T68 93T121 149Q143 149 158 135T173 96Q173 78 164 65T148 49T135 44L131 43Q131 41 138 37T164 27T206 22H212Q272 22 313 86Q352 142 352 280V287ZM244 248Q292 248 321 297T351 430Q351 508 343 542Q341 552 337 562T323 588T293 615T246 625Q208 625 181 598Q160 576 154 546T147 441Q147 358 152 329T172 282Q197 248 244 248Z"></path>
</defs>
<g stroke="black" fill="black" stroke-width="0" transform="matrix(1 0 0 -1 0 0)">
<use xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="#MJMAIN-39" x="394" y="0"></use>
</g>
</svg>
</body>
</html>[2] https://bugs.chromium.org/p/chromium/issues/detail?id=470608 and bugs that have been closed as duplicates, as well as https://bugs.chromium.org/p/chromium/issues/detail?id=449027
[3] https://bugzilla.mozilla.org/show_bug.cgi?id=1121708 and https://bugzilla.mozilla.org/show_bug.cgi?id=652991
[4] https://bugs.webkit.org/show_bug.cgi?id=140488
[5] https://svgwg.org/svg2-draft/linking.html#linkRefAttrs
[6] https://www.w3.org/TR/xmlbase/#same-document
The current draft of the SVG spec defines dataset attribute on the SVGElement interface while HTML 5 spec defines it on the HTMLElement interface.
Is there any particular reason why dataset couldn't be defined just once on the Element interface like other similar attributes such as classList?
Does sound play for audio and video elements which are hidden by conditional processing?
The current text only mentions rendering, but it doesn't say how events, animations or sound are affected. An improved wording to address events and animations was suggested: “All others will not be rendered (as if the display property were set to none.)” [1]
However, that also suggests that sound is always played.
Can you add the improved wording and mention how sound is affected?
[1] https://lists.w3.org/Archives/Public/www-svg/2014Mar/0049.html
Source: http://tavmjong.free.fr/SVG/TEXT_SYDNEY_2016/#Wrapped (See 3.5)
When the first glyph is positioned at the edge of a wrapping area that is not a vertical line (for horizontal text), how is the first glyph positioned?
Our PR was accepted w3c/github-notify-ml-config@788b65a
But issues are not being forwarded to the mailing list.
Source: http://tavmjong.free.fr/SVG/TEXT_SYDNEY_2016/#Wrapped (See 3.1)
Some ML discussion: https://lists.w3.org/Archives/Public/www-svg/2016Jan/0038.html
Possible solutions: Move down until first word fits:
Tav raised initial questions about how the pixels that are painted for a stroke are calculated:
http://tavmjong.free.fr/SVG/STROKING/
The following options are commonly used:
Specs that state strongly which method to use:
Specs that don't state which method to use:
Which option is used by implementations?
Cairo: 1
Ghostscript: 1
NV_Path: 1
Skia: 2
CoreGraphics: 2
Canon's PDF RIP: 1
Adobe PDF Print Engine: 1
Acrobat PRO: 1
Source: http://tavmjong.free.fr/SVG/TEXT_SYDNEY_2016/#Wrapped (See 3.4)
SVG 1.2 flowed text allowed text to be flowed into multiple shapes (as one shape was filled up, the text would flow into the next shape). It would be nice to preserve this functionality. (Inkscape implements this.)
CSS Regions may be the solution but it's not clear how it would work.
The co-ordinates chapter uses the term 'full glyph cell' when discussing calculation of the bounding box for text.
https://svgwg.org/svg2-draft/coords.html
"For text content elements, for the purposes of the bounding box calculation, each glyph must be treated as a separate graphics element. The calculations must assume that all glyphs occupy the full glyph cell. For example, for horizontal text, the calculations must assume that each glyph extends vertically to the full ascent and descent values for the font. An exception to this is when the ‘inline-size’ presentation attribute has been specified on the ‘text’ element, in which case the element's content area is its bounding box."
This defines a height for the full glyph cell, but no width. Width is typically the width of the tight bounding box.
https://jsfiddle.net/dodgeyhack/xt6yq5v3/
I think we all agree that having a common place to reference tabindex and sequential focus navigation is a good thing I have serious concerns over just pointing to the existing HTML specification. When I put the sequential focus navigation components in SVG2 HTML5 was still in flux and they were trying to lock it down. There are a number of significant differences between HTML5 and SVG that make this problematic. Here are just a few:
So, this puts us in a difficult position. We can't just point to it as it is not testable (per the spec.). What should really be done is that both groups create a single module that deals with focus navigation across the two documents that is inclusive of SVG and frankly is also accurate in terms of HTML 5.1. In fact, HTML5 has moved toward a modular design that would accommodate that. I believe this will take much longer than we have for the current SVG2 schedule. I believe what we have puts SVG at risk unless the group's intent is to just ignore the spec. and test it the way we think it should work.
I see only two options:
The zoomAndPan features from SVG 1 are not implemented in browsers as initially proposed. The section is still in SVG 2, however.
We either need commitments from implementers to add zoom & pan control, or need to significantly revise/remove this section.
http://dev.w3.org/csswg/css-transforms-2 is proposing translate, rotate, and scale properties which may clash with SVG. For example, tspan has a rotate attribute that would clash if it were ever promoted to be a presentation attribute. Similar issues exist for some filter elements such as SVGFEDisplacementMap's scale attribute.
transformation matrix definition in intro just specifies 3x3 CTMs. should (also?) specify 4x4 matrices
We have two definitions for viewport, both seem to define SVG viewport. We need to make sure that people don't mix it up with CSS viewport (which is relevant in the context of SVG as well).
Svg should require support for data-* attributes on all svg elements.
Also see: whatwg/html#327 (comment)
1. Are links allowed to be nested?
https://svgwg.org/svg2-draft/linking.html#Links
The ‘a’ element may contain any element that its parent may contain, except itself.
And then its content model description states it can contain <a> elements. Am I misunderstanding the spec? If the ability to nest links is being removed, why?
2. Should the <a> element gain the additional attributes it has from HTML?
In particular:
rel has a very popular use with the nofollow valuedownloadreferrertype, hreflang, and media are rather useless, but leaving them out while allowing the above would be a bit inconsistent.
The current https://svgwg.org/svg2-draft/implnote.html#ErrorProcessing section doesn't refer to initial/invalid values of attributes, so it's not exactly clear that you're meant to use them when an attribute is invalid in some way. For example looking at https://svgwg.org/svg2-draft/coords.html#ViewBoxAttribute it says that negative values for width/height inside the viewBox are an error, but the Error Processing section linked to doesn't make it clear that the behaviour should be as if the attribute weren't specified (as that's what's specified for the "initial value" in the grey attribute definition box).
See https://code.google.com/p/chromium/issues/detail?id=367890
Input appreciated on whether there are important use cases for SVGZoomEvent, or if it may simply be removed, given that it doesn't appear to be needed for web compat.
Should the list of options in
http://www.w3.org/TR/SVG2/animate.html#Introduction
include a link to W3C Web Animations?
http://www.w3.org/TR/web-animations-1/
Eric Willigers from Google has created an official SMIL polyfill implemented entirely on the Web Animations API. You can find it here: https://github.com/ericwilligers/svg-animation
This would allow the playback of SMIL animations EVERYWHERE, even in browsers that until now didn't supported SMIL (like old IE browsers).
https://svgwg.org/svg2-draft/single-page.html#struct-InterfaceSVGDocument says "For historical reasons, Window objects must also have a writable, configurable, non-enumerable property named SVGDocument whose value is the Document interface object."
This is clearly in analogy with https://html.spec.whatwg.org/#the-window-object
However, neither Blink nor IE expose this SVGDocument alias of document. WebKit and Gecko do. Unless needed for web compat, there's no reason to add it, so I propose dropping this requirement from the spec.
Export from Photoshop in SVG is currently very difficult because of many limitations of the SVG format. Please add support for the following:
Thank you.
I'm building an SVG editor that allows users to save SVG documents using either XML or HTML 5 serialization.
In order to preserve editing capabilities I need to store app-specific data as content attributes. For example, when user draws a star path, I want to preserve the information about the number of arms, the inner radius and the outer radius of the star.
When using XML serialization, the obvious solution is to use custom namespace:
<svg viewBox="0 0 500 500" xmlns="http://www.w3.org/2000/svg" xmlns:bx="http://www.boxy-svg.com/bx">
<path bx:shape="star" bx:arms="6" bx:r1="10" bx:r2="20" d="...">
</svg>However, I'm not sure how the corresponding markup should look like when using HTML 5 serialization. Should I use data-* attributes?
<svg viewBox="0 0 500 500">
<path data-shape="star" data-arms="6" data-r1="10" data-r2="20" d="...">
</svg>... or data-vendor-* attributes?
<svg viewBox="0 0 500 500">
<path data-bx-shape="star" data-bx-arms="6" data-bx-r1="10" data-bx-r2="20" d="...">
</svg>... or x-vendor-* attributes?
<svg viewBox="0 0 500 500">
<path x-bx-shape="star" x-bx-arms="6" x-bx-r1="10" x-bx-r2="20" d="...">
</svg>The data-* approach is very likely going to cause clashes when the file is opened with another editor.
The data-vendor-* approach does not seem to be mentioned in either HTML 5 or SVG 2 spec.
The x-vendor-* approach seems to be what the HTML 5 spec recommends, but it's not mentioned by the SVG 2 spec.
I would propose to update the SVG 2 spec to explicitly state what is the preferred approach here, so that various SVG editors could generate files with consistent sytnax. Ideally, just reference the corresponding section in the HTML 5 spec.
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
Django
The Web framework for perfectionists with deadlines.
Laravel
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
Microsoft
Open source projects and samples from Microsoft.
Google
Google ❤️ Open Source for everyone.
Alibaba
Alibaba Open Source for everyone
D3
Data-Driven Documents codes.
Tencent
China tencent open source team.