I've set the $topbar-height variable to a specific value, that is higher than the default value.
For the mobile version I'd like to keep the default value.
How can I do that?
I can't just change the height value of .topbar, as this variable is used by Foundation across many other attribues of the topbar and its children elements (line-height, padding, margin, etc).
I've found out that doing something like that works:
#media #{$small} {
$topbar-height: 85px;
#import "foundation/components/top-bar";
...
}
Maybe is not the cleanest approach (I must check if this produce redundant CSS) but I prefer this what, even though I consider #James answer good as well (probably it's even a cleaner way for what concerns the produced CSS).
I think that an actual top-bar mixin would solve this issue: I'll add it as a suggestion.
This is not possible with Foundation out of the box. I have done two things in the past to get custom functionality such as this:
1) override the CSS classes in app.scss by appending !important to force the changes to take effect.
or
2) copied the mixins and html class generation Sass from the zurb-foundation gem (for example foundation/components/top-bar.scss)
to either app.scss or a new file, then modify app.scss so you no longer use the blanket import by commenting it out
// #import "foundation";
and importing everything else (for development, but only the parts I need for production) with the exception with the file you want to override, in this case
// #import "foundation/components/top-bar";
Once you do that, you can modify the html generation or the mixins or add media queries for whatever you want to do.
Keep in mind if you make a modification like this it could break with future versions of Zurb Foundation.
Related
GTK3 applications can be styled and themed with CSS. How can I force GTK to use solely the CSS shipped with my application, instead of combining / cascading it with the theme installed on the user's system?
Why would one want to do that? In theory, CSS would be a great rules-based styling system, where you just add one screen full judiciously chosen rules to define the looks of your application consistently. Unfortunately, in practice, people tend to add hundreds of brain-dead, repetitious definitions into their stylesheets, thereby counterfeiting the very nature of cascading.
The actual problem is that my application shall get the typical, subdued dark-grey look of a media handling application, irrespective of the global theme installed on the user's system. From reading the GTK documentation and the GTKmm tutorial, I came up with the following code to read my own CSS stylesheet:
auto screen = Gdk::Screen::get_default();
auto css_provider = Gtk::CssProvider::create();
try {
css_provider->load_from_path(lib::resolveModulePath (stylesheetName, resourceSerachPath));
} catch(Glib::Error const& failure) {
WARN(gui, "Failure while loading stylesheet '%s': %s", cStr(stylesheetName), cStr(failure.what()));
}
Gtk::StyleContext::add_provider_for_screen(screen, css_provider, GTK_STYLE_PROVIDER_PRIORITY_APPLICATION);
Technically this works perfect. However -- now I am forced to work "against" the CSS rules present on the user's system. If I start with setting a suitable border colour in the default rule and a dark grey background and suitable text colour in a rule for GtkWindow, plus some rule for text entry fields, I get the desired look on some parts, but whenever the user's system theme adds a specific definition for some specific widget or widget combination, thereby repeating explicitly the colours instead of inheriting them from a generic rule, I need to add yet another specific rule into my application style sheet to fix that specific case. That is, the possibly ill-guided structure of the installed system theme forces my application stylesheet into the same ill-guided bad practice and have hundreds of single-case definitions repeating the same values over and over.
Questions
How can I tell GTK to use only my stylesheet for my application?
Is there any viable alternative, which is not so radical, yet still allows me to use CSS the way it was intended to be used (minimal set of rules + cascading)?
You can use the reset.css file from the GTK demos to unset all existing rules.
A less radical alternative might be to just ignore user themes other than the default. Presumably if a user has a theme built with bad CSS practices, they nonetheless like that theme. So why shouldn't they be able to view your application with their preferred theme?
as pointed out by #ptomato, you can install a CSS to effectively override any pre-existing other rules on the system. However, this also shows a way towards a less radical solution: just cancel out the problematic parts of the pre-installed theme.
How does it work?
We add catch-all rules to the CSS, i.e. rules which somehow select any possible element, or at least a complete subtree. This is achieved by using a wildcard * in the selector. And since we install our stylesheet with a higher priority (typically GTK_STYLE_PROVIDER_PRIORITY_APPLICATION), these rules will "stamp over" every specific rule which happens to be present with lower priority.
we can use the value unset to clear out a setting
we can use the value inherit to force the property to be derived from the parent widget's setting of this property.
Especially for the given problem to get "grey-subdued media application" look within a environment with a "light" theme, we can use
* {
color: inherit;
background-color: inherit;
}
...to cancel out only the problematic part of the pre-existing "light" theme, which is the background and colour setting. We can then set our own values once at a central point, and they will be inherited as expected.
We can even expand on that idea and treat further problematic settings within a given scope, by using the wildcard below a CSS contextual selector. And a key trick to get that right is to use the GTK+ inspector on your running application and investigate the actual settings to find the lowest possible point still to "grab" the problematic setting. (To activate the GTK+ inspector run your application with GTK_DEBUG=interactive path/to/my/app )
In the Aurelia SPA template it assumes that every page will be inside app.html and use the same nav-bar at the top. But I'll have many pages that don't want the nav-bar at the top and actually not use app.html at all. I was looking at main.js and it looks like I could hook into bootstrap() and change the aurelia.setRoot() for certain pages (I'm just guessing here), but then I start mucking up the main.js file and it won't be long before it gets really messy and maintenance headache. I really just want to have some pages use their own format altogether and ignore the app.html formatting without doing any crazy configurations.
My initial thought is maybe app.html should just be an empty file and make every page decide whether or not it wants the nav-bar and include it on the individual pages. But now I'm duplicating the code across many pages and if the standard page layout changes I have to change all the individual pages. Not sure the best way to go about his. Any suggestions?
I actually disagree with Gilbert's answer. Using .setRoot is a best practice; the root is just the parent view/viewModel pair and you will often have different parents. This is essentially what you're doing when you're creating an empty app view/viewModel, creating a new parent that doesn't do anything. But adding an unnecessary, unused layer is just extra complication.
One of the best use cases for this is a login page. The login page is totally different from your normal app page--there's a login prompt, no navigation bar, etc. Therefore, make a "login" app root and a "app" app root and switch back and forth between them. I've built a template called Sentry that demonstrates how to do this.
Sentry in action
Sentry on GitHub
Using set root, like you said, is a bad idea. Similar to what you said, you can make app.html contain just the router view tag. Different parts of your app, that you want to share a similar page layout, will be gruped under different routes. Now each of theses routes will point to another router that will have its different styles in the view
Just think of it as an empty app.html with child app.html's that have styles in them(e.g. Different navbars, page layout etc)
How can I personalize a list within ServiceNow?
I mean, I have this list:
But I think its very confusing to see the position on the right side.. How can I center it?
Like CSS customization or JS or something like that.. where can I find the customization form?
You can customise the position of the field content by using Field Styles.
If you mean customising the position of the field header, I have had a play around with doing this and I seem to have got it working.
If you inspect the HTML of the column header you want to target (the th tag), you'll see that there's an attribute on it called glide_type which contains in it the type of column. You can use this to create a CSS rule to target only headers of a particular type.
For example, I have a field of type decimal, and the th tag has the following attribute:glide_type="decimal". So to target that element, I could create a CSS rule like the below:
th.text-align-left.list_header_cell[glide_type="decimal"] {
text-align: right;
}
The hacky part is including that CSS so that it applies throughout the SN interface. You can use a UI Script to run some JavaScript which includes the Style Sheet. So if you put the above CSS inside a new Style Sheet (navigate to Content Management > Design > Style Sheets), and copy that new Style Sheet's Sys ID, you can create a UI Script with the below in it to include that Style Sheet on all pages:
link = document.createElement("link");
link.href = "STYLE_SHEET_SYS_ID_GOES_HERE.cssdbx?";
link.type = "text/css";
link.rel = "stylesheet";
link.media = "screen,print";
document.getElementsByTagName("head")[0].appendChild(link);
After doing that, you'll see that the Style Sheet is getting loaded on all pages, and if you've written your CSS right then you should find that the column header is now right-aligned!
As #Kirk said, performing this kind of customisation will mean that it's hard for ServiceNow Customer Support to assist if there's something you've customised getting in the way of their troubleshooting. Take this into account if you decide to implement something like this, and also thoroughly test this on a non-production instance.
In addition to the above, this solution may break in future releases as ServiceNow may decide to change the way that lists work and thus the CSS selector may no longer target the right/any element.
Hope this helps!
Dylan
It's not suggested to customize any sort of CSS or JS with that, we were told that is voids your support for that section if you do so.
You could just add a few more display fields if you really desire to remove the extra white-space.
For a complete description of that (which you may know how to do):
Click the Gear icon
Then select some relevant fields from the Available section, and click the Right arrow to add them.
i'm new in cakephp and I have started with version 3. I want to build a beautifull app and because I'm not good in design, I would really like to use a free template or buy one that I can use within cakephp.
So, I would really appreciate all your propositions and ideas or best practises. The easy way will be the best because I don't have a lot of time with this project. Thank you in advance.
If you don't have a lot of time like you mentioned, the easiest way to go ahead and get started is to paste a lot of the code in your default.ctp layout inside of src/Template/Layout/default.ctp.
You'll notice there are some lines of PHP already in there that are relevant to fetching blocks of css, meta tags, and other bits of code that could potentially exist throughout your project.
Find the main layout of the theme your trying to use - the one that will be consistent across most of the pages. That's the one you'll use for default.ctp. Compare what's already in default.ctp and make the comparable adjustments around the HTML in that document while keeping the important lines of PHP there as well.
For other important pages like a login or registration page, just create a new document for those, like 'login.ctp', then inside the function that loads the page (maybe 'login' inside of UsersController'), change the default layout with this line of code:
$this->viewBuilder()->layout('login'); // without the .ctp ending
This way you can create one-off layouts that don't really match any other page.
I'm building a site using Django and Grappelli. One of the requirements is to have a consistent theme across the entire site, both front end and admin interfaces.
At the least, the two things I would like to do are replace sections of the top bar to include the sites name (and logo) and customise the CSS for required fields to make them more obvious.
For example here: I'd like to replace "Grappelli" with "MySitename"
And below you can see the faint bolding indicates a required field, and I'd like to add some styling to make this stand out more:
Unfortunately, I can't scrap grappelli as I'm using some of its advanced functionality like foreign key autocompletes and sortables, so that's not an option.
Sadly the documentation doesn't really go into this detail regarding customisation and I'd rather not have to fork and override sections of Grappelli just for some small visual changes.
Is there any way to easily achieve this?
to update the name just add GRAPPELLI_ADMIN_TITLE = "MySitename" in your settings file
https://django-grappelli.readthedocs.org/en/latest/customization.html