User:Patches/PackagingDrafts/Web Assets

Scope

Web Assets are any static content that are shipped intact to web browsers, usually by web applications. This might be a user interface framework, a Flash video player, a CSS framework, an icon library, or lots of other possibilities.

If your package is primarily or solely shipped to a browser and not used locally, and is not JavaScript, it probably falls under these guidelines. JavaScript packages must follow the JavaScript guidelines instead of or in addition to these guidelines.

Web applications typically involve code that is executed locally, and thus do not fall under these guidelines.

Rationale

There are lots of little bits shipped to browsers that aren't just JavaScript that typically have been bundled along with web applications up to this point. There are a lot of good reasons why we shouldn't bundle JavaScript this way, so it only follows that we should fix it for the rest of that kind of stuff too.

BuildRequires

To ensure the presence of the necessary RPM macros, all packages that provide web assets must have:

BuildRequires:  web-assets-devel

Requires

To ensure the availability of the necessary directories, all packages that provide web assets must have:

Requires:  web-assets-filesystem

RPM Macros

Macro	Normal Definition	Notes
_assetdir	%{_datadir}/assets	The directory where all web assets are stored

Install Location

All web asset packages must install into a subdirectory of %{_assetdir}. For instance, the jquery-ui package should install itself into %{_assetdir}/jquery-ui.

Server Location

All HTTP daemons in the distribution should make %{_assetdir} available in /assets.

Therefore, if the fabulous-web-icons package ships an icon as %{_assetdir}/fabulous-web-icons/important.png, you can include it in a web application with the following HTML:

<img src="/assets/fabulous-web-icons/important.png">

Content Guidelines

Web Assets should follow the general guidelines for content, unless stated otherwise in this document.

CSS

Pure CSS frameworks can be included as-is. CSS frameworks that use an alternative language that compiles to CSS, such as LESS, must compile to CSS as part of the build process. It is not acceptable to include pre-compiled CSS in Fedora packages.

Flash

Flash files (which typically use the .swf extension) must follow the general and licensing guidelines for code, not content. Non-free Flash files are unacceptable in Fedora.

However, it may not be possible to build such files with a free software toolchain at this time. Therefore, it is permissible for precompiled Flash files to be included in Fedora packages. However, the source code must still be included as part of the SRPM.

Not sure if this is a good idea
I'm not entirely sure this is a great idea, but on the other hand it would suck if some awesome web video player that mostly did HTML5 but had a freely-licensed Flash fallback were blocked from Fedora because there isn't a free Flash toolchain.

If the Flash software supports being compiled by a free software toolchain, such as swfc, it must be compiled as part of the build process for that package.

Java applets

Java applets should follow the general and licensing guidelines for code, not content. Additionally, they should follow the Java guidelines, with the exception that the actual .jar file for the Java applet should be installed into a subdirectory of %{_assetdir}.

Images

Images that are part of a larger Web Asset package can be included in that package's subdirectory. For instance, a UI library might contain images for its UI components in its subdirectory.

Web Asset packages that consist solely of images, such as a set of icons, may be shipped as their own package.

Fonts

All system fonts (available in %{_datadir}/fonts are automatically made available in /assets/fonts/ via a symlink. For more information on packaging system fonts, see the font guidelines.

Additionally, fonts in formats that are supported by W3C standards, but not supported by Fedora applications (like WOFF) may be shipped in %{_assetdir}. This may be necessary for compatibility with older web browsers. Such packages must follow the font guidelines, with the following exceptions:

• The fonts must be shipped in a subdirectory of %{_assetdir}, not %{_datadir}/fonts.
• The package (which may be a subpackage of a SRPM that ships standard system fonts) must use -webfonts as the suffix instead of -fonts.
• System -fonts packages must not depend on -webfonts package as described here.

If at all possible, fonts available under web font formats should also be available in the Fedora Package Collection as system fonts as well.