Hi Mario, > If you are the first one that creates an appear widget, you basically have > the chance to define the name you want. So everyone will be fine with > <$appear>. .. but the core styling classes should be only used by the core > and nobody else. >
So far, I understood this nomenclature as a general best practice, not as a reserved namespace for core components only. So, dunno... If you need new classes in thenbase CSS rules, you should create a PR for > the core. ... plugins should use prefixes. Perhaps I will go wit the *tb-prefix* then (in the future) and entirely ignore any distinctions as for classes or fields or messages... they're all going to be *tb-foo*, if needed ...and quite possibly not everything that can be prefixed will be, e.g. I will not change the *rating* field to *tb-rating*. If a user needs something else, they can have it... using parameters. I also don't feel like I will use any prefixes for widgets, wikirules or macros. That is actual markup and needs to be short and recognizable, no *tb-foo-do* . If it was to clash with someone's wiki or other plugins, there's a good chance that it can be easily modified to some other name in that one case where it's needed. Anywho, I think I'll rather search for plugin names and components that I have not yet encountered, rather than prefix the every living foo out of every tiny detail. As a user, I would find that confusing. Best wishes, Tobias. -- You received this message because you are subscribed to the Google Groups "TiddlyWiki" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/tiddlywiki. To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywiki/05bb0b74-04d1-466a-be4d-2dc4e09da302%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
