In haste, PMariuo & TonyM TonyM wrote: > > Mario, > > - I think it is worth persisting before release so we do not > compromise the future possibilities > > I agree. PMario opened a lot of doors. We need time to go through them to TEASE out the power yet ensure workable default behavior. ONE thing on my mind is INLINE nesting. Current *@@ ... @@ *prevents it. I'd like time to show how a markup inline of »...« could support it and correct closure of inlined elements. So »tag-A ...»tag-B ...«« get closed correctly.
Best wishes TT > > - , 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/4c723799-af72-4dae-b2b9-22e612ac530ao%40googlegroups.com.
