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

Use definition of CSS <paint> from SVG 2 instead of CSS Fill Stroke #625

Open
cdoublev opened this issue Jun 15, 2022 · 2 comments
Open

Comments

@cdoublev
Copy link

cdoublev commented Jun 15, 2022

Thanks to this patch, the value definition of the fill property is picked from SVG 2 instead of CSS Fill Stroke. The reasons for this are explained in #127 (comment).

This value definition is <paint>. In SVG 2, <paint> is defined with none | <color> | .... But the definition from CSS Fill Stroke is selected during the curation and is none | <image> | <svg-paint>: none of these types allows to successfully parse black (matching <color>), which is the initial fill value defined in SVG 2.

EDIT: note that the definition of <paint> from SVG 2 is annotated in prose... (sorry).

@tidoust
Copy link
Member

tidoust commented Jun 16, 2022

I think we're going to need to somehow rename one of the <paint> definitions, e.g. the one in SVG 2 to something like <svg-fillstroke-paint> or the one CSS Fill Stroke to <fill-stroke-paint>.

That is needed because we both have properties that need to reference the SVG version (fill and stroke, at least for now) and properties that need to reference the definition in Fill Stroke (fill-image and stroke-image).

If we update the definition in SVG 2, we will also need to update the <paint> reference in SVG Strokes.

@cdoublev
Copy link
Author

I had not seen its use in other property definitions from CSS Fill Stroke.

I wonder if you would not better off revert picking fill and stoke from SVG. I will stick to SVG definitions, which are supported in all browsers, and ignore those of CSS Fill Stroke, whose differences with SVG are not supported in any browser, but browser support is a subjective goal and I understand yours (future-proof, maintanability, etc.). If I were using @webref/css for a CSS documation application (eg. CSSTree syntax reference), renaming <paint> to an unspecified name would be a problem.

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

No branches or pull requests

2 participants