Hide parts of a tiddler without using a tag or global css styles

[Danielo Rodríguez]

I'm not sure if what I want to do is possible, but if it is not a modification to the core would be required.

What I want to do is hiding certain parts of certain tiddler with the following conditions

• Not modifying the core view template.
• Not using global CSS styles. 
  
• Without assigning certain tag to the tiddler.

This is a very interesting thing for creating custom view templates based on conditions external to the tiddler itself, for example the existence of another tiddler. I find a bad practice to modify the users data (adding a tag) just for displaying it in a different way.

Thanks and regards

[Mat]

You can use a filter that if conditions are met shows a local (not global) style block. 

<$list filter="<my conditions>">
<style>
 <target> {display:none;}
</style>
</$list>

A potential problem with this is that you probably want to use it generally, on whichever tiddler fulfills some criteria, but that the "most styles" even if they are declared in a local style block, will be applied globally. I.e if the style concerns, say, .tc-tiddler-title then that affects all titles...

One limited way to get around this is to css target the title of the tiddler. This is of course very specific. It requires that you use "title links". Because of the html structure of a tiddler, you can unfortunately not reach other elements within the specific tiddler BUT you can use the title with e.g :before and :after pseudo elements so to include e.g an image. Yes, limited.

However, this is probably how I would currently solve the problem; Use a "shell tiddler" (my lingo) that displays its content via a custom viewtemplate.... and put whichever tiddler you want into this, by use of a filter that has [your words] "conditions external to the tiddler itself".

You kind of see this in the released-for-help version of Article Tiddlers.

<:-)

[Thomas Elmiger]

Hi Danielo and Mat

This is a feature I have been missing too: identification of individual tiddlers in the story river. If we had something like this:

<div id="HashValueDerivedFromTitle" class="tc-tiddler-frame tc-tiddler-view-frame tc-tiddler-exists   "><div class="tc-tiddler-title">
 <div class="tc-titlebar">

We could target individual tiddlers with (local) CSS. A hash value is just my first idea to get an id without special characters and spaces. (Spaces are not allowed in IDs.)

Kind regards, Thomas

[Mat]

@Danielo and @Thomas,

in deed. Identification/targeting of specific tiddlers. I don't understand why the tiddler title/ID isn't already designed to be at the outer div, but I'm guessing there is some good reason for this.

However this just gave me an idea:

In $:/core/modules/widgets/tiddler.js if you do a search for "tc-tagged" you'll find a mechanism that uri-encodes the tags and prepends "tc-tagged-". If my js skills were not sucky-sucky I could change this to instead simply do this with the title instead... but must now ask if you can try it? 

Then I think a stylesheet with e.g:

.tc-tagged-<title> {background:yellow;} 

...or display:none for that matter...

...should work. The title might have to be uri-encoded there too (see note in docs) so try it just with "foo" in tests.

<:-)

[Thomas Elmiger]

Hi Mat

Titles can be very long and contain special characters, maybe this is the reason, it was not done before. URI-encoding or hashing appear both to be possible, hash values tend to be shorter (if you have longer titles than "foo").

But I am not a JS hero neither. Sorry.
Good night!

[PMario]

On Monday, August 29, 2016 at 12:23:24 AM UTC+2, Thomas Elmiger wrote:

Titles can be very long and contain special characters, maybe this is the reason, it was not done before.

There is a long standing issue at github which discusses this issue. There is no consensus yet. Thus no fix. ... Just jump to github and resurrect the issue :)
 

URI-encoding or hashing appear both to be possible, hash values tend to be shorter (if you have longer titles than "foo").

The problem with hash values is, that if the tiddler title is changed, there is absolutely no way to find the "tiddler name" (responsible for the styling), if you only know the hash from the CSS definition.

The existing way, at least gives you a hint, about the connection between tag name and CSS class name.

-m

[Danielo Rodríguez]

Hello @Mat and @Thomas,

I think that Thomas's idea it's a very good one, but I would use a class instead of an ID. Remember that a tiddler can be opened more than once.

I don't think that there is any good reason for doing it for tags and not for titles. Probably the reason is because someone though it would be cool doing it for tags and no one proposed doing it for titles. Don't forget that, at the end, tags are tiddlers, and the tag body is the tiddler title, so at the end is exactly the same thing.

Modifying $:/core/modules/widgets/tiddler.js should be enough. It would be a matter of adding a class tc-entitled- with the same method the tags does.

I'll take a look.

[Danielo Rodríguez]

The problem with hash values is, that if the tiddler title is changed, there is absolutely no way to find the "tiddler name" (responsible for the styling), if you only know the hash from the CSS definition.

