Hello there,
We’re having a hard time to override a default icon style:
.format-standard .entry-content a:not(.x-btn):not(.x-img-thumbnail) {
border-bottom: 1px dotted;
}
When we put a button on a blog post, it will always have a 1px dotted bottom border.
Anyway to change that?
Thank you!
Hello @thisisbbc,
Thanks for writing in!
To change that, please add the following CSS code in the X > Theme Options > Global CSS (http://prntscr.com/evui3r)
.format-standard .entry-content a:not(.x-btn):not(.x-img-thumbnail) {
border-bottom: solid 2px black;
}
Please let us know if this works out for you.
Hello RueNel,
Thank you for the provided snippet.
Unfortunately that’s not exactly what I was expecting. I thought about doing that, but it also affects our social buttons and other anchor links. Not to mention, if we have different buttons styled differently, this might get tricky.
This rule override buttons and anchor links styling. After taking a deeper look, it doesn’t look like it’s an Icon-specific stylesheet rule, but rather something coming from the theme customizer, so I wouldn’t even be able to delete this from a core css file.
Hope this can be removed somehow.
Thank you!
Hey @thisisbbc,
This can be removed using JS script, try adding the following code in the Theme Options > JS:
jQuery(document).ready(function($){
if( $('.single-post div#cs-content.cs-content').length > 0 ) {
if($('article.post').hasClass('format-standard')) {
$('article.post').removeClass('format-standard');
}
}
});
Don’t forget to clear all caches including your browser’s cache after adding the code. Let us know how this goes!
Hello Nabeel,
Thanks for the provided snippet.
A bit of a brutal solution haha. We do rely on the format-standard class so we’ve gotta find another way but I appreciate the effort.
Also, loading a JS on all pages of the website when it’s only really needed on the single-post pages is against our performance guidelines.
Is there a core file we can edit somewhere to remove this without JS? We could eventually just alter the rule slightly so that we maintain the functionality of the theme (since this must be handled somewhere, although it’s not entirely clear where because we have the post links styling disabled) but it doesn’t conflict with other elements.
Changing the rule from…
.format-standard .entry-content a:not(.x-btn):not(.x-img-thumbnail) {
border-bottom: 1px dotted;
}
to…
.format-standard .entry-content a:not([class]) {
border-bottom: 1px dotted;
}
Makes it so that only bare <a> links without class are targeted, which is often the case for links that are added directly inside a post content. If you add a link to an image, a button or have floating social buttons in your content, they wouldn’t be targeted because all of these tags are bundled with a class and they won’t have a dotted border bottom.
This is not 100% fool proof, if you have a link in your post and you add a custom class, it wouldn’t be styled, but my guess is that if you add a custom class, you want to style it differently anyway.
So maybe a suggestion to change this rule as instructed for a future release and in the meantime is there any way for us to do that?
Thank you!
All best,
B
Hello @thisisbbc,
Thanks for updating in!
By default, we have this css built in the icon style.css
.format-standard .entry-content a:not(.x-btn):not(.x-img-thumbnail) {
border-bottom: 1px dotted;
}
.format-standard .entry-content a:hover:not(.x-btn):not(.x-img-thumbnail) {
opacity: 0.65;
filter: alpha(opacity=65);
}
If you want to target ordinary links, you can do it like this:
.format-standard .entry-content a {
border-bottom: 1px dotted !important;
}
.format-standard .entry-content a:hover{
opacity: 0.65 !important;
filter: alpha(opacity=65)!important;
}
.format-standard .entry-content a.x-btn,
.format-standard .entry-content a.x-img-thumbnail {
border-bottom: none;
}
.format-standard .entry-content a.x-btn:hover,
.format-standard .entry-content a.x-img-thumbnail:hover {
opacity: 1 !important;
filter: alpha(opacity=100)!important;
}
Or you can do it in reverse like this:
.format-standard .entry-content a {
border-bottom: none;
}
.format-standard .entry-content a:hover {
opacity: 1 !important;
filter: alpha(opacity=100)!important;
}
.format-standard .entry-content a.x-btn,
.format-standard .entry-content a.x-img-thumbnail {
border-bottom: 1px dotted !important;
}
.format-standard .entry-content a.x-btn:hover,
.format-standard .entry-content a.x-img-thumbnail:hover {
opacity: 0.65 !important;
filter: alpha(opacity=65)!important;
}
Hope this helps.
Hello @RueNel,
Thanks for the provided snippet and info about the stylesheet, I’ll edit it directly and try to remember to maintain this change on theme updates.
The solutions you’ve described are unfortunately equally as compromising as the initial CSS rules.
The first one adds a 1px dotted bottom border on all links (including the Pro button element since it uses a class x-anchor-button and not x-btn) and it would also target our floating social buttons.
The second solution removes the bottom border from all links, but it would also remove the bottom border from the Pro button element along with our social sharing buttons.
The only way I can think of is the solution I described:
.format-standard .entry-content a:not([class]) {
border-bottom: 1px dotted;
}
.format-standard .entry-content a:hover:not([class]) {
opacity: 0.65;
filter: alpha(opacity=65);
}
This ensure only naked links are styled, not buttons or images.
Do you think this change can be considered for future updates in the Icon stylesheet?
Thank you!
Having a little bit of a hard time locating the Icon style.css file…
It’s not in framework/views/icon and I couldn’t find the dotted border bottom rule in framework/dist/css/site/stacks/icon.css
Could you point me where exactly this style.css file is located?
Thank you!
Hi @thisisbbc,
Actually you can find it in the generated css file:
/x/framework/functions/frontend/generated-css/icon.php
Hope this helps. Please let us know how it goes.
Thanks @RueNel,
Any chance that this can be studied/implemented for future updates?
I believe this rule is too broad and affects negatively some of features provided by Cornerstone (or even other plugins).
Appreciate the consideration!
All best,
B
PS: Since this is generated CSS, will it be wiped out everytime we save the Theme Options panel?
PS2: You can check now on our blog posts that link are styled using the Icon rule but our social buttons and the Cornerstone buttons in our posts are not affected.
Hey @thisisbbc,
Yes, this could be a drastic change since all of the stacks are setup the same way but I have added this to our feature request list so that it will be considered in the future development.
Yes, that is right. If you make any changes in the settings of the Theme Options, the generated CSS will be recompiled.
Glad to hear it’s sorted.
Hello Jade,
Thanks for the provided additional information.
Hopefully enough we don’t go play very often in the theme options but I’ll have to put a note to override the generated CSS manually if it’s updated.
Appreciate your consideration and hope this can make it in a near future release 
All best,
B
You’re most welcome, B.
Hi @thisisbbc
I just saw Jade’s submission in our issue tracker and wanted to chime in so you know what our plan is moving forward. This is most certainly something we are taking steps towards improving at a fundamental level. We’re wrapping up a rather large development cycle focused on new elements at the moment. After that we’ll be working on a Layout Builder which allows you to make your own page and post type templates in Pro.
Finally, we’ll be revisiting base level Theme Options. The current approach of Stacks outputs rather opinionated styles. This was the right approach back in 2013 when the theme was in development, but as web building tech has evolved there has been more and more need for customization. We’re going to be working from scratch and making a new base level styling options that are un-opinionated as possible, then allow granular customization. I don’t have specifics on how this will work but our strategy will somewhat naturally remove conflicts like what you encountered in this support ticket.
I hope that helps shed some light on the development process and the future of X and Pro. Have a great week!
Hey Alexander,
Thanks for the input regarding future updates.
I’m happy to hear you’re considering a different approach for Stacks.
As X evolved into Pro, we found that Stacks were rather confusing since we could pretty much re-create any kind of style with the theme customizer and some CSS. With time, I’ve come to consider “stacks” as “theme presets” but I rarely ever play with them because it’s been unclear as to exactly what I was changing when switching from a stack to another. Obviously there are stacks-specific CSS rules but there’s also the layout on the blog page, single-post, etc.
It has never bothered me much but it’s good to know the mechanics of stacks are being revised.
Looking forward to those updates!
All best,
B
You are most welcome B!
This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.