Prev: Share Wireless Internet Connection?
Next: Freehand 11.0.2 on an Intel Mac w. 10.6.3
From: BreadWithSpam on 10 Jun 2010 19:21
Warren Oates <warren.oates(a)gmail.com> writes:
> In article <87d3a7Fk6lU1(a)mid.individual.net>,
> TaliesinSoft <taliesinsoft(a)me.com> wrote:
>
> > When one develops a site using Freeway the HTML code is only generated
> > when one "publishes" the site. The description of the site is kept in a
> > Freeway proprietary format. This has the advantage that at the moment

> Sounds flaky to me. I know I have a bare-bones approach (I use Emacs)
> but nonetheless, one's HTML shouldn't be tied to some company's
> proprietary binary code; they're just making sure their "customers"
> don't migrate. Hmm. Reminds me of the iPhone.

Every app which generates web pages where you are doing anything other
than writing the HTML yourself is going to "lock" you into their
system. There is no standard site-generation file system format.

In the end, though, nobody's every any more locked in than you are -
in the end, all these systems have to be generating HTML by the time
the code is pushed up to the server (well, unless they're generating
cgi or other more complex stuff). And just like you can always edit
your hand-written HTML, you can always continue to edit, by hand, the
HTML generated by, say, Sandvox or Rapidweaver or Freeway. In fact,
the HTML generated by one of those may be cleaner to begin with than
what one starts by hand, and thus easier to make small mods to.

I don't know of any fully GUI package which can import the intermediate
files from any other GUI package. Some lower-level programs which are
useful for writing HTML will happily show you the HTML generated by
somethign else and let you modify it with lots of GUI help, but those
are normally more along the lines of single-page-builders, rather than
full site-building packages which do things like automate having menus
on all the pages kept up-to-date, headers, footers, sidebars, navigation.

I've built sites which were 100% cgi-generated, which were hand-coded
HTML, which were built out of simple wiki-deployment, and which were
built using Sandvox and iWeb. Of all of them, the only sites which I
still bother to keep up (well, at least the ones which weren't
inherited by coworkers) are the Sandvox ones. I just don't have the
time to muck around with the rest of that stuff and it makes nice,
easy, pretty, mostly standards-compliant stuff.

Maintenance requires me to keep Sandvox running on my local machine
and to publish the updates when necessary, but that's a hell of a lot
easier and less time-consuming than any other system I've used. Every
once in a while, if I feel the inclination, I modify some of the CSS
or inject a little custom HTML into the pages, which Sandvox lets me
do. But for the most part, I open the app, add a page or two, hit the
Publish button and am done. Unless someone was going to pay me for
the time it would take me to keep the HTML all up to current standards
and debug it and all that, I've got better things to do.

Note, of course, that John is suffering from a mixture of having
generated his original HTML in a crappy package (MS Word, IIRC), and
now he's going and trying to continue to hack the HTML himself -- and,
of course, he's HTML-illiterate. He's got the worst of all worlds -
crappy auto-generated HTML being hacked by someone who couldn't have
written the HTML himself in the first place.

John, stop. Just stop. Start from scratch. Get a package like
Sandvox or Rapidweaver. Pay the price. They're cheap. Copy the raw
text from your current site and paste it into the new apps. Publish.
And you're done and can stop wasting everyone's time here.

Or just get yourself some space on a wiki. You could get yourself a
quite nice site on Wikidot, for example, pay your $50 annually, lock
down all the pages so nobody but you could edit them and you'd be good
to go - you'd be able to edit from anywhere, on any computer. Copy
and paste in all your stuff and, again, you're good to go.

But, then, of course, John is just a troll whose main goal seems to be
to waste all of our time (and perhaps whose secondary goal is to get
us to go look at his religious whatever).

> Strangely, MS Word has a plain text mode that's quite tasty to use.
> There's even some Emacs-like key bindings for the hard-of-mouse.

All mac programs which incorporate Apple's standard text-editing
widgets freely inherit some standard emacs-like keybindings. Go to
pretty much any text box in any app and hit c-a or c-e or c-f or c-b.
or even c-k (though c-y won't yank it back for you, I don't think).



--
Plain Bread alone for e-mail, thanks. The rest gets trashed.
From: Wes Groleau on 10 Jun 2010 22:10
On 06-10-2010 19:21, BreadWithSpam(a)fractious.net wrote:
> Every app which generates web pages where you are doing anything other
> than writing the HTML yourself is going to "lock" you into their
> system. There is no standard site-generation file system format.

I have no problemm imagining an editor that reads in HTML/CSS into
some temporary in-memory format, then writes it back out in HTML/CSS.

