why do people hate Frontpage?...

[Runnin' on Empty]

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]

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.

--

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

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

 

[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.
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]

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]

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]

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

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.

--

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

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

 

[Andy Dingley]

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.

--

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

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

 

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

 

[Runnin' on Empty]

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]

That's not even a close example of what I was describing....

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]

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.