Page 2 of 2

Re: CMSimple_XH 1.6 :: handling of config and text forms

Posted: Tue Mar 05, 2013 5:33 pm
by cmb
cmb wrote:I thought that ' isn't a generally accepted XHTML entity. But I just looked that up, and obviously I was wrong.
Indeed ' is a valid XHTML entity, but it is invalid in HTML 4.01; see http://www.w3.org/TR/REC-html40/charset.html#h-5.3.2. That explains the name ENT_COMPAT. Even if I don't consider any browser to have problems with ', we may stick with ENT_COMPAT for HTML 4.01 compliance (and double-check, that we use double-quotes around attribute values handled with htmlspecialchars()).

Re: CMSimple_XH 1.6 :: handling of config and text forms

Posted: Wed Jun 12, 2013 1:29 pm
by cmb
I have now implemented XH_message() and added the styles which Holger suggested earlier (r594). You may have a look at the API--might be improved. And of course the styling needs some improvements (maybe a background image).

You can see it in action under "Settings", when you delete the content or restore a backup (r595).

Re: CMSimple_XH 1.6 :: handling of config and text forms

Posted: Fri Aug 02, 2013 12:26 am
by cmb
cmb wrote:And of course the styling needs some improvements (maybe a background image).
I gave it a try (r803):

[ external image ]

What do you think?

For reference: the colors are taken from http://demos.pixelworkshop.fr/showcase/typography.php (thanks to learnandcode for the link); the images are from http://www.small-icons.com/packs/16x16- ... -icons.htm.

Re: CMSimple_XH 1.6 :: handling of config and text forms

Posted: Mon Aug 19, 2013 12:38 pm
by cmb
cmb wrote:You may have a look at the API--might be improved.
I have now changed the interface to take a format string directly (r881). This makes the function more flexible.

Re: CMSimple_XH 1.6 :: handling of config and text forms

Posted: Fri Sep 04, 2015 10:14 pm
by cmb
After XH_message() has been implemented more than two years ago, what's left of this idea is the general handling of an xh_success parameter. I'm still not sure how this would be handled best, and as I don't see any immediate need for it, I suggest to drop the idea. Core and plugin functionality which requires such a query parameter can easily handle the display for themselves.