The existing way, at least gives you a hint, about the connection between tag name and CSS class name. 

In case we use hashes we should also provide a macro that , passing the title as argument, returns the hash. Something similar to what the qualify macro does. 

[PMario]

Yea, that's easy. ... But I'm talking about the other way around. I'll give you the hash and you give me the title (after renaming it). This is maintenance nightmare!

-m

[Thomas Elmiger]

Hi Danielo

This is exactly how I would do it: The system uses the same hashing macro as the CSS developer. This makes sure, they get the same results.

Here is the hashing macro I used for TextStretch (it simply calls the core function for this):

/*\
title: $:/core/modules/macros/HashStr.js
type: application/javascript
module-type: macro

Generate a numeric hash from a string
uses $:/core/modules/utils/utils.js
\*/

(function(){
   /*jslint node: true, browser: true */
   /*global $tw: false */
   "use strict";

/*
Information about this macro
*/
   exports.name = "HashStr";
   exports.params = [
      {name: "str"}
   ];

/*
Run the macro
*/
   exports.run = function(str) {
      var hash = $tw.utils.hashString(str);
      return hash;
   };
})();

Good luck!
Thomas
 

[Thomas Elmiger]

Hi Mario

I would not recommend to include title-hashes in CSS ... but to somehow filter the titles you want to apply special css to and transclude the result in the CSS. In my theory this should work as long as the filter works, no matter how often you change the title.

Thomas

[Danielo Rodríguez]

I have opened a new issue about this topic:

https://github.com/Jermolene/TiddlyWiki5/issues/2564

Dear Thomas, Mat, and of course Mario, your input would be very valuable there.

[Mat]

PMario wrote:

Yea, that's easy. ... But I'm talking about the other way around. I'll give you the hash and you give me the title (after renaming it). This is maintenance nightmare!

Isn't that because the mechanism (if there is any) for dealing with "renamings" is insufficient? Renaming a tiddler ought to globally change all occurrences of the title to, for example, prevent links and transclusions to die. If this was solved I think the hash issue would be too.

<:-)

[Mat]

BTW, is there an advantage with hashes over uri-encoded titles? The latter is already in use in TW and we have e.g makeuri and in $:/core/modules/utils/utils.js there is a function tagToCssSelector that seems to mangle a tag (or title?) with escapes etc.

<:-)

[PMario]

On Monday, August 29, 2016 at 10:43:35 AM UTC+2, Thomas Elmiger wrote:

I would not recommend to include title-hashes in CSS ... but to somehow filter the titles you want to apply special css to and transclude the result in the CSS.

"but to somehow filter the titles" ... That's exactly, how it is implemented in the core atm. If you tag the tiddlers, that you want to specify with eg: use-me the CSS code is .tc-tagged-use-me

That works out of the box, in a consistent way.
No additional plugin / documentation is needed.
This gives the user the freedom to define rules in the way they want, because programmers always use the wrong defaults!
If the user wants to know which tiddlers s/he defined for special treatment the just need to use <<list-links "[tag[use-me]]">>.
...

------------------------------------------------

But we are slightly OT. The OP said:

• Not modifying the core view template.

 

The point is. TiddlyWiki implemented a consistent way to modify the UI.

a) TW applies default classes to every widget, that create HTML elements, to allow the built in "palette" and "themes" functionality.

b) TW automatically assigns a tag class="" to tiddlers, that are tagged. So if a user wishes, they can assign special rules to tagged tiddlers.
This was implemented because of high demand.

c) TW uses the <$list> widget to dynamically create the core ViewTemplate. All tiddlers tagged: $:/tags/ViewTemplate are used to build the "top level" tiddler UI

some important blocks are:

• $:/core/ui/ViewTemplate/title
• $:/core/ui/ViewTemplate/subtitle
• $:/core/ui/ViewTemplate/tags
• $:/core/ui/ViewTemplate/body

To get the full shadow list. Use: <<list-links [all[shadows]tag[$:/tags/ViewTemplate]]>>

If a plugin author wants to add or remove elements, they can just use this tag. If a special position within the template is needed the field: list-before can be used. No need to modify existing core templates!

$:/core/ui/ViewTemplate/title uses 2 elements to dynamically create the tiddler toolbar. The system tag: $:/tags/ViewToolbar and a "visibility" configuration tiddler prefixed: $:/config/ViewToolbarButtons/Visibility/??? which allows the user (and plugin authors) to decide which elements are shown by default.

Those settings can be changed at: ControlPanel: Appearance: Toolbars

