[Pro] untidy html

Freeway
1

Hi everyone
has anybody thought that freeway 6 seems to output some visually messy html. I don’t mean wrong or even inefficient but just plain messy.
If I look at the output especially if I have added markup then its a real dog’s dinner
I just did some quick tests from a complicated freeway output and then ran that html through an online Javascript html php beautifier you really can see a big difference.

Anyway just wondered if anyone else has noted that the output isn’t as visually logical as it used to be or is it just me

max

freewaytalk mailing list
email@hidden
Update your subscriptions at:
http://freewaytalk.net/person/options

2

I have noticed the same, probably, that there is a propensity for FWP6 to
group items that any pretty-fication tool would separate. On a busy page, I
tend to copy the code out and pretty-fy it before digging in.

–
Ernie Simpson

On Wed, Oct 9, 2013 at 5:35 PM, max email@hidden wrote:

Hi everyone
has anybody thought that freeway 6 seems to output some visually messy
html. I don’t mean wrong or even inefficient but just plain messy.
If I look at the output especially if I have added markup then its a real
dog’s dinner
I just did some quick tests from a complicated freeway output and then ran
that html through an online Javascript html php beautifier you really can
see a big difference.

Anyway just wondered if anyone else has noted that the output isn’t as
visually logical as it used to be or is it just me

max

freewaytalk mailing list
email@hidden
Update your subscriptions at:
http://freewaytalk.net/person/options

freewaytalk mailing list
email@hidden
Update your subscriptions at:
http://freewaytalk.net/person/options

3

Glad some one else has noticed it

I am using http://jsbeautifier.org
at the moment becuase it can handle php javascript and the html all in one go and its doing a pretty darn good job… to the point it got me thinking, why was the freeway output so untidy… The other reason why I was looking was because of the output from maccaw which was producing code that looked clean as a whistle.

freewaytalk mailing list
email@hidden
Update your subscriptions at:
http://freewaytalk.net/person/options

4

Hi Max,
I’ve always thought that Freeway’s page code could do with a bit of a tidy up. Some of the unruly code it is down to Actions (are you looking at me?) where Freeway leaves the indenting and position of the code to the Action developer rather than inserting it itself. Other times it is just Actions that aren’t aware that the page styles are getting stored externally and add their CSS to the document head regardless (the CSS menus Action is one of the biggest culprits IMHO).

