SVG2 Chapter Assessment

Note: This list is out of date. All remaining issues have been moved to github

Readiness Key

 The readiness of different sections is evaluated and represented as numbers 1 to 5.

 1 - The sections is not started at all
 2 - Many open issues exist
 3 - Some concepts need further refining
 4 - Editorial only work
 5 - Nothing to be done, ready for review

Chapters in progress

Document Structure (Erik) [readiness 4]

Number of issues: 13

In progress

• Issue 1 - editorial (not crucial to CR)
• Issue 17 - has assigned ACTION-3727 (Cyril)
• Issue 18 - has assigned ACTION-3727 (Cyril)
• Issue 19 - action on Cameron to fix consistent attribute tables throughout the spec
• Issue 20 - haven't had time to look at it yet (probably not crucial to CR)
• Issue 23 - other namespaced markup in title and desc, what is the purpose? See [1]
• Issue 24 - Cameron promised to look at this, but no action assigned, may be addressed by issue 25
• Issue 25 - will coordinate with Rich, see ACTION-3728 (ed)
• Issue 28 - coordinate with Web Components people, ACTION-3729 (Tab)
• Issue 32 - drop the offending paragraph? Still add example? See [2] What does the WG think of the example suggested by Amelia (http://lists.w3.org/Archives/Public/www-svg/2015Mar/0034.html)?
• Issue 36 - editorial, not sure that repeating what's already said elsewhere is good, but will figure smth out
• Issue 34 - wasn't entirely clear from f2f minutes, should scripts in external <use> documents run? See [3] and ACTION-3767 (Bogdan)
• Issue 37 - editorial, not crucial to CR
• Issue 40 - add grammar for list-of-extensions
• Issue 59 - add grammar for list-of-languages
• Issue 42 - editorial, figure out where to put things and avoid having duplicated wording
• Issue 43 - editorial, add some wording to discourage use of xml:base
• Issue 45 - editorial, add reference to html for parsing of tabindex
• Issue 58 - should some elements be disallowed in <use> content?
• Issue 60 - should we keep xml:base?
• Issue 61 - how should <html:base> affect svg paintservers and links etc?
• Issue 62 - SVGSVGElement.viewport (not implemented in mozilla, dummy implementation in blink [4] => drop it?)
• Issue 27 - is there a proposal for how to deal with this issue?

Depends on other specs

• Issue 4 - could be moved to next level, but has no impact on requirements AFAICT, it's a hint (not crucial to CR)
• Issue 5 - awaiting something to reference in Web Animations, ACTION-3726 (Brian)

Needing discussion

• issue 63 Should it be possible to somehow force rendering of unknown elements in other namespaces?
• issue 64 Do we need to mention anything about attributes, properties and such on SVGUnknownElements?
• issue 65 Should SVGUnknownElement be a container element?

Coordinate Systems, Transformations and Units (Dirk/Rossen ETA:F2F Checkpoint: F2F-1) [readiness 3]

Number of issues: 25

Resolved (pending review)

• Issue 2: Why are real world units relevant? Shouldn't we just be relying on CSS' fixed ratio of mm to px units?
• Issue 3: Do we need to port over some more up-to-date definitions of sizing from SVG Tiny 1.2?
• Issue 4: Talking about a "parent user agent" really makes this sound like we have a separate plugin SVG implementation communicating with a browser hosting the plugin. These days, it's going to be the same user agent.
• Issue 13: The example needs to be changed in light of the issue above about absolute units.
• Issue 14: Need to define what the union of rectangles with no area means. // already defined by geometry, this is not a special case
• Issue 15: Need to update this take into account ‘extent’ on ‘text’. // the way this is defined already addresses the problem - each glyph rect is used to calculate a union of them. This is no different from flowing or non-flowing text
• Issue 23: Proposal: disable rendering both for zero and negative width/height values inside the viewBox, but don't make it an error. // need to clarify intent here // WG: keep current text

Actionable

• Issue 1: The above paragraph and definitions need to be merged. // merge
• Issue 7: The lacuna value for viewBox is not yet defined. Should we have an explicit 'none' keyword like in SVG Tiny 1.2? // yes
• Issue 8: Transform on the ‘svg’ element is a bit special due to the ‘viewBox’ attribute. The transform should be applied as if the ‘svg’ had a parent element with that transform set. RESOLUTION: transform property applies conceptually to the outside of the 'svg' element and there is no difference between presentation attribute and style property (in terms of the visual result).
• Issue 11: This is misleading – path data for example takes values that look like coordinates and lengths yet does not allow units. // put explicit path units reference as those still use units established by viewBox
• Issue 12: That's wrong. 1px always corresponds to one user unit, and the "absolute" units must be interpreted as CSS says to, i.e. as fixed multiples of the CSS px, and not anything to do with the display's resolution. The recommendation to use the absolute units (apart from px) only for ‘width’ and ‘height’ on root ‘svg’ is a good one, however. Defining the size of a document in mm and then using mm units for shapes within it is going to give counterintuitive results, since they'll be converted to user units to resolve against the view box. // the issue is correct, need to change paragraph above to reflect that
• Issue 16: Need to determine whether 'display: none' on the ‘marker’ element itself has any effect here. // define paragraph as this would affect bounding box (bounding box should be calculated as if marker is not there)
• Issue 19: Add more examples for the new auto value? E.g some of the examples provided by David Vest.
• Issue 22: Proposal: combine the is-zero case with the negative case.
• Issue 25: Mention css object-fit/object-position as an alternative? // can do
• Issue 5: The section "effect of the transform attribute on sibling attributes" has been removed since we now reference the ‘transform’ property, but we probably should still include a similar section on how the property affects attributes on the element. // this should move to attributes section in other chapter if needed (and not there already) // WG: bring back the paragraph that was describing this
• Issue 6: Do we need this blue box, and if so, should we expand it to include all of the property definition information? Some sections (such as for ‘color’) do not have the blue box. Others, like the one for ‘white-space’, have all the information from the CSS specification it comes from. Regardless, I think we don't need to mention whether the property is animatable since all properties are animatable. // propose to remove section 7.6, at the very least we need to get rid of blue box // WG: remove it
• Issue 9: Link to the "effect of the 'transform' attribute on sibling attributes" in the above paragraph needs to be update. // Should follow the same resolution as issue 5 // WG: agreed
• Issue 17: Need a line for ‘meshGradient’. // WG: Action: Tav to do it.
• Issue 21: Add an attribute table for the definition of ‘viewBox’. // do we need to? Do we redefine something wrt SVG 1.1 // WG: add the table for the lacuna value
• Issue 18: Need to invoke the bounding box computation algorithm from the previous section with fill = true and the other options false. // WG: resolved -
• Issue 24: Add an attribute table for the definition of ‘preserveAspectRatio’. // same as 21 // WG: add the table for consistency

Needing discussion

• Issue 10: Is 'defer' supported in enough UAs and is it a compelling enough use-case to warrant it being kept? // it appears we should not need this but would like to clarify with the group // WG: needs more discussion on the list, ACTION: Bogdan will create a test case.
• Issue 20: This section needs to be updated to describe how it reflects the value of the ‘transform’ property, or just defer to css3-tranforms if everything is defined there. // latter sounds like a good option // WG: Clarify with Dirk

Text (Tav/Rossen/Cameron ETA: F2F Checkpoint: mid July) [readiness 3]

Number of issues: 34.

In Progress

• Issue 1: The discussion of vertical text (CJK and Mongolian) is lacking.
• Issue 6: Some browser may not render this SVG 1.1 figure correctly. Batik and Firefox seems to get it right.
• Issue 7: This SVG 1.1 image doesn't work in Firefox, even nightly. The "period" is in the incorrect place in Chrome.
• Issue 9, 10, 11: The values 'outside-shape' and 'auto' are probably not useful in SVG (on 'shape-inside).
• Issue 12: Shapes also defines 'inset'. It might be interesting to be able to use.
• Issue 14: The value 'auto' is probably not useful in SVG. A new value of 'none' is probably needed in which case the property is ignored.
• Issue 16: This image is a PNG. Figure out how to make a good SVG.
• Issue 17, 20: Update to CSS Writing Modes Module Level 3.
• Issue 18: In the model that text-on-a-path is text that is first layed out according to CSS and then warped along a path, we can get rid of the distinction made above.
• Issue 19: Insert figure.
• Issue 21. Correct figure (period on wrong side).
• Issue 22, 23, 24: Glyph orientation.
• Issue 25: "Current text postion"
• Issue 26: Rewrite to remove or clarify 'text chunks'.
• Issue 27: Update 'white-space' to include SVG xml:space behavior.
• Issue 32: Fully specify pre-formatted multi-line text.
• Issue 35: 'text-indent'
• Issue 36: 'hanging-punctuation'
• Issue 39: Update example (clipping).

Needing Discussion

• Issue 3: Define semantics of foriegnObject. // done
• Issue 13, 15: Allow 'shape-inside', 'shape-outside' to reference an image? // WG: yes, refer to CSS
• Issue 29, 30 Add 'font-kerning'. // WG: Tav and Cameron would discuss this
• Issue 31: 'base-line-shift' // WG: looks like we need to keep this for subscript / superscript scenarios
• Issue 34: Expand on how 'x' and 'y' effect characters. // WG: There is an empty chapter with the issue, from IRC: "it's describing how to apply x/y after CSS text layout, which is essential to have described in here"
• Issue 35: Does shape-padding effect text laid out using 'extent'? // WG:
• Issue 38: 'text-overflow' 'clip' value. // WG: Resolve on having it, nothing specific to SVG vs CSS definition here
• Issue 40: Mechanism to expose clipped text. // WG: Drop the issue. We should defer to CSS group since they're working on that problem area now

Painting: Filling, Stroking and Marker Symbols (Cameron/Dirk ETA: 3rd week of July Checkpoint: mid July) [readiness 4]

Number of issues: 13

Done

• Issue 26 - Reword some text about zero length subpaths.
• Issue 20 - Is "vertex marker" a good name?
• Issue 25 - Image resampling required to be done in linear colour space?
• Issue 18 - Should dashing still work on text?
• Issue 23 - Render chapter changes to accommodate paint-order required.

In progress

• Issue 2 - Add multiple paint "child" example.
• Issue 16 - Stroke shape calculation needs to take into account pathLength attribute.
• Issue 22 - Point out how paint-order can influence interactivity of marker children.
• Issue 24 - Should paint-order be allowed to address different types of markers (segment, vertex, etc.)?
• Issue 1 - How should 'child' behave with allowing multiple paints?
• Issue 3 - Should gradient elements also be context elements?

• Issue 19 - How do all the vector-effect keywords work with 3D transforms?
• Issue 21 - Unclear behaviour with marker orientation.

Needs review

• New vector effects section

Interactivity (Erik/Bogdan/Cameron ETA:3rd week of July (Checkpoint: mid July)) [readiness 4]

Number of issues: 5

In progress

• Issue 2 - editorial, add example
• Issue 3 - editorial, reference html spec instead of duplicating wording
• Issue 5 - define 'document view' for resize, scroll and SVGZoom (see discussion at Linköping F2F day 1)

Needing discussion

• Issue 4 - unclear if this is already addressed or not, needs Rich to be available for this discussion (see ACTION-3775)

Chapters ready for review

Introduction (Cyril/Cameron) [readiness 5]

// one editorial issue remains, should not block review

Rendering Model (Nikos/Dirk/Rossen (overflow) ETA:3rd week of July, Checkpoint:mid July) [readiness 5]

Number of issues: 10 (3 from Clipping, Masking and Compositing)

Resolved (pending review)

• Issue 2 - knock out has been removed from Compositing and Blending L1 - have re-worded section
• Issue 3 - We should mention blending. Updated text to do with groups and elements
• Issue 4 - Rather than list hatches and mesh gradients and all the other paint servers, have removed the list and added a reference to paint server chapter.
• Issue 7 - Will remove Clipping, Masking and Compositing chapter and merge content into Rendering chapter
• Issue 8 - Non normative z-index text. What do we do with it?
• Issue 6 - Not an issue, enable-background has been deprecated in favour of isolation.
• Issue 2 in masking.html - overflow-x and overflow-y property table. Resolved at SYD F2F to drop special mention of these
• Issue 9 (was 1) - what to do with overflow property table? (Clipping, Masking and Compositing)
• Issue 10 (was 3) - overflow:auto equivalent to visible? Resolved at SYD F2F to remove this text to integration spec (Clipping, Masking and Compositing)
• Issue 5 - Resolved to see what says HTML says in regard to animated images and see what applies to SVG. See ACTION-3788.

Basic Data Types and Interfaces (Cameron/Dirk ETA: 3rd week of July Checkpoint: mid July) [readiness 5]

Number of issues: 13

Done

• Issue 1 - per http://www.w3.org/2015/02/11-svg-minutes.html#item04 we will allow CSS comments/escaping in attributes
• Issue 7 - add wording explaining constant enum values
• Issue 19 - Remove the unit accessors on SVGAnimatedLength and SVGLength
• Issue 2 - there is now a definition of lacuna values to link to (ACTION-3720 on Cameron)
• Issue 20 - SVGViewSpec IDL attribute definitions; needs investigation
• Issue 3 - add wording about attribute reflection
• Issue 4/5 - linking to HTML for focus/blur definitions
• Issue 6 - SVGLength viewport size zero conversions; decided to throw an exception (ACTION-3722 on Cameron)
• Issue 12 - Making SVGGraphicsElement.transform reflect the 'transform' property (part of Issue 3)
• Issue 13 - getCTM on an <svg> element; awaiting investigation (ACTION-3724 on Dirk)
• Issue 14 - getScreenCTM taking into account 'transform' on <svg>
• Issue 15 - getTransformToElement with elements in other fragments; look at measurements
• Issue 21 - Serializing non-scalar values on SVGLength

Styling (Cameron ETA: mid September Checkpoint: F2F) [readiness 5]

Number of issues: 42

Done

• Issue 2: Ensure we don't require particular CSS versions where we don't have to.
• Issue 20: Remove talk of XSL/XSLT.
• Issue 21: Remove the "Alternative ways to specify styling properties" section or fold it into the following sections.
• Issue 22: Require CSS styling support in all conformance classes. (ACTION-3709 on Cameron)
• Issue 41: Improve an example.
• Issue 23: Remove all of the advantages/limitations discussion in the "Specifying properties using the presentation attributes" section
• Issue 5: Remove odd reference to "the CSS 2.1 cascade".
• Issue 6: Remove text that talks about not supporting CSS.
• Issue 24: Reference new section in Types about parsing presentation attributes.
• Issue 42: Improve an example.
• Issue 7: Revise a paragraph talking about CDATA sections in style elements.
• Issue 8: Update conformance classes re supporting CSS.
• Issue 27: Remove sentence allowing CDATA sections in style.
• Issue 10: Update some text from URIs to URLs.
• Issue 11: ?
• Issue 28: No longer require "correct" case to be used in presentation attributes. (ACTION-3276 on Cameron)
• Issue 29: Remove useless recommendation for authors to use exact casing.
• Issue 43: Remove the "Facilities from CSS and XSL used by SVG" section.
• Issue 12: Add discussion of @import.
• Issue 13: Add text that defines how HTML link works for style sheets in SVG.
• Issue 30: Fold "Referencing external style sheets" section into a previous one.
• Issue 31: Add text describing what effect the media attribute on style actually has.
• Issue 32: Update attribute definition table syntax.
• Issue 14: Call into HTML algorithm to parse class attribute.
• Issue 33: Add an attribute definition table for class.
• Issue 15: Add an attribute definition table for style, and refer to css-syntax's algorithm for parsing a declaration.
• Issue 34: Ensure other HTML style element attributes like scoped work. (ACTION-3277 on Cameron)
• Issue 35: Rework "Property inheritance" section.
• Issue 36: Mention style sheets in SVG inline in HTML.
• Issue 37: Condense the "The scope/range of styles" section.
• Issue 38: Add more text describing the width/height properties.
• Issue 39: Replace width/height property definitions with references to CSS.
• Issue 40: Remove mention of visual media wrt UA style sheet.
• Issue 1: Update list of properties and normative CSS spec dependencies.
• Issue 3: State which properties have corresponding presentation attributes. (ACTION-3732 on Cameron)
• Issue 25: Confirm animation of presentation attribute behaviour.
• Issue 9: Require CSS Selectors 3?
• Issue 26: Should we support ::before/::after?
• Issue 16: Do we need to define 'auto' for svg/foreignObject?
• Issue 18/19: Update UA style sheet. (ACTION-3733 on Cameron for some more investigation)

Paths (Cameron/Bogdan) [readiness 5]

Moving to Cameron to move Catmull-Rom to it's own spec per https://www.w3.org/Graphics/SVG/WG/track/actions/3745

Number of issues: 12

Resolved (pending review)

* Issue 1 Also they can be used by ‘mpath’ and ‘textPath’. // rewording to address issue

• Issue 3 The path data is defined to allow newline characters, but it should be noted that newlines inside attributes in markup will be normalized to space characters while parsing. If you wanted to, you could write

<path d="M 100,100 L 200,150"/> but it's not likely that you'd want to. // rewording to address issue

• Issue 4 Are there tools that have line limits nowadays? Do we still need to recommend generators to split up path data at 255 characters?
• Issue 5 The sentence about newline characters being allowed only at certain places makes it sound like these places are different from where white space more generally is allowed, but that's not the case. // rewording to address issue
• Issue 9 Where should we link to for a definition of Catmull-Rom curves so that we don't have to redefine them here? // we should link http://en.wikipedia.org/wiki/Centripetal_Catmull-Rom_spline at the first mention
• Issue 12 What should we do about the SVGPathSeg objects for these new path commands? // http://www.w3.org/2015/02/11-svg-minutes.html#item10 (see ACTION-3796)
• Issue 2 Although it is not explicitly stated, when an attribute is specified using an EBNF/ABNF symbol, it would be expected that it either parses or doesn't. However, the definition below of the path data grammar specifies error handling. We should make sure that this is clear upon seeing svg-path above. // rewording to address issue

Basic Shapes (Rossen) [readiness 5]

Number of issues: 0

Actionable

Issue 2 Rossen to edit the spec with the proposed changes.

Issue 3 Call out the direction of the arc explicitly - CW, which would disambiguate stroke pattern (the only detectable way to see the arc).

Issue 4 The issue is correct, we'll add the explicit text saying that the last coord is simply dropped without affecting the rendering of the previous shape. (reminder - fix first sentence which currently makes no sense).

Issue 5 The issue is correct, I'll remove the error definition.

Issue 1 Though it is true that shapes can always be expressed by an equivalent path, implementations should be allowed to optimize (perf) using native primitives.

Embedded Content (Bogdan ETA:3rd week of July Checkpoint: mid July) [readiness 5]

Resolved (pending review)

• Issue 5-6 I read this as frameWidth/Height and canvasWidth / Height specifying intrinsic size, while width/height - extrinsic
• Issue 7 This is minor issue I suggest we resolve to keep things where they are
• Issue 8 I believe this is covered in SVG DOM
• Issue 9 Fixed already
• Issue 1 Why this is Embedded resources issue? - this should be moved to Resource priorities for SVG Proposal
• Issue 2 - I see that issue was already removed
• Issue 3 - addressed as discussed with WG during Paris 2015 F2F
• Issue 4 - addressed as discussed with WG during Paris 2015 F2F

Paint Servers: Solid Colors, Gradients, Patterns and Hatches (Tav/Erik ETA:3rd week of July, Checkpoint:mid July) [readiness 5]

Number of issues: 11

In Progress

• Issue 1: "built-in" paint servers. // Done
• Issue 2: Merge text and definition.
• Issue 3: Choose better figure.
• Issue 4: Finish converting to MATHML. // Done
• Issue 5: Better explanation with diagram. // Optional
• Issue 6: Define 'x', 'y', 'gradientUnits', 'transform', and 'href' attributes. // Done
• Issue 7: Review content model.
• Issue 8: Proper example with links to SVG.
• Issue 9: IDL for SVGSolidcolorElement.
• Issue 10: IDL for SVGHatchElement.
• Issue 11: IDL for SVGHatchpathElement.

Linking (Bogdan/Amelia ETA: 3rd week of July Checkpoint: mid July) [readiness 5]

Number of issues: 13

Resolved (pending review)

• Issue 4 Looks like can be safely removed
• Issue 1 This just needs to happen
• Issue 2 Indeed - should be simple clarification and then this section would be ready for editorial work
• Issue 3 Why this needs to be harmonized? What is the real functional impact?
• Issue 6 Another paragraph that needs editorial work
• Issue 5 Needs discussion // this and two more below discussed May 7th - http://www.w3.org/2015/05/07-svg-minutes.html
• Issue 7 Needs discussion - why those parameters were not added yet?
• Move the URL reference restrictions from the big list in section 15.1.4 to throughout the spec, where individual elements/properties/attributes are defined
• Issue 8 What is the current support and why spec specifies different behavior?

// WG: Discuss with Amelia about these issues

• • Briefly mentioned what to do with #xywh here http://www.w3.org/2015/06/09-svg-irc#T14-32-33
• Issue 12-13 Needs discussion / action follow-up

Scripting (Bogdan) [readiness 5]

Number of issues: 2

Actionable

* Issue 1 Needs group discussion

• Issue 2 Also needs discussion

 Actions:
 * Remove sections 16.2 and 16.3
 * Keep section 16.1 and 16.4
 * Merge with the Interactivity chapter

 Note:
 * Didn't remove event attributes section (16.2) since there were a lot of links to it

Animation (Brian/Bogdan ETA:3rd week of July Checkpoint: mid July) [readiness 4]

Number of issues: 3

Actionable

issue 2 - huh? //WG: Reference the CSS white space section instead.

issue 8 - The issue is somewhat unclear - are we suggesting to remove this section in favor of the transform property? //WG: add an explanation the animate transform element can refer to both the transform property and the animateTransform attribute.

issue 3 to 7 - This looks actionable but not sure what the intended syntax is supposed to look like.

 Actions:
 Move this chapter to its own module.

Extensibility (Rossen) [readiness 5]

Number of issues: 2

Resolved (pending review)

issue 1 - will do

issue 2 and 3 - Why would FO presentation attributes be any different than the rest of SVG PAs?

 Actions:
 WG: Merge Embedded component and Extensibility chapter. Move the issues to the OM part of the spec.

Appendices

SVG Document Object Model (Bogdan/Rossen) [readiness 5]

Number of issues: 0

Resolved (pending review)

attr lifetime - The first paragraph states that an attr object is not live until its first modification, yet the previous paragraph states that all SVG DOM attr objects are live - need to sort out the contradiction.

hasFeature - current implementation in webkit reports 'true' for any requested feature even if it is bogus. //WG: remove this paragraph from the spec.

IDL Definitions (Bogdan/Rossen) [readiness 5]

Number of issues: 0

Resolved (pending review)

- issue 1 and 2 - We must either move all IDL defs here or remove this appendix all together.

Implementation Requirements (Bogdan/Rossen) [readiness 5]

Number of issues: 10

Resolved (pending review)

issue 4 - We should remove the specific paragraph "When an element has an attribute or property value..." since the following paragraph is more generic and it covers it.

issue 5 - The issue is correct, we should drop the requirement.

issue 7 - Let's pretend this paragraph never existed :)

issue 8 - There is nothing special about lacunae values, drop the issue.

issue 9 - Drop section C.3.

issue 6 - The issue is pointing out a good problem - the current requirement imposes implementation of partial/incomplete constructs such as partial animations, which is difficult and different from any other error recovery in DOM or CSS. We must drop the paragraph.

Range Clamping - Attribute preservation of out-of-range values sounds unreasonable in most cases. We should suggest simply a fallback to the lacuna value.

* We discussed this and the current paragraph wording is correct - so no change in the spec

issue 10 - Moving error handing to a specific section in each chapter sounds like the right thing to do.

issue 1 - Is the issue pointing out that SVG part of the document won't render or the entire HTML document? The later is certainly not true and the first is true for SVG, thus this shouldn't be an issue?

issue 2 and 3 - These are good points. We should move these to annotations since they're not really normative requirements.

Conformance Criteria (Bogdan/Rossen) [readiness 5]

Number of issues: 1

Resolved

issue 1 - This is a good issue to discuss with the WG.

 Actions:
 * Write the requirements in terms of blue boxes. 
 * Ideally generating this automatically from the blue boxes.

Accessibility Support (Bogdan/Rossen) [readiness 5]

Number of issues: 0

References (Bogdan/Rossen) [readiness 5]

Number of issues: 0

Element Index (Bogdan/Rossen) [readiness 5]

Number of issues: 1

Resolved (pending review)

issue 1 - Drop the issue. Not really an issue, since this entire appendix is informative and intended for indexing into the SVG document. From there elements are either defined or extended thus no further work should be done here.

Attribute Index (Cameron) [readiness 4]

Number of issues: 1

Property Index (Cameron) [readiness 4]

Number of issues: 2

IDL Index (Bogdan/Rossen) [readiness 5]

Number of issues: 1

Resolved

- appendix j - Since the IDL definitions will move to their own appendix, this appendix is no longer required and must be removed.

* We agreed this appendix just stays, since it's generated and not normative anyway

Feature Strings (Bogdan/Rossen) [readiness 5]

Number of issues: 1

Resolved (Needs review)

appendix K - None of this really matters if implementations currently return true for everything. Other than that this chapter is good.

 Actions:
 * Drop this appendix all together

Media Type Registration for image/svg+xml (Bogdan/Rossen) [readiness 5]

Number of issues: 0

Changes from SVG 1.1 (Bogdan/Rossen) [readiness 5]

Number of issues: 1

Needs Discussion

appendix M - This is everybody's responsibility to complete ones we close on all chapters of the document. Must revisit before we're ready to go to LC/PR.

Entire document

• Update exception throwing from DOMException plus a numeric code to the new exception names