Because of course:
Scroll the sidebar and highlight the title currently in the viewport.
5 Likes
well that sure jumped to the top of things I hadn’t thought of but knew I needed. For such a seemingly minor thing, it REALLY helps give a modern boost to the UI.
However, it fails when the Open is tagged $:/tags/SideBarSegment, and afaict, it’s not just to the change in text colour, but the way the style is set (so may be a code issue in focused-tiddler plugin or even more fundamentally in TW core?
I set the colour to red to help highlight the difference for the screenshot:
I also noticed it sets the colour in the search results - intentional or just a byproduct of the way other things are done?
That’s certainly a bug and I’ll fix it.
As for your other question, is this interpretation correct: Your sidebarsegment already naturally coloures the links blue, so the supposedly added blue colour from Seentid doesn’t have any visible effect? Is that what you’re saying?
My first draft reply was “yes, well almost…”
But on inspection as I wrote this, I think it’s now a solid “no, it’s not that”
- It’s TW out of the box colouring the links blue when it’s a sidebarsegment. (your wording implied it was my style setup? But I note my screenshot above was of your demo. All I did was add
$:/tags/SideBarSegmentas a tag to$:/core/ui/SideBar/Open) - More relevant: Seentid colouring isn’t applying at all (again I refer to the screenshot above, where I configured
$:/plugins/TWaddle/Seentid/stylesheetto set the colour to red). I initially thought this was TW’s native style taking precendece, but after a look at the browser inspector, I now think it’s because your css relies on it being within a.tc-sidebar-listsclass, but that’s not true for the SideBarSegment version.
OK, updated to not affect the search dropdown.
…but adding a SideBarSegment unfortunately doesn’t give any general way to target only it - so, the following solves your problem but I’m not including it in the plugin:
You need to modify the plugins stylesheet tiddler by inserting this line into it, ABOVE the other style def:
.tc-sidebar-tab-open a.tc-tiddlylink[href="#<<href>>"] {color:red;}
(This really colours both your extra stuff and the standard Open tab red, but if you put it ABOVE the existing line, then the lowermost line will override the previous for the relevant parts)
1 Like
Very nice. I’ve toyed a little and now have this on my personal version
.tc-sidebar-tab-open a.tc-tiddlylink[href="#%24%3A%2Fplugins%2FTWaddle%2FSeentid%2Fstylesheet"] {color:#000;}
.tc-sidebar-tab-open a.tc-tiddlylink[href="#%24%3A%2Fplugins%2FTWaddle%2FSeentid%2Fstylesheet"]::after {content:" đź“Ť";}
But will definitely mess with it more.
New bug found: if a title has brackets, then it’s not shown - though the stylesheet is updated (maybe the stylesheet needs different quoting or % escaping of the parenthesis?
Fun fact: you can use nested CSS to avoid repeating long selectors
For example, you can rewrite:
.tc-sidebar-tab-open a.tc-tiddlylink[href="#%24%3A%2Fplugins%2FTWaddle%2FSeentid%2Fstylesheet"] {color:#000;}
.tc-sidebar-tab-open a.tc-tiddlylink[href="#%24%3A%2Fplugins%2FTWaddle%2FSeentid%2Fstylesheet"]::after {content:" đź“Ť";}
like this:
.tc-sidebar-tab-open a.tc-tiddlylink[href="#%24%3A%2Fplugins%2FTWaddle%2FSeentid%2Fstylesheet"]
{
color:#000;
&::after {content:" đź“Ť";}
}
The & symbol replaces the need to repeat the outer CSS selector. You just need to add the ::after portion for the nested CSS rule.
enjoy,
-e
2 Likes
ah nice. and my previous quoting was after rendering too, which isn’t too useful for anyone else looking at this.
My current iteration looks like this:
.tc-sidebar-tab-open a.tc-tiddlylink[href="#<<href>>"] {
color:#000;
background-color: #FF66;
border-radius: 3px;
box-shadow: 1px 2px 4px 4px #9999;
&::after {content:" đź“Ť ";}
}
UPDATED. Good catch. Before updating also note that:
I’ve updated the css to change the link background instead of the link coloration. Much prettier IMO.
@EricShulman - do you happen to know why the makedatauri doesn’t properly replace quite a few characters? Is it intentional? I’m forced to compliment it like so:
+[search-replace:g[ ],[%20]search-replace:g['],[%27]search-replace:g[!],[%21]search-replace:g[(],[%28]search-replace:g[)],[%29]search-replace:g[*],[%2A]]
1 Like
love it!
I’ve done some more poking with browser dev tools, and seems to me that instead of .tc-sidebar-lists:not(.tc-sidebar-search) you can just have .tc-sidebar-header and it then matches both use cases neatly (and afaict, doesn’t catch anything it shouldn’t)
The final form of mine (so far) is
display:inline-block;
width:90%; /* it wraps awkwardly when this is 100% for some reason*/
background-image: linear-gradient(to right, #CCF6, #CCF6, #9CF);
border-radius: 5px;
outline:1px solid #ddd;
&::after {content:" đź‘€";}
}
Good stuff! I picked up on the .tc-sidebar-header - I had actually tried it earlier but dismissed it because if the wiki title is a link to a tiddler (which I sometimes do) it also highlights - but if this solves both the SideBarSegment problem and also the :not(.tc-sidebar-search) well… nothing more to say. Thank you @nemo !
I also tweaked the styling a tad with margin-left:-5px; padding-left:5px to move the highligting a tad to give a little air around the link. It’ll barely be visible for your gradient in the image you posted here but for your other Draft of' solution, I note you do the gradient in the other direction and there I believe it would look better.
So, UPDATED.
1 Like