#5

Sure, it’s just as in the photo, I caught the whole contents in the photo, but here is the file attached (I guess you can copy/paste it to test it?).

Thank you for checking into it.

select.css (1.4 KB)

#6

I’m not sure if I understand your purpose. I found a typo on line 54 that disable all config below.

I fixed it to restore backgound color of selection into orange. I hope it helps.

select.css (1.4 KB)

1 Like
#7

Not sure what you did, going to have to look through the code to see if I can spot the difference, but it works great now!

If I hover over a URL link, I can see the URL at the bottom of the note window, and if I highlight the note name, I can clearly see what is highlighted, whereas before, I couldn’t tell if the text was highlighted, or where the highlighting began or ended.

See here, for example, look at the note name that I’ve highlighted: http://postimg.cc/c6CM50cK

Sure, if you look ever sooo carefully, you could say that you can see a very pale blue highlight over the gray background, but is that acceptable? NO! When I highlight, I want to immediately and clearly see what is, or is not highlighted, as in this example, where the highlighting works properly: http://postimg.cc/XXs1pss5

I have no idea what it was about the coding that had broken that highlighting functionality… the URL mouse-over part was still working perfect, but the highlighting was virtually invisible.

Thank you @conbas2019! It might seem trivial, but it is not, I was needing to highlight the note names often to edit, and it was a serious pain in the arse.

What a relief! And no, not in that way… just in the way of ease of work.

EDIT: What? Was it just as easy as putting the code before the comments section? No way!, that can’t be it.

#8

Just to explain what @conbas2019 changed in your file:

/* some text */ produces a comment that is ignored by the program when reading style information. In your original css file, the comment hadn’t been closed - thus, everything after the /* had been ignored as well.

2 Likes
#9

Oh, the “*/” to close the comments section was missing? I didn’t realize that it worked that way, I thought that comments were like in other languages, where you just place a ; or other such character at the beginning of each line… basic stuff, now that you mention it, but not being very familiar with HTML, markdown, and other such languages, I wasn’t perceiving that open/close syntax. Silly me. Thank you for the light.

#10

In general: I would recommend to put different style adaptions into different files. This makes it, first, easier to decide which adaptation you want to switch on and maybe off again.

Second, if something is not working, it is easier to filter out what might be wrong.

So, I would put one thing in a file named select.css and the other one in a second file named link-preview.css…

2 Likes
#11

Thanks for the explaination.

1 Like
#12

By the way, a expressive title for your problem can be better.

3 Likes
#13

Absolutely, seperate into different files is better.

1 Like
#14

:slight_smile: When I wrote the post I was soooooooooo freakin’ frustrated with having to fool around with that crap instead of getting my work done… I was sooooo pissed at .css in general… I was trying different things to fix it, and nothing was working (if I’d accidentally thrown the code snippet before the comments section, I might have realized that there was something about the comments section that was causing the problem, but when I tried repositioning the code, I was only working just below the comments section).

Again, sounds trivial, just highlighting, but as mentioned, I was often editing the note names and not being able to see the highlighting was a MAJOR headache.

LOL! @alltagsverstand, again, basic level stuff for you guys, it’s going to sound hilarious, but I thought any modification code had to be added into that select.css file… hehe… such a dunce… I thought that the select.css file is where any .css modifications had to be put… but then when you told me this information (quote above), I realized that this snippets folder is where all modifications reside… now I get it, so I’m going to put Matthias’s URL code in a URLStatusView.css file, and the select code in a HighlightNoteName.css file… I understand an agree about the separation now that I understand that the .css code is accessed in this folder, and a bit better how that works.

Thanks guys.

2 Likes
#15

Totally agree. Sometimes it’s rather helpful to switch features on and off separately. And you could come back to the author of a snippet for help, which he might bluntly deny if it had been modified. :wink: (Error diagnosis and bug-fixing is made a lot easier if they’re separate, too.)

This is how mine look:

css-snippets
css-snippets738×1044 73.5 KB

2 Likes
#16

Thank you for that, I’m glad you posted this… I would probably have NEVER thought of that, and would have been pulling my hair out as to why all my .css codes were not working anymore since I’d renamed them.

No need to explain, I understand how each file in that folder is going to generate an entry in the settings, whereby you will have to enable them.

Maybe, just maybe I might vaguely remember having done that weeks ago when I was first given the code to create my note names highlighting, but back then I was just following instructions and had no idea why I was doing that in the settings and how everything was inter-linked.

1 Like
#17

Live and learn … every day something new. :slight_smile:

Now that you’ve cooled down, it might me a nice new experiment to try changing the thread title to something that others might like to read, maybe “How to best organize CSS snippets so you don’t mess them up” or something. Hint, hint … :rofl:

2 Likes
#18

Capital idea!

1 Like
#19

Wide grin (and believe me, I know the feeling!)

#20

It was just making working with Obsidian so difficult :frowning:

But the skies are brilliantly blue again :smiley:

#21

It’s just sometimes the minor issues that frustrate us most.

#22

That’s just it, the big problems are more interesting, a challenge to overcome, but when it’s everyday mundane, Mickey Mouse stuff that shouldn’t be interfering or slowing you down, that is the stuff that grates on one’s nerves, especially at work… when your work is being slowed down by some stupid little glitch that shouldn’t even be happening, and when such crap is persistent, tenacious, and won’t let you resolve it without great effort.

#23

Btw, that reminds me of one thing even I tend to forget:

  • When switching existing CSS snippets on/off, this usually works flawlessly and immediately.

  • When editing a CSS snippet or creating a new one, even after a “CSS snippet reload”, these probably won’t work correctly until you’ve restarted Obsidian!

  • (Off-topic but important:) Restarting Obsidian is also important after updating plugins.

2 Likes
#24

Oh, blasted! As I started to read your post, I thought:

“Oh, there’s the answer to my question about reloading the code without having to shut down Obsidian and restarting it… all I’ll have to do is turn them off, turn them back on, and they’ll reload the code and then I’ll be able to see if my code changes work as desired. Great!”

Then as I kept reading, I’m back to shutting down Obsidian and starting it back up anytime that I change .css code. Drats!

But Ok… good to know anyway.