Closed Bug 1212826 Opened 5 years ago Closed 5 years ago
(svg-info-db) Create JSON DB for SVG info
General information about SVG elements and attributes should be stored in a JSON DB. Sebastian
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 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  https://svgwg.org/svg2-draft/attindex.html
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.
(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
(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
Currently the SVG pages distinguish between 'Global attributes' and 'Specific attributes' while the specifications don't make this distinction. See <animateMotion> for example. Should we keep that separation in the JSON or not? Sebastian  https://developer.mozilla.org/en-US/docs/Web/SVG/Element/animateMotion  http://www.w3.org/TR/SVG11/animate.html#AnimateMotionElement
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).
Flags: needinfo?(jypenator) → needinfo?(jeremie.patonnier)
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 on attachment 8673656 [details] SVGData structure I've nothing to said about the data structure itself.
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
The JSON DB now exists. So let's call this one done. Subsequent changes can be done in separate bugs. Sebastian
Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
Comment on attachment 8673656 [details] SVGData structure Feedback was given in comment 2. Sebastian
You need to log in before you can comment on or make changes to this bug.