In fact, Microsoft Word (shudder) is quite capable of doing that,
though I personally can't tolerate its output.

Moreover, it's quite conceivable that the temporary internal format
could be a "standard" DOM tree, or that the GUI could know the screen
locations of the various elements [1] and translate your actions into
direct changes to the HTML/CSS.

[1] Two of the features of the FireFox developer's tool bar are that
it can outline the bounding box of the element you hover over, and it
can display the DOM path from the root to that element.

--
Wes Groleau

Online Journal: Reading in a Foreign Language
http://Ideas.Lang-Learn.us/russell?itemid=1452
From: BreadWithSpam on 10 Jun 2010 22:41
Wes Groleau <Groleau+news(a)FreeShell.org> writes:
> On 06-10-2010 19:21, BreadWithSpam(a)fractious.net wrote:
> > Every app which generates web pages where you are doing anything other
> > than writing the HTML yourself is going to "lock" you into their
> > system. There is no standard site-generation file system format.
>
> I have no problemm imagining an editor that reads in HTML/CSS into
> some temporary in-memory format, then writes it back out in HTML/CSS.

For a single page, that's reasonably true. For a *site* generation
tool, which does things like manage features common across pages
(menus, sidebars, headers, footers, etc), I don't know of any tool
that reads the files of any other tool.

Conceivably, you could manage some of the common stuff via
frames (yech) or server-side includes, but, again, I don't
know of any sets of GUI tools that make that all that simple
for average end-users.


--
Plain Bread alone for e-mail, thanks. The rest gets trashed.
From: Warren Oates on 11 Jun 2010 08:00
In article <yob1vcejwy5.fsf_-_(a)panix3.panix.com>,
BreadWithSpam(a)fractious.net wrote:

> Unless someone was going to pay me for
> the time it would take me to keep the HTML all up to current standards
> and debug it and all that, I've got better things to do.

The standards don't change that often, though. I'm trying not to sound
pretentious here, but I just don't write bad code when I do it by hand
-- I know the standards I'm working towards, and while I sometimes make
simple mistakes (which my validator will catch) I don't write
non-compliant code. I sometimes rail at the W3C nazis for taking away my
"target" attribute, and forcing me to write obscure JS into my anchors,
but that's another issue.

> John, stop. Just stop. Start from scratch. Get a package like
> Sandvox or Rapidweaver. Pay the price. They're cheap. Copy the raw
> text from your current site and paste it into the new apps. Publish.
> And you're done and can stop wasting everyone's time here.
>
> Or just get yourself some space on a wiki. You could get yourself a
> quite nice site on Wikidot, for example, pay your $50 annually, lock
> down all the pages so nobody but you could edit them and you'd be good
> to go - you'd be able to edit from anywhere, on any computer. Copy
> and paste in all your stuff and, again, you're good to go.

That's all good advice. I hope John is reading it. I know he has me in
his killfile (which is pretty un-Christian of him, I'd say) in case I
might destroy his faith.

> All mac programs which incorporate Apple's standard text-editing
> widgets freely inherit some standard emacs-like keybindings. Go to
> pretty much any text box in any app and hit c-a or c-e or c-f or c-b.
> or even c-k (though c-y won't yank it back for you, I don't think).
>

True, it works (even ctl-y) in TextEdit, say. But not MTNW, sadly. And
Word has its own key-bindings.
--
Very old woody beets will never cook tender.
-- Fannie Farmer
From: dorayme on 11 Jun 2010 19:19
In article <4c122578$0$32027$c3e8da3(a)news.astraweb.com>,
Warren Oates <warren.oates(a)gmail.com> wrote:

> I sometimes rail at the W3C nazis for taking away my
> "target" attribute, and forcing me to write obscure JS into my anchors,
> but that's another issue.

No one has taken the target attribute away. You can just use it
even with 4.01 Strict (which is about the only really justifiable
doctype anyone should be using given the market share of IE) and
it will be fine.

A lot of tommy rot is written about the absolute need to have web
pages validate 100%. And if you are bothered by breaking the
rules, you can modify the doctype in this respect so that it
validates - but easier to simply break the rules.

Or, better rather than easier, get to design without needing it,
rely instead on users' managing their own windows and tabs.
Obscure js is surely a worse evil and a lot more unnecessary
trouble than simply using the target attribute anyway (what dire
consequences do you imagine will happen anyway?)

--
dorayme
 |  Next  |  Last
Pages: 1 2
Prev: Share Wireless Internet Connection?
Next: Freehand 11.0.2 on an Intel Mac w. 10.6.3