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
Add support for scoped versioning #877
Conversation
…version info at build time. Modify core Fabric build to accommodate scoped Fabric
… gulp-changed from task since it was causing changes to not be reflected
…files. Include in scoped output
… the form ms-Fabric--v4-1-0
…c-core into jahnp/scoped-versioning # Conflicts: # src/sass/Fabric.Icons.Font.Output.scss
- Add scoping rules back to _Icon.Mixins.scss - Split out @font-face definiton from _Icon.scss into _IconFont.scss and import where necessary.
…phy.scss and _Font.scss, respectively
… typography classes into _Font.scss
@import './Font'; | ||
@import './Grid'; | ||
@import './IconFont'; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe Icon.Definition
to match the font definitions file? The word 'definition' is already bothering me but Font.Font
would be far worse.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah yes, good catch--I'll change this. And I agree, I'd really love to stick with single-word filenames as much as possible, but not sure how else to split this out.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@mikewheaton super pedantic preference: would you prefer Definition
or Definitions
for the Icon file? There's technically only one definition :/ I'm inclined to use the latter for pure consistency and flexibility but don't feel strongly about it.
Looks really good! A couple small to-dos:
|
@mikewheaton Thanks for the feedback! Great points.
|
@mikewheaton @micahgodbolt: Alright, I've added version scoping to My solution generates output like this: // @keyframes definitions
@keyframes fadeIn--v5-1-0 {
from {
opacity: 0;
animation-timing-function: cubic-bezier(0.1, 0.25, 0.75, 0.9);
}
to {
opacity: 1;
}
}
@keyframes slideRightIn10--v5-1-0 {
from {
transform: translate3d(-10px, 0px, 0px);
}
to {
transform: translate3d(0px, 0px, 0px);
}
}
// Scoped animation classes
.ms-Fabric--v5-1-0 .ms-u-slideRightIn10 {
animation-name: fadeIn--v5-1-0, slideRightIn10--v5-1-0;
animation-duration: 0.367s;
animation-timing-function: cubic-bezier(0.1, 0.9, 0.2, 1);
animation-fill-mode: both;
} Let me know what you think of the approach. I'll get started on getting the versioned icons on the CDN next. Also--huge thanks to @micahgodbolt for the suggestions on how to resolve, well, my variable resolution issues! |
Removed the 'waiting-to-merge' label, as the scoped icons for v5 are now available on the CDN. |
Inline version number instead of file based
Version scoping
This pull request adds support for "version-scoping" Fabric Core, which effectively wraps or "scopes" every Fabric class under a modifier of the
.ms-Fabric
base class, which is tied to the current version. If the version is5.0.1
, this "scope class" would take the form.ms-Fabric--v5-0-1
.Why is this useful?
Version scoping is targeted at the scenario where multiple versions of Fabric Core may live on a single web page, whose differences between major versions could potentially introduce regressions or conflicts.
A practical example of this is the SharePoint Web Parts used for publishing articles. Web Parts are effectively miniature applications, each of which can depend on their own version of Fabric. To ensure that they can continue to exist on the same publishing page without:
the Web Part developer can scope the Fabric styles for their entire Web Part to the particular version that was used during development.
Usage
Usage of version scoping is straightforward. Simply append the "versioned class" to the container element you wish to scope, then use Fabric Core classes as you normally would.
Here's a minimal HTML page demonstrating this:
Notes on fonts
Icon
@font-face
definitions (including thefont-family
name) and their font files are only scoped to major versions of Fabric. What this means is that all of the normal, additive changes to icon font files that occur within a major version's lifetime will be applied to a single font file, rather than maintaining separate font files for each minor or patch release. What this means is that there will not befabricmdl2icons-5.1.0.ttf
,fabricmdl2icons-5.2.0.ttf
, etc. There will simply befabricmdl2icons-5.ttf
.This is because generally icon font changes are purely additive, and rarely change significantly even between minor versions. However, the CSS classes for those icons (e.g.
ms-Icon--X
) are version scoped like normal classes. Also, note that the "unscoped" version of the icon font file as used today will still be available.Finally, the standard, "unscoped"
@font-face
definitions to the Segoe UI webfonts are included in scoped Fabric unchanged. These fonts almost never change appreciably and are not considered risky to depend on between major releases.