#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.

#25

Not much of a problem, I think. After the initial “adventurous phase”, one stops fiddling with CSS every day and starts using Obsidian for what it’s meant—real work. :wink:

#26

Yeah, I’m hoping I don’t need to fool around with .css very often… way back, fiddling around with batch files was a blast, I had a lot of fun with that, but .css is mostly used for formatting and appearance, from what I know of it, and that is not something I can generate nor acquire a passion for, even though in certain instances, such as those highlighting and mouse-over issues, it is very useful and important.

#27

You are very exploring! Please feel free to let us know when you meet a problem. :smiley:

By the way, I also hope these features can be support natively. :star_struck: