A serious drawback of CSS

[Alan J. Flavell]

Re: A serious drawback of Tables/CSS over frames [was: A seriousdrawback of CSS]

On Wed, 25 Jan 2006, Martin Lucas-Smith wrote:
[color=blue]
> Personally the drawbacks of frames are so incredibly great[/color]

One can agree with you up to that point!
[color=blue]
> that server-side processing becomes a must on any site above a very
> small number of pages.[/color]

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.

There are many ways of achieving that. The internal process could be
XML-based. Or indeed it could be based on familiar server-side syntax
such as SSI, PHP etc.
[color=blue]
> It's why such facilities (SSI, includes, etc) exist:[/color]

Those using SSI on Apache could be advised to use "XBitHack full"
instead (and, on unix platforms, set the ug+x bits). That can go some
way to remedying the cacheability problem, although it's still not as
good as serving-out plain files (it sets last-modified, but doesn't
generate size and Etag data, which a plain file would).

Those using PHP can be advised to read up about PHP's facilities for
setting HTTP headers, such as last-modified.
[color=blue]
> On Mon, 23 Jan 2006, Dario de Judicibus wrote:
>[color=green]
> > Often I have to code client-based pages, and in such a case I have
> > to duplicate a lot of stuff. That's crazy. XHTML has no import
> > statement, nor there is a way in CSS to specify division content
> > from another file.[/color]
>
> Yep, that's the way it's always been. For that you *have* to
> server-side processing.[/color]

The processing has to be done before the document is served-out,
that's clear - and in that sense it's "server side" indeed. But in
most cases there is no *need* to perform that processing at the
instant of serving the document out. It can be done once, at
publishing time, and then left alone until another update is needed.

Obviously this approach also represents some saving in server
resources - but that isn't the main motivation for it - more to the
point, as I say, is the benefit of cacheability, which can make a web
site seem significantly more responsive to the user.

Routinely recommended tutorial: http://www.mnot.net/cache_docs/
(and see the author's "cacheabili ty engine", which will report on
the cacheability of a web site).

regards

[Tim]

Re: A serious drawback of Tables/CSS over frames [was: A serious drawback of CSS]

On Wed, 25 Jan 2006 18:42:16 +0000, Alan J. Flavell sent:
[color=blue]
> 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.[/color]

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.

[Jasen Betts]

Re: A serious drawback of Tables/CSS over frames [was: A serious drawback of CSS]

On 2006-01-25, Alan J. Flavell <flavell@ph.gla .ac.uk> wrote:
[color=blue]
> Obviously this approach also represents some saving in server
> resources - but that isn't the main motivation for it - more to the
> point, as I say, is the benefit of cacheability, which can make a web
> site seem significantly more responsive to the user.[/color]

also less expensive to run.

Bye.
Jasen

[Alan J. Flavell]

Re: A serious drawback of Tables/CSS over frames [was: A seriousdrawback of CSS]

On Thu, 26 Jan 2006, Tim wrote:
[color=blue]
> On Wed, 25 Jan 2006 18:42:16 +0000, Alan J. Flavell sent:
>[color=green]
> > [...] 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.[/color]
>
> This can be the killer. You may end up changing every page if you
> altered a navigational menu array.[/color]

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 "dependenci es"
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.
[color=blue]
> 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).[/color]

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

[Martin Lucas-Smith]

Re: A serious drawback of Tables/CSS over frames [was: A seriousdrawback of CSS]



On Wed, 25 Jan 2006, Alan J. Flavell wrote:
[color=blue][color=green]
> > that server-side processing becomes a must on any site above a very
> > small number of pages.[/color]
>
> 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.[/color]

[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

[Dario de Judicibus]

Re: A serious drawback of Tables/CSS over frames [was: A serious drawback of CSS]

Alan J. Flavell wrote:
[color=blue]
> 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.[/color]

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
~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~ ~~~~~~~~~

[Hallvard B Furuseth]

Re: A serious drawback of CSS

Dario de Judicibus writes:
[color=blue]
> 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?[/color]

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

[Trevor L.]

Re: A serious drawback of CSS

Hallvard B Furuseth wrote:[color=blue]
> Dario de Judicibus writes:
>[color=green]
> > 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?[/color]
>
> 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[/color]

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.h tml" 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="newWin dow(\'images/display/trevor.jpg\',\' Trevor\');retur n
false"'
etc., finished by
+'</tr>'
+'</table>'
)
}

I then call the JS by
<script type="text/javascript">get head()</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

[Spartanicus]

Re: A serious drawback of CSS

Hallvard B Furuseth <h.b.furuseth@u sit.uio.no> wrote:
[color=blue][color=green]
>> 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?[/color]
>
>You mean <object>?[/color]

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*.
[color=blue]
>Also there is <iframe>.[/color]

Same comments apply.
[color=blue]
>These at least fix some of the problems with frames.[/color]

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

--
Spartanicus

[Alan J. Flavell]

Re: A serious drawback of Tables/CSS over frames [was: A seriousdrawback of CSS]

On Thu, 26 Jan 2006, Dario de Judicibus wrote:
[color=blue]
> The problem with this approach is that you cannot take really
> advantage of WYSYWYG[/color]

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).
[color=blue]
> by placing side by side development environment and browser window,
> since you have to continuosly run the preprocessor.[/color]

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.

--

[Dario de Judicibus]

Re: A serious drawback of Tables/CSS over frames [was: A serious drawback of CSS]

Alan J. Flavell wrote:[color=blue]
> On Thu, 26 Jan 2006, Dario de Judicibus wrote:
>[color=green]
>> The problem with this approach is that you cannot take really
>> advantage of WYSYWYG[/color]
>
> 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.[/color]

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).
[color=blue]
> 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).[/color]

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.
[color=blue]
> 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.[/color]

But it takes you to original design...
[color=blue]
> 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.[/color]

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
~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~ ~~~~~~~~~

[Dario de Judicibus]

Re: A serious drawback of CSS

Hallvard B Furuseth wrote:[color=blue]
> Dario de Judicibus writes:
>[color=green]
>> 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?[/color]
>
> You mean <object>?
>
> <object data="whatever. html" type="text/html">
> Text to display if <object> is not supported (like <img alt...>)
> </object>[/color]

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
~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~ ~~~~~~~~~

[Johannes Koch]

Re: A serious drawback of CSS

Dario de Judicibus wrote:
[color=blue]
> OK. there are ways, but it looks to me that they are only tricks to move
> around the problem. But the problem is still there. 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?[/color]

src for the img element as well as data for the object element
_reference_ an external resource. They do not _include_ something into
the HTML code with all the implications on e.g. CSS styling, rendering.

For XML-based languages there is XInlcude which is used to _include_
code. But popular browsers don't do XInclude, at least not for
text/html-labeled tag soup.
--
Johannes Koch
In te domine speravi; non confundar in aeternum.
(Te Deum, 4th cent.)