by Lee Moody.
Tagged with Newsletter.
TL;DR: This issue features Engine Room, Origami v2, and on-site messaging bugs.
Some of the bigger Origami news from the last month:
The talk covers a little history including why Origami exists, how Origami has adapted to new needs over the last 7 years, and gives a little peek at what’s to come. There are plenty of new opportunities for us to share and build on each others good work. The talk touches on a few technical subjects but is suitable for anyone within product and technology. If you missed it a recording is available here.
More Engine Room recordings are available in Google drive. There are many excellent talks to explore for those who couldn’t make it.
Work continues on our proposal to drop Bower support in favour of NPM. By switching we will align with the broader tech ecosystem and help speed up development at the FT.
This month we’ve tested out the proposed approach and… it works 🎉 We have also created a draft Origami v2 specification with the changes required to drop Bower support.
This proposal affects all projects which depend on Origami components. If you have any questions, thoughts, or feedback we’d love to hear in the #origami-chat Slack channel or as a comment on the proposal.
We know this is one many of our engineers are excited about. Thanks to everyone who has given us feedback so far, it’s much appreciated. 👏
Working with the design team we released a minor update to o-message this month, which fixes some visual bugs including improvements to spacing around message content. We’re careful not to release breaking changes within minor releases but unfortunately messaging on some projects broke as they were heavily customising
o-message in an unsupported way, with CSS overrides.
In response we offered to help update how projects use o-message to fix the problem. In addition, Xuan and the #design-ops team are auditing our on-site messaging currently so we can update
o-message and other Origami components to meet our current needs consistently, without the use of overrides.
Overriding component styles with CSS can be problematic for a few reasons. It introduces design inconsistency, code complexity, and fragility (overrides are liable to break without warning when components are updated, as happened in this case). Instead it’s better to:
The Origami team are here to help you decide which option is right for your project and make component updates if needed. We’re also happy to help you review a projects use of components, to remove duplication and overrides — let us know how we can help in #origami-support 😊
This month we’ve made more direct contributions to Customer Products projects than usual. Our special thanks goes to those who helped review and release our work quickly so we could move on to other tasks. That includes Nick Colley and Simon Plenderleith, thanks both! 🙏
A digest of other things that have happened this month:
o-brandas a dependency; Sass lint rules may be customised with a Style Lint configuration
.stylelintrc.js; we’ve also been working on the v2 draft specification as discussed previously.
listingelement for use with the landing layout, this is useful to list posts on a blog for example.
feedbackstate for the
lpd-au); adds a
romainmenke); rewrites the
Symbol.prototype.descriptionpolyfill to make it work with different
mhassan1); improves the error message for feature detection tests (thanks
getDataAttributesto only return namespaced data attributes.
dialoguerole; deprecates the
standardtheme option (these styles are output by default).
o-galleryto “dead”, due to its age and low (or no) use. Please let us know if your project relies on
o-gallerystill. Note there is a proposal for a similar carousel component.
:focus-visiblefocus styles (previously broken in Chrome/Edge 68).