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

[motion-1] The computed value of offset-path: path(' ') #392

Closed
BorisChiou opened this issue Jan 22, 2020 · 7 comments
Closed

[motion-1] The computed value of offset-path: path(' ') #392

BorisChiou opened this issue Jan 22, 2020 · 7 comments

Comments

@BorisChiou
Copy link

Based on the definition of SVG1.1 and SVG2:

The EBNF allows the path data string in the d property to be empty. An empty path data string disables rendering of the path. Rendering is also disabled when the d property has the value none.

So an empty path string is valid. And then what is the expected computed value for this case?

offset-path: path(' ');

If someone calls getComputedStyle(div).offsetPath, should we return path('') or none for offset-path? It seems Blinks return none for now. It looks like the spec doesn't mention this, anyway.

@BorisChiou
Copy link
Author

cc @ericwilligers

@BorisChiou BorisChiou changed the title [motion-1] How to present offset-path: path(' ') [motion-1] The computed value of offset-path: path(' ') Jan 22, 2020
@ewilligers
Copy link
Contributor

Blink treats <path d=""/> and <path /> and <path style="d: path('')" /> and <path style="d: none" /> all as having path none - example.

I don't see value in maintaining different computed style states for these.

The spec could state that path() with an empty path string serializes as none.

@BorisChiou
Copy link
Author

Great. Thanks. This is also for clip-path. I'm also updating Gecko to have none value for clip-path: path(' ').

@emilio
Copy link
Contributor

emilio commented Jan 23, 2020

It seems really odd to serialize it as none but parse it as valid. It seems to me that path('') is a fine path, just with no commands...

@ewilligers
Copy link
Contributor

It seems to me that path('') is a fine path, just with no commands..

It is, that is why in the example it sets the specified value, while path('nonsense') does not. This is about normalization: no commands is equivalent to no path.

@emilio
Copy link
Contributor

emilio commented Jan 23, 2020

But they're not the same, right? offset-path: path('') should establish a containing block and so on. It's just not equivalent to none the same way as transform: translate(0) is not equivalent to transform: none.

moz-wptsync-bot pushed a commit to web-platform-tests/wpt that referenced this issue Jan 24, 2020
Per SVG2 spec, the EBNF allows the path data string to be empty.
An empty path data string disables rendering of the path.
Therefore, we should make path('') a valid path string.

The related spec issue: w3c/fxtf-drafts#392.
Now we serialize `path("")` as `path("")` for offset-path and clip-path.

Differential Revision: https://phabricator.services.mozilla.com/D60771

bugzilla-url: https://bugzilla.mozilla.org/show_bug.cgi?id=1609786
gecko-commit: 1ef31cd775e69a42d7c9b67b5ac86f65ef808b25
gecko-integration-branch: autoland
gecko-reviewers: emilio
xeonchen pushed a commit to xeonchen/gecko that referenced this issue Jan 25, 2020
Per SVG2 spec, the EBNF allows the path data string to be empty.
An empty path data string disables rendering of the path.
Therefore, we should make path('') a valid path string.

The related spec issue: w3c/fxtf-drafts#392.
Now we serialize `path("")` as `path("")` for offset-path and clip-path.

Differential Revision: https://phabricator.services.mozilla.com/D60771
moz-v2v-gh pushed a commit to mozilla/gecko-dev that referenced this issue Jan 25, 2020
Per SVG2 spec, the EBNF allows the path data string to be empty.
An empty path data string disables rendering of the path.
Therefore, we should make path('') a valid path string.

The related spec issue: w3c/fxtf-drafts#392.
Now we serialize `path("")` as `path("")` for offset-path and clip-path.

Differential Revision: https://phabricator.services.mozilla.com/D60771

--HG--
extra : moz-landing-system : lando
moz-wptsync-bot pushed a commit to web-platform-tests/wpt that referenced this issue Jan 25, 2020
Per SVG2 spec, the EBNF allows the path data string to be empty.
An empty path data string disables rendering of the path.
Therefore, we should make path('') a valid path string.

The related spec issue: w3c/fxtf-drafts#392.
Now we serialize `path("")` as `path("")` for offset-path and clip-path.

Differential Revision: https://phabricator.services.mozilla.com/D60771

bugzilla-url: https://bugzilla.mozilla.org/show_bug.cgi?id=1609786
gecko-commit: 1ef31cd775e69a42d7c9b67b5ac86f65ef808b25
gecko-integration-branch: autoland
gecko-reviewers: emilio
gecko-dev-updater pushed a commit to marco-c/gecko-dev-comments-removed that referenced this issue Jan 28, 2020
Per SVG2 spec, the EBNF allows the path data string to be empty.
An empty path data string disables rendering of the path.
Therefore, we should make path('') a valid path string.

The related spec issue: w3c/fxtf-drafts#392.
Now we serialize `path("")` as `path("")` for offset-path and clip-path.

Differential Revision: https://phabricator.services.mozilla.com/D60771

UltraBlame original commit: 1ef31cd775e69a42d7c9b67b5ac86f65ef808b25
gecko-dev-updater pushed a commit to marco-c/gecko-dev-wordified that referenced this issue Jan 28, 2020
Per SVG2 spec, the EBNF allows the path data string to be empty.
An empty path data string disables rendering of the path.
Therefore, we should make path('') a valid path string.

