I have a problem where I set the window background to one colour and the page background to another and the page background does not go to the bottom of my content. Anyone else having this same problem?
I’ve posted an example here: http://www.wyrless.com/colourtest/
Thanks!
John F.
http://www.wyrless.com/colourtest/
freewaytalk mailing list
email@hidden
Update your subscriptions at:
http://freewaytalk.net/person/options
By coincidence, I encountered this problem only yesterday.
I’ve temporarily (I hope) got round it by placing an HTML box with the colour I want over the page and stretching it as far down as needed. That’s clumsy and makes working on a page a bit awkward and so a proper fix would be welcome.
freewaytalk mailing list
email@hidden
Update your subscriptions at:
http://freewaytalk.net/person/options
Thanks Colin, I’ve been doing exactly that but as you say it is a bit clumsy. Hopefully a fix is on the way soon.
freewaytalk mailing list
email@hidden
Update your subscriptions at:
http://freewaytalk.net/person/options
I’ve posted an example here: http://www.wyrless.com/colourtest/
The only problem here is the Paradigm of the Page which has clouded your
thinking about this. The truth is, there is no Page – only something that
you want to make look and act like one.
#Freeway HTML Basics
The Page settings you apply in Freeway actually apply to an HTML Item (aka,
a div element) called PageDiv. Freeway automatically creates this PageDiv
element when you publish your page code from the app. PageDiv acts as a
parent container for all the other items you make… this is why drawing your
own parent item to act as a visible “page” is usually a bad idea as Freeway
has already done this for you.
###Workspace Does Not Equal Page
The work area in Freeway Pro looks like a page, and in many ways tries to
mimic a page with the (PageDiv) settings you make. It, however, is just a
Workspace – like a canvas for us to draw on. It is not a “page” in any
meaningful sense nor does it always accurately reflect the actual HTML
structure the app will create. More than anything else, It will help you
think of this are as the Freeway “workspace” and forget all this page
nonsense.
###Content and Containers
One thing we should notice about the behavior of the cyan-colored PageDiv
element in this example is that it is always the exact height of the
browser window. Change the browser window height and refresh the page, and
you can see the PageDiv element assumes the height of the browser window.
But because the text box (#item1) is longer than the browser window, we are
also able to scroll down below the PageDiv and see its end.
So why doesn’t the #PageDiv element stretch down to accommodate the #item1
element in the same way #item1 element stretches to accommodate the text it
contains? The answer has to do with something called the Flow of Elements.
###Position is Everything
Every div element (what Freeway calls “html items” and many others just
call a “box”) possesses a series of attributes (aka, styles) to describe it
– height, width, background-color… etc. One very important but often
overlooked attribute is position. Position not only tells the browser
where an item should be shown, but it’s relation to other items as well.
If you think of items in an html document as a string or “flow” of items,
you can see they all share something in common. They “flow” together…
becoming “parents” and “children” and “siblings” all in relation one to
another. However, it is possible to remove any item from that normal family
flow by using the very powerful position attribute value of absolute. And
it is this value of positioning that has been given to #item1 by Freeway
Pro.
###Restoring Relativity
With absolute positioning ascribed to #item1, #PageDiv behaves as if #item1
is no longer content which can affect its own flexible dimensions. If you
could change the positioning value of #item1 to relative you would see
the cyan area envelope the text.
But how can we do that, and why doesn’t Freeway do this for us already?
That last bit is harder to answer because I don’t understand just where the
developer’s strategy is leading us. Old-timers may correct me, but I think
at one time Freeway made every drawn item relative by default. Using the
inspector, you could change the position to a value of absolute or fixed.
As of version 6 at least (I still have 7 in a box until I finish my current
project, soon I hope) all drawn items are positioned as absolute, with
fixed the only other choice.
However, there is a relatively simple solution.
##Inline Construction to the Rescue
In recent years, many Freeway users have begun abandoning the traditional
‘draw and drag’ approach to building Freeway websites with a novel method
of construction called Inline Construction (or also Inflow or Box Model
Construction), mainly because html boxes (divs) would be inserted into
other divs in the same way you would insert a line of text. Not at all
WYSIWYG, this construction method is more in keeping with the Flow of
Elements of a document, using floats and margins and padding to position
everything in a relative fashion. In fact, Freeway Pro writes the style
code for inline elements using the relative value for the position
attribute.
###A Very Simple Fix
To make #item1 in this example an inline (and therefore, relative) item,
let’s first cut it out of the workspace with command-X (or the Edit menu if
you like). Then, insert the cursor into the workspace area (double-click or
select and Enter) so that you see the flashing text cursor (and the
paragraph symbol if you have invisibles enabled in your View setting, which
I think you always should, just as a matter of practice). Then paste the
#item1 element and voila – you have an inline construction! Publish and we
can now see that #PageDiv completely encapsulates the relatively positioned
#item1. Style #item1 with some padding and the faux-page look works
regardless of how much content you have (depending of course on the height
settings you give to the #PageDiv element).
##Summary
There is no fix to wait for… because, nothing is broken except our
understanding of what Freeway Pro is doing based on what WE think we’re
doing. There is a document flow, and understanding how the position
attribute affects that flow empowers us to greater control of our work. I
wish that I knew what Softpress has in mind, making absolute positioning
the default (I mean, who builds websites that way these days?) but having
embraced the inline concept I can only hope they will continue to
strengthen support for that method.
Cheers,
freewaytalk mailing list
email@hidden
Update your subscriptions at:
http://freewaytalk.net/person/options
Thank you for your incredibly well-worded essay on positioning, Ernie. Nicely said! I’ve been using Freeway since before version 1, so I can chime in on the historical aspects here. While I cannot explain some of these choices, I can at least point out what has come before, and from the perspective of a user, but not an in-house developer of the code tree, why they might have made some of these choices.
Freeway began life as a print DTP application named Uniqorn. It was a direct competitor to QuarkXPress during the 2.3.x version era of QXP, IIRC. Because it was “Steved” with the removal of QuickDraw GX from the Mac OS, and because Uniqorn had the ability to create Java “widgets” out of print page layouts (yes, this is what passed for trans-media design in the early- to mid-90s), while the developers of Uniqorn were casting about for something to do for a living, they were already primed for the Web as an output medium.
In any DTP application, there is a page model, and within that, an object model. Each object on the page may contain other objects (including text). This mapped pretty neatly to the dominant “layout” technique for Web in that day — invisible tables with clear GIF spacers.
Freeway 1 let you have the notion of a true WYSIWYG layout space, wherein you could draw things — even overlapping HTML items or graphics — and Freeway would simply create the mother of all tables to translate your layered workspace into a single, flattened table. This would often lead to some nasty issues of images being invisibly sliced and then dragged apart when text to their left or right was scaled by the browser, but even this was easily worked around by making a deeply nested table (drawing an HTML box, sending it to back, then nudging it with the arrow keys to make it one pixel larger right and bottom than the elements it was meant to “contain”).
Freeway 2 let you add independently-positioned “Layers” (named for the Netscape Navigator name for that feature), but these were difficult to integrate with the remainder of the page layout, since that was naturally done in a table in order to deal with the browsers of the day and their independent notions of font size, leading, and other basic typographic niceties. Fonts were still measured in +1, -1 keyword increments, as I recall. About the only thing I ever used layers for was to have a message slide into the page, using the then-revolutionary Move Layer Action to slide the div into the page from off-screen somewhere. Otherwise, they were still too new for the browsers of the day. Freeway 2 also introduced the idea of the inline table, and I recall many times making a single-cell table in order to create a nested inline element (since you couldn’t insert an HTML item in another HTML item until version 3) and using that to provide a captioned inset image within a run of text. That, and adding padding to the side of a photo in Photoshop so it wouldn’t crash into the text too awfully when floated left or right in a paragraph.
Freeway 3 introduced the Layers-First style of the Freeway we know today, as browsers had by then caught up to the brave new world of CSS for everything. This began to be a problem for long-term users, because the natural constraints imposed by a table-based layout were removed, but so too were the natural advantages of that layout technique (awful and non-semantic as it may have been). Table layouts are still to this day entirely unbreakable, which is why they remain in use in the harshest browser environment on Earth — e-mail. I cannot even begin to imagine how many answers I have posted to FWTalk have dealt with layers sliding over other layers when their site is viewed in a cranked-font browser (or Windows XP).
This transition was in many ways one of the most difficult of Freeway’s history, because while the developers knew (and know) that inline is the way things should be done, they could not untwist the basic assumptions of DTP in a meaningful way, and still maintain usability for their established customers or their market base of traditionally-trained designers. It comes down to the basic problem of figuring out what the user MEANS when they overlap two things or place them near one another. Do they want them to be independent layers, or do they want them to be merged into a third object, or do they want one to push the other away? Inventing a whole new interface modality that allows a designer to signal the fine points of intent without obscuring the design elements in the process — that’s genuinely hard to imagine.
Brave pioneers such as Dan Jasker popularized the idea of nested inline layouts, which return that degree of flexibility and resilience to a DIV-based CSS layout, albeit at the expense of everyday workflow convenience. The pain of having to design your pages twice — once for what you want it to look like, and once for how you want the browser to interpret the HTML — has driven more than a few designers away from Freeway once they attain enough knowledge about the medium to want to work “smarter”.
Remember, “as the twig is bent”: Freeway of today is still a child of Uniqorn and DTP. Its page model is entirely print-centric and not aligned with the browser’s DOM. When you drag things around in the design view, you are modifying the traditional DTP object model, with its x,y,z coordinates and dimensions and all. Each item lives on its own sheet of glass in the animation camera stand, and cannot touch any of its neighbors. When the final page is composed to HTML in the “print” (publish) process, that object model is translated to HTML (dumbed down, I like to say). But because this process happens last, and only in an output stage where the final result is entirely divorced from what you see on screen as you design, there is no meaningful way for Freeway to let the DOM into its design view and give you better feedback about how the final HTML will be constructed.
Finally, it’s been a long-term problem for designers to not care about the messy bits behind the glass until it gets to be a problem. Then they raise their fists and blame Freeway for not reading their mind. It’s a genuinely hard problem that Freeway has carved out for itself, and the alternative is a cliff-shaped learning curve. I have been fortunate to have long legs and a force of will you cannot believe, and I have been paying out the rope behind me for the other climbers since 1998 or so (1997-8 were basically coming to terms with Freeway and browsers and asking so many questions that the developers on the mailing list were plenty sick of me). I continue to bang the drum that you should learn as much about HTML, DOM, CSS, and JavaScript as you can possibly learn — it’s the paper grain and dot gain and ink coverage of your chosen medium. Ignore them at your peril.
Walter
On Oct 25, 2014, at 12:15 PM, Ernie Simpson email@hidden wrote:
That last bit is harder to answer because I don’t understand just where the
developer’s strategy is leading us. Old-timers may correct me, but I think
at one time Freeway made every drawn item relative by default. Using the
inspector, you could change the position to a value of absolute or fixed.
As of version 6 at least (I still have 7 in a box until I finish my current
project, soon I hope) all drawn items are positioned as absolute, with
fixed the only other choice.
freewaytalk mailing list
email@hidden
Update your subscriptions at:
http://freewaytalk.net/person/options
I was just browsing Q&A today and came across these two excellent posts - kudos Ernie and Walter!
freewaytalk mailing list
email@hidden
Update your subscriptions at:
http://freewaytalk.net/person/options
Thanks everyone, I think I have a grasp on the whole concept of inline now. Thanks for the detailed explanations, they are very helpful and much appreciated. I look forward to learning more and more about Freeway. I used Sitegrinder for years and only found Freeway after the demise of Sitegrinder. The forum here has been a great resource for me.
Thanks again,
John
freewaytalk mailing list
email@hidden
Update your subscriptions at:
http://freewaytalk.net/person/options