Hi David, we've used @extend with SASS in our projects and ended up not using it a lot due to its drawbacks, instead we use Bootstraps mixins more directly.
I haven't read the article in its entirety, but here are my thoughts: For decoupling the components it might be possible to wrap the needed CSS in placeholder selectors and aggregate them it in custom shared classes and load only what needed. But if the components don't use the Bootstrap classes directly we would need to change 2 classes if we like to change behavior (e.g. .form-control and .t5-form-control). And this doesn't deal with changed HTML-structure of Bootstrap components between version. We needed to adapt our TML multiple times between Bootstrap 4.0.0 beta and 4.1.2 and 4.2.1 (especially custom controls stuff). Separated JARs or component swaps might be the better or at least more maintainable option IMO. Nevertheless the direct integration of SASS-support would be great. As written before we added it ourselves with the help of https://github.com/bit3/jsass so we can build Bootsrap from its SASS-source instead of using the CSS-only version, and we can add some SASS beforehand to set the https://github.com/twbs/bootstrap/blob/master/scss/_variables.scss before compiling Bootstrap to customize it (thanks to !default). Works without any major issues in our projects. Ben On Thu, Feb 21, 2019 at 4:24 AM David Taylor <david.tay...@extensiatech.com> wrote: > Anyone have experience working with the @extend directive in CSS > preprocessors? > > I came across a post that advocates decoupling HTML markup from > bootstrap classes by using @extend. I don't particularly agree with many > of the points the author makes, but the technique is intriguing and > might be something that can applied to Tapestry since we support Less. > Here is the link to the article. > > > https://hackernoon.com/the-backendification-of-frontend-development-62f218a773d4 > > The interesting bit is titled "Dealing with CSS Frameworks" and contains > the following example: > > %our-warning-button { > @extend .btn; > @extend .btn-warning; > } > .empty-shopping-cart-button { > @extend %our-warning-button; > } > > Searching the web a bit I came across another article that gets into > this in more detail. The article's title is a bit misleading since it > actually advocates the @extend technique and offer somes advice on best > practices. > > https://webinista.com/updates/dont-use-extend-sass/ > > David > > emailsig On 2/19/2019 6:03 AM, Chris Poulsen wrote: > > Hi > > > > I think working on making the framework "core" more css agnostic seems > like > > a good direction, allowing things to move forward without having to try > and > > pick (and maintain) the correct bootstrap version (or other css framework > > version/flavor). There is a pretty good chance that whatever is selected, > > will not fit the requirements of everybody anyway. > > > > It is a while back, but was the tapestry bootstrap integration not > > initially handled "externally" by a markup renderer filter (I guess it > > removed the tapestry default styling and added the bootstrap equivalent). > > Maybe something similar could be used to apply styling (Tapestry-BS3, > > Tapestry- BS4 or whatever) to the tapestry components, without having to > > dream up new stuff. (Provided that the processing does not become a > > significant performance bottle-neck). > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org > For additional commands, e-mail: users-h...@tapestry.apache.org > >
