Posted by William Gill on 06/27/07 15:05

Willem Bogaerts wrote:
>> ...I have to do the html in a WYSIWYG editor...
>
> There is no WYSIWYG...

No, but there is the concept of seeing the "finished product" on one
platform, screen setup, and browser combination, before I test it on
other combinations.


>...There is just content. Which, by the way, includes
> HTTP headers you send, especially if you work with special characters.
> You are responsible for what you send to a browser. I encounter loads of
> sites that are full of XHTML, but start with a HTML doctype. I am still
> amazed that some of these sites work, and most of them don't.
> Every browser handles things differently, and you are supposed to know
> what works and what does not. And if you do not know, you should at
> least interested be in knowing.

Are you suggesting I don't know or want to know?

I have seen the same, and have accidentally committed the doctype error
on occasion (that's sometimes the byproduct of having to use too many
different tools for different parts of the job.)

I have this discussion with clients regularly. That's why we can't
control things exactly like print media, or TV can. It is also why I
avoid "bleeding edge" and aim for what I expect the majority of our
visitors to experience. It's also why competitors can optimize for the
client's personal environment and try to steal the account. It's the
message (content) that counts, but putting it in a nice package is
important too. The flash and dazzlers often get these two points backwards.

>
> That said, you can use PHP to generate snippets of HTML where it
> belongs. You can write "control" classes that generate controls
> (buttons, fields, etc). You can write HTML templates (there are enough
> template engines to choose from) to put those controls and anything else
> you want in.
> And, as said by someone else, you use CSS for the presentation...

Yes, separating content from presentation, I know, but when I say a
WYSIWYG (actually what you see is what you hope to get) editor, I'm
looking at HTML and CSS. Sometimes aesthetics means "this doesn't look
so good over here, it would look better if I moved it over there." That
means changing the HTML.

>
> Best regards,

My sites are basically static pages. I even have a couple that are
database driven, but I run the updates and publish the static results.
I don't see the need for each request to generate a db query, especially
when the specific request can be anticipated. Fortunately, these sites
are simple enough to allow me this personal indulgence.

This thread is drifting into a philosophical discussion of points that
can be properly debated elsewhere. I spend hours sometimes starting
with a Photoshop mock-up. When I get the look I think my client will
like, I then proceed to the coding to replicate it as reliably as
possible, for as many visitors as possible. (Aren't you even a little
put off by a site that says you are using the wrong setup. That's what
I think when I see "this site best viewed in...".) I also try to keep
the "dynamics" limited to xhtml/javascript or an occasional flash
insert, but form processing is dynamic, and I chose PHP for that engine.
My original problem was to be able to add and edit that code while
still being able to see and edit the HTML/CSS. My preference was to
keep logic and presentation in one place (two counting the external
css). I guess I will just put the form in an (x)html doc, and the
processing in a seperate PHP doc, or I could just use Python :)

[Back to original message]