I am wondering if there is any key differences between these two grid systems. I can't see any on the surface and dont know why I would want to choose one over the other. I built sites with both singularity and susy 1 in the last few months and they both worked great. They both appear to be actively developed and built by solid folks. Is there any specific advantages that one offers over the other? Are there any situations where on might be a better choice?
Susy 1 and Singularity 1.1.2 offered different types of responsive grids. Now, however, Susy 2.1.1 and Singularity 1.2.0 are quite similar in that respect. I believe that Susy incorporated some ideas from Singularity. I have re-built my website using Susy 2.1.1; previously I had used Singularity 1.1.2. I have tried Singularity 1.2.0 but at the moment there are some changes in coding that I cannot get to work. IMHO, they are both excellent but there is one huge difference. The documentation for Susy 2.1.1 is very good, whereas Singularity's documentation is still minimal and the Changelogs don't help a lot. There is also a video at 'sass bites #29' which though long-winded gives quite a lot of help with Susy 2. I have found (again) that the documentation isn't perfect. For example the methodology for setting a background or overlay grid can vary and I have found (from the video) a neater way of doing that. The new $maps and the new functions are really helpful in Susy 2 (e.g. #include break). There are a lot of changes in functions in Susy and Singularity and Susy's comprehensive documentation is essential.
Related
I stumbled on a web app project that was using ElementUI and spent most of the year updating dependencies. Ended up installing PostCSS and rebuilding the admin Panel how I wanted it to look and feel. It way recently decided to install Vuetify as the UI components are more modern looking and they use tailwind.
Whilst it has given some dated UI components a better feel. I still find myself reskinning and re theming. In some cases building my own transitions or adding new effects.
I hate using apps that have a repetitive UI.
My question is is there any point using Vuetify as at times I find myself battling with their "skin" and using a ton of CSS !important - which doesn't seem like good practice.
Sometimes I see UI or /UX design, and I think it looks cool, but I don't always want the whole thing. I'm the only one on the team that has been fond of tackling the CSS.
I'm a graphic designer who just started learning Laravel this week, recently I've been searching how to install the latest bootstrap version in my project correctly, which is all I need to be honest and I'm not too comfortable with other options like Tailwind.
As some tutorials and answers have suggested I ended up compiling and using a famous project named laravel/ui, sadly the resulting version comes with a few changes, that just doesn't look as good in my opinion (different fonts like Nonito, colors and margins)
So now I'm wondering...
Why is it not recommended to just add the CDN links in my master template?
Is it possible to update this compiled CSS somehow to make it look as the CDN?
Sorry if this questions might be opinion based, but I'm really out of places to ask, seems like the documentation for Laravel 8.x has removed everything related to Frontend, which are making thing even more confusing for me with all these options Laravel offers.
I have version 77 running my home page and want to make some updates. I can't seem to figure out how to upgrade from 77 to 100 (latest version). Is it possible to use both versions on the same page?
The code I'm using to pull in the latest version locally:
<script src="/static/js/three77.min.js"></script>
Thanks in advance for your thoughts!
Maybe in time someone will prove this wrong with a better answer, but no, there is no good way to run multiple versions of three.js on a single page.
Often, a good workaround around is keeping the old three.js implementation on a separate page and displaying that within an iframe. Iframes are not hip, but very functional that way :-).
The Susy documentation says:
The only requirement is Sass, but Susy was built to be part of the Compass ecosystem, and we recommend pairing with tools like Breakpoint and Vertical Rhythms.
Of course if you want to use the recommended Vertical Rhythms, which is part of Compass, you're dependent on Compass.
But other than using the functions/mixins Compass provides, are there any reasons why I would want to use Compass with Susy? Are there parts of Susy that only work, or work better, when Compass is available?
For example, in the file _breakpoint-plugin.scss you see that Susy actively checks if the Breakpoint Plugin is available, and changes its behavior accordingly. I want to know if there are similar optional dependencies on Compass built in.
PS, In reaction to the close vote:
I do not mean to ask for opinions. I want to know if there are features in the Susy codebase that do not work (or not as well) when Compass is not available. I will update the title to make that more clear. Please let me know if you see more ways to improve the question.
Check the custom support docs for all our integrations. Basically: we'll use Compass prefixing, clearfix, vertical rhythms, and rem fallback if you ask for them.
[...] are there any reasons why I would want to use Compass with Susy?
Yes, compass has some mixins and functions that aren't available in Susy. For example: sticky footer.
Are there parts of Susy that only work, or work better, when Compass is available?
As far as I'm concerned it doesn't. If you read it correctly you will see this:
The only requirement is Sass, but Susy was built to be part
of the Compass ecosystem, and we recommend pairing with
tools like Breakpoint and Vertical Rhythms.
This is for Susy 2, but for 1 however:
Compass is still required for the Susy One syntax.
I'm using both scrollTo and the "child"-plugin serialScroll quite frequently, and like them because they
Actually SCROLL things, rather than animating css-properties (margin/position etc)
Are flexible and can be used in many different situations, unlike lots of other scroller/sliders that adds a bunch of bells and whistles that you don't really need.
Thing is, the plugins haven't been updated since 2009, and although they still work just fine, regardless of jquery version, there are things that could need improving (like the ability to change settings after initilaisation), and overall it doesn't fell optimal to use a 3 year old plugin, solid and stable as it is.
Does anyone have a suggestion of other plugins that might do the same thing, perhaps better?
http://flesler.blogspot.se/2007/10/jqueryscrollto.html
This is an old question, but for the record, as Shauna said, the plugins aren't outdated, OP might have been looking at Google code hosting which is indeed out of date.
The plugin is now hosted on Github. There's no much of a need to update it too often given it's very stable already, but I do land some commits every now and then when needed.
I don't have a suggestion for anything better (even Google is coming up with Flesler's plugin or hand-written from base JavaScript or jQuery), but Flesler is still updating the plugin. You can find the latest version in GitHub.