Review implementation support - SVG 2 Master issue

[AmeliaBR]

Tracking issue, collecting all issues reviewing the implementation status of SVG 2 changes.

By chapter:

• 1, Introduction / Whole Document changes: Review implementation support - Intro / whole document #488
• 2, Conformance Criteria, Review implementation support - Conformance Criteria #491
• 3, Rendering Model, Review implementation support - Rendering Model #492
• 4, Basic Data Types, Review implementation support - Basic Data Types and Interfaces #494
• 5, Document Structure
• 6, Styling
• 7, Geometry Properties
• 8, Coordinate Systems, Transformations, and Units
• 9, Paths Review implementation support - Paths chapter #385
• 10, Basic Shapes Review implementation support - Basic Shapes chapter #484
• 11, Text
• 12, Embedded Content Review implementation support - Embedded Content chapter #384
• 13, Painting (fill, stroke, markers)
• 14, Paint servers
• 15, Scripting and Interactivity
• 16, Linking
• Appendices

(I'll add links to the chapter issues as I create them.)

Each chapter's implementation issue will have a checklist of new features, which should not be checked off until either:

• tests have been contributed, and at least 2 implementations pass (and ideally, bugs filed on any non-passing browsers/major authoring tools)
• or, the feature is removed or deferred

Only once all the features in a chapter's implementation checklist have been checked off, that chapter can be checked off in this issue.

[css-meeting-bot]

The Working Group just discussed implementation review.

The full IRC log of that discussion

<krit> topic: implementation review
<AmeliaBR> Github: https://github.com//issues/487
<krit> AmeliaBR: tried to get some structure with linking to tests in SVG 1.1
<krit> AmeliaBR: some changes in SVG 2 are editorial and don't require test updates. I tried to create issues for tests on every item to the list.
<krit> AmeliaBR: if ppl add more tests that need more discussions, go back to the GitHub issue 487 and update the section in question with your question.
<krit> AmeliaBR: Please add new information as a comment and never edit existing comments otherwise ppl wouldn't get noticed. But if status changes on a section, edit the initial comment on each GitHub section issue.
<krit> krit: Could you please update the README so that we have a link to 487?
<krit> AmeliaBR: would be good to have a link so that it doesn't get lost.
<krit> AmeliaBR: some specific issues I discovered: A number of tests for data types. Didn't get to going through the list if they have been updated. Someone should review them. More generic issue: How do we keep track of which paragraph/section line up to specific tests. Tests should have links to the section/paragraph in the spec but that depends on the granularity of links in SVG2.
<krit> AmeliaBR: Bikeshed added reverse linking from tests to the spec but we do not have this generic way.
<krit> Tavmjong: how does CSS do it?
<krit> AmeliaBR: they use Bikeshed to generate the specs.
<krit> AmeliaBR: we have our own build system.
<krit> Tavmjong: would be great to have this back linking
<krit> AmeliaBR: would be great to have links to tests in the spec right to the repository.
<krit> AmeliaBR: automated tests results don't happen for manual tests.
<krit> AmeliaBR: we should come up with some metrics to see what we have tests for.
<krit> krit: with the current build system... should we manually add links to the tests?
<krit> AmeliaBR: yes.
<krit> krit: are those links commented out or hidden from the spec?
<Tavmjong> https://www.w3.org/TR/css-fonts-3/#font-style-matching
<krit> AmeliaBR: we could do something with a whole list of tests per section... I'd rather make more efforts to break down the tests paragraph by paragraph
<krit> Tavmjong: Do you plan something like in CSS Fonts.
<krit> AmeliaBR: not as detailed as CSS does it.
<krit> liam: CSS has complex tools to do that including Bikeshed.
<krit> krit: was more thinking of something simple as adding <!--- comments to the spec text itself for now.
<krit> Tavmjong: could you do an example for next week?
<AmeliaBR> Example. Circles should be round (<a href="https://wpt.fyi/results/svg/shapes/...>Test</a>)
<liam> s/complex tools/tools (that require different markup in the spec)/
<AmeliaBR> Real result page: https://wpt.fyi/results/svg/painting/reftests/paint-context-001.svg
<krit> krit: would be easier to see a PR and we'd follow its lead.
<krit> AmeliaBR: sounds good
<krit> AmeliaBR: we should resolve when we have specific examples.
<AmeliaBR> https://github.com//issues/506
<krit> krit: so we take it up next week?
<liam> +1 to spec linking back to tests (or to metadata in tests linking back, and a tool to connect them)
<krit> krit: I'd be in favour for those back links. Makes it easier to prove that we have tests in place for each section.
<krit> krit: are there more tests on SVG beside DOM APIs?
<krit> AmeliaBR: browser implementers do upload SVG tests for specific scenarios but no basic testing. Beside the tests for SVG 1.1 and the PNG manual pixel testing.
<krit> Tavmjong: this is not a priority for us.
<krit> AmeliaBR: Right, we focus on the changes from sVG 1.1 to SVG 2.0
<krit> krit: any advice on creating the section specific implementation support?
<krit> AmeliaBR: was going through the changes section. However, we had a lot of reorganisation of the spec. So changes might not only be in the section one would expect them to be. Make sure to find all the changes.
<krit> Tavmjong: one thing about webplatofrm tests: they don't show the reference. So you don't see how and why they fail.
<krit> AmeliaBR: yes. Either they pass or fail
<krit> AmeliaBR: it is mostly optimized for automised tests
<krit> AmeliaBR: there are 2 types: script focused tests and ref tests.
<krit> krit: both are intended to run in the console for every browser.
<krit> AmeliaBR: that is true.