Mario,
*Widgets*
There is a lot of serendipity in this "Custom Markup" project, as I said
before it is opening up a number of different directions all of which
approach infinity. Truly amazing but only possible because of tiddlywikis
underlying openness.
- I think it is worth persisting before release so we do not compromise
the future possibilities, or release something which is later very
different and confuses people.
- Not with standing this perhaps a MVP just for paragraphs and div's
plus classnames and no customisation?
- This could allow a set of companion stylesheets to be build and
tested
*On parameter names*
- Using a naming standard like your proposed one, always makes things
harder for me to read, especially coming back to it after some time away,
that is the leading c as when I scan wikitext the c interferes with
spotting the name
- Have you considered using parameter names with the $ as we do
elsewhere to separate it from another fieldname like in the macro-call
$name?
- .name and _name and others should be possible, perhaps there is a
precedent somewhere?
- They will not be used outside the pragma?
*On underline*
Can I suggest you stop referring to "_" as Underline as it is an
underscore, sure wiki text uses double underscore to wrap text and
underline it. But the character is underscore and its used to underline in
some cases.
*On Custom tag*
If the one parameter can now be used for html tags and widgets, although
they are tags, we do not call widgets tags, perhaps a different name like
"element"? which doco will say is a "html tag or widget name" Arbitrary
html tags permitted.
See https://www.w3schools.com/html/html_elements.asp where element is valid
for html and not a long way to referring widgets as elements as well,
elements beginning "<$elementname" and ending with "</$elementname>"
*Other*
I wonder if arbitrary widget names can be used?, and by customising we can
toggle if that widget introduced by that tick can be disabled/enabled. eg
debug mode.
´.debug This when in debug mode like <<transclusion>>
I note that
Top
<$arbitrary>
Content of arbitrary widget
</$arbitrary>
bottom
Produces;
Top
Undefined widget 'arbitrary'
bottom
I wonder if we could toggle this "Undefined widget " message off, when not
debugging, on by default.
Regards
Tony
On Friday, 11 September 2020 07:22:37 UTC+10, PMario wrote:
>
> On Thursday, September 10, 2020 at 9:43:14 PM UTC+2, PMario wrote:
>
> If I did use different IDs I could have made the whole list widget thing
>> into a completely cryptic line of almost nothing.
>>
>> \customize degree htmlTag="$presentation" mode=block endString="---"
>> \customize angel htmlTag="$list" mode=block endString="--"
>> filter="[tag[slide]sort[title]]"
>> \customize tick htmlTag="$slide" mode=block endString="-"
>>
>> ° » ´ <$transclude mode=block /> - -- ---
>>
>
> Something "bad" needs to happen! I need to rename the pragma parameter
> names :/
>
> As you can see, the <$transclude mode=block /> widget call has a "mode"
> parameter. ... This parameter causes a naming conflict with the "mode"
> param from the pragma. That's why it's impossible to "replace" the
> transclude widget with a wikitext call.
>
> In Version 0.3.0 all the params will be renamed, like so:
>
> \customize <ID>=<userSymbol> *cHtmlTag=<tag> .. or <widget-name>*
> cParams=<class definitions eg: .i.hl.x.y>
> cEndString=<string>
> cUse=<userSymbol reference>
>
> I did check all TW widgets. There should be no naming conflict with the new
> names.
>
> As you can see, there is an other minor issue now. cHtmlTag isn't the right
> name anymore, since it can be a HtmlTag or a $widgetname
>
> So a question. Will we keep cHtmlTag or should it be customTag or *cTag*?
>
> Feedback please!
>
> -mario
>
>
--
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 [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/tiddlywikidev/3975c849-c2b3-41f5-84a6-7618d9cb41c9o%40googlegroups.com.
