A serious drawback of CSS

On Wed, 25 Jan 2006 18:42:16 +0000, Alan J. Flavell sent:

Except where there is a genuine requirement for particular page(s) to be
kept up-to-the-minute by incorporating content which is frequently
changing, I would tend to recommend doing that processing at the point
where the materials are published /to the server/. I.e run your scripts
to assemble the finished web page (maybe outputting the result to your
development server running on 127.0.0.1), review the results, then
transfer the finished product to the production server. Don't change the
files on the production server (i.e don't change their last-modified
stamp) unless and until their content really changes.

This can be the killer. You may end up changing every page if you altered
a navigational menu array. And comparing local and remote dates can be
difficult over FTP (timezones appear to be a problem unless you can kludge
your client to compensate).

--
If you insist on e-mailing me, use the reply-to address (it's real but
temporary). But please reply to the group, like you're supposed to.

This message was sent without a virus, please destroy some files yourself.

On Thu, 26 Jan 2006, Tim wrote:

On Wed, 25 Jan 2006 18:42:16 +0000, Alan J. Flavell sent:

[...] run your scripts to assemble the finished web page (maybe
outputting the result to your development server running on
127.0.0.1), review the results, then transfer the finished product
to the production server. Don't change the files on the
production server (i.e don't change their last-modified stamp)
unless and until their content really changes.

This can be the killer. You may end up changing every page if you
altered a navigational menu array.

At least you have it under control if you do it this way. If the page
is casually assembled using SSI or PHP (without going to the trouble
of learning how to work with last-modified headers etc.) then you get
that effect /every/ time that you serve-out a page.

It's up to whoever sets up a Makefile scheme, to decide whether a
particular included component is a vital part of every page, such that
a change to that component really does mean rebuilding every page, or
whether it can be left to wait until some substantive content on the
page next changes. Accordingly, one would adjust the "dependencies"
which are used by make in deciding what to do. You can still have a
special "target" for make which would force a complete update when you
really want it.

As I say, the attraction of this approach can be that you get as much
flexibility as you care to implement - the decisions aren't forced
upon you by the server-side technology that you picked, as they are
with server-time processing like SSI, PHP and friends.

And comparing local and remote dates can be difficult over FTP
(timezones appear to be a problem unless you can kludge your client
to compensate).

If you consistently maintain your production site with a Makefile
that's set up on the development platform, then the development
platform can keep a note of when a page was last uploaded - it doesn't
need to find out from the production server.

But sure, that's not the only way. If you're in control of the
production server there are wget, rsync... lots of ways of keeping
things in step. If you're not in control of the production server
(say, it's operated by a web service provider and you only get limited
access to features), then I'd say that's even more reason to keep
control of process on your development platform. But YMMV: I'm only
making suggestions, discussing some of their implications, which you
can evaluate in your particular environment, and use or not as you see
fit.

best

On Wed, 25 Jan 2006, Alan J. Flavell wrote:

that server-side processing becomes a must on any site above a very
small number of pages.

That depends on quite what people understand by "server-side
processing". Server-side processing *at the point of delivery* tends to
produce documents which have no usable last-modified information,
causing problems with cacheability. One needs a certain minimum level
of expertise with the various techniques (SSI, PHP, whatever) to achieve
the levels of cacheability that come "for free" when documents are
served-out from plain files.

Except where there is a genuine requirement for particular page(s) to be
kept up-to-the-minute by incorporating content which is frequently
changing, I would tend to recommend doing that processing at the point
where the materials are published /to the server/. I.e run your scripts
to assemble the finished web page (maybe outputting the result to your
development server running on 127.0.0.1), review the results, then
transfer the finished product to the production server. Don't change
the files on the production server (i.e don't change their last-modified
stamp) unless and until their content really changes.

[snip rest of post]

Yes, I agree, pre-processing is a valid option, though for many sites it's
arguably an extra layer of complexity and either way still requires
server-side processing. Like all web development, it's a balance.


Martin

Alan J. Flavell wrote:

Except where there is a genuine requirement for particular page(s) to
be kept up-to-the-minute by incorporating content which is frequently
changing, I would tend to recommend doing that processing at the point
where the materials are published /to the server/. I.e run your
scripts to assemble the finished web page (maybe outputting the result
to your development server running on 127.0.0.1), review the results,
then transfer the finished product to the production server. Don't
change the files on the production server (i.e don't change their
last-modified stamp) unless and until their content really changes.

The problem with this approach is that you cannot take really advantage of
WYSYWYG by placing side by side development environment and browser window,
since you have to continuosly run the preprocessor. And all that because
there is no src option in tags different from img. Hard to understand.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Dr. Dario de Judicibus - Italy (EU)
Site: http://www.dejudicibus.it/
Blog: http://lindipendente.splinder.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Dario de Judicibus writes:

In my opinion, the only practical solution would be to allow SRC
attribute for html code too. We use it already for images. Why not
tags?

You mean <object>?

<object data="whatever.html" type="text/html">
Text to display if <object> is not supported (like <img alt...>)
</object>

See <http://www.w3.org/TR/html4/struct/objects.html#h-13.3>.
Also there is <iframe>.

These at least fix some of the problems with frames. And introduce
others, I'm sure... I remember some old advice to disable <iframe>
in my browser, but I don't remember why.

--
Hallvard

Hallvard B Furuseth wrote:

Dario de Judicibus writes:

In my opinion, the only practical solution would be to allow SRC
attribute for html code too. We use it already for images. Why not
tags?

You mean <object>?

object data="whatever.html" type="text/html"
Text to display if <object> is not supported (like <img alt...>)
/object

See <http://www.w3.org/TR/html4/struct/objects.html#h-13.3>.
Also there is <iframe>.

These at least fix some of the problems with frames. And introduce
others, I'm sure... I remember some old advice to disable <iframe
in my browser, but I don't remember why.

--
Hallvard

O.K.
I am not the OP, but I am struggling with replacing frames and of
course the duplication of code issue.

I tried this
<object data="gethead.html" type="text/html">
<b>Header</b>
</object>

gethead.html is a file in the same folder (I am doing this locally)
The result was that neither the contents of gethead.html nor the text
"Header" was included
Is there something missing ?

My only way at the moment is to place the code in a JS file which is
called.
The code is placed inside
function gethead() { document.write(' and ')}
Because there are many lines of code, each line of code is preceeded by
+' and terminated by '. All occurrences of ' in the code are replaced
by \'
e.g it looks like this
document.write(
'<table border="1px">'
+'<tr>'
+' <td width="5%">'
+' <a href=""'
+'
onclick="newWindow(\'images/display/trevor.jpg\',\'Trevor\');return
false"'
etc., finished by
+'</tr>'
+'</table>'
)
}

