why do people hate Frontpage?...
Smed
little laugh and say, "well i guess you aren't serious about making a
website"...
i really dont see the disadvantages to it but then i have only used
Frontpage so i dont know the advantages to the others...
why do people hate Frontpage?..
what editors would you recommend?..
-s
Runnin' on Empty
"Smed" <gsx130...@yahoo.com> wrote in message
news:rZiNg.1484$Y73...@tornado.rdc-kc.rr.com...
Homesite+
It comes packaged with Dreamweaver, but it's a separate install.
FrontPage is lame on many levels, not the least of which is how it creates
dynamic content... and forget the HTML it creates...
Beauregard T. Shagnasty
> whenever i tell people i use Frontpage for my html editor, they give
> that little laugh and say, "well i guess you aren't serious about
> making a website"...
I suppose it is ok for a personal/hobby site.
> i really dont see the disadvantages to it but then i have only used
> Frontpage so i dont know the advantages to the others...
The best 'editor' is a text editor.
If you read the generated output source code, you might understand why
FrontPage is not a good choice. It helps to understand raw HTML and CSS.
Further, given its head, it will generate stuff that only IE users could
see.
> why do people hate Frontpage?..
"Name the four worst HTML 'editors':"
4. Microsoft FrontPage
3. Microsoft Word
2. Microsoft Excel
1. Microsoft Publisher
> what editors would you recommend?..
http://crimsoneditor.com/ is quite good. It is an editor, not a WYSINWYG
tool.
If you really need a Gui, try NVu. http://nvu.com/
--
-bts
-Motorcycles defy gravity; cars just suck.
Nikita the Spider
"Smed" <gsx130...@yahoo.com> wrote:
> whenever i tell people i use Frontpage for my html editor, they give that
> little laugh and say, "well i guess you aren't serious about making a
> website"...
>
> i really dont see the disadvantages to it but then i have only used
> Frontpage so i dont know the advantages to the others...
>
> why do people hate Frontpage?..
Just about all of the WYSIWYG editors produce poor quality HTML. What's
more, they encourage the bad (and common) misbelief that building a Web
page with HTML is just like laying out a page for a magazine using
Scribus or Pagemaker or Quark Xpress. Frontpage in particular likes to
produce IE-specific code which is bad for non-IE users (like myself) and
bad for standards in general.
> what editors would you recommend?..
I'll suggest Notepad but only to drive home the point that you can write
high quality, interesting pages using nothing but that simple tool. It's
worth doing (but only once!) as a learning experience. FirstPage from
evrsoft.com used to be very good, but ISTR that something has gone
downhill about their product and Web site. UltraEdit seems quite good;
I've been using it on a project for about two weeks now. It has a free
45-day eval period. Then there's JEdit which is 100% free. It is a
general programmers editor and more complicated than you need if all you
want to do is HTML.
I assume you're not using a Mac since you're asking about Frontpage, but
BBEdit is quite good on the Mac side.
--
Philip
http://NikitaTheSpider.com/
Whole-site HTML validation, link checking and more
bigdaddybs
> whenever i tell people i use Frontpage for my html editor, they give that
> little laugh and say, "well i guess you aren't serious about making a
> website"...
These people don't seem to realize that you can create the page in
FrontPage Edit mode, and then edit the source to do what you wish. Yes,
there are problems with FrontPage, but there are "problems" of some
sort with ANY WYSIWYG and other editors.
Personally, I use FP in Edit mode to type in my content. (No groans...
I have absolutely NO CLUE how to use DBs for the sites I have that
could, and it's much easier to edit the HTML if FP has put the tags on
most of the stuff for me.) I do use the PREVIEW tag to double-check
that my editing has not screwed up the way I wanted the page to look,
and close it out. When I publish, FP keeps track of what pages are
linked where (images, other pages, subdirectories, whatever) on my
computer, and redoes the website links after everything's moved. (Other
editors do this, too. However, I've had cases where when I didn't use
FP for publishing, the links had to be redone "on-the-fly" live on the
web. Maybe I'm missing something here...(?))
And, yes... I have used Notepad at times. I also tried other
(admittedly free) HTML editors, and none seemed to work as well for
what I needed them to do.
Purists will probably say you should NEVER use a WYSIWYG editor, though
I'm sure all WYS's allow for much quicker and cleaner development and
prototyping. Yes, if you have your layout, you can use Notepad (or it's
cousins), though sometimes you will miss things that FP (or others)
catches.
If you feel comfortable with using FP while others don't, I don't see a
problem either. I would simply say to be careful and DO NOT USE any of
the "bells and whistles" that come with it... and DEFINITELY be careful
if you create forms and input fields. You should be able to find
examples by just searching for "forms html" or "form fields html" or
something like that, and add them into your HTML directly (FP source,
Notepad, etc.).
Everyone has their favorites.
> i really dont see the disadvantages to it but then i have only used
> Frontpage so i dont know the advantages to the others...
Personally, I don't either, and, as long as it works for me...
> why do people hate Frontpage?..
Because it's a Microsoft product, plain and simple. They (MS) created a
webpage builder so anyone who has used almost any MS (and other)
product (especially word-processors) could use it, and people hate
that!
> what editors would you recommend?..
I do agree that other MS products (Word, Excel, etc.) are VERY BAD at
creating websites. They put a LOT of extra code in the HTML (almost, if
not, EVERY line of HTML) that is unnecessary. (The only "extra" code I
leave in my FP-created/-edited pages are in the META tags.)
As I said, I've tried a few others, but as long as I'm (and you're)
aware of what FP will add in that shouldn't be there, of what it CAN'T
do, you validate your pages at http://validator.w3.org/, and the page
layouts are double-checked with AT LEAST Firefox, I, personally, don't
see a problem with it.
BS
Jasbird
<a.non...@example.invalid> wrote:
>Smed wrote:
>
>> whenever i tell people i use Frontpage for my html editor, they give
>> that little laugh and say, "well i guess you aren't serious about
>> making a website"...
>
>I suppose it is ok for a personal/hobby site.
>
>> i really dont see the disadvantages to it but then i have only used
>> Frontpage so i dont know the advantages to the others...
>
>The best 'editor' is a text editor.
I actually use TextPad sometimes when coding because
- I prefer the search and replace functions,
- it loads instantly,
- you can add a syntax file which allows HTML to be displayed with basic
colour separation for elements, attributes, strings and content. From
this I conclude that all those people claiming to use NotePad as their
HTML editor are lying.
PS: I think I agree with the comments above too because I used to
Homesite a few years ago too. I prefer it to Dreamweaver's cluttered
layout.
Why would anyone use FrontPage in preference to GoLive, Dreamweaver,
Homesite or even TextPad?
Jasbird
wrote:
Ooops - The question was "why do I hate Frontpage"? I don't. I haven't
used it because everyone has recommended me not to.
What possible reason would I have for using it when I can use
recommended editors instead (like GoLive, Dreamweaver, Homesite, or
frigging TextPad)?
Smed
"Smed" <...
Andrew
wrote:
>Smed wrote:
>> whenever i tell people i use Frontpage for my html editor, they give that
>> little laugh and say, "well i guess you aren't serious about making a
>> website"...
snip>>>>>>>>>>>>>>>>>>>
>
>> why do people hate Frontpage?..
>
>Because it's a Microsoft product, plain and simple. They (MS) created a
>webpage builder so anyone who has used almost any MS (and other)
>product (especially word-processors) could use it, and people hate
>that!
Hi Bigdaddy,
I seem to remember that many years ago Front Page was originally not
actually a Microsoft program. Did they buy out a company that was at
the time making a program called 'Front Page' and then apply the
Microsoft magic to it?
All the best,
Andrew
--
David Segall
>
>"Smed" <gsx130...@yahoo.com> wrote in message
>news:rZiNg.1484$Y73...@tornado.rdc-kc.rr.com...
>> what editors would you recommend?..
>>
>> -s
>
>
>Homesite+
>
>It comes packaged with Dreamweaver, but it's a separate install.
If you have already paid for Dreamweaver why do you prefer Homesite?
Beauregard T. Shagnasty
> I actually use TextPad sometimes when coding because
> - I prefer the search and replace functions,
..mark of a good editor.
> - it loads instantly,
..means it's not bloated.
> - you can add a syntax file which allows HTML to be displayed with
> basic colour separation for elements, attributes, strings and
> content. From this I conclude that all those people claiming to use
> NotePad as their HTML editor are lying.
Colour-coding, right? Quite beneficial. But, no, not necessary. Crimson
Editor does that by default; no additional files necessary.
If you take care how you code, leaving appropriate whitespace and
perhaps even indents of code blocks, Notepad will work well. However,
since it is a weak and basic editor, most people would choose something
better, especially a tool that can edit multiple files at the same time.
Jonathan N. Little
> Jasbird wrote:
>> - you can add a syntax file which allows HTML to be displayed with
>> basic colour separation for elements, attributes, strings and
>> content. From this I conclude that all those people claiming to use
>> NotePad as their HTML editor are lying.
>
> Colour-coding, right? Quite beneficial. But, no, not necessary. Crimson
> Editor does that by default; no additional files necessary.
What I like about CrimsonEditor is that you can edit and make custom
syntax files. I edited the Perl file to fully include the CGI.pm syntax,
very useful...
--
Take care,
Jonathan
-------------------
LITTLE WORKS STUDIO
http://www.LittleWorksStudio.com
Jonathan N. Little
> As I said, I've tried a few others, but as long as I'm (and you're)
> aware of what FP will add in that shouldn't be there, of what it CAN'T
> do, you validate your pages at http://validator.w3.org/, and the page
> layouts are double-checked with AT LEAST Firefox, I, personally, don't
> see a problem with it.
Many would say you have it backwards. Build and view in Firefox (or
other modern browser) first then check and tweak if required to fix for
IE...
Travis Newbury
> Many would say you have it backwards. Build and view in Firefox (or
> other modern browser) first then check and tweak if required to fix for
> IE...
But since IE is STILL the most popular browser I think this way is
backwards. Make it work in IE (what everyone uses) the tweek for the
lesser used browsers.
I am NOT saying IE is better, only used more.
Runnin' on Empty
"David Segall" <da...@address.invalid> wrote in message
news:3r8dg2tmsja96nueq...@4ax.com...
I (the company I work for, actually) purchases all my products in bundles
and suites, I may only use some of the software once or twice a year, but
when it's needed, we'd better have it.
I do notice that Adobe is selling Homesite+ on it's own for only $99.00,
what a deal, it used to be $600.00.
Why is Homesite better than Dreamweaver?
From a code only standpoint, Dreamweaver blows... macromedia tried to
incorporate some of the better features of Homesite into it for coders, but
it's still too cluttered and awkward to use for my tastes.
Once set up to your coding pref's Homesite is extremely fast for coding
HTML, CFML, PHP, and even ASP (although I don't use it), not so helpful for
CSS.
But that's not an issue, since a style sheet is the smallest part (as far as
volume) of the code.
First of all, the color coding does two things for you, it separates our
markup code from the dynamic code, (in mine HTML is green, CFML is brown and
PHP is gray), make it fast to find blocks of troublesome code.
This also helps if you typo'd a quotation mark, bracket or something, if the
code is not well formed, all the color coding skews, giving you a quick
heads up to start looking for the problem.
Secondly, with auto fill and code hint set to 0 seconds, I don't actually
have to type out entire tags or scripts to complete, for code that you use
all the time, it's a great time saver, to hit the left bracket key, the
first 3 or 4 elements of the tag, and then when you know (from experience)
the code hint selector is on the right block, hit the enter key and
complete.
You still have to know how to code, but once you are familiar with how these
two features works, your fingers can fly, and the code comes spitting out.
You can code a whole page in much less time than without it.
It even has a WYSIWYG side, but I've never used it and wouldn't know how it
compares to Dreamweaver, which I do know is miles ahead of Golive or
Frontpage.
As far as WYSIWYG code goes, I often have to modify code created in WYSIWYG
editors by both good and bad designers.
Dreamweaver is not actually that bad in code generation, but I shudder every
time I have to dig through that ugly, bloated crap that FrontPage or MS Word
creates, it's usually faster to just start over from scratch, which is
probably an intended feature from MS and not a shortcoming (from their
standpoint).
Rick Brandt
Initial testing should be run against the browser that more strictly
conforms to the standards. Then you tweak for the browser that is "wrong".
Popularity doesn't enter into it except that it would take a popular browser
for the second step to be even necessary.
Beauregard T. Shagnasty
> Jonathan N. Little wrote:
>> Many would say you have it backwards. Build and view in Firefox (or
>> other modern browser) first then check and tweak if required to fix
>> for IE...
>
> But since IE is STILL the most popular browser I think this way is
> backwards. Make it work in IE (what everyone uses) the tweek for the
> lesser used browsers.
No, you have it backwards. It is far easier to write to the common
standards (which work in modern browsers) and later tweak what doesn't
work in the ancient IE, than it is to write specific IE crap and later
try to standardize it.
If you write well to the standards, there should be little to tweak for
Internut Exploder.
> I am NOT saying IE is better, only used more.
Well, that's a relief!
Runnin' on Empty
"Beauregard T. Shagnasty" <a.non...@example.invalid> wrote in message
news:47DNg.118347$5i3....@bgtnsc04-news.ops.worldnet.att.net...
Actually Standards are great as a goal post, but they apply best to static
brochure sites and not to anything approaching enterprise level.
Do this simple test, run any major enterprise level or ecommerce site
through the w3c validator, guess what, none validate.
That's right, the most expensive, intensively used sites with some of the
best and brightest developers in the country, (or out of the country), that
are making the most money, don't validate worth beans.
The reason is that there is more to successfully using the Internet (or WWW,
if you prefer), than making sure the HTML or CSS validates.
Making a simple 10 page vanity site, it should validate and conform to
standards, working on a major n-tier ecom application with several layers of
access, admin and functions, backed up by a multi terabyte database, you
concerns are more making sure it and the multiple functions0 work and are
secure against improper use, in the IE and Firefox.
This often means standards are thrown to the wayside in choosing better
methods for the task at hand.
I know this drives CSS and validation zealots nuts, but it's the case.
I'm all for standards, but they don't apply to every site.
David Dorward
> Do this simple test, run any major enterprise level or ecommerce site
> through the w3c validator, guess what, none validate.
http://validator.w3.org/check?verbose=1&uri=http%3A%2F%2Fwww.sophos.com%2F
Valid
http://validator.w3.org/check?verbose=1&uri=http%3A%2F%2Fwww.sophos.com%2Fproducts%2F
Valid
Valid
Valid
http://validator.w3.org/check?verbose=1&uri=http%3A%2F%2Fwww.sophos.com%2Fsecurity%2F
Valid
http://validator.w3.org/check?verbose=1&uri=http%3A%2F%2Fwww.sophos.com%2Fsecurity%2Fanalyses%2F
Valid
Valid
> The reason is that there is more to successfully using the Internet (or
> WWW, if you prefer), than making sure the HTML or CSS validates.
Yes, there is more to it, but that doesn't stop validity being a yummy piece
of very low hanging fruit on the tree of quality assurance.
--
David Dorward <http://blog.dorward.me.uk/> <http://dorward.me.uk/>
Home is where the ~/.bashrc is
David Dorward
> Jonathan N. Little wrote:
>> Many would say you have it backwards. Build and view in Firefox (or
>> other modern browser) first then check and tweak if required to fix for
>> IE...
> But since IE is STILL the most popular browser I think this way is
> backwards. Make it work in IE (what everyone uses) the tweek for the
> lesser used browsers.
Most authors seem to find it easier to get things working in browsers which
more closely follow then standard and then implement work arounds for IE.
This approach may not work for you, but it seems to for the majority.
Runnin' on Empty
"David Dorward" <dor...@yahoo.com> wrote in message
news:ee76ki$ks0$1$830f...@news.demon.co.uk...
> Runnin' on Empty wrote:
>
>> Do this simple test, run any major enterprise level or ecommerce site
>> through the w3c validator, guess what, none validate.
>
Case in point:
Dell
http://validator.w3.org/check?uri=http%3A%2F%2Fwww.dell.com%2F&charset=%28detect+automatically%29&doctype=Inline&verbose=1
Amazon
http://validator.w3.org/check?uri=http%3A%2F%2Fwww.amazon.com%2F&charset=%28detect+automatically%29&doctype=Inline&verbose=1
UPS
http://validator.w3.org/check?uri=http%3A%2F%2Fwww.ups.com%2F&charset=%28detect+automatically%29&doctype=Inline&verbose=1
FEDEX
http://validator.w3.org/check?uri=http%3A%2F%2Fwww.fedex.com%2F&charset=%28detect+automatically%29&doctype=Inline&verbose=1
Kinkos
http://validator.w3.org/check?uri=http%3A%2F%2Fwww.kinkos.com%2F&charset=%28detect+automatically%29&doctype=Inline&verbose=1
Sears
http://validator.w3.org/check?uri=http%3A%2F%2Fwww.sears.com&charset=%28detect+automatically%29&doctype=Inline&verbose=1
Best Buy
http://validator.w3.org/check?uri=http%3A%2F%2Fwww.bestbuy.com%2F&charset=%28detect+automatically%29&doctype=Inline&verbose=1
Target
http://validator.w3.org/check?uri=http%3A%2F%2Fwww.target.com%2F&charset=%28detect+automatically%29&doctype=Inline&verbose=1
New Egg
http://validator.w3.org/check?uri=http%3A%2F%2Fwww.newegg.com%2F&charset=%28detect+automatically%29&doctype=Inline&verbose=1
none validate
>> The reason is that there is more to successfully using the Internet (or
>> WWW, if you prefer), than making sure the HTML or CSS validates.
>
> Yes, there is more to it, but that doesn't stop validity being a yummy
> piece
> of very low hanging fruit on the tree of quality assurance.
>
>
Very true, very true..... I always get a warm feeling when that green bar
comes up.
David Dorward
>>> Do this simple test, run any major enterprise level or ecommerce site
>>> through the w3c validator, guess what, none validate.
> Case in point:
> none validate
Only if you discount the example I provided (which was off the top of my
head as I'm not in any mood to go hunting for decently written sites).
So lots of websites don't conform to standards? So what? It doesn't make the
standard any less useful to content authors (it is rather a pain if you are
a browser author though).
dorayme
<1158079408.1...@i42g2000cwa.googlegroups.com>,
"Travis Newbury" <Travis...@hotmail.com> wrote:
Doubtless, when building a caravan, one should take into account
who will use it and where it is likely to go.
But, apart from other things, it would be unpleasant work to
build for IE (in the sense of watching it every step of the way
in the browser - as one does). Perhaps there is an argument to
say that nevertheless one should do it. My point is that it needs
to be a pretty good one in that case. That it is the most popular
browser is not good enough.
And there are significant dangers. In some cases, the
fundamentals of the design (both HTML and CSS) will suffer as a
foundation for the future of the site. Focus on good behind the
scenes design gets lost, You get it to work well in IE. And what
happens to the tweaking for FF or Opera or Safari? You tweak and
tweak and end up with what? Not likely a clean good thing sitting
there underneath. More likely an even bigger box of tricks.
--
dorayme
dorayme
"Runnin' on Empty" <westfo...@yahoo.com> wrote:
> The reason is that there is more to successfully using the Internet (or WWW,
> if you prefer), than making sure the HTML or CSS validates.
Sure. But alt.html is not the place to trumpet this one. The
mafia don't get Reserve Bank advice before organizing their ...
ahem... financial arrangements.
--
dorayme
Beauregard T. Shagnasty
> "Beauregard T. Shagnasty" <a.non...@example.invalid> wrote:
>> If you write well to the standards, there should be little to tweak
>> for Internut Exploder.
>
> Actually Standards are great as a goal post, but they apply best to
> static brochure sites and not to anything approaching enterprise
> level.
Heh. Wrong.
> Do this simple test, run any major enterprise level or ecommerce site
> through the w3c validator, guess what, none validate.
Some do, but not many.
> That's right, the most expensive, intensively used sites with some of
> the best and brightest developers in the country, (or out of the
> country), that are making the most money, don't validate worth beans.
Making money and observing standards are apples and oranges. What's that
expression? Mutually exclusive? Read the current thread in
alt.www.webmaster subject: "Validation? Tables? Business?"
> The reason is that there is more to successfully using the Internet
> (or WWW, if you prefer), than making sure the HTML or CSS validates.
Of course there is. A valid site selling used vomit won't make much
money. (Well... who knows what people will buy?) [1]
> Making a simple 10 page vanity site, it should validate and conform
> to standards,
Sure, why not?
> working on a major n-tier ecom application with several
> layers of access, admin and functions, backed up by a multi terabyte
> database,
..can still be written with valid code.
> you concerns are more making sure it and the multiple functions0 work
> and are secure against improper use, in the IE and Firefox.
And that too. Secure multiple functions, works in all browsers, has
nothing to do with the designers writing invalid code. C'mon now.
> This often means standards are thrown to the wayside in choosing
> better methods for the task at hand.
Why would deliberately writing bad code be a better method?
> I know this drives CSS and validation zealots nuts, but it's the
> case.
The case is those designers you speak of haven't been trained yet.
> I'm all for standards, but they don't apply to every site.
..but most of them.
I retired five years ago from a fair-sized marketing company which did
web sites for, among others, a major U.S. drug company and a major U.S.
bank. All made extensive use of MSSQL databases, dynamically generated
pages, took orders for drugs - or money - and did the job.
The required tools were Visual Interdev, MSSQL, and SourceSafe. I wrote
valid code, the rest of the team used the graphical editor, never looked
at the souce window, and didn't write valid code. When I tried to
convince the IT manager that, when updates and changes were required, it
took *3-4 times longer* to update everyone else's pages, he argued that
it would take too long to train the others. (Bollocks, I said. It only
took me a few days to catch on.)
I put comments at the top of all my pages: "a pox on anyone who messes
up this layout" but it didn't help. One of the reasons I decided to
retire.
[1] Is there such a thing as new vomit?
Sally Thompson
(in article <M4GNg.31131$QM6....@bgtnsc05-news.ops.worldnet.att.net>):
<snip>
>
> Of course there is. A valid site selling used vomit won't make much
> money. (Well... who knows what people will buy?) [1]
<snip>>
> [1] Is there such a thing as new vomit?
Heh heh.
http://www.geeklife.com/modules/news/article.php?storyid=1774
<g>
--
Sally in Shropshire, UK
bed and breakfast near Ludlow: http://www.stonybrook-ludlow.co.uk
Burne-Jones/William Morris window in Shropshire church:
http://www.whitton-stmarys.org.uk
Beauregard T. Shagnasty
> On Tue, 12 Sep 2006 22:59:08 +0100, Beauregard T. Shagnasty wrote:
> <snip>
>> Of course there is. A valid site selling used vomit won't make much
>> money. (Well... who knows what people will buy?) [1]
> <snip>>
>> [1] Is there such a thing as new vomit?
>
> Heh heh.
>
> http://www.geeklife.com/modules/news/article.php?storyid=1774
>
> <g>
I *knew* someone would post a link like that! :-)
Jonathan N. Little
Yeah, and if they finally 'fix' IE you get the pleasure of redoing your
site the standard as it should have done. BTW for which IE should you
code for?
Kevin Scholl
> "David Segall" <da...@address.invalid> wrote in message
> news:3r8dg2tmsja96nueq...@4ax.com...
>> "Runnin' on Empty" <westfo...@yahoo.com> wrote:
>>
>>> "Smed" <gsx130...@yahoo.com> wrote in message
>>> news:rZiNg.1484$Y73...@tornado.rdc-kc.rr.com...
>>>> what editors would you recommend?..
>>>>
>>>> -s
>>>
>>> Homesite+
>>>
>>> It comes packaged with Dreamweaver, but it's a separate install.
>> If you have already paid for Dreamweaver why do you prefer Homesite?
>
> I (the company I work for, actually) purchases all my products in bundles
> and suites, I may only use some of the software once or twice a year, but
> when it's needed, we'd better have it.
>
> I do notice that Adobe is selling Homesite+ on it's own for only $99.00,
> what a deal, it used to be $600.00.
>
>
> Why is Homesite better than Dreamweaver?
For all intents and purposes, code view in the most ecent versions of
Dreamweaver is essentially Homesite+. Note...
> From a code only standpoint, Dreamweaver blows... macromedia tried to
> incorporate some of the better features of Homesite into it for coders, but
> it's still too cluttered and awkward to use for my tastes.
>
> Once set up to your coding pref's Homesite is extremely fast for coding
> HTML, CFML, PHP, and even ASP (although I don't use it), not so helpful for
> CSS.
>
> But that's not an issue, since a style sheet is the smallest part (as far as
> volume) of the code.
>
> First of all, the color coding does two things for you, it separates our
> markup code from the dynamic code, (in mine HTML is green, CFML is brown and
> PHP is gray), make it fast to find blocks of troublesome code.
>
> This also helps if you typo'd a quotation mark, bracket or something, if the
> code is not well formed, all the color coding skews, giving you a quick
> heads up to start looking for the problem.
>
> Secondly, with auto fill and code hint set to 0 seconds, I don't actually
> have to type out entire tags or scripts to complete, for code that you use
> all the time, it's a great time saver, to hit the left bracket key, the
> first 3 or 4 elements of the tag, and then when you know (from experience)
> the code hint selector is on the right block, hit the enter key and
> complete.
...that all of the things you just mentioned as points that make
Homesite+ better than Dreamweaver, are all present in Dreamweaver as well.
> You still have to know how to code, but once you are familiar with how these
> two features works, your fingers can fly, and the code comes spitting out.
>
> You can code a whole page in much less time than without it.
>
> It even has a WYSIWYG side, but I've never used it and wouldn't know how it
> compares to Dreamweaver, which I do know is miles ahead of Golive or
> Frontpage.
True.
> As far as WYSIWYG code goes, I often have to modify code created in WYSIWYG
> editors by both good and bad designers.
>
> Dreamweaver is not actually that bad in code generation, but I shudder every
> time I have to dig through that ugly, bloated crap that FrontPage or MS Word
> creates, it's usually faster to just start over from scratch, which is
> probably an intended feature from MS and not a shortcoming (from their
> standpoint).
Five minutes in the Preferences of Dreamweaver, and the (X)HTML code it
generates in WYSIWYG mode is darn near as clean as hand coding. The
server-side coding is not as strong, but still not as bad compared to
the others. That said, while I AM a Dreamweaver user, I spend probably
80-90% of my time in code view.
--
*** Remove the DELETE from my address to reply ***
======================================================
Kevin Scholl http://www.ksscholl.com/
ksc...@comcast.DELETE.net
------------------------------------------------------
Information Architecture, Web Design and Development
------------------------------------------------------
We are the music makers, and we are the dreamers of
the dreams...
======================================================
Kevin Scholl
> Actually Standards are great as a goal post, but they apply best to static
> brochure sites and not to anything approaching enterprise level.
No offense intended, but I find that to be utter nonsense.
> Do this simple test, run any major enterprise level or ecommerce site
> through the w3c validator, guess what, none validate.
That doesn't mean that they COULDN'T, and indeed, SHOULDN'T. A few
little errors and/or warnings are to varying degrees acceptable, but
when these sites display dozens if not hundreds of validation problems,
that's simply a demonstration of laziness or, worse, complete apathy.
> That's right, the most expensive, intensively used sites with some of the
> best and brightest developers in the country, (or out of the country), that
> are making the most money, don't validate worth beans.
You think these sites are developed by "some of the best and brightest
developers"? Are you serious? Newsflash: most of these sites are
developed either internally or by the lowest bidder, either of which
rarely equates to the "best and brightest".
> The reason is that there is more to successfully using the Internet (or WWW,
> if you prefer), than making sure the HTML or CSS validates.
Indeed, but that's no excuse to not strive for something that is
relatively easy to achieve, and helps eliminate other problems by default.
> Making a simple 10 page vanity site, it should validate and conform to
> standards, working on a major n-tier ecom application with several layers of
> access, admin and functions, backed up by a multi terabyte database, you
> concerns are more making sure it and the multiple functions0 work and are
> secure against improper use, in the IE and Firefox.
Again, no reason why these requirements cannot be met along with largely
valid, standards-based front-end development.
> This often means standards are thrown to the wayside in choosing better
> methods for the task at hand.
By all means, can you suggest any "better methods" that would preclude
the use of recommended standards?
> I know this drives CSS and validation zealots nuts, but it's the case.
Unfortunately, you're right ... it is the case much of the time. But
once again, it really shouldn't be, and certainly doesn't HAVE to be.
And I'm in no way a CSS or validation zealot, just a very experienced
and logical designer and front-end developer who recognizes the clear
advantages to standards-based development.
> I'm all for standards, but they don't apply to every site.
The question is not why to use standards, but rather WHY NOT.
Andy Dingley
Travis Newbury wrote:
> But since IE is STILL the most popular browser I think this way is
> backwards. Make it work in IE (what everyone uses) the tweek for the
> lesser used browsers.
Yes, but as you've been teetering on the edge of the killfile for
weeks, why should your opinion matter ? These days you seem to swing
between outright troll and devoid of clue.
(The justification for the right answer is the need to support both
eventually, and integrating the total effort over the path of deisgn ->
standards - IE, vs. design -> IE -> standards. Standards-first is
easier)
Travis Newbury
> > But since IE is STILL the most popular browser I think this way is
> > backwards. Make it work in IE (what everyone uses) the tweek for the
> > lesser used browsers.
> > I am NOT saying IE is better, only used more.
> Initial testing should be run against the browser that more strictly
> conforms to the standards. Then you tweak for the browser that is "wrong".
> Popularity doesn't enter into it except that it would take a popular browser
> for the second step to be even necessary.
Popularity most certainly enters into the equation.
Sym
Kevin Scholl wrote:
> Runnin' on Empty wrote:
> > I'm all for standards, but they don't apply to every site.
>
> The question is not why to use standards, but rather WHY NOT.
>
Runnin - I agree with most of what you say.
Kevin - ALL software development projects are compromises, Usually they
are based on existing code, existing paradigms, existing business
models etc and are certainly ring fenced in terms of function and
price, Yes we would all want to start from scratch and write pertfect
code every time. However the nature of most large enterprise
developments, is that they start of OK, but soon by the n'th iteration,
shortcuts HAVE to be made because you end up against the limits of what
wnet before or the timescales/costs etc.
Rgds
Sym.
dorayme
<1158136234.8...@e63g2000cwd.googlegroups.com>,
"Andy Dingley" <din...@codesmiths.com> wrote:
> Travis Newbury wrote:
>
> > But since IE is STILL the most popular browser I think this way is
> > backwards. Make it work in IE (what everyone uses) the tweek for the
> > lesser used browsers.
>
> Yes, but as you've been teetering on the edge of the killfile for
> weeks, why should your opinion matter ? These days you seem to swing
> between outright troll and devoid of clue.
Yes, well... I like this way of putting things. I am now going to
redouble my own efforts to avoid these two pitfalls. Travis,
there is little hope for you. That one terrible vote for Bush
means you deserve everything AD throws at you. I expect you don't
know that good old Al Gore, the last future president, is down
under and saying left wingish things...
--
dorayme
Kevin Scholl
> Kevin Scholl wrote:
>> Runnin' on Empty wrote:
>
>>> I'm all for standards, but they don't apply to every site.
>>
>> The question is not why to use standards, but rather WHY NOT.
>
> are based on existing code, existing paradigms, existing business
> models etc and are certainly ring fenced in terms of function and
We're talking about Web sites, not software development. While there is
some overlap with regard to Web-based applications, generally speaking
there is a clear distinction between the two.
> price, Yes we would all want to start from scratch and write pertfect
Most Web sites are indeed started from scratch. Some of the back end
aspects may carry over from iteration to iteration, adn certainly
content, but more often than not, the front end (HTML and CSS) is
created anew.
> code every time. However the nature of most large enterprise
> developments, is that they start of OK, but soon by the n'th iteration,
> shortcuts HAVE to be made because you end up against the limits of what
> wnet before or the timescales/costs etc.
If that were the case, there would rarely be improvements made to even
the software you mention above. But as it pertains to Web development,
implementing standards-based front end code could be treated as any
other versioned improvement or revision. The idea is to solidify the
product, not let it slip behind (as taking shortcuts tends to do). If
you have limits that preclude the use of a standards-based approach,
then I would maintain that you have a flawed system/appplication design
to begin with, and perhaps starting over would be a better approach.
And for the record, standards-based development ultimately SAVES time
(and therefore costs) in the long run, as it typically eases maintenance
and future (re)development.
Gernot Frisch
> Yeah, and if they finally 'fix' IE you get the pleasure of redoing
> your
> site the standard as it should have done. BTW for which IE should
> you code for?
3.51 ?? ;)
Sym
Kevin Scholl wrote:
[snip]
Kevin - FYI - i was replying to the comments about enterprise
solutions, i understand and agree with what you say with regard to "web
sites".
Peter
Jonathan N. Little wrote:
> Travis Newbury wrote:
> > Jonathan N. Little wrote:
> >> Many would say you have it backwards. Build and view in Firefox (or
> >> other modern browser) first then check and tweak if required to fix for
> >> IE...
> >
> > But since IE is STILL the most popular browser I think this way is
> > backwards. Make it work in IE (what everyone uses) the tweek for the
> > lesser used browsers.
> >
> > I am NOT saying IE is better, only used more.
> >
> Yeah, and if they finally 'fix' IE you get the pleasure of redoing your
> site the standard as it should have done. BTW for which IE should you
> code for?
> --
> Take care,
>
> Jonathan
I have only coded simple web pages before, and they all look
essentially identical in whatever browser you view them with.
Could somebody explain what IE does diffrently? Where does it not
include the standards?
-Peter-
Andy Dingley
Peter wrote:
> Could somebody explain what IE does diffrently?
Lots of things:
* Bugs. Lots of them, particularly around CSS
* Rendering modes. If you make IE work in "strict" mode then it's not
too bad (why we're all obsessed with doctypes). Generally though, IE
renders in "quirks" mode, which has glaring errors in it. However it's
hoow IE always used to work, so M$ (probably rightly) see it as better
to remain compatible with the broken standard unless given a strong
hint that it's time to get things right. As compatibility hacks go,
this isn't a bad attempt.
Search on "CSS box model" if you want the gory details on just what's
most broken.
Jonathan N. Little
> Jonathan N. Little wrote:
>> Travis Newbury wrote:
>>> Jonathan N. Little wrote:
>>>> Many would say you have it backwards. Build and view in Firefox (or
>>>> other modern browser) first then check and tweak if required to fix for
>>>> IE...
>>> But since IE is STILL the most popular browser I think this way is
>>> backwards. Make it work in IE (what everyone uses) the tweek for the
>>> lesser used browsers.
>>>
>>> I am NOT saying IE is better, only used more.
>>>
>> Yeah, and if they finally 'fix' IE you get the pleasure of redoing your
>> site the standard as it should have done. BTW for which IE should you
>> code for?
> I have only coded simple web pages before, and they all look
> essentially identical in whatever browser you view them with.
>
> Could somebody explain what IE does diffrently? Where does it not
> include the standards?
Well with simple styling, IE does okay so you should not have too much
problems. In general IE usually flubs up margins & padding, especially
when floats are involved. And IE lack of selectors support means you
need to define more classes and ids and hard-code it into your markup.
Here is a good property comparison table that will get you started...
http://www.webdevout.net/browser_support_css.php
Web Browser CSS Support
Unfortunately, many on the web are woefully obsolete not listing Firefox
or Opera and can be misleading.
Runnin' on Empty
"Kevin Scholl" <ksc...@comcast.DELETE.net> wrote in message
news:J-Odne9ZlbikT5XY...@comcast.com...
> Sym wrote:
>> Kevin Scholl wrote:
>>> Runnin' on Empty wrote:
>>
>>>> I'm all for standards, but they don't apply to every site.
>>>
Sym wrote:
> Kevin Scholl wrote:
We're talking about Web sites, not software development. While there is
some overlap with regard to Web-based applications, generally speaking
there is a clear distinction between the two.
It depends on what you mean by "web site" ?
Are Dell.com or Amazon.com "websites"? If they are your statement is
incorrect, if by website you mean a simple static brochure site, then I
agree with you.
Example One: you make a site for a local motorcycle dealer (or what ever),
it got about 10 pages of core navigation (home, about us, new bikes, used
bikes, parts dept, staff, locations, contact us, bike safety, etc)
Each page is create in Dreamweaver, then gone over by hand,and FTP'd to the
server. There is no reason for any of these pages not to validate.
Example Two:
You make a web site for a major level real estate and development company,
it has a similar core navigation for 10, or so pages, only some of the pages
are maintained by agents using a common javascript CMS tool bar and a PHP
interface to the Database.
It has several layers of access to various other dynamic functions
including:
Amazon remote shopping cart that takes Amazon AWS XML feeds to sell books
both to agents and property prospects,
A proprietary, members only shopping cart written in PHP, that interfaces
with a database so agents can order sign, business cards, pens and other
schwag. The Database is maintained by a combo CMS and Cart Admin written in
PHP.
It includes a Multiple Listings XML feed from a third party provider that
allows site users to view property descriptions by agent.
Also. well you get the picture, I guarantee that this "website" will not
validate.
Why not? Because much of the "Front End" HTML and CSS is generated by
automated process that are impossible to vet to clean code. For instance the
Amazon data will generate HTML tables that may or may not be in balance
depending on how many record sets a query returns, hence no validation for
the HTML.
Most Web sites are indeed started from scratch.
Any thing "Started" is from scratch, any thing "maintained" wont be.
Most people that have web standards as there goal have never worked on a
majorly large and dynamic "web site"
Kevin Scholl
>> We're talking about Web sites, not software development. While there is
>> some overlap with regard to Web-based applications, generally speaking
>> there is a clear distinction between the two.
>
> It depends on what you mean by "web site" ?
>
> Are Dell.com or Amazon.com "websites"? If they are your statement is
> incorrect, if by website you mean a simple static brochure site, then I
> agree with you.
Of course they are Web sites. How does that make my statement in any way
incorrect? Web sites are not software in the true sense of the phrase.
There may be some software running things in the background, but
ultimately what the user sees is passed to the browser as HTML, and
therefore can always be configured to be standards-compliant and valid.
> Example One: you make a site for a local motorcycle dealer (or what ever),
> it got about 10 pages of core navigation (home, about us, new bikes, used
> bikes, parts dept, staff, locations, contact us, bike safety, etc)
>
> Each page is create in Dreamweaver, then gone over by hand,and FTP'd to the
> server. There is no reason for any of these pages not to validate.
Correct.
> Example Two:
>
> You make a web site for a major level real estate and development company,
> it has a similar core navigation for 10, or so pages, only some of the pages
> are maintained by agents using a common javascript CMS tool bar and a PHP
> interface to the Database.
And this precludes validation how...?
> It has several layers of access to various other dynamic functions
> including:
>
> Amazon remote shopping cart that takes Amazon AWS XML feeds to sell books
> both to agents and property prospects,
And this...?
> A proprietary, members only shopping cart written in PHP, that interfaces
> with a database so agents can order sign, business cards, pens and other
> schwag. The Database is maintained by a combo CMS and Cart Admin written in
> PHP.
>
> It includes a Multiple Listings XML feed from a third party provider that
> allows site users to view property descriptions by agent.
Again, why could this not be presented as valid code?
> Also. well you get the picture, I guarantee that this "website" will not
> validate.
Indeed, probably not. But not because it couldn't. What you seem to not
follow is that all of these individual features that are generated from
[wherever] COULD be standards-compliant. They COULD validate. You may or
may not have control over them, unfortunately, depending upon your feed.
But if the various pieces are valid, the whole should similarly be.
> Why not? Because much of the "Front End" HTML and CSS is generated by
> automated process that are impossible to vet to clean code. For instance the
> Amazon data will generate HTML tables that may or may not be in balance
> depending on how many record sets a query returns, hence no validation for
> the HTML.
I reiterate... regardless of what all goes on in the background,
ultimately everything the user sees is sent to the browser as HTML. As
such, if everyone involved does their job, it is perfectly POSSIBLE for
any site as you describe to be accomplished with a standards-based
approach, and indeed even validate. The trick, and the part that is
seldom realized, is getting the various developers to all use that
standards-based approach.
> Most people that have web standards as there goal have never worked on a
> majorly large and dynamic "web site"
I cannot speak for others, but that is certainly not the case for me.
Just because something isn't typically done in practice (for whatever
reason), doesn't mean it CANNOT be done. You seem to be arguing that
it's impossible for anything more than a simple static site to be
standards-compliant and valid. However unlikely it may be to actually
happen, it's perfectly possible to do.
If you are merely saying that it is not often done, then I couldn't
agree more. But there's a difference between not doing something, and
not being able to do it.
That's my point, nothing more.
Runnin' on Empty
> Runnin' on Empty wrote:
>
>
> I reiterate... regardless of what all goes on in the background,
> ultimately everything the user sees is sent to the browser as HTML. As
> such, if everyone involved does their job, it is perfectly POSSIBLE for
> any site as you describe to be accomplished with a standards-based
> approach, and indeed even validate. The trick, and the part that is seldom
> realized, is getting the various developers to all use that
> standards-based approach.
> > If you are merely saying that it is not often done, then I couldn't
> agree more. But there's a difference between not doing something, and not
> being able to do it.
>
> That's my point, nothing more.
>
That reminds me of a song...
In the Big Rock Candy Mountains there's a land that's fair and bright
Where the handouts grow on bushes and you sleep out every night
Where the boxcars are all empty and the sun shines every day
On the birds and the bees and the cigarette trees
Where the lemonade springs where the bluebird sings
In the Big Rock Candy Mountains
In the Big Rock Candy Mountains all the cops have wooden legs
And the bulldogs all have rubber teeth and the hens lay soft boiled eggs
The farmer's trees are full of fruit and the barns are full of hay
Oh, I'm bound to go where there ain't no snow
Where the rain don't fall and the wind don't blow
In the Big Rock Candy Mountains
In the Big Rock Candy Mountains you never change your socks
And the little streams of alcohol come a-trickling down the rocks
The brakemen have to tip their hats and the railroad bulls are blind
There's a lake of stew and of whiskey too
You can paddle all around 'em in a big canoe
In the Big Rock Candy Mountains
In the Big Rock Candy Mountains the jails are made of tin
And you can walk right out again as soon as you are in
There ain't no short handled shovels, no axes saws or picks
I'm a goin to stay where you sleep all day
Where they hung the jerk that invented work
In the Big Rock Candy Mountains
I'll see you all this coming fall in the Big Rock Candy Mountains
So yeah, I guess you're right....if we lived in a perfect world, and all the
many hands the web code passes through were capable, standards driven
hands.... then there's no reason it shouldn't.... that's just not the world
we live in.
Andy Dingley
Runnin' on Empty wrote:
> The Database is maintained by a combo CMS and Cart Admin written in
> PHP.
>
> It includes a Multiple Listings XML feed from a third party provider that
> allows site users to view property descriptions by agent.
>
> Also. well you get the picture, I guarantee that this "website" will not
> validate.
Why? There is _no_ reason why this website needn't validate, even with
the embedded XML and with serving it in HTML as text/html.
It's a "web" site. To make it work it must either _be_ valid "web
stuff", or it must be presented through the browser by complex
manglings until it's approximately valid enough for the browser to make
sense of it. If it's not a web site, then the web browser just can't
handle it -- you have to be either close, or automatically convertable
to close.
The closer you start, the less trouble this process generates.
The XML can be replaced with some XML, accessed through AJAX on
start-up and probably some XSLT. All valid, but it requires JavaScript.
Then again, I imagine your original site relied on JavaScript too, else
why send XML? If it's going to be non-JavaScript, then it's also going
to be static pages with nothing dynamic between HTTP requests, so you
can just transform the XML to static, valid HTML on the server and get
the same results.
Why do you think it must still be invalid ?
Runnin' on Empty
"Andy Dingley" <din...@codesmiths.com> wrote in message
news:1158274037....@e3g2000cwe.googlegroups.com...
>
> Runnin' on Empty wrote:
>
> Why do you think it must still be invalid ?
>
I gave a simple example... in this case, the simple fact that the Amazon
remote cart (or more exactly, the utilized xslt stylesheet), will return
tables with varied number of cells per row, depending on how many records
are returned per query.
This coupled with the many different hands manning various CMS functions,
and how they choose to format textual content will make it impossible to
validate.
The more layers of this sort of complexity, the further you get away from
static HTML templates, the less likely you can vet the HTML to ensure
validation.
It's simple... too many factors beyond the control of the developer, or
delivered by third parties, or auto generated... result, validation errors.
But that's all they are, as far as browser use, no problems.
I don't expect people wedded to the concept that validation is the end all
of development to either get this, or agree.
Kevin Scholl
Heh heh ... not sure what THAT'S all about, but amusing nonetheless.
> So yeah, I guess you're right....if we lived in a perfect world, and all the
> many hands the web code passes through were capable, standards driven
> hands.... then there's no reason it shouldn't.... that's just not the world
> we live in.
Indeed. Shame, too, because it's a world that we as the developers have
the power to change. Unfortunately, some are just too lazy to actually
exercise that power.
Andy Dingley
Runnin' on Empty wrote:
> The more layers of this sort of complexity, the further you get away from
> static HTML templates, the less likely you can vet the HTML to ensure
> validation.
No, the more more complex it is, the more important it is to validate,
and to understand the implications of validation at each step.
My current project is a web app that builds a deliverable package over
100MB. Multi-developer, multi-continent distributed Agile development
using everything form AJAX to XSLT. Just the Java part of it goes from
the worst of years-old Indian bucket-shop structureless JSP through to
the latest in Facelets (I don't even know what a Facelet _is_ yet).
Whatever it is you're building here, I bet it counts as pretty small
and simple in comparison.
Now this doesn't validate (yet). It's also resolutely IE-only and
horribly inflexible. Much of what's wrong with the presentation side of
it comes down to bad HTML and bad CSS. I'd say I can make even _this_
mess standards-based, but I'd have to start playing the A-Team music in
the background. It needs doing though - it's our only way forward if
we're to get the presentation manageab;e and cross-platform portable.
Kevin Scholl
> I don't expect people wedded to the concept that validation is the end all
> of development to either get this, or agree.
Bear in mind that someone striving for valid, standards-based solutions
doesn't necessarily think that's the end-all of development. In fact,
quite the contrary -- someone who truly understands the value of these
things knows that they are indeed NOT the end itself, but rather
effective building blocks TO a more efficient end.
Chris F.A. Johnson
>
> Also. well you get the picture, I guarantee that this "website" will not
> validate.
>
> Why not? Because much of the "Front End" HTML and CSS is generated by
> automated process that are impossible to vet to clean code. For instance the
> Amazon data will generate HTML tables that may or may not be in balance
> depending on how many record sets a query returns, hence no validation for
> the HTML.
There is no reason that generated HTML should not validate. One of
my pages <http://cfaj.freeshell.org/ttc/> even takes invalid html
from an external site and fixes it so that it does validate.
There are still some pages on my site that do not validate; I am
fixing those as I have time.
--
Chris F.A. Johnson <http://cfaj.freeshell.org>
===================================================================
Author:
Shell Scripting Recipes: A Problem-Solution Approach (2005, Apress)
Runnin' on Empty
"Chris F.A. Johnson" <cfajo...@gmail.com> wrote in message
news:8vmpt3-...@xword.teksavvy.com...
> On 2006-09-14, Runnin' on Empty wrote:
>>
>> Also. well you get the picture, I guarantee that this "website" will not
>> validate.
>>
>> Why not? Because much of the "Front End" HTML and CSS is generated by
>> automated process that are impossible to vet to clean code. For instance
>> the
>> Amazon data will generate HTML tables that may or may not be in balance
>> depending on how many record sets a query returns, hence no validation
>> for
>> the HTML.
>
> There is no reason that generated HTML should not validate. One of
> my pages <http://cfaj.freeshell.org/ttc/> even takes invalid html
> from an external site and fixes it so that it does validate.
>
> There are still some pages on my site that do not validate; I am
> fixing those as I have time.
>
> --
>
That's not even a close example of what I was describing....
Chris F.A. Johnson
Then ignore the example. The statement still stands:
There is no reason that generated HTML should not validate.
(Unless the generator is incompetent or is not aware of the
standards or the validator tool.)
Dan
Kevin Scholl wrote:
> Indeed. Shame, too, because it's a world that we as the developers have
> the power to change. Unfortunately, some are just too lazy to actually
> exercise that power.
And, contrary to what the other poster said, it should actually be
*easier* to have the big, complex, dynamically-generated sites validate
than the smaller ones where each page is hand-coded; all you'd have to
do is make sure to use correct code in the templates from which the
many pages of the site are generated, and then the validity would take
care of itself.
Wikipedia manages to (almost always) have valid code, because the
MediaWiki program is set up that way; editors can throw all sorts of
malformed stuff into the individual pages, but in nearly all cases it's
converted to perfectly standards-compliant code.
--
Dan