One of my biggest drivers to creating the Externalize Action (http://actionsforge.com/actions/view/301-externalize) was to try and get the page code as clean as I could. It trawls through the document looking for code to move off of the page including manually looking for normally inaccessible code produced by other Actions.

The one thing it doesn’t do (but have been considering) is to format the HTML code left behind in the page. At the moment it will compact or beautify the externalized code but not the HTML in the page. Having said that I fully expect this Action to have a limited shelf life as I’d love to see these features rolled into the application itself sometime soon.
Regards,
Tim.

On 9 Oct 2013, at 22:35, max wrote:

has anybody thought that freeway 6 seems to output some visually messy html.

freewaytalk mailing list
email@hidden
Update your subscriptions at:
http://freewaytalk.net/person/options

5

HI Tim

Actually just before you posted your comments I was looking at your externalise action and thinking that it would be a perfect candidate to do the tidying, as it’s doing it on the css.
The problem I see is that an action like your would need be able to handle javascript, html, css, php which quite a task for an action.
The only beautifier that I can find to handle all this is this one http://jsbeautifier.org
I downloaded the page including the opens source scripts and doctored some of the dropdowns like wrap lines to a allow for greater amount than 160 character etc and the result of what it does on the messy html that is published is really good (but not perfect).
Although getting all of the dozen or so scripts to work in a freeway action would I suspect be a blooming whopper task.

I can also envisage trying to get the scripts to work at the very end of the publishing cycle would be another problem especially when other actions are executing at the same point.

In reality Freeway should handle this natively including the choice to clean up markup. At the moment the output is a bit of a mess and programs that are now coming online are looking pretty darn good… Not just Maccaw either. I test Google Web Designer editor yesterday and that one you can actually edit the html as well as flicking back to visual editor.
The competition is mounting up and its starting to show some of the rough edges within Freeway.
Anyway just my thoughts …

freewaytalk mailing list
email@hidden
Update your subscriptions at:
http://freewaytalk.net/person/options

6

To be fair FWP tidies the code to a large extent - but that is what I find
most hard to understand, is why does it behave so partially measured… with
so many things.

It’s as if part of the development group is searching about for direction
and the other part keeps stopping them at half measures.

freewaytalk mailing list
email@hidden
Update your subscriptions at:
http://freewaytalk.net/person/options

7

I have some theories. I’ve written a lot of software over the years that generates HTML, and usually the process is modular: build a block here, a block there, based on templates which can have their formatting set or not. Freeway works at a more atomic level, building individual tags and stitching them together into a DOM (document object model). This reminds me of the XSLT transform process, which is building a tree of tags, and then transforming it into a plain text representation as the last step. But some leaves of that DOM “tree” may already be text – in the case of Action output, that’s sometimes the only way to get what you need done. If those leaves are output in the same process as the full-figured tag nodes, then any refinements possible during the output process are going to be skipped, because the text node doesn’t understand its contents – it’s just “dumb” text.

One thing I have used over and over is the idea of a post–process with a code-aware pretty printer (usually Tidy). This system ingests the raw HTML in any state of validity, and corrects it and outputs it in beautiful hand-coder style. I was inspired by Rails’s beautifully formatted source code: no matter how many layers of template nesting you perform, the output is always properly indented.

This carries with it a certain risk, because the process can be “lossy”. Just as invalid code may render differently in one browser than another, a “correcting” system like this must make certain guesses when it encounters something that is not according to the spec (actually wrong, not just messy). While Freeway doesn’t write incorrect code, you are certainly free to do so in the HTML Markup and Extended interfaces, and Actions can always be badly written, too (I’m certainly guilty of this from time to time). So you could end up with beautifully-formatted code that didn’t match your layout in some regard.

Walter

On Oct 11, 2013, at 10:12 AM, Ernie Simpson wrote:

To be fair FWP tidies the code to a large extent - but that is what I find
most hard to understand, is why does it behave so partially measured… with
so many things.

It’s as if part of the development group is searching about for direction
and the other part keeps stopping them at half measures.

freewaytalk mailing list
email@hidden
Update your subscriptions at:
http://freewaytalk.net/person/options

freewaytalk mailing list
email@hidden
Update your subscriptions at:
http://freewaytalk.net/person/options

8

Hi walter talking about the invalid markup problem couldn’t a validator run prior to any clean up which could flag up invalid code. That way the tidier would only work on valid html… and I suppose some way of disabling the tidying if required. Would not that work?

just a thought

freewaytalk mailing list
email@hidden
Update your subscriptions at:
http://freewaytalk.net/person/options

9

That’s an interesting idea. Anything like this is the sort of post-processing that you could hack into Freeway yourself, using a post-publish tool to process the entire site before you upload. Naturally, this would also mean that you’d have to forego Freeway’s smart upload, in favor of a different tool (Transmit’s “synchronize” command is what I use).

Here’s a quick stab at this sort of processor:

Note how there’s more comments than anything else here – Ruby is magic like that.

Walter

On Oct 11, 2013, at 11:46 AM, max wrote:

Hi walter talking about the invalid markup problem couldn’t a validator run prior to any clean up which could flag up invalid code. That way the tidier would only work on valid html… and I suppose some way of disabling the tidying if required. Would not that work?

just a thought

freewaytalk mailing list
email@hidden
Update your subscriptions at:
http://freewaytalk.net/person/options

freewaytalk mailing list
email@hidden
Update your subscriptions at:
http://freewaytalk.net/person/options

10

Um, before you ask, this doesn’t do the pre-validation and error reporting, but it could be made to quite simply.

Walter

On Oct 11, 2013, at 12:35 PM, Walter Lee Davis wrote:

Note how there’s more comments than anything else here – Ruby is magic like that.

freewaytalk mailing list
email@hidden
Update your subscriptions at:
http://freewaytalk.net/person/options