-
Notifications
You must be signed in to change notification settings - Fork 9.4k
Closed
Labels
Area: FrontendEvent: imagine2019Issue: Clear DescriptionGate 2 Passed. Manual verification of the issue description passedGate 2 Passed. Manual verification of the issue description passedIssue: ConfirmedGate 3 Passed. Manual verification of the issue completed. Issue is confirmedGate 3 Passed. Manual verification of the issue completed. Issue is confirmedIssue: Format is not validGate 1 Failed. Automatic verification of issue format is failedGate 1 Failed. Automatic verification of issue format is failedIssue: Ready for WorkGate 4. Acknowledged. Issue is added to backlog and ready for developmentGate 4. Acknowledged. Issue is added to backlog and ready for developmentReproduced on 2.1.xThe issue has been reproduced on latest 2.1 releaseThe issue has been reproduced on latest 2.1 releaseReproduced on 2.2.xThe issue has been reproduced on latest 2.2 releaseThe issue has been reproduced on latest 2.2 releaseReproduced on 2.3.xThe issue has been reproduced on latest 2.3 releaseThe issue has been reproduced on latest 2.3 releasebug report
Description
The .lib-font-face()
mixin is not very flexible as it requires you have the font in all the formats listed (eot, woff2, woff, ttf, and svg). If your font is not available in all these formats then you will run into problems with 404 errors.
For example the font I'm using isn't available as a Woff or Woff2 file so I can't use the .lib-font-face()
mixin as it leaves me with several 404s:
Steps to reproduce
- Use a font that doesn't contain a Woff/Woff2 variant
- Check the console in your browser:
// Regular Noto Sans
.lib-font-face(
@family-name: @font-family-name__base,
@font-path: '@{baseDir}fonts/NotoSans-Regular',
@font-weight: 400,
@font-style: normal
);
// Italic Noto Sans
.lib-font-face(
@family-name: @font-family-name__base,
@font-path: '@{baseDir}fonts/NotoSans-Italic',
@font-weight: 400,
@font-style: italic
);
// Bold Noto Sans
.lib-font-face(
@family-name: @font-family-name__base,
@font-path: '@{baseDir}fonts/NotoSans-Bold',
@font-weight: 700,
@font-style: normal
);
Expected result
- I'd expect to have the option to specify the font formats I'd like to us, default should be all the fonts as it currently is but the option to exclude formats would be good.
Maybe (optionally) setting a variable to false could be the answer?
.lib-font-face(
@family-name: @font-family-name__base,
@font-path: '@{baseDir}fonts/NotoSans-Bold',
@font-weight: 700,
@font-style: normal,
@eot: false,
@woff: false,
@woff2: false
);
Actual result
- The mixin attempts to retrieve all the font formats which leaves 404 errors.
Workaround
To get around this I've had to manually declare my fonts without using the mixin.
// Regular Noto Sans
@font-face {
font-family: @font-family-name__base;
src: url('@{baseDir}fonts/NotoSans-Regular.ttf') format('truetype');
font-weight: 400;
font-style: normal;
}
// Italic Noto Sans
@font-face {
font-family: @font-family-name__base;
src: url('@{baseDir}fonts/NotoSans-Italic.ttf') format('truetype');
font-weight: 400;
font-style: italic;
}
// Bold Noto Sans
@font-face {
font-family: @font-family-name__base;
src: url('@{baseDir}fonts/NotoSans-Bold.ttf') format('truetype');
font-weight: 700;
font-style: normal;
}
And I no longer get the 404s
Metadata
Metadata
Assignees
Labels
Area: FrontendEvent: imagine2019Issue: Clear DescriptionGate 2 Passed. Manual verification of the issue description passedGate 2 Passed. Manual verification of the issue description passedIssue: ConfirmedGate 3 Passed. Manual verification of the issue completed. Issue is confirmedGate 3 Passed. Manual verification of the issue completed. Issue is confirmedIssue: Format is not validGate 1 Failed. Automatic verification of issue format is failedGate 1 Failed. Automatic verification of issue format is failedIssue: Ready for WorkGate 4. Acknowledged. Issue is added to backlog and ready for developmentGate 4. Acknowledged. Issue is added to backlog and ready for developmentReproduced on 2.1.xThe issue has been reproduced on latest 2.1 releaseThe issue has been reproduced on latest 2.1 releaseReproduced on 2.2.xThe issue has been reproduced on latest 2.2 releaseThe issue has been reproduced on latest 2.2 releaseReproduced on 2.3.xThe issue has been reproduced on latest 2.3 releaseThe issue has been reproduced on latest 2.3 releasebug report