RFC: core attributes

colak · 2016-11-09 13:57:50

Hi Oleg

smd_thumbnail for example makes use of the class attribute.

In the past there were a number of plugins which enhanced article_lists and they were using the wraptag and break attributes.

But as I said, I may not have fully understood.

etc · 2016-11-09 14:42:17

Thanks, Yiannis. Yes, many plugins accept wraptag attribute, but they all (or not?) use it in the same way: wrap the output in wraptag if given. But if you pass wraptag="" to smd_thumbnail, it does not wrap the output, right? My idea is the following: when you call <smd_thumbnail wraptag="p" break="br" class="thumb" ... />:

the parser detects wraptag="p" and class="thumb"
it keeps them for itself, calling <smd_thumbnail wraptag="" break="br" class="" ... /> instead (roughly speaking)
once smd_thumbnail returns its (unwrapped) output, the parser wraps it into <p class="thumb">...</p> block, as expected.

This way all tags (core and plugins) would automatically “accept” wraptag, without any change in their code. The question is whether all plugins already wraptag-aware treat wraptag="" as “no wrap”. Same for class and other potential core attributes.

Bloke · 2016-11-09 15:03:25

etc wrote #302803:

The question is whether all plugins already wraptag-aware treat wraptag="" as “no wrap”. Same for class and other potential core attributes.

A broad question!

For things like wraptag and class (and html_id, et al) that do something then I would expect most authors to handle empty cases the same way. But I know there are plugins I’ve written (zem_contact_reborn for example, although it’s not done on a potential ‘core’ attribute) where I deliberately set the default to null specifically so that I can detect if the user has supplied the attribute or not. That way I can take action in one of three ways:

User supplied a value: use it.
User supplied an empty value: a positive action on their behalf “I do not want this set”.
User did not supply the attribute at all: ignore the attribute entirely (if it was null) or apply the default if $atts had one.

For those reasons, when intercepting a global attribute at the parser level, I’d be inclined to pass wraptag=null class=null onto the plugin rather than wraptag="" class="" because then it’s as if the attributes don’t exist rather than “do exist but have been set empty”. I feel that might be more robust, but I can’t say for sure.

Does that make sense? Any downsides?

etc · 2016-11-09 15:32:34

Bloke wrote #302804:

… when intercepting a global attribute at the parser level, I’d be inclined to pass wraptag=null class=null onto the plugin rather than wraptag="" class="" because then it’s as if the attributes don’t exist rather than “do exist but have been set empty”. I feel that might be more robust, but I can’t say for sure.

Does that make sense? Any downsides?

It’s me, but when an attribute (say, wraptag) is not set by the user, I see it as “do what you deem appropriate with it”. And I can decide to wrap the output into something depending on context, other attributes, etc. But when I see wraptag="" it means the user expressly says “don’t wrap it!”

Bloke · 2016-11-09 15:36:41

etc wrote #302806:

when I see wraptag="" it means the user expressly says “don’t wrap it!”

Actually, you’re right. Ignore me. Passing "" makes way more sense.

etc · 2016-11-10 09:46:01

etc wrote #302799:

should we reserve few special attributes (wraptag, class, label, labeltag, not, ...) exclusively for core usage, hoping that there will be no clashes with plugins?

Ok, this will not work, unless we introduce tags attributes registration. Some plugin tags (like <txp:etc_search />) need wraptag and html_id to function. And if wraptag or html_id are empty or not set by the user, the tag generates them itself. The parser has no idea of what plugins need and can not do it for them.

Anyway, with <txp:evaluate />, wrapping will be easy:

<txp:evaluate test="wrapless_tag">
    <div id="some_id" class="some_class">
        <h3><txp:text item="some_label" /></h3>
        <txp:wrapless_tag />
    </div>
</txp:evaluate>

will output nothing if <txp:wrapless_tag /> is empty.

etc · 2017-03-25 23:10:15

For early adopters: I’ve made an attempt to introduce the global attributes (currently wraptag, class, html_id, atts, label, labeltag and escape) in this branch. Every tag (core or plugin) automatically accepts them now:

<txp:prev_title wraptag="h2" class="prev" html_id="prevtest" atts='rel="prev"' label="Previous" labeltag="h4"  />

should work fine, even if <txp:prev_title /> still ignores all attributes. So new plugins do not need to treat these common attributes, unless they do something unusual with them. But some very old plugins could not play well.

phiw13 · 2017-03-26 08:32:22

etc wrote #305034:

For early adopters: I’ve made an attempt to introduce the global attributes (currently wraptag, class, html_id, atts, label, labeltag and escape) in this branch.

Oh, that sounds nice! I‘ll have play with this next week.

But atts? That is new, right? Does that imply the ability to add attributes (such as aria-* or data-*)?

philwareham · 2017-03-26 11:41:47

Also as part of this patch Oleg has allowed JSON encodings via the escape="json" attribute. Needs testing.

etc · 2017-03-26 17:54:04

phiw13 wrote #305038:

But atts? That is new, right? Does that imply the ability to add attributes (such as aria-* or data-*)?

Not quite new, though I don’t remember which tags support it. And yes, you could add any attribute with atts, but it feels a bit dirty. We’ll decide on it later, atm it’s important to test the feasibility, as Phil says. Note that the tags already supporting wraptag, lable and escape should not be concerned by this change atm.

phiw13 · 2017-03-27 01:47:22

etc wrote #305044:

Not quite new, though I don’t remember which tags support it. And yes, you could add any attribute with atts, but it feels a bit dirty.

OK. I don’t often have a need to add attributes. Once I think I needed it, I ended up building the whole thing more manually and add the attribute with JS.

Note that the tags already supporting wraptag, lable and escape should not be concerned by this change atm.

Yeah, I figured that one out :-) When I have time later this week, I‘ll take your branch for a walk in the bushes, and play with tags that currently don’t support those global attributes (me will go checking the docs to verify that). Hmm, and see if the plugins in use don’t throw any kind of protest.

Textpattern CMS

Textpattern CMS support forum

#25 2016-11-09 13:57:50

Re: RFC: core attributes

#26 2016-11-09 14:42:17

Re: RFC: core attributes

#27 2016-11-09 15:03:25

Re: RFC: core attributes

etc wrote #302803:

#28 2016-11-09 15:32:34

Re: RFC: core attributes

Bloke wrote #302804:

#29 2016-11-09 15:36:41

Re: RFC: core attributes

etc wrote #302806:

#30 2016-11-10 09:46:01

Re: RFC: core attributes

etc wrote #302799:

#31 2017-03-25 23:10:15

Re: RFC: core attributes

#32 2017-03-26 08:32:22

Re: RFC: core attributes

etc wrote #305034:

#33 2017-03-26 11:41:47

Re: RFC: core attributes

#34 2017-03-26 17:54:04

Re: RFC: core attributes

phiw13 wrote #305038:

#35 2017-03-27 01:47:22

Re: RFC: core attributes

etc wrote #305044:

Board footer