1212826 - (svg-info-db) Create JSON DB for SVG info

Status: RESOLVED FIXED

(Developer Documentation Graveyard :: Macros/Templates, enhancement)

Description

[Sebastian Zartner [:sebo]]

General information about SVG elements and attributes should be stored in a JSON DB.

Sebastian

Comment 1

[Sebastian Zartner [:sebo]]

Attachment: SVGData structure

This is a first draft of a JSON structure holding the SVG data.
The elements part is pretty straightforward, though the attributes part gives me some headache.

The SVG specification, especially SVG 2 refers to different resources[1] with different ways of defining the attributes. Sometimes a single attribute has multiple meanings. See 'height' for example. And presentational attributes like 'font-size' refer to CSS properties, which include additional info like inheritance, percentage values, computed value, etc.

So how should we store this information in the DB?
And is the current chosen structure for SVG elements ok?

Sebastian

[1] https://svgwg.org/svg2-draft/attindex.html

Comment 2

[Jean-Yves Perrier [:teoli]]

Comment on attachment 8673656 [details]
SVGData structure

A few feedback (non exhaustive)

Categories
"categories": "basicShapeElement, graphicsElement, shapeElement" 
This should be a list: ["basicShapeElement", "graphicsElement", "shapeElement"] and [] for none. 
Two reasons for this: a) not every script uses ',' as a delimiter b) if we want to create a macro listing all the basic shape element, it is possible without complex parsing.

I wonder if we should do it in two passes. First we deal with the elements, letting the attribute aside (not in the DB, hardcoded as now in the pages).

That would mean: a table similar to the one of HTML (including interfaces for example), but also adding a spec table at the bottom of each element.

A second bug can deal with attributes afterwards. I wonder if having attributes at the SVG level is the right thing to do. Maybe we should have attributes below elements (like for API members)? ni/ Jeremie for its insight too here.

Comment 3

[Sebastian Zartner [:sebo]]

(In reply to Jean-Yves Perrier [:teoli] from comment #2)
> Comment on attachment 8673656 [details]
> SVGData structure
> 
> A few feedback (non exhaustive)
> 
> Categories
> "categories": "basicShapeElement, graphicsElement, shapeElement" 
> This should be a list: ["basicShapeElement", "graphicsElement",
> "shapeElement"] and [] for none. 
> Two reasons for this: a) not every script uses ',' as a delimiter b) if we
> want to create a macro listing all the basic shape element, it is possible
> without complex parsing.

Good point.

> I wonder if we should do it in two passes. First we deal with the elements,
> letting the attribute aside (not in the DB, hardcoded as now in the pages).
> 
> That would mean: a table similar to the one of HTML (including interfaces
> for example)

Sounds good to me. Created bug 1214725 to cover the attributes part.

> but also adding a spec table at the bottom of each element.

I didn't mention it explicitly, though of course there should be a spec table at the bottom of each page. That's why I did not include the spec in the JSON.

Sebastian

Comment 4

[Sebastian Zartner [:sebo]]

