Input on an Open Source Project

david64

Hi,

I have recently released an open source project as open beta. It is an XML transformation language, which uses a PHP parser to automate, simplify and standardise creating and processing HTML forms. Features include things such as automatic population of form fields and simplistic out-of-the-box validation.

I am looking for people to have a dabble with it for general ideas, PHP code over-viewing as well as finding any potential bugs. However, I do believe it is quite stable. I am already using it for my own sites.

You can find the main page here:

http://semlabs.co.uk/products/xfl
Docs: http://semlabs.co.uk/docs/xfl
Demos: http://semlabs.co.uk/docs/xfl/demos

effim

Have you seen the Zend Framework? They already have Zend_Form which allows you to create forms via PHP, creating a render script (optional), and attaching filters and validators. Check it out here: http://framework.zend.com/manual/en/zend.form.html

david64

Yes. I saw that, but I didn't like the way they were using to construct the forms. I wanted something that was XML based.

effim;10914700 wrote:
Have you seen the Zend Framework? They already have Zend_Form which allows you to create forms via PHP, creating a render script (optional), and attaching filters and validators. Check it out here: http://framework.zend.com/manual/en/zend.form.html

Weedpacket

Have you seen the XForms specification?

Forms are an important part of the Web, and they continue to be the primary means for enabling interactive Web applications. Web applications and electronic commerce solutions have sparked the demand for better Web forms with richer interactions. XForms 1.0 is the response to this demand, and provides a new platform-independent markup language for online interaction between a person (through an XForms Processor) and another, usually remote, agent. XForms are the successor to HTML forms, and benefit from the lessons learned from HTML forms.

Further background information on XForms can be found at http://www.w3.org/MarkUp/Forms.

david64

Yes, I am familiar with XForms. I was not keen on the methodology though. You can produce forms with much less code using XFL than XForm, particularly complex repeating forms which become really difficult in XForms, but are simple using XFL.

effim

