why do people hate Frontpage?...

D

David Dorward

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).
 
D

dorayme

"Travis Newbury said:
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.

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.
 
D

dorayme

"Runnin' on Empty said:
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.
 
B

Beauregard T. Shagnasty

Runnin' on Empty said:
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?
 
J

Jonathan N. Little

Travis said:
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?
 
K

Kevin Scholl

Runnin' on Empty said:
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/
(e-mail address removed)
 
K

Kevin Scholl

Runnin' on Empty said:
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.

--

*** Remove the DELETE from my address to reply ***

======================================================
Kevin Scholl http://www.ksscholl.com/
(e-mail address removed)
 
A

Andy Dingley

Travis said:
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)
 
T

Travis Newbury

Rick said:
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.
 
S

Sym

Kevin said:
Runnin' on Empty wrote:

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.
 
D

dorayme

"Andy Dingley said:
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...
 
K

Kevin Scholl

Sym said:
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

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.

--

*** Remove the DELETE from my address to reply ***

======================================================
Kevin Scholl http://www.ksscholl.com/
(e-mail address removed)
 
G

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 ?? ;)
 
S

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".
 
P

Peter

Jonathan said:
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?

-Peter-
 
A

Andy Dingley

Peter said:
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.
 
J

Jonathan N. Little

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.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,769
Messages
2,569,580
Members
45,054
Latest member
TrimKetoBoost

Latest Threads

Top