(In reply to Sebastian Zartner [:sebo] from comment #3)
> > but also adding a spec table at the bottom of each element.
> 
> I didn't mention it explicitly, though of course there should be a spec
> table at the bottom of each page. That's why I did not include the spec in
> the JSON.

I've added a 'Specifications' section to every SVG element now replacing the link in the info box.

Sebastian

Comment 5

[Sebastian Zartner [:sebo]]

Currently the SVG pages distinguish between 'Global attributes' and 'Specific attributes' while the specifications don't make this distinction. See <animateMotion>[1][2] for example.
Should we keep that separation in the JSON or not?

Sebastian

[1] https://developer.mozilla.org/en-US/docs/Web/SVG/Element/animateMotion
[2] http://www.w3.org/TR/SVG11/animate.html#AnimateMotionElement

Comment 6

[Jean-Yves Perrier [:teoli]]

I'm forwarding the question to Jérémie, I would like to hear his opinion about attributes in SVG (likely beginning of next week).

Comment 7

[Jeremie Patonnier :Jeremie]

Hi!

SVG attributes are quite complex. It's true that the global vs specific distinction is "wrong". To be accurate there is 3 kind of attributes on SVG elements:

* Attributes that can be used by all SVG elements (likely some sort of "global" attributes)
  https://svgwg.org/svg2-draft/struct.html#TermCoreAttribute

* Attributes that can be used by a given group of SVG elements
  Some spec try to define groups of attributes that apply in bulk to some given elements:
  https://svgwg.org/specs/animations/#AdditionAttributes
  https://svgwg.org/specs/animations/#TermAnimationEventAttribute
  https://svgwg.org/specs/animations/#AttributeNameAttribute
  https://svgwg.org/specs/animations/#TimingAttributes
  https://svgwg.org/specs/animations/#ValueAttributes
  https://svgwg.org/svg2-draft/struct.html#TermARIAAttribute
  https://svgwg.org/svg2-draft/struct.html#TermConditionalProcessingAttribute
  https://svgwg.org/svg2-draft/interact.html#TermDocumentEventAttribute
  http://www.w3.org/TR/2014/CR-html5-20140204/webappapis.html#globaleventhandlers
  https://svgwg.org/svg2-draft/interact.html#TermGraphicalEventAttribute
  https://svgwg.org/svg2-draft/styling.html#PresentationAttributes
  https://svgwg.org/svg2-draft/styling.html#ElementSpecificStyling
  https://svgwg.org/svg2-draft/linking.html#XLinkRefAttrs
  ...
  And I'm pretty sure I miss some.

* Attributes that can be used by a single SVG elements
  Basically all attributes that are listed individually within elements definition

The fun parts begin with the fact that some attributes can have the same name but behave very differently from one element to the another. For example: fill which is different for basic shapes and animation elements:
https://svgwg.org/svg2-draft/painting.html#FillProperty 
https://svgwg.org/specs/animations/#FillAttribute

And of course, there are the presentation attributes than can be used both as CSS properties or attributes.

Because of all that mess, the spec do very little difference between attributes:
https://svgwg.org/svg2-draft/attindex.html

Oh, and for what it worth, we should relay on the SVG2 spec draft (and all its independent modules) for all things about SVG if we want an accurate vision of what really happens within browsers:

SVG 2: https://svgwg.org/svg2-draft/ 
SVG Animation: https://svgwg.org/specs/animations/
SVG Markers: https://svgwg.org/specs/markers/
SVG Paths: https://svgwg.org/specs/paths/ (no attributes defined)
SVG Strokes: https://svgwg.org/specs/strokes/
(Note: SVG fonts have been removed from SVG 2 clear and simple, we shouldn't bother documenting that)

I have no idea what should be done in the JSON, but I would tend to make a single attribute/element association and if it's possible to do some factorization (to avoid documenting things twice), that will be at another level.

Comment 8

[Jeremie Patonnier :Jeremie]

Comment on attachment 8673656 [details]
SVGData structure

I've nothing to said about the data structure itself.

Comment 9

[Sebastian Zartner [:sebo]]

Thank you for the info, Jeremie! I've copied your comment over to bug 1214725, as we decided to split the implementation of the attributes out, so we can track them separately.

I've now created https://developer.mozilla.org/en-US/docs/Template:SVGData, which currently holds the data from the different en-US pages.
In a next step I'll try to merge in the localizations from the other pages.

Sebastian

Comment 10

[Sebastian Zartner [:sebo]]

The JSON DB now exists. So let's call this one done.
Subsequent changes can be done in separate bugs.

Sebastian

Comment 11

[Sebastian Zartner [:sebo]]

Comment on attachment 8673656 [details]
SVGData structure

Feedback was given in comment 2.

Sebastian