Re: [svgwg] Potentially invalid value for dasharray (#642)

The SVG Working Group just discussed `Potentially invalid value for dasharray`, and agreed to the following:

* `RESOLVED: Change the syntax as I wrote it out in AmeliaBR's comment yesterday`

<details><summary>The full IRC log of that discussion</summary>
&lt;myles> Topic: Potentially invalid value for dasharray<br>
&lt;myles> GitHub: https://github.com/w3c/svgwg/issues/642<br>
&lt;myles> AmeliaBR: About the syntax for stroke-array. As I commented yesterday, this is something we discussed before, and we changed a lot of other examples and this one somehow got missed in all those edits.<br>
&lt;myles> AmeliaBR: So, I would recommend changing the grammar to be consistent with the other edits we made, which is to explicitly separate out the space-separated repeats and the comma separated repeats using square brackets<br>
&lt;myles> AmeliaBR: The other issue that krit discovered is there are some weird things where you don't need space separating at all, and I'm not sure if that's consistent with CSS or not. I pinged TabAtkins to see his thoughts, but he didn't get back to me. All browsers are consistent, though, so CSS parsing should change.<br>
&lt;myles> krit: I know TabAtkins's opinion on that, so I would not count on a spec change. At least for the SVG attribute we can specify it how it's implemented. For CSS, it's up to the CSSWG.<br>
&lt;myles> krit: On the other hand, this part is not that important.<br>
&lt;myles> AmeliaBR: We can make an edit to the grammar ourselves, and follow-up on whether spaces are necessary between subsequent numbers if the numbers are obviously distinguishable otherwise. It's a separate issue.<br>
&lt;TabAtkins> There's a bunch of stuff in CSS where you don't *technically* need spaces, if you're careful in how you're butting things against each other.<br>
&lt;myles> AmeliaBR: The other comment I made at the end. We have a statement about how these things are serialized if we allow spaces or comments and I haven't looked to see whether we have that<br>
&lt;myles> krit: For computed style?<br>
&lt;myles> AmeliaBR: Yes, and for serialization too<br>
&lt;myles> AmeliaBR: &lt;reads TabAtkins's IRC comments><br>
&lt;myles> krit: They don't technically need spaces.<br>
&lt;myles> chris: I remember TabAtkins trying to explain that to me. There's a grammar that defines it but &lt;missed><br>
&lt;myles> chris: It sounded like handwaving magic to me but okay.<br>
&lt;myles> AmeliaBR: With that clarification from TabAtkins it covers that topic<br>
&lt;myles> AmeliaBR: I'll see if the other part is already covered, if it isn't, I'll make another issue<br>
&lt;TabAtkins> ? No grammar weirdness, you just follow the parsing algorithm. `.9.9` is NUMBER(.9) NUMBER(.9), because the number-token parsing stops at the second `.`, emitting the NUMBER, then starts a new NUMBER.<br>
&lt;AmeliaBR> s/other part/serialization issue/<br>
&lt;myles> krit: We should have another issue to see if implementations actually align.<br>
&lt;myles> krit: Let's open another issue<br>
&lt;chris> s/missed/it says spaces are required then says they aren't in some cases/<br>
&lt;chris> we agree, TabAtkins<br>
&lt;myles> krit: If you read the syntax, the prose doesn't require spaces.<br>
&lt;myles> AmeliaBR: It just says "repeated tokens" without commas that usually means spaces separation but it doesn't necessarily mean that<br>
&lt;TabAtkins> Note that serialization *should* always emit spaces, regardless of what the author input.<br>
&lt;myles> RESOLVED: Change the syntax as I wrote it out in AmeliaBR's comment yesterday<br>
&lt;myles> s/as I wrote/as AmeliaBR wrote/<br>
&lt;myles> AmeliaBR: I can make the edit. I'll also look into the other issue I brought up.<br>
</details>


-- 
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/svgwg/issues/642#issuecomment-474093370 using your GitHub account

Received on Monday, 18 March 2019 20:44:38 UTC