Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

'd' presentation attribute: use path() function #374

Open
wants to merge 2 commits into
base: main
Choose a base branch
from
Open
Show file tree
Hide file tree
Changes from 1 commit
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Prev Previous commit
d attribute has different syntax than property
  • Loading branch information
ericwilligers committed Nov 5, 2018
commit 7d96fba8a60ee24742292524f4a7a4aec3f178ca
36 changes: 34 additions & 2 deletions master/paths.html
Original file line number Diff line number Diff line change
Expand Up @@ -231,6 +231,10 @@ <h3 id="TheDProperty">Specifying path data: the <span class='property'>'d'</span
If the path data string contains no valid commands, then the behavior
is the same as the <span class='prop-value'>none</span> value.</p>
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We probably need to clarify how this fallback works in CSS terms.
Would this affect the "used value" or only the "actual value"?
Or should we match the terminology used in other shapes, e.g., "A computed value of zero for either dimension disables rendering of the element."?
(So it would be "A path data string that contains no valid commands disables rendering of the element.")


<p>When <a>'d'</a> is parsed as an attribute, it is parsed according to the
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could you be more specific what this means for the path() function please? I thing what you want to say is that the grammar would not allow path() and falls back to EBNF as specified in this spec.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree that it could be more clear. Maybe:

Suggested change
<p>When <a>'d'</a> is parsed as an attribute, it is parsed according to the
<p>When <a>'d'</a> is parsed as a <a>presentation attribute</a>,
the entire attribute value is parsed as if it was a `<string>` wrapped with `path()` function notation.
The string is then parsed according to the
<a href="#PathDataBNF">svg-path</a> <a href="types.html#syntax">EBNF grammar</a>,
and not as a sequence of CSS tokens.
</p>

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We also need to define the term "path data string" somewhere, since it's used a lot in the prose.

<a href="#PathDataBNF">svg-path</a> <a href="types.html#syntax">EBNF
grammar</a>, instead of the CSS grammar given above.</p>

<p>
For animation, two <a>'d'</a> property values can only be
interpolated smoothly when the path data strings contain have the
Expand All @@ -253,12 +257,40 @@ <h3 id="TheDProperty">Specifying path data: the <span class='property'>'d'</span
<a href="https://drafts.csswg.org/web-animations/#animation-interpolation">interpolated</a>
separately <a href="https://drafts.csswg.org/web-animations/#real-number-animation-type">as
real numbers</a>. Flags and booleans must be interpolated as
fractions between zero and one, with any non-zero value considered
to be a value of one/true.
integer values clamped between zero and one.
</p>

</div>

<div class='ready-for-wider-review'>

<h3 id="TheDAttribute">The <span class="attr-name">'d'</span> attribute</h3>
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why was this section added?

I'd prefer to stick with defining both the property and attribute syntax in one place.
They are the same value, just with special parsing rules when the value is provided as a presentation attribute.


<dl class="attrdef-list">
<dt>
<table class="attrdef def">
<tr>
<th>Name</th>
<th>Value</th>
<th>Initial value</th>
<th>Animatable</th>
</tr>
<tr>
<td><dfn id="TermD" data-dfn-type="element-attr" data-dfn-for="path" data-export="">d</dfn></td>
<td>"<span class="attr-value">path data</span>"</td>
<td>As if not specified.</td>
<td>yes</td>
</tr>
</table>
</dt>
</dl>

<p>
The contents of the attribute must match the svg-path EBNF grammar defined below, and errors within the string are handled according to the rules in the Path Data Error Handling section. If the path data string contains no valid commands, then the behavior is the same as if the attribute was not specified.
</p>

<h3 id="PathData">Path data</h3>

<p>The following sections list the commands that can be used
in path data strings. Those that
draw straight line segments include the <a href="paths.html#PathDataLinetoCommands">lineto commands</a>
Expand Down
6 changes: 5 additions & 1 deletion master/types.html
Original file line number Diff line number Diff line change
Expand Up @@ -143,7 +143,11 @@ <h2 id="syntax">Attribute syntax</h2>
unitless length and angles to be used in presentation attribute while
disallowing them in corresponding property values.</p>

<p class="note">Note that all <a>presentation attributes</a>, since they are
<p>The <a>'d'</a> presentation attribute is an exception, it is parsed
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For CSS Transforms we are a little bit more verbose and explain why there are differences as well. See https://drafts.csswg.org/css-transforms/#svg-syntax I think we should be a little bit more verbose here too.

Did we agree on freezing the d presentation attribute to the definition of SVG 1.1? No support of the additional CSS property values?

IMO we should allow all values the property has + the string value itself for backwards compatibility reasons. But I am not sure if:

  1. We have discussed this in the WG already and resolved to not extend the grammar
  2. Chrome would support the additional CSS syntax on the attribute as well.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Guess I commented here already. Still applies IMO.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it would confuse parsing too much to to allow the path() notation inside the attribute.

That said, I don't see any reason to freeze the attribute at SVG 1.1 when it comes to path data commands. Instead, treat the attribute value as a string injected into a path() wrapper. If we ever do add other commands, they would be valid here, too.

according to the <a href="paths.html#PathDataBNF">svg-path</a>
<a href="types.html#syntax">EBNF grammar</a>.</p>

<p class="note">Note that all other <a>presentation attributes</a>, since they are
defined by reference to their corresponding CSS properties, are defined using
the CSS Value Definition Syntax.</p>

Expand Down