If a plugin author wants to add or remove elements, they can just use this tag. If a special position within the template is needed the field: list-before can be used. If a button needs to be visible by default, just create the needed config tiddler. No need to modify existing core templates!

-> This mechanism is consistent for all View- and EditTemplates.

• Without assigning certain tag to the tiddler.
• Not using global CSS styles.
  

d) If all those dynamic mechanisms don't give enough possibilities, every plugin author is free to create their own UI, with partially or completely change the default behaviour. Best practice is: modify the core Templates with your own implementations.

IMO at a certain point of customization it is needed to modify the core templates, because every other possibility is much more fragile, and a lot more work to maintain.

have fun!

mari

[Thomas Elmiger]

Thank you, Mario, for the detailed explanations!

IMO at a certain point of customization it is needed to modify the core templates, because ever other possibility is much more fragile, and a lot more work to maintain.

have fun!

mari

--
You received this message because you are subscribed to a topic in the Google Groups "TiddlyWiki" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/tiddlywiki/NiS6c9yO-Lg/unsubscribe.
To unsubscribe from this group and all its topics, send an email to tiddlywiki+unsubscribe@googlegroups.com.
To post to this group, send email to tiddl...@googlegroups.com.
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/71de5d61-0d8a-412f-9cd0-6a56d8c3722e%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Danielo Rodríguez]

Hello Mario,

That is a very good explanation. I already know all those mechanisms but it would be a very good reference for incoming users or even myself when I forget about any detail.

However, I don't understand your reticence to implement a very simple feature which is already implemented for another similar (but not same!) component: the tag.

IMO modifying any port of the core should be avoided as long as possible. Tiddlywiki is about personalization, so I think it is a good idea to implement mechanisms to provide that personalization. If the current mechanism does not provide the required level of personalization then it should be reviewed. I don't care about the particular implementation as long as the result is that the required level of personalization is achieved. 

Dynamic/customizable view templates it's at TW core, and has been encouraged since first day. Currently there are enough mechanisms to add as many parts as you require at the position you need, I can't discuss that. So, if you are able to add everything you want and at the position you want, why not provide the same functionality to hide certain parts ? It's the only bit missing to achieve the total customization level, without changing the core.

[PMario]

I think there needs to be a different way, Also for tags. I think the existing tc-tagged- mechanism is extremely inconvenient, because it doesn't handle special characters well.

I did a test with a new ta-title attribute in the ViewTemplate. See the attached file.

It modifies the ViewTemplate and adds a ta-title attribute, which can be used to style tiddlers based on their real title. It seems there is no url encoding needed and the attribute selector allows to select attributes in a very felxible way.

for reference material see:

• https://developer.mozilla.org/en/docs/Web/Guide/CSS/Getting_started/Selectors
• https://developer.mozilla.org/en-US/docs/Web/CSS/Attribute_selectors
• spec: https://www.w3.org/TR/css3-selectors/#attribute-selectors

It seems the CSS specification allows special characters int attribute values.

have fun!
mario

[Danielo Rodríguez]

Hello Mario,

That is awesome, and far better than using a class. This allows very flexible selectors as ta-title^="Draft of '" for selecting all the tiddlers begginig with that string, including single quotes. And the browsers compatibility seems to be very wide, from IE7 and all the mayor browsers.

I hope you have posted this information on the GH issue. I find it very valuable.

How open are you to implement this on the core? I know this depends ultimately on Jeremy, but your opinion has a lot of weight too.

Regards

[Danielo Rodríguez]

I just tried 

[ta-title="<<currentTiddler>>"] .tc-tiddler-body {

background: orange;

}

[ta-title="<<currentTiddler>>"] .tc-title {

display: none

}

And works flawlessly. As I said, very promising. I can't wait to see this as a core default!

[Danielo Rodríguez]

Some more tests that works with mario's setup:

<$list filter="[is[current]has[caption]]">

<style>

[ta-title="<<currentTiddler>>"] .tc-title {

display: none

}

</style>

</$list>

This is awesome. Maybe a bit CSS hacky... I don't know if implementing this feature (dynamic element showing) into the core could lend to more performant results.

[Mat]

On Monday, August 29, 2016 at 4:48:51 PM UTC+2, PMario wrote:

I did a test with a new ta-title attribute in the ViewTemplate. See the attached file.

REALLY EXCELLENT! Thank you Mario!!!!

Could this be used generically for any field? If one does want to style using tags, or any other field? 

Also, this would also make it possible to, in each tiddler, have a dedicated style field (just like currently there can be a color field) for quick styling of a tiddler without a separate stylesheet. I.e directly in the tiddler create a field with style: color:green; background:yellow;

