An update on 5.b3 and my previous emails regarding the use of em and % for html and table items.
- Page width and height are ignored in 5p3 (go looking for your defined page width in the code - it’s not there!). However it’s not obvious to the user that there actually is no defined height and width. To get the old Freeway functionality (of defined page width and height) one must put a div inside the page of the dimensions you want, and put everything else inside this. I’m not saying this is a bad thing, I actually think this is a step forward. I very much prefer to start with undefined height and width. It permits the use of percentage values for widths much more easily than before.
But it is confusing to the user who expects a certain width, having set that, or tries to set a percent height (percent of what? - there is no enclosing div height to get a percent of).
Wouldn’t it be more intuitive to permit empty values for page height and width, so that (a) if width and height are specified by the user, a div of those dimensions encloses all the objects on the page, yet also (b) allow the user to set page width and height to empty or zero values, to accomodate the user that doesn’t want an enclosing div of specified dimensions???
-
likewise, overall table heights and individual table row heights STILL can’t be set to ‘no value’ - ie no height - even if they contain text. Softpress have finally done this for html boxes. It is really nice if the height of a table row automatically expands to the height of the enclosed text - just as it is a good thing for html boxes. C’mon Softpress!
-
The same applies for table column widths, which should also be able to be set to ‘no value’. They then compress to ‘nothing’ or the width of the enclosed text. None of the beta’s so far has addressed this failure to provide a basic and useful html formatting feature. Since html 1.0 it is possible to make a table that has NO width or height parameters - but something as basic as this is still not permitted in Freeway. Why not???
-
Percentages or ems still can’t be used for table cell dimensions, despite being perfectly useful and legal coding practice. Ems and % permit truly liquid layouts - without them, flexible tables become much less easy to construct. Once again, they can be used for html boxes - why not for tables??? There are some things that only tables are good for (eg, a table of numbers in a report, surprisingly). To make this table look good regardless of user font size and page size, it is really helpful to be able to use ems or % and to set some rows or columns to zero or empty dimensions. Thank goodness for the remove dimensions action, but surely a Pro app would let a user do this.
-
if ems are used as the units for the width of an empty html box, they are drawn in Freeway’s main screen as if 1 em = 1 point. It turns out that Freeway sets the div-style font-size for an empty html box to 1pt. Why 1pt? Freeway should assume 12 points for the default font size, because often that’s what it will be. Why it assumes 1 point I don’t know. A user’s default font size will normally determine the size of an em. So if ems are used, it’s best to use them for every dimension. If you can use ems for every dimension, then your page looks great regardless of user font size. But pre-setting the em value for an empty html box to 1pt is plain silly. On the other hand, and empty text box with dimensions set in ems looks the same in Freeway and in the browser, because the browser will override the default em value (their browser’s font value) with the font-size for the enclosing div, which is set to 1. So although they look the same now, they are nothing like the ‘normal’ size of an em, at least 12 times too small!
-
As soon as the user types anything into a text box, Freeway no longer sets the font-size of the div to 1 px. BUT Freeway still draws it on-screen as if the font-size was still one point (ie with 1 em = 1px), whereas the browser now uses 12 or 14px, so they two no longer look the same. Freeway is doing it wrong, not the browser! There seems to be no way around this, so USING EMS FOR HTML BOXES REMAINS BROKEN.
-
The ‘smart’ way to override this is to go to extended attributes the div-style to set a font-size for that div to something you want the user to see, ie 14px or something. BUT THIS WON’T WORK because of how Freeway sets type styles! The result is that setting font-size for divs doesn’t fix the problem and worse still is ignored in Freeway.
-
To test how ems for divs don’t work in Freeway, make two html boxes each containing some text with different background colours, one vertically above of the other. Set one to be 240px wide and the other 20 em wide. If your browser’s default font is 12 point, then they will be equal width in the browser, despite looking totally different in Freeway. Increase the browser’s font size, and the em specified box will increase in size along with the enclosed text, while the px specified box does not.
Strictly the em is the point size of the enclosing div; the browser’s font size being the ultimate enclosing div. In the above test, try putting a copy of the same two html boxes as children of a parent div, and set its extended div-style to font-size 20px. Note how the html boxes inside the em-defined-font-size box now uses 20px per em, whereas those on the page (outside that div) still use the browser’s default. And note that the result in the browser is totally different from what we see in Freeway.
Freeway can easily calculate how em dimensions should appear on-screen, just as Safari does. Freeway should, in the document setup, have the ability to set the default font size and typeface (as one would in a browser). This value should be used as the default value for an am (as it would be in a browser). Then, every div should have the option to set the font-size for the div, and this should apply to an em-specified objects within it and to any plain text within it (as it would in a browser). It’s not that hard, really. It remains a mystery to me why this is not made to work properly in Freeway. Ems are fantastic for liquid layouts because enclosing boxes grow as required with changes in user’s font size.
Also the cutting/editing/clearing links issues I mentioned before are still not fixed in 5p3.
And there are no new CSS attributes like underline or border in the styles options; seems to be the same as v4.
And no ‘help’ on how to use actions within the actions interface.
Is there a document listing what has been changed from 5p2 to 5p3?
Sorry to rant on about these things. I am feeling that they won’t be addressed in v5 (as they never have been in any previous update).
Please please Softpress, give us a pro app with pro dimensioning options. It’s about time. We should NOT have to resort to third party actions to override Freeway and resort to ‘extended code’ all the time to achieve simple, frequently used and essentially basic outcomes.
Freeway says you don’t need to understand code. That’s plain misleading, in my opinion.
Chris.
Freeway5beta mailing list
email@hidden
Update your subscriptions at:
http://freewaytalk.net/person/options