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

[svg-native] support xlink:href on gradients #670

Open
dirkschulze opened this issue Apr 16, 2019 · 8 comments
Open

[svg-native] support xlink:href on gradients #670

dirkschulze opened this issue Apr 16, 2019 · 8 comments

Comments

@dirkschulze
Copy link
Contributor

The xlink:href attribute on <linearGradient> or <radialGradient> is ignored right now. We should consider keeping it.

Without support for objectBoundingBox, referencing other gradients is straight forward.

The xlink:href is mainly used to share color stops between multiple gradients. W/o objectBoundingBox this is even more important. Otherwise SVG files blow up a lot.

@svgeesus
Copy link
Contributor

Although we would probably want bare href, not xlink:href.

@jarek-foksa
Copy link

jarek-foksa commented Apr 18, 2019

The xlink:href is mainly used to share color stops between multiple gradients. W/o objectBoundingBox this is even more important. Otherwise SVG files blow up a lot.

This shouldn't be a problem if you compress the file. In my opinion gradient inheritance is a feature that makes sense in a rich document format (such as SVG), not in an output format (such as SVG Native).

@litherum
Copy link
Contributor

Otherwise SVG files blow up a lot.

Is this the main motivation? If so, we should compare file sizes of compressed-without-stop-sharing files against compressed-with-stop-sharing files.

@dirkschulze
Copy link
Contributor Author

@litherum fair enough. That assumes that compression will happen though. You are probably just thinking about sending SVGs over the wire or as embedded vector for OT fonts. Can we make this assumption on native apps? Usually, applications don't compress SVG files upon shipping. Decompression takes time and native applications come with a lot of icons. Adobe's application may have more than thousand icons for one application. Decompression does add up on so many icons.

@jarek-foksa
Copy link

@dirkschulze Aren't all Adobe products using flat icons for the UI? I think this is also the case for the majority of iOS, Android, macOS and Windows 10 apps that follow the Human Interface Guidelines.

@dirkschulze
Copy link
Contributor Author

@jarek-foksa I am not sure what you are referring to with flat icons in UI? Do you ask if we support gradients in icons used within Adobe products? We aim to support SVG Native features in our UI.

@jarek-foksa
Copy link

jarek-foksa commented Apr 19, 2019

@dirkschulze I meant that most modern apps are adopting flat design patterns which are discouraging heavy use of gradients. Therefore, the potential benefits of supporting gradient inheritance would be negligible even for an application that defines over a thousand of icons such as Photoshop.

@dirkschulze
Copy link
Contributor Author

@jarek-foksa Design patterns come and go :)

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

4 participants