A style field would also make it possibly to style easily via actions (a button); it is just to "set that field". Powerful!

<:-)

[Tobias Beer]

Hi Danielo,

I think it should be possible and relatively easy to extend the core
so that for each ViewTemplate element one could define a filter
whereby the element would only be displayed if the filter had any result.

Best wishes,

Tobias.

[PMario]

On Tuesday, August 30, 2016 at 7:45:45 AM UTC+2, Mat wrote:

Could this be used generically for any field? If one does want to style using tags, or any other field? 

Not really. The attributes we are talking about here are DOM attributes, not tiddler fields. I did change the core ViewTemplate for the test and used the "outer" <div> the holds the tiddler-frame. That's the same one, that uses the class="tc-tagged-xxxx". I just used the "attribute selector" CSS feature, that seems to be well supported by all browsers. So there should be no compatibility problem, if we use it.

Adding tiddler-field values to the DOM structure would be possible but I have no idea, what it does to TW performance. ATM I don't know, if the [attr] CSS feature is slow. ... So some more tests are needed.
 

Also, this would also make it possible to, in each tiddler, have a dedicated style field (just like currently there can be a color field) for quick styling of a tiddler without a separate stylesheet. I.e directly in the tiddler create a field with style: color:green; background:yellow;

Using the <style> element imo isn't a good idea, because it generally has one of the highest priorities. So it overwrites everything defined in theme style sheets. It should be the absolutely last possibility to style something and not the default. IMO it has the possibility to destroy themes and adds a lot of maintenance overhead. eg: once a <style> element is inserted in the DOM, it's close to impossible to change something with a standard class definition. The default should be class= and may be [attr]. But for the [attr] feature we'll need more tests.
 

A style field would also make it possibly to style easily via actions (a button); it is just to "set that field". Powerful!

Yea, powerful and imo toxic, if you want to design generic features or plugins.

just some thoughts
mario

[PMario]

On Monday, August 29, 2016 at 5:48:34 PM UTC+2, Danielo Rodríguez wrote:

That is awesome, and far better than using a class.

ATM I don't know, if CSS [attr] styling is considered "slow". It depends, a lot on browser optimizations. eg: drop-shadows are supported for a long time, but still can slow down page rendering on mobile devices. ... 
 

This allows very flexible selectors as ta-title^="Draft of '" for selecting all the tiddlers begginig with that string, including single quotes. And the browsers compatibility seems to be very wide, from IE7 and all the mayor browsers.

That's true. We would have very powerful and very specific CSS filters, that can be used in standard stylesheets. So no need for "hard coded" <style> elements or IDs or !important ..
 
The biggest pro would be, that it seems no url-encoding is needed. So we could use real tiddler titles. ... BUT ... some tests with Cyrillic and other languages should be made. ... So it may be necessary to add access to other tiddler fields, and use them for workarounds if tiddler titles fail.
 

I hope you have posted this information on the GH issue. I find it very valuable.

Not yet. ... more tests needed.
 

How open are you to implement this on the core? I know this depends ultimately on Jeremy, but your opinion has a lot of weight too.

Yes. I think it might be a possibility fix issue 958 and even improve the possibilities.

But it will introduce backwards incompatibility, if we replace the existing mechanism, which is definitely needed in my point of view see issue 958

 - So we would need to deprecate the existing one and introduce the new one.
 - After enough time eg: 2 version updates we could remove the old mechanism.

So the way to convince Jeremy is: to prove, that it works and is actually a lot better then the existing mechanism.

--------------

I'm not sure, how much the tc-tagging mechanism is really used. There aren't many posts in this group about problems. May be because many tags are "single words", or low usage. .. I don't know.

-m

[Jeremy Ruston]

Hi Mario

Yes. I think it might be a possibility fix issue 958 and even improve the possibilities.

What do you mean by fixing #958? That ticket merely points out that tag names have to be encoded for use in a stylesheet. We don’t have a plausible proposal for how to avoid the need for escaping, so I’m not sure what a fix would look like.

I’m happy with the proposal to put the tiddler title into an attribute of the tiddler frame, but I’d recommend `data-tiddler-title`.

Best wishes

Jeremy

But it will introduce backwards incompatibility, if we replace the existing mechanism, which is definitely needed in my point of view see issue 958

 - So we would need to deprecate the existing one and introduce the new one.
 - After enough time eg: 2 version updates we could remove the old mechanism.

So the way to convince Jeremy is: to prove, that it works and is actually a lot better then the existing mechanism.

--------------