The related spec issue: w3c/fxtf-drafts#392.
Now we serialize `path("")` as `path("")` for offset-path and clip-path.

Differential Revision: https://phabricator.services.mozilla.com/D60771

UltraBlame original commit: 1ef31cd775e69a42d7c9b67b5ac86f65ef808b25
emilio pushed a commit to emilio/servo that referenced this issue Feb 10, 2020
Per SVG2 spec, the EBNF allows the path data string to be empty.
An empty path data string disables rendering of the path.
Therefore, we should make path('') a valid path string.

The related spec issue: w3c/fxtf-drafts#392.
Now we serialize `path("")` as `path("")` for offset-path and clip-path.

Differential Revision: https://phabricator.services.mozilla.com/D60771
emilio pushed a commit to emilio/servo that referenced this issue Feb 11, 2020
Per SVG2 spec, the EBNF allows the path data string to be empty.
An empty path data string disables rendering of the path.
Therefore, we should make path('') a valid path string.

The related spec issue: w3c/fxtf-drafts#392.
Now we serialize `path("")` as `path("")` for offset-path and clip-path.

Differential Revision: https://phabricator.services.mozilla.com/D60771
emilio pushed a commit to emilio/servo that referenced this issue Feb 12, 2020
Per SVG2 spec, the EBNF allows the path data string to be empty.
An empty path data string disables rendering of the path.
Therefore, we should make path('') a valid path string.

The related spec issue: w3c/fxtf-drafts#392.
Now we serialize `path("")` as `path("")` for offset-path and clip-path.

Differential Revision: https://phabricator.services.mozilla.com/D60771
imiklos pushed a commit to szeged/servo that referenced this issue Feb 12, 2020
Per SVG2 spec, the EBNF allows the path data string to be empty.
An empty path data string disables rendering of the path.
Therefore, we should make path('') a valid path string.

The related spec issue: w3c/fxtf-drafts#392.
Now we serialize `path("")` as `path("")` for offset-path and clip-path.

Differential Revision: https://phabricator.services.mozilla.com/D60771
@css-meeting-bot
Copy link
Member

The CSS Working Group just discussed [motion-1] The computed value of offset-path: path(' '), and agreed to the following:

  • RESOLVED: Invalid path strings make the syntax invalid at parse time
  • RESOLVED: Empty path is considered invalid
The full IRC log of that discussion <dael> Topic: [motion-1] The computed value of offset-path: path(' ')
<dael> github: https://github.com//issues/392
<dael> fantasai: I don't know much on this, but it seemed we should resolve and fix.
<dael> heycam: The ultimate issue is we have path function which takes string value. string is svg data string.
<dael> heycam: Some strings are invalid. What does that mean for validity of path function. If you use invalid path string inside is it all parse as invalid and dropped or is string preserved and invalidity handled later
<dael> TabAtkins: If it's valid how to serialize and if not valid clarify that
<dael> florian: Precedint in other properties
<dael> fantasai: IN grid we throw out what's invalid after parsing
<fantasai> s/Precedint/Precedent/
<dael> florian: Same here?
<dael> heycam: NO reason not to
<dael> florian: No architectural complexity so seems like right thing to do
<dael> TabAtkins: Larger question then what's asked in issue. If you have invalid pass it's a separate question. The empty string specifically is a valid path per svg grammer but it disabled rendering of paths. Question is how is it cannonicalized and serialized. In chomre it's serialized as none. All other paths stay as paths but none doesn't so doesn't create containing block
<dael> heycam: Surprises me. I think it then does not make sense to serialize as none
<dael> TabAtkins: If we decide to treat as invalid that's okay with me and this solves iteself. If we want that we should record it. It's about if empty path is valid or not.
<dael> florian: Is it useful?
<dael> TabAtkins: No
<dael> florian: THen make it invalid ad see if world breaks
<dael> TabAtkins: Invalid is probably more consistent with chrome behavior
<dael> fantasai: 2 resolutions?
<dael> heycam: IN issues it's also mentioned strings with only whitespace. Same?
<dael> florian: Suppose so
<dael> TabAtkins: Yeah. Regardless of specifics of svg grammar shouldn't treat different
<dael> Rossen_: can someone summerize?
<dael> TabAtkins: 1) Invalid path strings make the syntax invalid at parse time
<dael> Rossen_: Objections?
<dael> RESOLVED: Invalid path strings make the syntax invalid at parse time
<dael> TabAtkins: 2) The empty string is an invalid path string
<dael> florian: With whoever does the edits being careful for all empty types
<dael> fantasai: Basically 0 length path
<dael> fantasai: 0 length path description
<dael> TabAtkins: If we say it's empty we can deal with specifics lather
<dael> florian: Empty path not empty strong
<fantasai> s/strong/string
<dael> Rossen_: Empty path is considered invalid
<dael> Rossen_: Objections?
<heycam> "a string with no path commands in it", maybe
<dael> RESOLVED: Empty path is considered invalid
<astearns> s/lather/later/
<dael> Rossen_: Anything else?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

6 participants