In any version of Freeway, it can be tempting to draw form elements where you want them to appear. After all, that’s what Freeway encourages you to do in all cases. But for forms, this can introduce an enormous deficit in the final built site’s code. Layers are rendered in the page as individual DIV elements. (A DIV, or Division, is an undifferentiated HTML element. It means nothing, and in a normal Freeway layout – not inline or processed to be inline as with RPL – it occupies a certain amount of space alone on a layer all by itself.) These DIVs may appear to have a logical order on the page, but in the final code, they may be miles apart and out of order. Worse, if you draw another HTML box and fill it with some styled text to describe a particular form field or group of fields, that description may be immediately left of the field, yet a thousand miles from the field it describes in the actual code.
Who cares? I mean, it looks right… Well, computers that try to read and index the Web care. And particularly, my dear friend Beverly’s computer cares, as it rasps out the names of the fields in a mechanical voice and tries in vain to describe them further. Since they don’t have proper labels, only undifferentiated text blocks somewhere else on the page, the fact that Beverly suffers from end-stage macular degeneration prevents her from knowing any more about your form than the bare names of the form fields themselves. Not even the order of the elements can be predicted, since they may look correct visually, but are actually laid out in code in some random order predicated by the order which you added them to the field – or subsequently used the layer-stacking controls to move to front or back.
So what’s the answer? Semantic layout. Or the nearest thing that Freeway offers – an invisible table to hold the form elements. If you make a two-column by [number of fields]-row table, and insert your form elements into it as inline elements, with the description on the left column and the field itself on the right, then Beverly’s ancient copy of JAWS can read the table out loud to her in order, and in a structural format that mirrors the actual content of the page. This is not the same thing as the bad old days of using tables for layouts, reinforcing them with clear GIF spacers – that was and is rightly frowned upon, for the same reason: a table is meant to hold tabular data, where the structure MEANS something. I would argue that in this case, the apposition of label to field MEANS something.
Now that the lesson is out of the way, and now that you’ve gained some insight into why we do certain things the way we do, I can tell you another secret: if you apply the cart setup Action to this table, all of the fields within it will be properly contained by the form tag, and you won’t have this problem any more.
As TIm said earlier, the fact that it worked at all in earlier versions of Freeway is more of a fluke than an actual sign of how things were supposed to work. If Freeway < 6 was working correctly, you should have gotten the same broken behavior that you are now seeing in 6. You were lucky then – not correct – in other words.
Walter
On Dec 7, 2013, at 9:18 AM, A . Randolph wrote:
I would still like to know what it is in 6 that is causing a headache though for the order forms I made to not work.
freewaytalk mailing list
email@hidden
Update your subscriptions at:
http://freewaytalk.net/person/options