Folks,
I simply can't get over the power this adds to tiddlywiki.
- Even just to use a symbol for a known or arbitrary html element name
is immensely powerful.
- Having a symbol and name simply replace a specific implementation of a
widget and pre-set attributes
- This inclu
Mario,
Perhaps there is something I do not understand but I am suggesting a
specific symbol lets say ¤ as a working symbol
- Perhaps I can state it in different words?
Consider this
\customise sym=elementname _element=elementname
¤elementname that will internally parse this as if there exi
On Monday, October 5, 2020 at 11:05:20 AM UTC+2, @TiddlyTweeter wrote:
>
> For readers on email in my last post prefaced *Regarding examples &
> WikiText "interactivity" *I deleted the last paragraph as it was
> misleading.
> TT
>
I think it was the one with the space-space-enter, that produce
On Monday, October 5, 2020 at 10:03:40 AM UTC+2, @TiddlyTweeter wrote:
>
> *Regarding a use case using "shorthand"*
>
> PMario wrote:
>>
>>
>> The point is, I'm completely clueless, why you write "content" with CSS?
>> What is the purpose? Or is it just testing out the possibilities?
>>
>
> Its a
Hi
´aside test asdf
is already possible
--
You received this message because you are subscribed to the Google Groups
"TiddlyWikiDev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to tiddlywikidev+unsubscr...@googlegroups.com.
To view this discussion on
On Monday, October 5, 2020 at 2:54:08 PM UTC+2, TonyM wrote:
This makes me ask if one of out special characters could simply default to
> the element that follows the special character
>
> eg
> 'aside Content is an aside
>
>
>- That is nominate one of the special character to just automatical
On Monday, October 5, 2020 at 2:54:08 PM UTC+2, TonyM wrote:
By the way I do nor think we shopuld say
>
> =
>
> Since to me the tick degree etc.. is a symbol
>
>
This will be some docs changes only. I would be OK with this.
> To me
>
> =
> Would be better and note that name can be a single c
Mario,
I have returned to research after a short break, and realise it is not as
intuitive when you come back to, it but I am getting there.
As a starter I am reviewing first simple elements only
eg;
\customise tick=kbd _element=kbd _mode='inline'
\customise tick=div _element=div
\customise ti
Sorry, To be a little clearer on my previous question answer
You may use answers to display all answers at once;
Otherwise
'q1 Question 1
'a1 answer 1
etc...
Tony
On Monday, 5 October 2020 23:54:08 UTC+11, TonyM wrote:
>
> Mario,
>
> I have returned to research after a short break, and realise
>
> PMario
> I was thinking about °/ some text and /° ... Since start and end are
> different, it should be possible to identify nesting. So
> ›/ and /› .. may be a second option and ´/ and /´ a 3rd one.
>
> I would like to keep °° some text °°
>
Well you are the developer :-).
TBH I don't
TT ..
> I have two other simpler suggestions ...
>>
>> 1 - only have ONE character not two ... using @@ or °° is nowhere near as
>> readable as @ ° alone. *Markup in-line should be the most readable and
>> the most minimal *because that is where reading happens most.
>>
>
PMario ...
> That's
--- Largely OT
> PMario ...
>
> The middle dot is very similar to the "Mediopunkt" in German "Leichte
> Sprache" rule-set. So we can't really use it. "Leichte Sprache" and
> "Einfache Sprache" are a "big thing" at the moment.
>
Ha! I had a quick look at https://en.wikipedia.org/
On Monday, October 5, 2020 at 11:34:48 AM UTC+2, @TiddlyTweeter wrote:
I was suggesting tentatively that there be two ID's for inline markup ...
>
> degree "°" (entity = °)
>
>
> and another ... (I can help you find one :-) maybe ...
>
I was thinking about °/ some text and /° ... Since start and
*Discussing putative inline IDs *
> @TiddlyTweeter wrote:
>
>
>> 2 - ADD a second ID, maybe aimed at paired use by default?
>>
>
>
PMario ..
> Not sure, what you mean here.
>
I was suggesting tentatively that there be two ID's for inline markup ...
degree "°" (entity = °)
and another ..
For readers on email in my last post prefaced *Regarding examples &
WikiText "interactivity" *I deleted the last paragraph as it was misleading.
TT
--
You received this message because you are subscribed to the Google Groups
"TiddlyWikiDev" group.
To unsubscribe from this group and stop receivi
*Regarding examples & WikiText "interactivity"*
TT wrote:
>
>
>> These can variously interact under nesting. They can also change existing
>> WikiText behaviors on line-spacing (when its nested inside some custom
>> constructs) in a way that can be confusing at first. Now I understand it
>> mu
Users on email please note that in my last post prefaced *Regarding a use
case using "shorthand" *I added a PS at the end reading ...
PS. There is a side-effect too that is very good for me. Generated content
CSS can't be copied via select on screen. Since these lessons are very
costly to make
Regarding a use case using "shorthand"
PMario wrote:
>
>
> The point is, I'm completely clueless, why you write "content" with CSS?
> What is the purpose? Or is it just testing out the possibilities?
>
Its a good question to ask. It forces me to be explicit about it. Yeah, it
seems very bizarre
I was about to post a note on in-lining :-)
I'll update first. A dopo.
TT
On Sunday, 4 October 2020 14:23:33 UTC+2, PMario wrote:
>
> Hi foks,
>
> I did just upload V0.6.0 which has some INCOMPATIBLE changes.
>
>
>- *New Functionality*
> - $:/config/custom-markup/pragma/PageTemplate
*Regarding fonts ...*
@TiddlyTweeter wrote:
>
>
>> 2 - SOME NOTES ON FONT SUPPORT - PMario & I already briefly discussed
>> this.
>> Its not an issue on the 6 IDs, at least not for European languages.
>>
>> But it *is an issue if you want to use Unicode characters in \customize
>> pragma*.
20 matches
Mail list logo