Docs site refresh effort

gaekwad · 2021-01-20 13:15:37

Sorry I dropped this, real life stuff got in the way and threw me off course a bit.

Bloke wrote #328259:

Currently (as of Txp 4.8.4) break is a per-tag attribute, and is thus included in the common presentational atributes include file. As of 4.8.5 due imminently, break becomes global so it’ll have to move to the global atts include file.

[…]

It’s kinda naughty to document something that’s not in a release yet but, y’know, saved effort and all that. Thoughts?

+1 for doing it. No harm in doing it now and noting that changes happened in 4.8.5, since there will inevitably be a long tail of people running pre-4.8.5 anyway.

Bloke · 2021-01-20 15:56:18

Oki doke, done. Just gotta decide what the best default value is for break. Traditionally it’s been ‘br’ but now it’s global I’m not so sure if that’s still the case, as it may be unset by default.

etc · 2021-01-20 21:37:08

Bloke wrote #328261:

Just gotta decide what the best default value is for break. Traditionally it’s been ‘br’ but now it’s global I’m not so sure if that’s still the case, as it may be unset by default.

We should first agree on what the global break should do. For example, in <txp:site_name break="br" />?

colak · 2021-01-21 07:38:12

li is a more common break for menus such as section_list and related_articles but I think that if the attribute becomes global, unset will be the list invasive.

Re Oleg’s very valid comment. I can see issues with a number of tags such as txp:die, if_yield, in fact most of the if_ tags, etc. I’m wondering if tags could be divided into front end presentation for the ones which actually render some content, and conditional for the ones that test the context. site_name is a strange hybrid tag which can be used both in the head and the body of an article, txp:css though is the one which might help into making the decision.

etc · 2021-01-21 09:16:15

colak wrote #328295:

li is a more common break for menus such as section_list and related_articles but I think that if the attribute becomes global, unset will be the list invasive.

… I’m wondering if tags could be divided into front end presentation for the ones which actually render some content, and conditional for the ones that test the context.

Global attributes have no default value, one must call them explicitly. Also, they are (mostly) tag-agnostic. Actually, global break has little value per se: why would one want to break the site name? It was introduced mainly as a counterpart to fields="list(field)" article attribute. You can try this example with and without wraptag="ul" break="li" attributes to see how they work:

<txp:article_custom fields="authorid, list(title)">
    <h3><txp:author /></h3>
    <txp:title wraptag="ul" break="li" />
</txp:article_custom>

Bloke · 2021-01-21 09:36:31

All good. I was thinking in terms of the default we set in the docs include file. Currently it’s br. When you call the include, you can optionally override this default by passing break="some thingy" into the include template. That will override the default value that displays in the tag for that attribute.

We often need this for class. It’s usually empty and takes whatever you give it, but sometimes the class is preset to be the name of the tag. So you can pass this in as an exception when the tag page is built.

What I don’t want to do is have the default for break set to ‘br’ and then find nearly every single include from every tag page needs to override this. I’d rather set the include to use the most common break attribute value we use in core, and then override it if necessary for a handful of tags. Make sense?

etc · 2021-01-21 09:49:35

Ah, got it. Well, br seems to be the most common one among the tags that accept it natively, closely followed be the empty string.

Textpattern CMS

Textpattern CMS support forum

#46 2021-01-20 13:15:37

Re: Docs site refresh effort

Bloke wrote #328259:

#47 2021-01-20 15:56:18

Re: Docs site refresh effort

#48 2021-01-20 21:37:08

Re: Docs site refresh effort

Bloke wrote #328261:

#49 2021-01-21 07:38:12

Re: Docs site refresh effort

#50 2021-01-21 09:16:15

Re: Docs site refresh effort

colak wrote #328295:

#51 2021-01-21 09:36:31

Re: Docs site refresh effort

#52 2021-01-21 09:49:35

Re: Docs site refresh effort

Board footer