Images are 1st class citizens of TXP

maverick · 2010-07-19 17:46:43

I think I lean to keeping 0 (false) since everything else is.

My one immediate “but” thought is that txp tags are xhtml like (and have been promoted as such over the years). xhtml is supposed to be less programming language-like and more easy-to-read English like.

(Which I seriously doubt is much help to people who don’t find English easy to read).

In that sense, “off” and “on” are more english like than “0” and “1”.

Unless I’m confused (which could easily be the case), txp image height and width and css height and width are similar, related, interact with each other, but remain different creatures.

Tthe instinctive move from a uninformed user perspective is to approach them the same — both are dealing with an image, and with height and width. Which means that the expectation is “0” and “1” would function the same. Yet “0” functions differently. For non-programming designers and non-designers making their home website, using the programming paradigm seems unexpected/slightly disconcerting to the friendly xhtml paradigm.

However, for consistency sake, to make it function differently in the case would be even more disconcerting.

Gocom · 2010-07-19 19:30:17

maverick wrote:

My one immediate “but” thought is that txp tags are xhtml like (and have been promoted as such over the years). xhtml is supposed to be less programming language-like and more easy-to-read English like.

Yes, the tags indeed use XML like syntax, but the way the tags are used are far from HTML. Closer to progamming language that use XML like syntax than markup language.

Last edited by Gocom (2010-07-19 19:40:00)

uli · 2010-07-19 20:01:56

Sorry, guys, one last attempt. But then I’m off to save the planet (or do I want a Hummer beforehand?)

Bloke wrote:

I can’t see any reason for someone to go to the trouble of writing an image tag that didn’t display an image (i.e. willfully display an invisible image). Perhaps I’ve missed a use case somewhere…?

This is not the point. It’s not the point if there really is a use case or if someone only thinks he’s re-invented an image preloader. The point is to create a user interface that is generally unambiguous:

If we leave everything as it is now, width="1" would have the meaning of “turn on the use of image size values” plus “image-width is 1px”. That’s neither unambiguous nor does it mean “turn on the use of image size values”.

And it’s not Textpattern, intermingling numerals and booleans is not Textpattern, as far as I remember there’s nothing else than booleans wherever booleans are used.
Jukka, I agree that 0 is widespread used for off and thus it’s actually clear and unambiguous. I’m just in favor of not applying it exactly at a point where other numerals are used with different meanings. Textpattern is use_width="0" (or just a simple omit_width).

Bloke · 2010-07-19 22:48:41

uli wrote:

If we leave everything as it is now, width="1" would have the meaning of “turn on the use of image size values” plus “image-width is 1px”.

I totally get where you’re coming from. And if Textbook indicated that the attribute type was boolean I’d agree 100%. But the attribute type is going to be integer and it will state something like:

width: manually specify the width= HTML attribute in the <img> tag. Omit it to use the width stored in the database, or set it to 0 to remove the attribute entirely from your markup

That’s fairly unambiguous in my book, but it can probably be improved.

as far as I remember there’s nothing else than booleans wherever booleans are used.

… except the widespread limit attribute (also of type integer). Specifying a limit of 0 doesn’t mean “show me no results” it means “show me all results” (i.e. no limit). I see the limit attribute in the same bracket as the width/height here. Why would you go to the trouble of specifying a tag to display something and then say “…but don’t get any rows from the database”? (EDIT: incidentally, a different use case from pgonly="1"!)

Hence, TXP has assigned a special meaning to the ‘0’ case. In theory, it should be limit="all" or limit="none", limit="9999" or, as Adi pointed out earlier, something like limit="-1". I guess we have to draw the line somewhere and decide which is less confusing for users:

to remember to set it to some arbitrarily defined English word, which may differ from tag to tag
to use the well-defined (if slightly programmery) semantics of 0’ to do something slightly different from its boolean counterpart when attributes are of type Integer?

As you can probably tell I’m in camp #2 but then I’m a self-confessed geek.

Last edited by Bloke (2010-07-19 22:55:24)

uli · 2010-07-19 23:26:20

I’ve self-selected adhesive across my mouth :))

Gocom · 2010-07-19 23:26:28

More aliases? Conditional to every tag? Lol. I’m not giving away my true/false & 1/0.

Bloke wrote:

… except the widespread limit attribute (also of type integer). Specifying a limit of 0 doesn’t mean “show me no results” it means “show me all results” (i.e. no limit).

Well, I personally have always read the 0 as false. Meaning that limit="0" translates into limit is false. It showing all makes sense, and I really can’t think any TXP tag that doesn’t use 0 as false.

Last edited by Gocom (2010-07-19 23:27:04)

gomedia · 2010-07-20 01:17:46

A quick tangent …

Bloke wrote:

… except the widespread limit attribute (also of type integer). Specifying a limit of 0 doesn’t mean “show me no results” it means “show me all results” (i.e. no limit).

Gocom wrote:

Meaning that limit=“0” translates into limit is false.

Er, I wanted there to be a no limit option for article tags but I don’t think it ever happened.

jsoo · 2010-09-28 11:40:16

Bloke wrote:

to turn off both height and width you use width="0" height="0". If either are omitted you get the size from the database being output.

Reviving this now that 4.3.0 rc1 is out. I’m not entirely clear from the old discussion what the final decision on intent was to be, but I see that in rc1 width="0" height="0" does indeed suppress those attributes in the final HTML output. In image and article_image. But not in thumbnail. Any reason these shouldn’t all behave the same way?

[Code-wise, reason for the difference is that thumbnail uses an empty($width) check, whereas the other two use $width=="" checks.]

