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

Add support for scoped versioning #877

Merged
merged 28 commits into from Jan 4, 2017
Merged

Conversation

Jahnp
Copy link
Collaborator

@Jahnp Jahnp commented Dec 17, 2016

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 is 5.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:

  1. Risking regressions from other web parts that might be using an older version of Fabric, and
  2. Forcing them to consume the latest (which would likely require work to update),

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:

<html>
    <head>
        <!-- Link to the scoped styles for the current version of Fabric Core -->
        <link rel="stylesheet" href="/fabric-5.0.1.scoped.css">
    </head>
    <body>
        <!-- Add the scoping class -->
        <div class="ms-Fabric--v5-0-1">
            <!-- 
                Use Fabric as usual. These styles will be unaffected
                by other versions of Fabric. They also cannot be used
                outside of a scoped class.
            -->
            <h1 class="ms-font-su">Some scoped title <i class="ms-Icon ms-Icon--Info"></i></h1>
        </div>
    </body>
</html>

Notes on fonts

Icon @font-face definitions (including the font-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 be fabricmdl2icons-5.1.0.ttf, fabricmdl2icons-5.2.0.ttf, etc. There will simply be fabricmdl2icons-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.

…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
…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.
@import './Font';
@import './Grid';
@import './IconFont';
Copy link
Contributor

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.

Copy link
Collaborator Author

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.

Copy link
Collaborator Author

@Jahnp Jahnp Dec 17, 2016

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.

@mikewheaton
Copy link
Contributor

mikewheaton commented Dec 19, 2016

Looks really good! A couple small to-dos:

  • Animations (the @keyframes, not the classes) are not scoped. Do we want to scope them by appending the version number (e.g. @keyframes slideRightIn10--v5-1-0)?
  • We need to get the scoped icon fonts (e.g. fabricmdl2icons-5.woff2) on the CDN before this is released. I've added the waiting-to-merge label. Want me to get those onto the CDN and update our icons release process?

@Jahnp
Copy link
Collaborator Author

Jahnp commented Dec 19, 2016

@mikewheaton Thanks for the feedback! Great points.

  • RE: Scoping keyframs: That's a really good point, I hadn't considered that. Since they wouldn't affect classes, the "interface" for developers wouldn't be affected either. I'll go ahead and make this change.
  • RE: Scoped icons on the CDN--definitely. I'll try to get to this today. I'd generally prefer waiting on CDN inclusion before merging, but since this is a new/currently-unused feature, I'm a little less concerned about that.

@Jahnp
Copy link
Collaborator Author

Jahnp commented Dec 20, 2016

@mikewheaton @micahgodbolt: Alright, I've added version scoping to @keyframes definitions and their uses within the mixins. However, I didn't change the mixin names--that seems unnecessary at this stage (and is actually impossible as of right now without re-defining versions).

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!

@mikewheaton
Copy link
Contributor

mikewheaton commented Dec 21, 2016

Approved! 🎉 🎉 🎉

Approved with PullApprove

@mikewheaton
Copy link
Contributor

Removed the 'waiting-to-merge' label, as the scoped icons for v5 are now available on the CDN.

@mikewheaton mikewheaton added this to the 6.0.0 milestone Jan 4, 2017
@mikewheaton mikewheaton merged commit f17c069 into master Jan 4, 2017
@mikewheaton mikewheaton deleted the jahnp/scoped-versioning branch January 4, 2017 20:04
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

Successfully merging this pull request may close these issues.

None yet

4 participants