I then call the JS by
<script type="text/javascript">gethead()</script>

This relies on Javascript being present, but the object method relies
on object working (which it didn't for me)

Can you explain why the <object> method fails

Thanks

Hallvard B Furuseth <h.b.furuseth (AT) usit (DOT) uio.no> wrote:

In my opinion, the only practical solution would be to allow SRC
attribute for html code too. We use it already for images. Why not
tags?

You mean <object>?

That would open a new viewport inside the existing viewport for
displaying a *complete* HTML document in.

The OP wants to merge in a code *fragment*.

Also there is <iframe>.

Same comments apply.

These at least fix some of the problems with frames.

Not at all, <iframe> has poorer client support than regular frames.

--
Spartanicus

On Thu, 26 Jan 2006, Dario de Judicibus wrote:

The problem with this approach is that you cannot take really
advantage of WYSYWYG

As I've said before: in a medium whose whole concept is based on the
separation of content from presentation, there cannot fundamentally be
such a thing as WYSIWYG. In HTML, "what you get" is structured
markup, not a visual presentation. Ignore that, and what you get is
div/span soup, with no real structure.

Naturally, you want to preview your pages in a range of browsing
situations before you publish them. No disagreement about that. But
that should go along with the other QA activities such as syntax
validation and other QA checks (who can say what the 48 reported XHTML
syntax errors on your blog page are really going to cause across a
range of different browsing situations? I would rather pay attention
to that, than worry about the last pixel of visual presentation in a
particular browser).

by placing side by side development environment and browser window,
since you have to continuosly run the preprocessor.

If you worked that way, you would need to re-run the preprocessor
after making substantive changes, before each previewing session, yes.

Or you could develop a design template, as a separate activity,
without the pre-processing; and then break it up into its parts for
use in the pre-processing scheme.

As long as one is only changing the detailed content of pages from day
to day, it really isn't necessary or even useful to continously review
the visual design, is it? Seems to me to be a pointlessly
labour-intensive way of creating web pages. Most sites want a
harmonious framework (i.e for consistency from page to page), with
different content on each page - not a fresh and different visual
design for every page of the site. And that's where the pre-processor
approach seems to me to represent a win.

If you really -are- wanting custom visual design for each and every
separate web page, then probably this isn't the solution that you're
looking for. Whether it can still sensibly achieve the benefits of
"separation of content and presentation" is left as an exercise for
the student.

--

Alan J. Flavell wrote:

On Thu, 26 Jan 2006, Dario de Judicibus wrote:

The problem with this approach is that you cannot take really
advantage of WYSYWYG

As I've said before: in a medium whose whole concept is based on the
separation of content from presentation, there cannot fundamentally be
such a thing as WYSIWYG. In HTML, "what you get" is structured
markup, not a visual presentation. Ignore that, and what you get is
div/span soup, with no real structure.

From a technical point of view is correct, from a practical point of view is
not. When I develop a site I continuosly modify all elements related to that
site: content (XHTML), presentation (CSS), graphics (GIF, JPEG, PNG),
structure (folders). As I apply a change, I wish to immediately see the
result. WYSIWYG allows me to "play & see", taht is, quickly test idea,
prototype new pages, develop on the fly taking advantage of both fantasy
(irrational brain) and logics (rational one).

Naturally, you want to preview your pages in a range of browsing
situations before you publish them. No disagreement about that. But
that should go along with the other QA activities such as syntax
validation and other QA checks (who can say what the 48 reported XHTML
syntax errors on your blog page are really going to cause across a
range of different browsing situations? I would rather pay attention
to that, than worry about the last pixel of visual presentation in a
particular browser).

They are due to the non-conformant banner prefixed by Splinder to my code.
It is the price to have free blog platform. My template is XHTML conformant,
the template plus ad code is note. Out of my control.

As long as one is only changing the detailed content of pages from day
to day, it really isn't necessary or even useful to continously review
the visual design, is it? Seems to me to be a pointlessly
labour-intensive way of creating web pages.

But it takes you to original design...

If you really -are- wanting custom visual design for each and every
separate web page, then probably this isn't the solution that you're
looking for. Whether it can still sensibly achieve the benefits of
"separation of content and presentation" is left as an exercise for
the student.

Again, I do not see any reason for not having SRC in P or DIV; for example.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Dr. Dario de Judicibus - Italy (EU)
Site: http://www.dejudicibus.it/
Blog: http://lindipendente.splinder.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Hallvard B Furuseth wrote:

Dario de Judicibus writes:

In my opinion, the only practical solution would be to allow SRC
attribute for html code too. We use it already for images. Why not
tags?

You mean <object>?

object data="whatever.html" type="text/html"
Text to display if <object> is not supported (like <img alt...>)
/object

Yes, that would be a solution, but as far as I know, it does not work.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Dr. Dario de Judicibus - Italy (EU)
Site: http://www.dejudicibus.it/
Blog: http://lindipendente.splinder.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~