Textpattern CMS support forum
You are not logged in. Register | Login | Help
- Topics: Active | Unanswered
Re: The direction of Textpattern 5
Will TXP5 generate HTML5?
Offline
Re: The direction of Textpattern 5
joebaich wrote:
Will TXP5 generate HTML5?
The only barrier to using HTML5 with TXP 4.X is the acronym element generated by Textile. Textpattern gives me such fine-grain control over markup that I use HTML5 anyway— peppering the articles with abbr instead of depending on Textile’s ABC(Always Be Closing) pattern is a small price to pay.
Edit: Use an apostrophe to indicate possessive. Oops! [HT to Strunk & White]
Last edited by johnstephens (2011-01-21 16:59:45)
Offline
Re: The direction of Textpattern 5
hcgtv wrote:
I would eliminate Form Types though, they serve no purpose
I disagree up to a point. Without types, you are doomed to one loooong list of Forms. Scroll city. There’d be no mechanism for tucking away groups that you’re not working on, and the only way you could move them about would be by renaming them, which is a pain unless you’re super anal about a naming convention.
I see groups as a nice way to logically subdivide your Forms into more manageable chunks, however I don’t agree with having fixed names for the groups. The default install should contain one or two groups to house the scant few default forms that we actually need, and you should be able to add / rename as many groups as you see fit to suit your site. Since the groups offer no functional distinction this is not a major issue, especially if the useless ‘Preview’ button is removed from the Forms tab.
The smd plugin menagerie — for when you need one more gribble of power from Textpattern. Bleeding-edge code available on GitHub.
Hire Txp Builders – finely-crafted code, design and Txp
Offline
Re: The direction of Textpattern 5
hcgtv wrote:
Personally, I like the distinction of Page and Form. I would eliminate Form Types though, they serve no purpose other than to confuse at first.
I’d like to go the other direction and add more power to form types.
Code is topiary
Offline
Re: The direction of Textpattern 5
Custom form types would be awesome. Right now, I use the aforementioned anal naming convention to handle this.
Offline
#21 2011-01-21 17:08:31
- net-carver
- Archived Plugin Author
- Registered: 2006-03-08
- Posts: 1,648
Re: The direction of Textpattern 5
John
re: Textile’s acronym tag — there are changes afoot (it won’t take place immediately though) to allow a certain amount of customisation in textile. The first step — allowing an extendible block markup scheme is already a feature candidate.
abbr support is now on the repo issue tracker as issue 15. Please add to the issue if you have specific examples of how you want abbr markup to work and the output it should produce.
— Steve
Offline
Re: The direction of Textpattern 5
johnstephens wrote:
joebaich wrote:
Will TXP5 generate HTML5?
The only barrier to using HTML5 with TXP 4.X is the
acronymelement generated by Textile. Textpattern gives me such fine-grain control over markup that I use HTML5 anyway— peppering the articles withabbrinstead of depending on Textile’sABC(Always Be Closing)pattern is a small price to pay.Edit: Use an apostrophe to indicate possessive. Oops! [HT to Strunk & White]
Thanks John, I was thinking more along the lines of having the self closing / not present in the generated html tags (or an option to do that). Phil Wareham outlined the requirement quite well recently.
Offline
Re: The direction of Textpattern 5
artagesw wrote:
This is the approach Escher takes.
Is that a recommendation to switch to using Escher or is this something that is planned for TXP5 as well? :)
See Escher namespaces. An “abc” namespaced plugin tag would be evoked as <txp:abc:plugin_tag />, for example.
Can this be extended even further. For example if an author ‘zem’ has multiple plugins, one of them being ‘contact’, could a user do this (taking ZCR as an example):
<txp:ns:zem:contact>
<txp:form>
<txp:email />
<txp:textarea />
<txp:submit />
</txp:form>
</txp:ns:zem:contact>
And what rules are set to avoid namespace collisions between TXP core and plugins? TXP4 has registered 3-char prefixes for plugin authors.
I was under the impression that GPL3 and GPL2 are compatible. Could be wrong though.
Is GPLv3 compatible with GPLv2?
No. Some of the requirements in GPLv3, such as the requirement to provide Installation Information, do not exist in GPLv2. As a result, the licenses are not compatible: if you tried to combine code released under both these licenses, you would violate section 6 of GPLv2.
However, if code is released under GPL “version 2 or later,” that is compatible with GPLv3 because GPLv3 is one of the options it permits.
Personally, I’d go for GPL3 or later if possible.
I am one of the those people, which is why Spark/Plug’s code cache ensures that all plugin code can be “included” instead of “evaled.”
Nice!
Offline
Re: The direction of Textpattern 5
joebaich wrote:
Thanks John, I was thinking more along the lines of having the self closing
/not present in the generated html tags (or an option to do that). Phil Wareham outlined the requirement quite well recently.
As I understand, using the / for self-closing tags is allowed in HTML5:
W3C HTML5 spec, 8.1.2.1 Start tags
Then, if the element is one of the void elements, or if the element is a foreign element, then there may be a single U+002F SOLIDUS character (/). This character has no effect on void elements, but on foreign elements it marks the start tag as self-closing.
Offline
Re: The direction of Textpattern 5
hcgtv wrote:
Think about it, if TXP5 is going to deviate substantially from what we’ve become accustomed to, and it may take a year to see the light of day, why not cut to the chase and start using Escher today?
Our intention is to preserve Textpattern’s unique character – the “secret sauce” that makes Txp what it is. Any changes we consider will take that goal into account. (I for one do not see eliminating such Textpattern concepts as front page, template-per-section, etc.)
Escher does not share this goal, and as a result, does some things quite differently. That said, it does have some features that Txp users have been demanding for some time. Many of these features will eventually find their way into Txp 5. If you need them now, or if you just want a taste of things to come in Txp 5 (feature-wise – not model-wise or UI-wise) I suggest giving Escher a spin.
Offline
Re: The direction of Textpattern 5
ruud wrote:
Is that a recommendation to switch to using Escher or is this something that is planned for TXP5 as well? :)
Neither. It is my personal preference, but the devs have not discussed it specifically.
ruud wrote:
Can this be extended even further. For example if an author ‘zem’ has multiple plugins, one of them being ‘contact’, could a user do this (taking ZCR as an example):
<txp:ns:zem:contact>
<txp:form>
<txp:email />
<txp:textarea />
<txp:submit />
</txp:form>
</txp:ns:zem:contact>
Certainly. I made a decision to not support nested namespaces in Escher 1.0 for simplicity of implementation. But there’s no reason it could be supported.
ruud wrote:
And what rules are set to avoid namespace collisions between TXP core and plugins? TXP4 has registered 3-char prefixes for plugin authors.
None. Conventions and/or registry will need to be created.
ruud wrote:
Thanks.
Last edited by artagesw (2011-01-21 18:46:37)
Offline
Re: The direction of Textpattern 5
Bloke wrote:
I see groups as a nice way to logically subdivide your Forms into more manageable chunks, however I don’t agree with having fixed names for the groups. The default install should contain one or two groups to house the scant few default forms that we actually need, and you should be able to add / rename as many groups as you see fit to suit your site. Since the groups offer no functional distinction this is not a major issue, especially if the useless ‘Preview’ button is removed from the Forms tab.
That’s what I’ve campaigning for, but waiting for TXP5 to see it happen does make one wonder why such a small change has to wait for an MVC paradigm shift. Right now, these types are hard coded in /include/txp_form.php, as in no plugin can change or add to them.
artagesw wrote:
Our intention is to preserve Textpattern’s unique character – the “secret sauce” that makes Txp what it is. Any changes we consider will take that goal into account. (I for one do not see eliminating such Textpattern concepts as front page, template-per-section, etc.)
Well until we see a roadmap, I don’t know what’s in store. As for Escher, I like the concepts you’ve programmed into it, the same way I like MODx. It’s just the amount of years I’ve dedicated to learning Textpattern that I don’t want to give up.
We Love TXP . TXP Themes . TXP Tags . TXP Planet . TXP Make
Offline
Re: The direction of Textpattern 5
hcgtv wrote:
It’s just the amount of years I’ve dedicated to learning Textpattern that I don’t want to give up.
If you’ve dedicated years to learning Txp, you should be able to adjust to Escher in a matter of days, if not hours. It’s different. But it’s not that different. ;)
Offline
Re: The direction of Textpattern 5
So Happy! about this direction I feel like a teenager again. Posted happy thoughts on the blog.
Since we are re-factoring a lot of shizzle under the hood. How’s about my triplet of pet ideas.
- Unlimited categories (heck call em tags if you like)
- Custom content types (possibly with associations and nesting).
- glz-ish style custom fields
Awesome News!
Offline
Re: The direction of Textpattern 5
mrdale wrote:
So Happy! about this direction I feel like a teenager again. Posted happy thoughts on the blog.
Since we are re-factoring a lot of shizzle under the hood. How’s about my triplet of pet ideas.
- Unlimited categories (heck call em tags if you like)
- Custom content types (possibly with associations and nesting).
- glz-ish style custom fields
Awesome News!
Escher has all of the above (well, not nested content types). Read into that what you may.
Offline