I'm not sure, how much the tc-tagging mechanism is really used. There aren't many posts in this group about problems. May be because many tags are "single words", or low usage. .. I don't know.

-m

--
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 tiddlywiki+...@googlegroups.com.

To post to this group, send email to tiddl...@googlegroups.com.
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/fc82b6c8-c6b4-4ada-996b-de707d0bebc9%40googlegroups.com.

[Danielo Rodríguez]

I just realized about the following on the filter of the body view template:

!field:hide-body[yes]

I think it will be much easier, and powerful, and performant, and less error prone to implement this to all the view templates (title and tags).

It will easily integrate with TW philosophy.

What do you think? 

[Danielo Rodríguez]

Here is what I think, after think about it a while.

I don't like this idea because it also implies to modify the current tiddler, so it's like going to the starting point again. I downvote this option :D

[Mat]

PMario wrote, in reply to my comment:

Also, this would also make it possible to, in each tiddler, have a dedicated style field (just like currently there can be a color field) for quick styling of a tiddler without a separate stylesheet. I.e directly in the tiddler create a field with style: color:green; background:yellow;

Using the <style> element imo isn't a good idea, because

I tried the following for a tiddler-local style field. The <div style> element is outside the other <div classes> which gives it lower priority than any classes applied (according to tests I did). Is this a example of the "bad idea" or did you mean something else? - Unfortunately it doesn't seem to work (why?) with the transclusion in the viewteplate but it should give an idea. 

\define style() {{$(currentTiddler)$!!style}}
\define frame-classes()
tc-tiddler-frame tc-tiddler-view-frame $(missingTiddlerClass)$ $(shadowTiddlerClass)$ $(systemTiddlerClass)$ $(tiddlerTagClasses)$
\end
\define folded-state()
$:/state/folded/$(currentTiddler)$
\end
<$set name="storyTiddler" value=<<currentTiddler>>><$set name="tiddlerInfoState" value=<<qualify "$:/state/popup/tiddler-info">>><$tiddler tiddler=<<currentTiddler>>><div style=<<style>>><div class=<<frame-classes>>><$list filter="[all[shadows+tiddlers]tag[$:/tags/ViewTemplate]!has[draft.of]]" variable="listItem"><$transclude tiddler=<<listItem>>/></$list>

</div></div>
</$tiddler></$set></$set>


<:-)

[Danielo Rodríguez]

Hey!

I just found a solution to my problem, how convenient !

I realized that there is something that hides the subtitle, the tags and the body, everything but the title, which was exactly what I wanted: the fold state.

So what I did is add a "section" after the title, show it when needed and at the same time fold the tiddler body. It looks amazing and I didn't touched a single core tiddler.

I have to thank everyone their proposed editions to the view templates, they made me realize about the fold reveal. But, in any case, I think we should consider continuing this discuss.

Regards

[PMario]

On Tuesday, August 30, 2016 at 11:01:48 AM UTC+2, Jeremy Ruston wrote:

Yes. I think it might be a possibility fix issue 958 and even improve the possibilities.

What do you mean by fixing #958?

closing, if we reach an agreeable proposal.
 

That ticket merely points out that tag names have to be encoded for use in a stylesheet.
We don’t have a plausible proposal for how to avoid the need for escaping, so I’m not sure what a fix would look like.

That's exactly the point. Due to the CSS spec, class names have to be escaped. So I think, there is no solution, other than create weird looking classes. The problem with those classes are, that they are extremely inconvenient for newbie users. IMO it's impossible for humans to create valid CSS stylesheets by hand. Except for simple tag names. .....

Having a look to this group, it seems there aren't many problems with this functionality. .. Either because
 - the feature it's rarely used
 - tag names are simple by default
 - Users just use simpler tag names, if complicated ones don't work

As I wrote several times, we need more testing with the new [attr] selector. I'm not sure yet, how it handles quotes. ..

I'm ok with a `data-tiddler-title` html attribute, but need to look at the specs, what characters it allows for the values section.

-m

[PMario]

As Jeremy suggested, I did change the html attribute name to "data-*". It actually seems to be designed with our usecase in mind. So the CSS handling should be optimized already and there are some other nice side effects.

The generic browser javascript api seems to be demanding, but that's not important for our usecase, since we store our dynamic data in tiddlers and not in the DOM. So we should be good here.

I did also test tiddlers with special chars and a Cyrillic tiddler title.
It seems to work well. See the attachment. Please test and report back!

have fun!
mario

[Mat]

@pmario

Brief tests on Win10 chrome works good, including it surviving some arbitrary crash-attempts.

Thank you very much for this Mario!

<:-)