I took a browse through your docs and it looks like you're using some HTML form elements in potentially non-standard ways. For example, you're closing input tags with </input> instead of closing the tag with " />" as should be done for XHTML, but not HTML. Also, you're using the name attribute on your inputs, which isn't valid XHTML (id should be used instead. Finally, you're using <button> instead of <input> as a submit button even though it's much more typical (and semantic) to use <input type="submit">.

I'd review your code output and make sure it's as flexible as possible. There's no sense in having a flexible form handler with restrictive output.

david64

effim;10914825 wrote:
I took a browse through your docs and it looks like you're using some HTML form elements in potentially non-standard ways. For example, you're closing input tags with </input> instead of closing the tag with " />" as should be done for XHTML, but not HTML.

You can use input tags like <input></input> in non-XHTML documents. For example in XSL you can do something like this:

<input>
<xsl:attribute name="id">some-id</xsl:attribute>
</input>

and it will output

<input id="some-id" />

Same with XFL. All inputs will be output self-closing. If you look at a live demo, you can see how input tags are output correctly in HTML. Having <input></input> in non-HTML documents is not invalid. They are transformed to self-closing by the XML parser, libxml2.

effim;10914825 wrote:
Also, you're using the name attribute on your inputs, which isn't valid XHTML (id should be used instead.

Do you have any reference on that? I can't find any info on it. I checked the XHTML 1.0 and 1.1 Transitional and Strict DTD and the name attribute is still defined there. In addition, I tried making a form with just id and it didn't work - not even in Amaya.

effim;10914825 wrote:
Finally, you're using <button> instead of <input> as a submit button even though it's much more typical (and semantic) to use <input type="submit">.

Personal preference - Button uses less CSS. You can use whatever buttons you want.

effim;10914825 wrote:
I'd review your code output and make sure it's as flexible as possible. There's no sense in having a flexible form handler with restrictive output.

Output is valid XHTML.

effim

david64;10914829 wrote:
You can use input tags like <input></input> in non-XHTML documents.

I'm referring to your docs which show an HTML sample output.

http://semlabs.co.uk/docs/xfl/creating-a-form

david64 wrote:
Do you have any reference on that?

http://www.w3.org/TR/xhtml1/#diffs
http://www.w3schools.com/Xhtml/xhtml_syntax.asp
http://codex.wordpress.org/HTML_to_XHTML#ID_and_NAME_attributes

Technically it's "valid", but it's deprecated.

david64

I'm referring to your docs which show an HTML sample output.

http://semlabs.co.uk/docs/xfl/creating-a-form

Thanks. Shall fix that.

Re. the id - name thing - are you sure about this? The only place I can find that actually says that you should use id instead of name on form elements is that WordPress link you sent over. On the name-id thing, the spec at w3.org says "elements listed above" in reference to the elements a, applet, form, frame, iframe, img, and map.

It is puzzling as the only valid characters for id attributes are a-z, 0-9, (full-stop), (hyphen), (underscore) and (colon). So that would mean collections of elements are invalid XHTML like:

<input id="colour[a]">
<input id="colour[b]">

I've checked through the DTDs of XHTML 1.* and HTML 4 and the name attributes of a, img and form have changed from CDATA to NMTOKEN, while input, textarea and select's name attribute have remained as CDATA, which suggests to me that the name-id change is not indented from input etc. Hence why no browsers (at least none I have) support this.

http://www.w3.org/TR/xhtml1/dtds.html#a_dtd_XHTML-1.0-Strict
http://www.w3.org/TR/REC-html40/sgml/dtd.html

effim

david64;10914845 wrote:
Re. the id - name thing - are you sure about this? The only place I can find that actually says that you should use id instead of name on form elements is that WordPress link you sent over. On the name-id thing, the spec at w3.org says "elements listed above" in reference to the elements a, applet, form, frame, iframe, img, and map.

I'm not sure, no. I actually haven't put together any forms since reading about the deprecation, and I didn't catch the above listed elements. I'd imagine that if they were going to deprecate the attribute all together for those elements that they'd go ahead and do away with it.

Honestly, it shouldn't matter anyways. XHTML 2 is dead in the water, so we'll end up using HTML 5 in a year or two anyways. The name attribute is here to stay, I suppose!

For the record, it's actually invalid to use the name tag on anchors like previously was done for page bookmarks. Instead, ids are used, and they're supported by most browsers. 😉

david64

effim;10914850 wrote:
Honestly, it shouldn't matter anyways. XHTML 2 is dead in the water, so we'll end up using HTML 5 in a year or two anyways. The name attribute is here to stay, I suppose!

I read a while back that the "release date" for XHTML2 is going to be Dec 2012 and then there will probably be a year or 2/3/4/5 for propagation and catching up of Microsoft 😐

Oh, no. It's next year: http://www.w3.org/MarkUp/xhtml-roadmap/#schedule

Weedpacket

Just to clarify for other readers:

The name= attribute on <input> elements is not deprecated in XHTML 1, and still means the same thing that it means in HTML. It is deprecated on <form> elements in both document types. (See the HTML 4.01 specification, sections §17.2 - §17.4; particularly the second line of §17.2, and the lines describing the name= attribute for <form> and <input> elements respectively in the other two sections). The definitive positions wrt XHTML 1 are the DTD entries for form and input elements.

Incidentally, HTML 5 as it currently stands also use the name= attribute to name <input> elements, while XHTML 2 uses XForms instead (where the closest analogue is the ref= attribute).

The id= attribute provides a document-unique identifier for the element, while the name= attribute names the form field the <input> element represents (or, in the case of radio buttons particularly, the form field represented by multiple <input> elements - do that with an id!). Quite different beasts, in other words.

It was using the same attribute ("name") for different purposes (naming an element and naming a form field), and using different attributes ("id" and "name") for the same purpose (naming an element) that the deprecation is intended to fix. The XHTML specification notes that some older browsers still get them confused when XHTML is served as HTML, and end up using the wrong one in some situations, which causes problems if they have different values. This issue and the issue of what type of value the attributes can contain is addressed in appendix C.8. The upshot of that discussion is that id="foo[a]" is illegal as david64 says (both in XHTML and HTML), name="foo[a]" is legal in <input> elements, and illegal in <form>, <a> and the other elements listed there (where the whole attribute is deprecated anyway) because they would be illegal values in id= attributes.