jsoo · 2010-09-28 11:47:35

Great to have pagination with image_list. And the new image context, hence cool category URLs such as:

http://example.foo/category/image/bar/

But there’s a wee issue with pagination with URLs such as the above. Actually, it’s a more general issue than that. The above URL is image context, hence an article tag returns nothing. But you’ll get a does not contain a txp:article tag notice if you don’t have an article tag for that context. You can suppress the notice by sticking in the article tag anyway. But then pagination doesn’t work.

I haven’t looked into it enough to glean what might be a reasonable solution.

Bloke · 2010-09-28 12:24:10

jsoo wrote:

You can suppress the notice by sticking in the article tag anyway. But then pagination doesn’t work.

Hmmm, yes that could be a potential problem. But I just tried this on my default Page and removed all txp:article tags:

<txp:if_category type="image">
   <txp:image_list limit="3" pageby="limit">
      <txp:thumbnail />
   </txp:image_list>
</txp:if_category>

I didn’t get the warning — even in debugging mode — which is curious as I’d have expected it to do so. Maybe it’s just my installation though and I need to try it on a clean install. Does that work for you or do you still get the warning?

width="0" height="0" … Any reason these shouldn’t all behave the same way?

Erm, nope. I thought I’d made them all the same, d’oh. Good catch, thanks I’ll fix that.

jsoo · 2010-09-28 13:02:00

Bloke wrote:

I didn’t get the warning — even in debugging mode — which is curious as I’d have expected it to do so. Maybe it’s just my installation though and I need to try it on a clean install. Does that work for you or do you still get the warning?

Reeeeally stupid question, but did you check it in a suitable image-contexty URL? Because I just copied the exact code above into a template and triggered the error.

Bloke · 2010-09-28 13:17:44

jsoo wrote:

did you check it in a suitable image-contexty URL?

Yep. site.com/category/image/my-cat. Must be my install then, being a mashup of about 50 different environments. Curious why it’s suppressing the error: that’s good, but I don’t know why!

I’ll try again in a clean installation. Perhaps it’s time to lose that silly warning, but that in itself unfortunatley doesn’t solve the problem of what happens if you have an article tag on the same page as a context list. My guess is the problem stems from the fact that pagination is on by default for articles but off by default for everything else, and articles take precedence over other content types. Pants.

Bloke · 2010-09-28 13:34:20

Unsatisfactory solution #1: if you put <txp:article pgonly="1" /> after the <txp:image_list /> tag, the error is suppressed and the navigation works.

I lied when I said articles take precendence, the first pagination context encountered on the page takes precedence: every time the paging array is updated it is first checked to see if pagination has already been set up: it’s bypassed if so.

Longer term I kinda half figured that a single pagination array would bite us. You can see how I got round it in smd_gallery by assigning a unique code to each gallery instance so you can page independently of other galleries on the same page, and indeed of TXP. We could probably do with either making discrete pagination arrays for each context type or one multi-dimensioned array — with a dimension for each type. Or something like that. Ideas on a postcard to the usual address…

jsoo · 2010-09-28 13:41:12

Bloke wrote:

Unsatisfactory solution #1: if you put <txp:article pgonly="1" /> after the <txp:image_list /> tag, the error is suppressed and the navigation works.

I tried that earlier but had no success; will try again with a more stripped-down template to see what’s going on.

Edit: yep, works. I don’t know what I did wrong the first time.

I lied when I said articles take precendence, the first pagination context encountered on the page takes precedence: every time the paging array is updated it is first checked to see if pagination has already been set up: it’s bypassed if so.

Thought so; I had to dig into this a while back w/r/t my pagination plugin.

Longer term I kinda half figured that a single pagination array would bite us.

Maybe, but this is a pretty small problem. Off the top of my head I think just adding a context check to /publish.php:537 (where my error message arose) would do it:

if (!$has_article_tag and $pretext['context']=='article' and  // ...

Last edited by jsoo (2010-09-28 13:43:45)

Bloke · 2010-09-28 15:38:26

jsoo wrote:

adding a context check to /publish.php:537 (where my error message arose) would do it:

Makes a lot of sense. Committed, along with the thumbnail width/height fix. Many thanks, sir.

Textpattern CMS

Textpattern CMS support forum

#91 2010-07-19 17:46:43

Re: Images are 1st class citizens of TXP

#92 2010-07-19 19:30:17

Re: Images are 1st class citizens of TXP

#93 2010-07-19 20:01:56

Re: Images are 1st class citizens of TXP

#94 2010-07-19 22:48:41

Re: Images are 1st class citizens of TXP

#95 2010-07-19 23:26:20

Re: Images are 1st class citizens of TXP

#96 2010-07-19 23:26:28

Re: Images are 1st class citizens of TXP

#97 2010-07-20 01:17:46

Re: Images are 1st class citizens of TXP

#98 2010-09-28 11:40:16

Re: Images are 1st class citizens of TXP

#99 2010-09-28 11:47:35

Re: Images are 1st class citizens of TXP

#100 2010-09-28 12:24:10

Re: Images are 1st class citizens of TXP

#101 2010-09-28 13:02:00

Re: Images are 1st class citizens of TXP

#102 2010-09-28 13:17:44

Re: Images are 1st class citizens of TXP

#103 2010-09-28 13:34:20

Re: Images are 1st class citizens of TXP

#104 2010-09-28 13:41:12

Re: Images are 1st class citizens of TXP

#105 2010-09-28 15:38:26

Re: Images are 1st class citizens of TXP

Board footer