Converting transitional to strict
Alfred Molon
strict and ran into problems.
Here is the original transitional page:
http://www.molon.de/l/upsgn.html
and here is my attempt:
http://www.molon.de/l/upsgn1.html
A validator check shows 12 errors. BTW, INPUT elements are not allowed
anymore in HTML 4?
I'm not an HTML expert and I was wondering if perhaps some
translators/converters exist, which convert transitional code into
strict code. Any ideas?
--
Alfred Molon
http://www.molon.de - Photos of Asia, Africa and Europe
Beauregard T. Shagnasty
> I was trying to convert the pages from my site from transitional to
> strict and ran into problems.
>
> Here is the original transitional page:
> http://www.molon.de/l/upsgn.html
> and here is my attempt:
> http://www.molon.de/l/upsgn1.html
>
> A validator check shows 12 errors. BTW, INPUT elements are not allowed
> anymore in HTML 4?
Yes, of course they are. See the actual error message:
"document type does not allow element "INPUT" here; missing one of "P",
"H1", "H2", "H3", "H4", "H5", "H6", "PRE", "DIV", "ADDRESS" start-tag"
Your <input>s are floating free within <td>s - rather than one of the
above. They need to be direct descendants of one of those.
I think you also have mis-level form tags as well. e.g. the <form> and
the </form> are somehow not inside the same <td>. With all those
myriads of nested tables, it is very hard to follow so I will let that
up to you. Looks like you have tables five-deep? Maintenance nightmare.
> I'm not an HTML expert and I was wondering if perhaps some
> translators/converters exist, which convert transitional code into
> strict code. Any ideas?
Sorry, can't help with that. I've been writing Strict for so long I
wouldn't know where to look, 'cept Google...
--
-bts
-Four wheels carry the body; two wheels move the soul
Jukka K. Korpela
> I was trying to convert the pages from my site from transitional to
> strict and ran into problems.
It's usually pointless, and sometimes outright harmful, to convert existing
pages from one HTML version to another.
> http://www.molon.de/l/upsgn1.html
There are several more important issues there than the syntactic nitpicking
that HTML 4.01 Strict (vs. Transitional) is about. For example, setting a
large fixed width is a bad idea. And if you test the page with images
disabled (easy on Firefox when you have Web Developer Extensions installed,
as any web author should have), you'll understand _why_ alt attributes are
required and you know better than to use alt="" for an image containing
text.
> A validator check shows 12 errors.
And they are all described rather clearly. If you really want to work on
this, just read the explanations and fix the errors that you understand,
then re-validate. (Often fixing one simple error removes some other error
messages as well.) The only confusing thing here is that several errors are
caused by the use of text-level (inline) elements directly inside a <form>
element.
> BTW, INPUT elements are not allowed
> anymore in HTML 4?
Of course they are. In Strict, they must be wrapped inside block-level
containers (such as div or table).
> I'm not an HTML expert and I was wondering if perhaps some
> translators/converters exist, which convert transitional code into
> strict code. Any ideas?
It would be possible to create a converter, and most probably pointless. In
particular, some styling features that are possible in HTML 4.01
Transitional are not allowed in HTML 4.01 Strict and either very problematic
or impossible to do in CSS as currently defined and implemented. But of
course "conversion" can be defined in various ways, e.g. so that
presentational attributes and elements that are disallowed in HTML 4.01 are
simply omitted. :-)
In general, you should use CSS rather than HTML for presentational (styling)
features, but it is usually pointless to do HTML to CSS conversion for
existing documents. What you might find useful is learning the CSS way of
doing things that you accustomed to doing in HTML, especially since CSS
usually gives more possibilities and often an easier way. So don't change
existing documents, change your mind and habits. See "Mapping presentational
HTML to CSS",
http://www.cs.tut.fi/~jkorpela/html2css.html
--
Yucca, http://www.cs.tut.fi/~jkorpela/
Alfred Molon
Shagnasty says...
> Yes, of course they are. See the actual error message:
> "document type does not allow element "INPUT" here; missing one of "P",
> "H1", "H2", "H3", "H4", "H5", "H6", "PRE", "DIV", "ADDRESS" start-tag"
>
> Your <input>s are floating free within <td>s - rather than one of the
> above. They need to be direct descendants of one of those.
>
> I think you also have mis-level form tags as well. e.g. the <form> and
> the </form> are somehow not inside the same <td>. With all those
> myriads of nested tables, it is very hard to follow so I will let that
> up to you.
Well, it's a form and a table is the simplest way to adjust the layout.
HTML 4 may not like it, but if you use div elements to achieve the same
result the whole thing does not get simpler, it gets more complex.
> Looks like you have tables five-deep? Maintenance nightmare.
But this page is never changed, no need to maintain it.
Rob W.
>> the</form> are somehow not inside the same<td>. With all those
>> myriads of nested tables, it is very hard to follow so I will let that
>> up to you.
>
> Well, it's a form and a table is the simplest way to adjust the layout.
Seems like a table is not the simplest way to house a div-encapsulated
form with another table next to it.
--
Rob
Alfred Molon
> Also, don't use for formatting.
How else to push things a little bit to the right or leave some space in
between?
Jukka K. Korpela
>> Your <input>s are floating free within <td>s - rather than one of the
>> above. They need to be direct descendants of one of those.
[...]
> Well, it's a form and a table is the simplest way to adjust the
> layout.
There's nothing wrong with structuring a form as table, typically with
labels in one column and corresponding fields in another, and there's
nothing wrong in letting that create a tabular layout.
The statement about <input>s floating free within <td>s is misleading. There
is nothing wrong with <td><input ...></td> as such. A <form> element may
contain a <table> which must contain a <tr> which may contain a <td> which
may contain an <input>. No reason to introduce a block level container,
since <table> is such a container.
However, e.g. the following is a syntax error, in _any_ version of HTML:
<div style="margin: 5px;">
<form method="post" action="gbwrite.php">
</div>
When you start a <form> element within a <div> element, you must end (close)
it there, too.
>> Looks like you have tables five-deep? Maintenance nightmare.
>
> But this page is never changed, no need to maintain it.
So why are you rewriting it? "There is always someone who rewrites working
code, to clean it up or to speed it up." And this saying about programming
applies to HTML authoring as well, with the same ironic tone. (Quite often,
the result is neither cleaner nor faster, but bugs are introduced, as usual
in code modifications.)
--
Yucca, http://www.cs.tut.fi/~jkorpela/
Adrienne Boswell
<alfred...@yahoo.com> writing in
news:MPG.265a4d8cc...@news.supernews.com:
> In article <slrnhv01bc....@ibook-g4.local>, Lewis says...
>> Also, don't use for formatting.
>
> How else to push things a little bit to the right or leave some space in
> between?
You use CSS, eg:
input {padding-left: .5em;}
--
Adrienne Boswell at Home
Arbpen Web Site Design Services
http://www.cavalcade-of-coding.info
Please respond to the group so others can share
Alfred Molon
> <form method="post" action="../suche/" class="searchform" >
> <div>
> <input maxlength="255" name="s" size="30" value="" class="searchform">
> <input value="Search" type="submit" class="searchform1">
> </div>
> </form>
I tried that and it messed up the layout (search window no longer in one
line with the other menu elements).
Also noticed that lots of major sites are still using transitional. Even
www.webmasterworld.com, the site of the gurus, has doctype set to
transitional. I think I'll continue sticking to transitional, as long as
the browsers support this. "Strict" is too strict for me ;-)
Alfred Molon
Boswell says...
> > How else to push things a little bit to the right or leave some space in
> > between?
>
> You use CSS, eg:
>
> input {padding-left: .5em;}
.5em corresponds to one space?
Jukka K. Korpela
> .5em corresponds to one space?
No, it means half of the font size.
A space is typically 0.25em wide, but this depends on the font design,
especially on the average width of characters.
Why do you care? It's the em unit that should be considered as the basic
unit of spacing, not a space.
--
Yucca, http://www.cs.tut.fi/~jkorpela/
Neredbojias
That's fine for your old pages but you should really at least attempt
to do new pages in "strict". The real reason for this is that it
actually offers more styling possibilites and is boded to be presented
more uniformly across different browsers.
--
Neredbojias
Alfred Molon
says...
> However, e.g. the following is a syntax error, in _any_ version of HTML:
>
> <div style="margin: 5px;">
> <form method="post" action="gbwrite.php">
> </div>
>
> When you start a <form> element within a <div> element, you must end (close)
> it there, too.
Shame. There were syntax errors in the transitional document with which
I started. I've now corrected it and it validates:
http://www.molon.de/l/upsgn.html
> So why are you rewriting it?
I was told strict is the way to go...
Jukka K. Korpela
>> "Strict" is too strict for me ;-)
>
> That's fine for your old pages but you should really at least attempt
> to do new pages in "strict". The real reason for this is that it
> actually offers more styling possibilites and is boded to be presented
> more uniformly across different browsers.
No, it offers _less_ styling possibilities and it tends to be presented
_less_ uniformly.
The real reason for using Strict is that a) it is conceptually more logical
and b) it forces you to do at least part of the formatting in CSS and not in
HTML, thereby separating presentation from content+structure. This is fairly
theoretical, and if you actually benefit from using non-Strict constructs,
feel free to use them (and to use a suitable DOCTYPE, for the purposes of
validation).
Anything that can be done in HTML 4.01 Strict can be done in HTML 4.01
Transitional. The reverse is not true. (You can, of course, use CSS for
styling an HTML 4.01 Transitional document, either in addition to
presentational HTML features or instead of them.)
Presentational HTML attributes and elements tends to be honored, in
consistent manner, better than CSS. Besides, CSS can be overruled by a user
style sheet or by disabling CSS support; these do not affect presentational
HTML. This is _not_ an argument in favor of using presentational HTML.
Rather the opposite. An author's presentational suggestions _should_ be
easily overridable, and any user who takes the trouble of switching CSS off
or setting up his own user style sheet should be expected to have a very
good reason to that.
--
Yucca, http://www.cs.tut.fi/~jkorpela/
Ben C
[...]
> So why are you rewriting it? "There is always someone who rewrites working
> code, to clean it up or to speed it up." And this saying about programming
> applies to HTML authoring as well, with the same ironic tone. (Quite often,
> the result is neither cleaner nor faster, but bugs are introduced, as usual
> in code modifications.)
Right, but the "working" code that was there before is also full of bugs
(even if some have been painstakingly fixed over the years).
My rule is to rewrite code when I reach the point where I am sure I
understand the problem better than the people who wrote it in the first
place.
As for converting pages to strict doctypes, that may be worth doing so
as to avoid browser quirks modes and thus increase the probability
results will look closer in browsers you haven't tested in.
Jukka K. Korpela
> As for converting pages to strict doctypes, that may be worth doing so
> as to avoid browser quirks modes and thus increase the probability
> results will look closer in browsers you haven't tested in.
If a page has been designed loosely, the odds are that it relies on "quirks"
mode, so converting it to something that triggers "standards" mode might be
particularly counter-productive.
However, if you wish to enhance an existing page e.g. by using CSS features
that aren't supported by IE in "quirks" mode (there are loads of such
features), then you might consider changing your DOCTYPE. But only after
checking that the page, with no enhancements, really works in "standards"
mode.
Using Strict syntax is quite immaterial here. What matters is the DOCTYPE
declaration, at the string level, as a "magic string" that triggers "quirks"
or "standards" mode - quite independently of actual conformance to the
declared document type definition.
--
Yucca, http://www.cs.tut.fi/~jkorpela/
Ben C
> Ben C wrote:
>
>> As for converting pages to strict doctypes, that may be worth doing so
>> as to avoid browser quirks modes and thus increase the probability
>> results will look closer in browsers you haven't tested in.
>
> If a page has been designed loosely, the odds are that it relies on "quirks"
> mode, so converting it to something that triggers "standards" mode might be
> particularly counter-productive.
When I say "convert to a strict doctype" I mean you also fix those
things, and that's the whole point of the exercise.
Pamela
not believe, but it is true.
There are two models on
http://www.luxuryowner.net/Replica-TAG-Heuer-Tiger-Woods-Golf-Watches.html
White: Tag Heuer Tiger Woods Golf White Mens Watch WAE1112.FT6008:
http://www.luxuryowner.net/Replica-Tag-Heuer-Tiger-Woods-Golf-White-Mens-Watch-WAE1112.FT6008.html
Black: Tag Heuer Tiger Woods Golf Black Mens Watch WAE1111.FT6004
http://www.luxuryowner.net/Replica-Tag-Heuer-Tiger-Woods-Golf-Black-Mens-Watch-WAE1111.FT6004.html
More replica watches you can refer: http://www.luxuryowner.net/
"Alfred Molon" <alfred...@yahoo.com>
??????:MPG.265a0d462...@news.supernews.com...
--- news://freenews.netfront.net/ - complaints: ne...@netfront.net ---
dorayme
"Pamela" <Luxuryow...@gmail.com> wrote:
> Buy high quality...
>
> "Alfred Molon" <alfred...@yahoo.com>
> ??????:MPG.265a0d462...@news.supernews.com...
> >I was trying to convert the pages from my site from transitional to
> > strict and ran into problems.
> >
Please do not top post.
--
dorayme
Neredbojias
That was goofy - replying to a spam post. See, we all have our little
quirks.
GTalbot
> I was trying to convert the pages from my site from transitional to
> strict and ran into problems.
[snipped]
> I was wondering if perhaps some
> translators/converters exist, which convert transitional code into
> strict code.
HTML Tidy would do that but it's not a perfect tool to convert page
written according to a transitional DTD into one written according to
strict DTD.
There are several HTML Tidy options which do that:
clean:
This option specifies if Tidy should strip out surplus presentational
tags and attributes replacing them by style rules and structural
markup as appropriate. It works well on the HTML saved by Microsoft
Office products.
http://tidy.sourceforge.net/docs/quickref.html#clean
drop-font-tags:
This option specifies if Tidy should discard <FONT> and <CENTER> tags
without creating the corresponding style rules. This option can be set
independently of the clean option.
http://tidy.sourceforge.net/docs/quickref.html#drop-font-tags
enclose-block-text:
This option specifies if Tidy should insert a <P> element to enclose
any text it finds in any element that allows mixed content for HTML
transitional but not HTML strict.
http://tidy.sourceforge.net/docs/quickref.html#enclose-block-text
Best is still to learn how to fix HTML errors starting from the W3C
markup validator and learn how to avoid writing HTML errors in the
first place.
I use Bluefish 1.0.7 with HTML Tidy on Linux; I use PSPad 4.5.4 with
HTML Tidy on Windows.
These are the arguments I use with Bluefish:
tidy --char-encoding utf8 --clean yes --doctype strict --drop-font-
tags yes --drop-proprietary-attributes yes --enclose-block-text yes --
enclose-text yes -indent --logical-emphasis yes --output-html yes --
replace-color yes --show-warnings no --wrap 76 --write-back yes >'%f'
2>/dev/null
regards, Gérard
--
Internet Explorer 7 bugs: 185 bugs so far
http://www.gtalbot.org/BrowserBugsSection/MSIE7Bugs/
Internet Explorer 8 bugs: 60 bugs so far
http://www.gtalbot.org/BrowserBugsSection/MSIE8Bugs/
GTalbot
> In article <slrnhv01bc.1hin.g.kr...@ibook-g4.local>, Lewis says...
>
> > Try this:
> > <form method="post" action="../suche/" class="searchform" >
> > <div>
> > <input maxlength="255" name="s" size="30" value="" class="searchform">
> > <input value="Search" type="submit" class="searchform1">
> > </div>
> > </form>
>
> I tried that and it messed up the layout (search window no longer in one
> line with the other menu elements).
Then you should continue to investigate your markup code, CSS code.
> Also noticed that lots of major sites are still using transitional. Evenwww.webmasterworld.com, the site of the gurus, has doctype set to
> transitional.
This is an utterly weak argument. Because others don't do "x" (or do
"y"), then I won't do "x" (or will do "y").
> I think I'll continue sticking to transitional, as long as
> the browsers support this. "Strict" is too strict for me ;-)
Strict, by definition, should be better supported than transitional as
it does not have presentational elements and presentational
attributes. The strict DTD is reduced, smaller than transitional DTD.
But what you said is revealing how many people think and feel about
strict DTD: they think it will be strict, enforcing parsing rules,
etc.
Strict should be understood has more pure HTML, more correct HTML, not
necessarly more strict or less forgiving, or less lenient.
GTalbot
> Alfred Molon wrote:
> > I was trying to convert the pages from my site from transitional to
> > strict and ran into problems.
>
> It's usually pointless, and sometimes outright harmful, to convert existing
> pages from one HTML version to another.
>
> >http://www.molon.de/l/upsgn1.html
>
> There are several more important issues there than the syntactic nitpicking
> that HTML 4.01 Strict (vs. Transitional) is about.
There may be other more important issues: it's usually the case too.
But, in the process of making a webpage, if making sure that
presentation and style are done by CSS then it becomes normal to
declare a reference to a strict DTD. Fixing validation markup errors
does not fix everything but it's nevertheless a necessary minimum.
For example, setting a
> large fixed width is a bad idea. And if you test the page with images
> disabled (easy on Firefox when you have Web Developer Extensions installed,
> as any web author should have), you'll understand _why_ alt attributes are
> required and you know better than to use alt="" for an image containing
> text.
A missing alt attribute is going to be reported by a validator as a
validation markup error.
> It would be possible to create a converter, and most probably pointless.
I disagree. I've used HTML Tidy to convert several hundreds of
webpages to use a doctype declaration referencing a strict DTD at
mozilla.org and never thought it was pointless.
> In
> particular, some styling features that are possible in HTML 4.01
> Transitional are not allowed in HTML 4.01 Strict and either very problematic
> or impossible to do in CSS as currently defined and implemented.
I'm curious. Can you name a few of such styling features that are
possible in HTML 4.01
Transitional and that are not allowed in HTML 4.01 Strict and either
very problematic
or impossible to do in CSS as currently defined and implemented. ?
> In general, you should use CSS rather than HTML for presentational (styling)
> features, but it is usually pointless to do HTML to CSS conversion for
> existing documents. What you might find useful is learning the CSS way of
> doing things that you accustomed to doing in HTML, especially since CSS
> usually gives more possibilities and often an easier way. So don't change
> existing documents, change your mind and habits. See "Mapping presentational
> HTML to CSS",http://www.cs.tut.fi/~jkorpela/html2css.html
I see errors or questionable "CSS or HTML+CSS replacements" in that
"Mapping presentational HTML to CSS".
1- <element align="center"> You give
<table style="margin-left: auto; margin-right: auto;"> (for table
elements)
but that should be for block-level elements too.
2-
<table bordercolor="color"> . First bordercolor is invalid.
<table style="border-color: color">
Second: without a border-style, the declaration border-color: color
will be ignored.
3- <center>content</center> <div style="text-align:center">content</
div>
It can be margin-left: auto; margin-right: auto; for block level
elements. It depends on what the author intended. <center> can be
converted in 2 manners; it depends on the context and what the author
intended.
4- <ol start="number"> no CSS counterpart
but there is counter-reset for this and list-style-type: decimal.
regards, Gérard
Jeremy J Starcher
> I'm curious. Can you name a few of such styling features that are
> possible in HTML 4.01
> Transitional and that are not allowed in HTML 4.01 Strict and either
> very problematic
> or impossible to do in CSS as currently defined and implemented. ?
Actually, I can ... but in the end I was finally able to abandon it.
One of my sites [the parts lookup] was used by a customer who used an old
cell phone that only had some HTML 3.2 browser on it. I used a table
structure and a center tag to get a layout that worked. When he upgraded
phones, I dropped all that.
(He would use his phone while he crawled around a bike, ordering parts
right off the parts list instead of trying to write things down an order
them later.)
Jukka K. Korpela
> But, in the process of making a webpage, if making sure that
> presentation and style are done by CSS then it becomes normal to
> declare a reference to a strict DTD.
It depends. If you need, say, a working method (i.e. one that works at least
in most situations) for allowing (but not requiring) a line break in a
string, then you should use the <wbr> tag and just deal with the
consequences in validation. You might still declare the Strict DTD (to get
"standards" mode) but then you need to ignore certain errors, and finding
unintentional markup errors becomes more difficult. Of course, in this
context, Transitional would not help. My point is that document type
declarations are something to be chosen on very pragmatic grounds.
>> you'll understand _why_
>> alt attributes are required and you know better than to use alt=""
>> for an image containing text.
>
> A missing alt attribute is going to be reported by a validator as a
> validation markup error.
Yes, with any published HTML DOCTYPE since 3.2. But my point was that
validators do _not_ catch alt="" - it's not a syntax error, and it would be
quite wrong to report it as syntax error.
> I've used HTML Tidy to convert several hundreds of
> webpages to use a doctype declaration referencing a strict DTD at
> mozilla.org and never thought it was pointless.
Well, you didn't tell us what the point was.
Mechanical conversions like those performed by HTML Tidy when I last used it
(admittedly, years ago) tend to make the document more messy, not less. When
I see presentational attributes in a tag, I know what they relate to. If I
see some CSS code with an automatically generated non-mnemonic
non-suggestive class name, I need to search for that class name's
occurrences to see what is being done.
> Can you name a few of such styling features that are
> possible in HTML 4.01 Transitional and that are not allowed in
> HTML 4.01 Strict and either very problematic
> or impossible to do in CSS as currently defined and implemented. ?
1) <ol start="42"> and <ol value="10">
2) target attribute
3) <small> (no defined counterpart in CSS - operates with a special scale of
sizes)
4) <menu> (I know I'm stretching here, but a browser may render <menu> and
<ul> differently - that was originally the intent, and Lynx does that - and
since you cannot in general know what the difference might be, how could you
achieve it in CSS?)
> I see errors or questionable "CSS or HTML+CSS replacements" in that
> "Mapping presentational HTML to CSS".
Thanks for pointing these out.
> 2-
> <table bordercolor="color"> . First bordercolor is invalid.
Whether it is valid depends on the document type definition. Besides, it's
irrelevant, since the topic of my page is practical mapping from
presentational HTML to CSS, without taking a position on "standards" or the
question whether people should use presentational HTML or CSS.
> <table style="border-color: color">
> Second: without a border-style, the declaration border-color: color
> will be ignored.
So the effect is just the same as for bordercolor="color"
> 4- <ol start="number"> no CSS counterpart
> but there is counter-reset for this and list-style-type: decimal.
That does not correspond to the start attribute, which affects the number in
the numbering that browsers generate by default for <ol>. If you use
counters, you must specifically _suppress_ such numbering, otherwise you
will get two numbers for each item. This means that the rendering will be
different, except by accident.
--
Yucca, http://www.cs.tut.fi/~jkorpela/
Jukka K. Korpela
> 1- <element align="center"> You give
> <table style="margin-left: auto; margin-right: auto;"> (for table
> elements)
> but that should be for block-level elements too.
[...]
> 3- <center>content</center> <div style="text-align:center">content</
> div>
> It can be margin-left: auto; margin-right: auto; for block level
> elements. It depends on what the author intended. <center> can be
> converted in 2 manners; it depends on the context and what the author
> intended.
When I reread these comments, while editing my document, I realized that
there seems to be an error in your error correction.
By HTML specifications, <div align="center">...</div> and
<center>...</center> are equivalent and center each line in the content.
This means that text-align: center is the CSS equivalent.
Some old browsers are known to deviate from the specifications, and indeed
some authors may have relied on faulty behavior, but that's what I describe
at
http://www.cs.tut.fi/~jkorpela/html2css#al
--
Yucca, http://www.cs.tut.fi/~jkorpela/
Jukka K. Korpela
>> 3) <small> (no defined counterpart in CSS - operates with a special
>> scale of sizes)
>
> font-size: 90%;
>
> and for smaller
>
> font-size: 80%;
Thank you for the usual bogosity signals, including forged sender
information and lack of any citation, in a context where you a replying to a
statement about lack of _defined_ counterpart. If you claim that there is a
defined correspondence, you should be able to cite a definition.
Besides, your statement is wrong even if taken just as an observation of how
browsers typically behave in the implementation of <small>. To see this,
just try
<small>W</small><span style="font-size:90%">W</span>
on some browsers. Using a large basic font size will help you make the
observations faster.
--
Yucca, http://www.cs.tut.fi/~jkorpela/
GTalbot
> GTalbot wrote:
> > But, in the process of making a webpage, if making sure that
> > presentation and style are done by CSS then it becomes normal to
> > declare a reference to a strict DTD.
>
> It depends. If you need, say, a working method (i.e. one that works at least
> in most situations) for allowing (but not requiring) a line break in a
> string, then you should use the <wbr> tag and just deal with the
> consequences in validation. You might still declare the Strict DTD (to get
> "standards" mode) but then you need to ignore certain errors, and finding
> unintentional markup errors becomes more difficult. Of course, in this
> context, Transitional would not help. My point is that document type
> declarations are something to be chosen on very pragmatic grounds.
Instead of <wbr>, I believe there is a character entity for this...
but it's not well supported IIRC.
"­
A soft hyphen (­) indicates where an optional word break may
occur. (...)"
http://www.robinlionheart.com/stds/html4/spchars
> > I've used HTML Tidy to convert several hundreds of
> > webpages to use a doctype declaration referencing a strict DTD at
> > mozilla.org and never thought it was pointless.
>
> Well, you didn't tell us what the point was.
The point was to achieve clearer separation of style and presentation
from content and structure. More consistent look, more consistent
coding manners, therefore easier to maintain, to do site-wide changes
if needed.
> Mechanical conversions like those performed by HTML Tidy when I last used it
> (admittedly, years ago) tend to make the document more messy, not less.
You need to test HTML Tidy, experiment, make adjustments. Tuning of
options to use is delicate in HTML Tidy when you're beginning with
HTML Tidy.
> When
> I see presentational attributes in a tag, I know what they relate to. If I
> see some CSS code with an automatically generated non-mnemonic
> non-suggestive class name, I need to search for that class name's
> occurrences to see what is being done.
You have a point here. I totally agree with you on this. I manually
have to rename "c" classes (generated by HTML Tidy) into better
descriptive class names, more mnemonic, intuitive class names.
css-prefix
This option specifies the prefix that Tidy uses for styles rules. By
default, "c" will be used.
http://tidy.sourceforge.net/docs/quickref.html#css-prefix
Some options in HTML Tidy are not that useful; others are more useful,
I'd say.
> > Can you name a few of such styling features that are
> > possible in HTML 4.01 Transitional and that are not allowed in
> > HTML 4.01 Strict and either very problematic
> > or impossible to do in CSS as currently defined and implemented. ?
>
> 1) <ol start="42"> and <ol value="10">
I would suggest to use counter-reset.
> 2) target attribute
Frames are pretty much obsolete, definitely not recommendable. There
is the target property in a CSS 3 module. Anyway, I do not recommend
any of this. target as an HTML attribute is really something which
should not be used anymore
> 3) <small> (no defined counterpart in CSS - operates with a special scale of
> sizes)
I would suggest CSS declaration
{font-size: smaller;}
as a CSS replacement for <small>
> > 2-
> > <table bordercolor="color"> . First bordercolor is invalid.
>
> Whether it is valid depends on the document type definition.
bordercolor is not in any document type definition that I know of.
It's not in transitional DTD. bordercolor is not listed in HTML 3.2
and is not listed in HTML 4.01. bordercolor is an HTML extension from
Microsoft.
> Besides, it's
> irrelevant, since the topic of my page is practical mapping from
> presentational HTML to CSS, without taking a position on "standards" or the
> question whether people should use presentational HTML or CSS.
Okay. Fair enough.
>
> > <table style="border-color: color">
> > Second: without a border-style, the declaration border-color: color
> > will be ignored.
>
> So the effect is just the same as for bordercolor="color"
I am not sure. I would need to test this. I believe
bordercolor="color" will be honored in quirks mode in a number of
browsers with a default solid (or is it outset?) border and a default
2px width. When converting to HTML 4.01 strict, <table style="border-
color: color"> may not suffice.
> > 4- <ol start="number"> no CSS counterpart
> > but there is counter-reset for this and list-style-type: decimal.
>
> That does not correspond to the start attribute, which affects the number in
> the numbering that browsers generate by default for <ol>.
> If you use
> counters, you must specifically _suppress_ such numbering, otherwise you
> will get two numbers for each item. This means that the rendering will be
> different, except by accident.
I understand what you're saying. <ol> would have to be dropped then.
It could still work with a counter-reset set at, say, 42 and a counter-
increment.
regards, Gérard
dorayme
<37ddc3b2-003b-45ed...@j27g2000vbp.googlegroups.co
m>,
GTalbot <news...@gtalbot.org> wrote:
> target as an HTML attribute is really something which
> should not be used anymore
I doubt there is a good argument for so sweeping a statement.
--
dorayme
Adrienne Boswell
writing in news:dorayme-20AEFB...@news.albasani.net:
I have to agree with GTalbot. The user can right click and open in a
new window or tab. Authors should not decide what the user wants to do
for him.
I use mouse gestures, have for years, and the thing I really hate is
having the back button broken.
Of course, this is with the exception of frames, which also should not
be used anymore, unless it is in an intranet application.
dorayme
Adrienne Boswell <arb...@yahoo.com> wrote:
> Gazing into my crystal ball I observed dorayme <dor...@optusnet.com.au>
> writing in news:dorayme-20AEFB...@news.albasani.net:
>
> > In article
> ><37ddc3b2-003b-45ed...@j27g2000vbp.googlegroups.co
> > m>,
> > GTalbot <news...@gtalbot.org> wrote:
> >
> >> target as an HTML attribute is really something which
> >> should not be used anymore
> >
> > I doubt there is a good argument for so sweeping a statement.
> >
>
> I have to agree with GTalbot. The user can right click and open in a
> new window or tab. Authors should not decide what the user wants to do
> for him.
>
Authors decide all sorts of things for users. Users often have
not a clue what they really want to do. Right click and open in
another tab indeed! Do you really dream that the average person
on the Clapham bus would know such a thing? There is a super
idealised caricature of the user that is behind the idea that
target should *never* be used.
> I use mouse gestures, have for years, and the thing I really hate is
> having the back button broken.
Yes, and you mention this because there is something typical
about you? Mouse gestures!
I become uneasy when I hear that a film is going to be more than
90 or so minutes and I get a panic attack if it is over 120 or so
mins. But I will not be banning such films when I become ruler of
the world. This caution allows for various circumstances hard to
foresee.
--
dorayme
GTalbot
> GTalbot wrote:
> > 4- <ol start="number"> no CSS counterpart
> > but there is counter-reset for this and list-style-type: decimal.
>
> That does not correspond to the start attribute, which affects the number in
> the numbering that browsers generate by default for <ol>. If you use
> counters, you must specifically _suppress_ such numbering,
list-style-type: none suppress such numbering.
> otherwise you
> will get two numbers for each item. This means that the rendering will be
> different, except by accident.
Ok. I created a testpage on this:
CSS replacement for <ol start="42">
http://www.gtalbot.org/BrowserBugsSection/css21testsuite/css-replacement-list-start-attribute.html
2 rules and 4 declarations is all that is needed.
It works as expected in Firefox 3.6.3, Opera 10.10, Konqueror 4.4.3,
Chrome 5.0.375.55. It should work in IE8.
regards, Gérard
--
Internet Explorer 7 bugs: 185 bugs so far
http://www.gtalbot.org/BrowserBugsSection/MSIE7Bugs/
Internet Explorer 8 bugs: 60 bugs so far
http://www.gtalbot.org/BrowserBugsSection/MSIE8Bugs/
Contributions to CSS 2.1 test suite from web authors:
http://www.gtalbot.org/BrowserBugsSection/css21testsuite/
dorayme
<78092639-9b2a-41c7...@j27g2000vbp.googlegroups.co
> CSS replacement for <ol start="42">
> http://www.gtalbot.org/BrowserBugsSection/css21testsuite/css-replacement-list-
> start-attribute.html
Dangerous if CSS is off, imagine if the steps were algorithm for
bomb making and suddenly the 42nd step is step number one...
--
dorayme
Neil Gould
> Gazing into my crystal ball I observed dorayme
> <dor...@optusnet.com.au> writing in
> news:dorayme-20AEFB...@news.albasani.net:
>
>> In article
>> <37ddc3b2-003b-45ed...@j27g2000vbp.googlegroups.co
>> m>,
>> GTalbot <news...@gtalbot.org> wrote:
>>
>>> target as an HTML attribute is really something which
>>> should not be used anymore
>>
>> I doubt there is a good argument for so sweeping a statement.
>>
>
> I have to agree with GTalbot. The user can right click and open in a
> new window or tab. Authors should not decide what the user wants to
> do for him.
>
> I use mouse gestures, have for years, and the thing I really hate is
> having the back button broken.
>
> Of course, this is with the exception of frames, which also should not
> be used anymore, unless it is in an intranet application.
>
There are some presentational situations (beyond intranet) that are best
served by the use of frames, and there is no CSS equivalent that works with
all browsers, as frames do. There are facilities within the existing frames
model to address almost every concern that I've read from those who oppose
their usage, and I haven't seen one legitimate concern for dropping them
(no, I don't need to re-read the "frames are evil" drivel) so AFAICT, there
isn't a good reason NOT to use frames if they're the best solution to a
presentational requirement.
--
best,
Neil
Neil Gould
> Ok. I created a testpage on this:
>
> CSS replacement for <ol start="42">
>
http://www.gtalbot.org/BrowserBugsSection/css21testsuite/css-replacement-list-start-attribute.html
>
> 2 rules and 4 declarations is all that is needed.
>
> It works as expected in Firefox 3.6.3, Opera 10.10, Konqueror 4.4.3,
> Chrome 5.0.375.55. It should work in IE8.
>
My beef with the arbitrary deprecation of working structures is that it is
often done without a functionally superior replacement, and your test is a
good example of that problem.
--
Best regards,
Jonathan N. Little
> There are some presentational situations (beyond intranet) that are best
> served by the use of frames, and there is no CSS equivalent that works with
> all browsers, as frames do. There are facilities within the existing frames
> model to address almost every concern that I've read from those who oppose
> their usage, and I haven't seen one legitimate concern for dropping them
> (no, I don't need to re-read the "frames are evil" drivel) so AFAICT, there
> isn't a good reason NOT to use frames if they're the best solution to a
> presentational requirement.
>
Ugh! Again...
Simple reason: because a much better implementation can be done via
server-side scripting. Frames was a Netscape invention to accommodate
document modular assembly at a time when server-side technologies were
very limited. That is not the case now, and even Netscape abandoned
using frames shortly after their introduction. Frames are a little like
White-Out, indispensable in the age of typewriters but obsolete in the
age of Word Processors.
--
Take care,
Jonathan
-------------------
LITTLE WORKS STUDIO
http://www.LittleWorksStudio.com
Neil Gould
> Neil Gould wrote:
>
>> There are some presentational situations (beyond intranet) that are
>> best served by the use of frames, and there is no CSS equivalent
>> that works with all browsers, as frames do. There are facilities
>> within the existing frames model to address almost every concern
>> that I've read from those who oppose their usage, and I haven't seen
>> one legitimate concern for dropping them (no, I don't need to
>> re-read the "frames are evil" drivel) so AFAICT, there isn't a good
>> reason NOT to use frames if they're the best solution to a
>> presentational requirement.
>>
>
> Ugh! Again...
>
> Simple reason: because a much better implementation can be done via
> server-side scripting.
>
approach adds a lot of complexity to a relatively simple presentational task
and isn't as universally functional as frames. Although your opinion is not
uncommon among web programmers, you still haven't provided a good reason why
frames should be abandoned.
--
Best regards,
Jukka K. Korpela
> CSS replacement for <ol start="42">
> http://www.gtalbot.org/BrowserBugsSection/css21testsuite/css-replacement-list-start-attribute.html
>
> 2 rules and 4 declarations is all that is needed.
>
> It works as expected in Firefox 3.6.3, Opera 10.10, Konqueror 4.4.3,
> Chrome 5.0.375.55. It should work in IE8.
It "works" in IE 8 as well, in the same sense as on other browsers you
mentioned: when style sheet support is enabled, it creates a numbered list
with numbering starting at 42.
But it does _not_ work as a replacement for <ol start="42"> in the sense of
creating the same appearance. The left indentation is different, and so is
the spacing between the number and the item text. You can add rules to
affect that, but the effect depends on the browser, as the spacing of the
numbers generated by browsers by default for <ol> may vary.
Now you might say that this is irrelevant and that CSS-generated spacing can
be more consistent and that pages should not rely on details of spacing. And
I might agree, mostly. But you still cannot replace the start="42" attribute
by CSS code that creates the _same_ effect. Similar, maybe essentially
similar, and maybe much better - but still not the same.
And there are lots of web pages that rely in details of formatting, so the
cleanup could actually do some harm.
--
Yucca, http://www.cs.tut.fi/~jkorpela/
GTalbot
> Authors decide all sorts of things for users. Users often have
> not a clue what they really want to do. Right click and open in
> another tab indeed! Do you really dream that the average person
> on the Clapham bus would know such a thing? There is a super
> idealised caricature of the user that is behind the idea that
> target should *never* be used.
A very wide majority of graphical web browsers (IE7+, Firefox 1+,
Opera 7+, Safari 3+, Konqueror 3+, Chrome 3+) in use today are tab-
capable web browsers and they all have a setting which allow users to
divert a new window (or linked reference with a target attribute) into
a new tab or into the same window. So, for a lot of reasons, the
target attribute, as originally designed, fails (or can not be ensured
that it will succeed as originally designed/planned) for a majority of
people. The least successful one (with regards to opening a new
window) must be <a href="..." target="_blank">.
"
The HTML 4.01 target attribute is primarly used to target a specified
frame but it can also target a new window or an already opened
secondary window. Clicking a link which has a target attribute will no
longer open another window (or an already opened window) if the user
has checked (...)
"
http://www.gtalbot.org/FirefoxSection/Popup/PopupAndFirefox.html#OpenLinkNewWindow
regards, Gérard
Jukka K. Korpela
> Instead of <wbr>, I believe there is a character entity for this...
> but it's not well supported IIRC.
>
> "­
No, it is a completely different thing. See
http://www.cs.tut.fi/~jkorpela/html/nobr.html#suggest
for a lengthy explanation.
> The point was to achieve clearer separation of style and presentation
> from content and structure.
That's a theoretical benefit - no tangible effect on the functionality or
appearance on the page, _except_ that you may break a page in converting it
(after all, we make mistakes, and computers are great in assisting us there)
and that the page won't look as it used to when CSS is off. Very marginally,
you might achieve some reduction in page size and thereby in load time, if
you manage to replace lots of <font> etc. markup by some simple CSS.
> More consistent look, more consistent
> coding manners, therefore easier to maintain, to do site-wide changes
> if needed.
Maybe - but is there a proof thereof? And maintainability and modifiability
depends on much more than Strict vs. Transitional. To create a really
maintainable and easily modifiable _site_ you would need to redesign it, not
just modify the markup. You should probably then start from selecting or
creating tools and procedures for generating the pages etc., and then you
would basically reconstruct the markup, not just convert it.
> Tuning of options to use is delicate in HTML Tidy when you're beginning
> with
> HTML Tidy.
Thanks for the heads-up. :-) I'll keep avoiding HTML Tidy if I can.
>> 1) <ol start="42"> and <ol value="10">
>
> I would suggest to use counter-reset.
As discussed in another sub-thread, it does not do exactly the same, and it
does not work widely enough to justify the approach in WWW authoring.
>> 2) target attribute
>
> Frames are pretty much obsolete, definitely not recommendable.
The issue was converting from Transitional to Strict by replacing non-Strict
constructs by CSS, not the desirability or usefulness of such constructs.
Millions of pages use the target attribute. Hint: It cannot be replaced by
CSS, but it can be replaced by JavaScript, though here, too, you cannot
achieve _exactly_ the same effect (except by cheating: by using JavaScript
that modifies the document by adding a target attribute!).
>> 3) <small> (no defined counterpart in CSS - operates with a special
>> scale of sizes)
>
> I would suggest CSS declaration
> {font-size: smaller;}
> as a CSS replacement for <small>
One might also say font-size: 10pt, and it _might_ (just as your suggestion
_might_) have the same effect on some browsers under some conditions. Or,
more sensibly, one might say font-size: 85%, and it might, by accident, have
the same effect. The point is that <small> is of its own kind.
>>> 2-
>>> <table bordercolor="color"> . First bordercolor is invalid.
>>
>> Whether it is valid depends on the document type definition.
>
> bordercolor is not in any document type definition that I know of.
Well, that can be arranged. See
http://www.cs.tut.fi/~jkorpela/html/own-dtd.html#tagsoup
> I am not sure. I would need to test this. I believe
> bordercolor="color" will be honored in quirks mode in a number of
> browsers with a default solid (or is it outset?) border and a default
> 2px width. When converting to HTML 4.01 strict, <table style="border-
> color: color"> may not suffice.
You're right, bordercolor also sets the border style to solid (as opposite
to outset, which is what most browsers use by default), but it's even more
complex. The effect does not depend on quirks vs. standards mode, but it
depends on browser. On Firefox, bordercolor sets only the color of the
border around the table; on IE, cell borders are affected too.
This is further evidence for my statement that it is not possible to convert
from Transitional to Strict, in a manner that preserves the original
formatting on all browsers, or even in a few major browsers. Moving from
Transitional to Strict thus involves a design change, not just mechanical
replacement.
--
Yucca, http://www.cs.tut.fi/~jkorpela/
Jonathan N. Little
> I agree that server-side scripting provides a lot of capability, but that
> approach adds a lot of complexity to a relatively simple presentational task
> and isn't as universally functional as frames. Although your opinion is not
> uncommon among web programmers, you still haven't provided a good reason why
> frames should be abandoned.
>
For one, savvy folks disable them to prevent falling victim to iframe
injection....
GTalbot
> GTalbot wrote:
> > CSS replacement for <ol start="42">
>
> > 2 rules and 4 declarations is all that is needed.
>
> > It works as expected in Firefox 3.6.3, Opera 10.10, Konqueror 4.4.3,
> > Chrome 5.0.375.55. It should work in IE8.
>
> It "works" in IE 8 as well, in the same sense as on other browsers you
> mentioned: when style sheet support is enabled, it creates a numbered list
> with numbering starting at 42.
>
> But it does _not_ work as a replacement for <ol start="42"> in the sense of
> creating the same appearance. The left indentation is different, and so is
> the spacing between the number and the item text. You can add rules to
> affect that, but the effect depends on the browser, as the spacing of the
> numbers generated by browsers by default for <ol> may vary.
>
> Now you might say that this is irrelevant and that CSS-generated spacing can
> be more consistent and that pages should not rely on details of spacing. And
> I might agree, mostly. But you still cannot replace the start="42" attribute
> by CSS code that creates the _same_ effect. Similar, maybe essentially
> similar, and maybe much better - but still not the same.
It still does not perfectly look the same; it still does not perfectly
appear the same. You may have to add a few more properties to adjust
indentation here, spacing there, etc.
> And there are lots of web pages that rely in details of formatting, so the
> cleanup could actually do some harm.
You have to test and verify before copying such code. And adjust
accordingly.
By the way,
"
The value attribute for the li element is no longer deprecated as it
is not presentational. The same goes for the start attribute of the ol
element.
"
HTML5 differences from HTML4
http://dev.w3.org/html5/html4-differences/#new-attributes
Gérard
Neredbojias
> Neil Gould wrote:
>
>> I agree that server-side scripting provides a lot of capability, but
>> that approach adds a lot of complexity to a relatively simple
>> presentational task and isn't as universally functional as frames.
>> Although your opinion is not uncommon among web programmers, you
>> still haven't provided a good reason why frames should be abandoned.
>>
>
> For one, savvy folks disable them to prevent falling victim to iframe
> injection....
Ah, but which of those 5 is really good-looking?
Neredbojias
> The issue was converting from Transitional to Strict by replacing
> non-Strict constructs by CSS, not the desirability or usefulness of
> such constructs. Millions of pages use the target attribute. Hint: It
> cannot be replaced by CSS, but it can be replaced by JavaScript,
> though here, too, you cannot achieve _exactly_ the same effect
> (except by cheating: by using JavaScript that modifies the document
> by adding a target attribute!).
That isn't "cheating"; that's using the old noodle as God intended.
As for the target attribute, I earnestly believe that the w3c was
completely ill-advised in devalidating it as they did. A better
approach would have been to try to make it more useful for what it was
originally intended as in the first place.
Neil Gould
> Neil Gould wrote:
>
>> I agree that server-side scripting provides a lot of capability, but
>> that approach adds a lot of complexity to a relatively simple
>> presentational task and isn't as universally functional as frames.
>> Although your opinion is not uncommon among web programmers, you
>> still haven't provided a good reason why frames should be abandoned.
>>
>
> For one, savvy folks disable them to prevent falling victim to iframe
> injection....
>
Peter
says...
Iframes are used for most online credit card authentication pages, such
as Verified by Visa, would you believe. Not saying I'm recommending it,
but as bad as you make it out to be, it is used in one of the most
important parts of any online shopping transaction.
--
Pete Ives
Remove All_stRESS before sending me an email
dorayme
<429647cd-ef97-4c9b...@c13g2000vbr.googlegroups.co
> On 26 mai, 23:52, dorayme <dora...@optusnet.com.au> wrote:
>
> > Authors decide all sorts of things for users. Users often have
> > not a clue what they really want to do. Right click and open in
> > another tab indeed! Do you really dream that the average person
> > on the Clapham bus would know such a thing? There is a super
> > idealised caricature of the user that is behind the idea that
> > target should *never* be used.
>
> A very wide majority of graphical web browsers (IE7+, Firefox 1+,
> Opera 7+, Safari 3+, Konqueror 3+, Chrome 3+) in use today are tab-
> capable web browsers and they all have a setting which allow users to
> divert a new window (or linked reference with a target attribute) into
> a new tab or into the same window.
And, of course, the man on the Clapham bus knows his browser
preferences (options) as well as he knows to take a brolly when
waiting for this jolly trolley.
As it happens, I have at least one of my browsers set to open
normal links in the same window but to "open new tabs instead of
new windows" and that targets target="_blank". So what? I have
never been on the Clapham bus. And if I had been I would as
likely have taken the really irritating alternative of making all
links open in new tabs or new windows or come up in 3-D in the
dunny or whatever. These things require some extra attention,
knowledge, time and patience, and motivation.
Take Adrienne for a nice bus ride and meet some ordinary
commuters. <g>
> So, for a lot of reasons, the
> target attribute, as originally designed, fails (or can not be ensured
> that it will succeed as originally designed/planned) for a majority of
> people. The least successful one (with regards to opening a new
> window) must be <a href="..." target="_blank">.
The target blank attribute can be wildly successful and do what
some authors mostly *really* want. Not all authors care deeply
that their target blank should open a *completely new browser
window*. Some of the serious ones are concerned that users not
lose their place in the text and are perfectly happy to let users
choose to open these particular links in another tab and do the
switch tab dance to go back and forth rather than simply have two
windows side by side, one (window or tab) going into detail about
some one single line or portion in or of the other.
The real motivation can be separation in any way but time. Time?
If a content is gone in time, it needs to be retrieved and this
can cause the user more trouble and not less, having to remember
more to come back. Sometimes the second window or tab will go on
to other links and if the whole show was in one window, the back
button would have to be used repeatedly (careful not to
overshoot).
Look, I am not actually a big fan of target but I do object at
over simplistic all or nothing sweeping arguments against it.
--
dorayme
dorayme
"Neil Gould" <ne...@myplaceofwork.com> wrote:
You mean Jonathan has not repeated the many documented downsides
of Frames which you have indicated a reluctance to hear again
earlier in this thread with your 'no, I don't need to re-read the
"frames are evil" drivel'.
The one big reason I moved a site made with frames to no-frames
one fine day (one fine month or two actually, it was a bit of
work!) is that I got thoroughly fed up of the URL not showing
specific enough address and the (related) bookmarking problem.
And you are now reading the words of a past fan of and present
nostalgic sentimental fool for frames.
--
dorayme
Jonathan N. Little
> In article<htm23b$oqt$1...@news.eternal-september.org>, lws...@gmail.com
> says...
>> Neil Gould wrote:
>>
>>> There are some presentational situations (beyond intranet) that are best
>>> served by the use of frames, and there is no CSS equivalent that works with
>>> all browsers, as frames do. There are facilities within the existing frames
>>> model to address almost every concern that I've read from those who oppose
>>> their usage, and I haven't seen one legitimate concern for dropping them
>>> (no, I don't need to re-read the "frames are evil" drivel) so AFAICT, there
>>> isn't a good reason NOT to use frames if they're the best solution to a
>>> presentational requirement.
>>>
>>
>> Ugh! Again...
>>
>> Simple reason: because a much better implementation can be done via
>> server-side scripting. Frames was a Netscape invention to accommodate
>> document modular assembly at a time when server-side technologies were
>> very limited. That is not the case now, and even Netscape abandoned
>> using frames shortly after their introduction. Frames are a little like
>> White-Out, indispensable in the age of typewriters but obsolete in the
>> age of Word Processors.
>>
>>
>
> Iframes are used for most online credit card authentication pages, such
> as Verified by Visa, would you believe.
Hmmmm, most? Some yes, and I have seen some of those that do break the
SSL encryption putting that lovely red broken lock in the URL inspiring
great confidence in customers. Iframes are a credible risk of XSS, just
because some sites employ bad practice does not validate it.
> Not saying I'm recommending it,
> but as bad as you make it out to be, it is used in one of the most
> important parts of any online shopping transaction.
>
--
Jonathan N. Little
> In article<htm23b$oqt$1...@news.eternal-september.org>, lws...@gmail.com
> says...
>> Neil Gould wrote:
>>
>>> There are some presentational situations (beyond intranet) that are best
>>> served by the use of frames, and there is no CSS equivalent that works with
>>> all browsers, as frames do. There are facilities within the existing frames
>>> model to address almost every concern that I've read from those who oppose
>>> their usage, and I haven't seen one legitimate concern for dropping them
>>> (no, I don't need to re-read the "frames are evil" drivel) so AFAICT, there
>>> isn't a good reason NOT to use frames if they're the best solution to a
>>> presentational requirement.
>>>
>>
>> Ugh! Again...
>>
>> Simple reason: because a much better implementation can be done via
>> server-side scripting. Frames was a Netscape invention to accommodate
>> document modular assembly at a time when server-side technologies were
>> very limited. That is not the case now, and even Netscape abandoned
>> using frames shortly after their introduction. Frames are a little like
>> White-Out, indispensable in the age of typewriters but obsolete in the
>> age of Word Processors.
>>
>>
>
> Iframes are used for most online credit card authentication pages, such
> as Verified by Visa, would you believe.
Hmmmm, most? Some yes, and I have seen some of those that do break the
SSL encryption putting that lovely red broken lock in the URL inspiring
great confidence in customers. Iframes are a credible risk of XSS, just
because some sites employ bad practice does not validate it.
> Not saying I'm recommending it,
> but as bad as you make it out to be, it is used in one of the most
> important parts of any online shopping transaction.
>
--
Jonathan N. Little
> Oh really? Aren't you conflating "Frames" and "iFrames"?
Conflating? Frames - iFrames same mechanism, just MS's inline take on a
bad idea...
Neil Gould
reason to abandon the use of frames, one would have to get beyond that and
other similar arguments.
> The one big reason I moved a site made with frames to no-frames
> one fine day (one fine month or two actually, it was a bit of
> work!) is that I got thoroughly fed up of the URL not showing
> specific enough address and the (related) bookmarking problem.
> And you are now reading the words of a past fan of and present
> nostalgic sentimental fool for frames.
>
The thing about good design is that it is based on an understanding of basic
principles to employ the best-fit solution to a problem. In the early days
of aviation, people tried copying things that worked without an
understanding of why they worked or how to make the underlying principles
serve their needs in a new design. The poor chaps that early-on tried only
one wing crashed, but those Wright brothers' airplane with two wings
actually got off the ground. So if two wings worked so well, three or ten
wings must be a better approach to achieving flight, right? After enough
people killed themselves with such contraptions, and the Wright brothers got
patents for the fundamental principles that allowed their aircraft to work,
a few of the brighter folks decided to study those principles and apply them
to new designs. Eventually, the one-wing approach was "no longer
deprecated".
Frames are not the best solution for every page, but there are circumstances
where they are the best solution. For example, in cases where the URL
needn't show (or shouldn't show) specific addresses for sub-pages, and the
designer wants a fluid, easily implemented presentation that works across
the majority of browsers without the whole screen being redrawn, causing the
context to flash and requiring the viewer to confirm that they are where
they thought they were by re-scanning the whole screen. Try achieving that
with CSS (a process I'm in the middle of as I write this, btw, and it ain't
pretty).
--
best regards,
Neil Gould
> Neil Gould wrote:
>> Oh really? Aren't you conflating "Frames" and "iFrames"?
>
> Conflating? Frames - iFrames same mechanism, just MS's inline take on
> a bad idea...
>
appear to be even remotely similar, beyond the use of the term "Frame". Not
surprisingly, they don't function the same way, either.
I get that you don't like them... but that doesn't explain why they're
functionally a bad idea or should be dropped.
--
best regards,
Jukka K. Korpela
> When I read the W3C specifications for the two, their "mechanisms" do
> not appear to be even remotely similar, beyond the use of the term
> "Frame". Not surprisingly, they don't function the same way, either.
Frames and iframes are very similar, the main difference being that an
iframe, inline frame ("floating frame"), is an inline element that you can
place in any document, wherever inline content is allowed. Frames on the
other hand must be used at the topmost syntactic level: to use them, you
make the entire document (page) a frameset and then define how it is divided
into frames.
Their _uses_ might be rather different, but the concepts and techniques are
farely similar. Basically, a document with a URL of its own is embedded in
another document, to be displayed in a fairly autonomous way (a document
displayed as such, just within a subwindow).
--
Yucca, http://www.cs.tut.fi/~jkorpela/
Athel Cornish-Bowden
[ ... ]
>
> There are some presentational situations (beyond intranet) that are best
> served by the use of frames,
This might (though I doubt it) become believable if you supplied the
URL of a page that is better with frames than without.
> and there is no CSS equivalent that works with
> all browsers, as frames do.
All browsers?!! (All except the ones that don't?)
> There are facilities within the existing frames
> model to address almost every concern that I've read from those who oppose
> their usage, and I haven't seen one legitimate concern for dropping them
> (no, I don't need to re-read the "frames are evil" drivel) so AFAICT, there
> isn't a good reason NOT to use frames if they're the best solution to a
> presentational requirement.
--
athel
Neil Gould
concept, and thanks for posting it.
I'm writing from a different perspective, as I'm currently re-creating a
site I wrote using frames about 10-15 years ago, trying to come close to the
same level of functionality with CSS and server-side scripting. The reasons
for the use of frames on that site hasn't changed, and I may just keep a
portion of that site in "frames mode" since CSS is incapable of managing
content in the same manner. Where it doesn't matter, frames are not as
convenient, but where it does...
Functionally, frames and iframes serve different purposes, have different
control parameters, and follow different principles in their implementation.
That they may share some of the same down-side issues is another matter...
;-)
--
Best regards,
Jonathan N. Little
> Jonathan N. Little wrote:
>> Neil Gould wrote:
>>> Oh really? Aren't you conflating "Frames" and "iFrames"?
>>
>> Conflating? Frames - iFrames same mechanism, just MS's inline take on
>> a bad idea...
>>
> When I read the W3C specifications for the two, their "mechanisms" do not
> appear to be even remotely similar, beyond the use of the term "Frame". Not
> surprisingly, they don't function the same way, either.
>
> I get that you don't like them... but that doesn't explain why they're
> functionally a bad idea or should be dropped.
>
Okay I will not get into the exhaustive list that ample discussion can
be found in the NG and online. But here is a little demo page that
debunks some of the "virtues" of iframes:
<http://littleworksstudio.com/temp/usenet/iframeVincludes>
Jonathan N. Little
Oh glory will be the day when IE6 joins NN4 and we designers can just
look back with a shudder, "It was only a nightmare!".
Peter
says...
Personally, I hate internet carholder authentication and avoid it like
the plague, where possible. However, here in the UK, the banks are now
forcing it upon new ecommerce sites that need to process credit cards by
charging extra for every transaction if you don't want to play along. So
there's going to be no avoiding it eventually.
All we can hope for is that they come up with something new. It was a
bad design concept from the very beginning.
Adrienne Boswell
<ne...@myplaceofwork.com> writing in
news:hto7q6$23ev$1...@adenine.netfront.net:
I use frames at work a lot of the time because they are the best thing
for what I want to do. A form in one frame, and information on the
other that is used to fill out the form. Of course, I am the only one
who uses it, so for me, it's not a big deal. I just found it more
convenient -- for me.
--
Adrienne Boswell at Home
Arbpen Web Site Design Services
http://www.cavalcade-of-coding.info
Please respond to the group so others can share
dorayme
"Neil Gould" <ne...@myplaceofwork.com> wrote:
All the best arguments against frames are exhausted in the set
that you suppose inadequate. What is your reason to be obviously
working hard to remove frames from some site you are working on
as you mention below? Are there some new arguments? I agree with
you that there might be some cases where it is perfectly adequate
and convenient to use document frames.
> > The one big reason I moved a site made with frames to no-frames
> > one fine day (one fine month or two actually, it was a bit of
> > work!) is that I got thoroughly fed up of the URL not showing
> > specific enough address and the (related) bookmarking problem.
> > And you are now reading the words of a past fan of and present
> > nostalgic sentimental fool for frames.
> >
> The thing about good design is that it is based on an understanding of basic
> principles ...
> ... The poor chaps that early-on tried only
> one wing crashed, ...
I still don't understand why a left wing on a Boeing 747 is not
sufficient to fly the plane, I think it a scandal that the public
is not told that they are doomed if the right falls off. The
airlines try to distract travellers by emphasising how the plane
can fly with just one engine and can glide. Cunning! I always
take a spare wing in case.
>
> Frames are not the best solution for every page, but there are circumstances
> where they are the best solution. For example, in cases where the URL
> needn't show (or shouldn't show) specific addresses for sub-pages, and the
> designer wants a fluid, easily implemented presentation that works across
> the majority of browsers without the whole screen being redrawn, causing the
> context to flash and requiring the viewer to confirm that they are where
> they thought they were by re-scanning the whole screen. Try achieving that
> with CSS (a process I'm in the middle of as I write this, btw, and it ain't
> pretty).
With caching and the speed of modern computers and
communications, I am not aware of any big problem with 'flashing'
where frame are dispensed with. I have many php includes in some
of my sites and the included material loads pretty much like it
would if it had been hand tailored for the page alone. The page
is assembled on the server out of sight of prying eyes, it is no
doubt an ugly business back there. But what comes out is treat
enough.
I once went back to see what went on on the server. The language
used was *disgusting*, the sheer pandemonium unsettling and the
first tries a joke. A bit like going into the kitchen of some of
our best restaurants (don't do it!). But my, what lovely frauds
would come out the door to fool the punters. "What a nice
webpage!" they would gasp. "How pretty *and* informative", "And
look at that navigation and url, no way of getting lost!"
As for fluid, I am sure this concept does not particularly belong
to frames technology.
--
dorayme
Jenn
> In article <hto7q6$23ev$1...@adenine.netfront.net>,
>>
>> Frames are not the best solution for every page, but there are
>> circumstances where they are the best solution.
...... speaking of frames......... that reminds me that pictures can be
framed ... and oh .. yeah ... some of us like to take pictures that go into
frames... and.. um... some are even really good at creating images to put
into frames....... yeah!
Hey... speaking of creating images.. did you notice the thread about the
Tennis Match game? <hint hint> :)
--
Jenn (from Oklahoma)
dorayme
"Jenn" <no...@noway.atnohow.anyday> wrote:
> dorayme wrote:
> > In article <hto7q6$23ev$1...@adenine.netfront.net>,
>
> >>
> >> Frames are not the best solution for every page, but there are
> >> circumstances where they are the best solution.
>
I don't think I said this. But I don't mind that much if I did
(as I did in in fact another possible world)
>
> ...... speaking of frames......... that reminds me that pictures can be
> framed ... and oh .. yeah ... some of us like to take pictures that go into
> frames... and.. um... some are even really good at creating images to put
> into frames....... yeah!
>
> Hey... speaking of creating images.. did you notice the thread about the
> Tennis Match game? <hint hint> :)
Yes, I did notice this. I am afraid I am not much one for games
these days, only play occasional chess and sudoku. Plus, I would
be unlikely to be so boldly off-topic in this usenet group. You
are braver than me.
btw, I mention this following because I know you like a chat: I'm
not bad at draughts but almost never play it! I was helped by a
madmen who had been locked up in a ward for the criminally insane
for the greater part of a decade and he told me he had met some
Australian draughts champion in there and that helped him
strengthen his game.
--
dorayme
Neil Gould
>
> All the best arguments against frames are exhausted in the set
> that you suppose inadequate.
>
preference, rather than of technical inadequacy of the frames element, yet
they are presented as such. The same approach could be taken for any HTML
element, and even more so for CSS.
> What is your reason to be obviously
> working hard to remove frames from some site you are working on
> as you mention below?
>
Largely because the old code os cumbersome, and can be managed more
efficiently with server-side code and CSS (e.g. the cache and faster
computers that you mentioned), so while I was at it, I restrict the use of
frames to those pages that can't be presented adequately without them.
> Are there some new arguments?
>
For or against? I can't think of a good *technical* reason not to use them,
if the W3C recommendations are followed. OTOH, not many presentations
actually require them
>>> The one big reason I moved a site made with frames to no-frames
>>> one fine day (one fine month or two actually, it was a bit of
>>> work!) is that I got thoroughly fed up of the URL not showing
>>> specific enough address and the (related) bookmarking problem.
>>> And you are now reading the words of a past fan of and present
>>> nostalgic sentimental fool for frames.
>>>
>> The thing about good design is that it is based on an understanding
>> of basic principles ...
>> ... The poor chaps that early-on tried only
>> one wing crashed, ...
>
> I still don't understand why a left wing on a Boeing 747 is not
> sufficient to fly the plane, I think it a scandal that the public
> is not told that they are doomed if the right falls off.
>
Actually, it may be, but you wouldn't want to be a passenger on that flight.
=8-0
> With caching and the speed of modern computers and
> communications, I am not aware of any big problem with 'flashing'
> where frame are dispensed with. I have many php includes in some
> of my sites and the included material loads pretty much like it
> would if it had been hand tailored for the page alone. The page
> is assembled on the server out of sight of prying eyes, it is no
> doubt an ugly business back there. But what comes out is treat
> enough.
>
I mostly agree, but this is largely a matter of what people are running,
rather than a controlled development environment. I try to stay away from
folks' "back end", since they are so varied and unpredictable.
--
best regards,
Neil
Neil Gould
> Neil Gould wrote:
>> Jonathan N. Little wrote:
>>> Neil Gould wrote:
>>>> Oh really? Aren't you conflating "Frames" and "iFrames"?
>>>
>>> Conflating? Frames - iFrames same mechanism, just MS's inline take
>>> on a bad idea...
>>>
>> When I read the W3C specifications for the two, their "mechanisms"
>> do not appear to be even remotely similar, beyond the use of the
>> term "Frame". Not surprisingly, they don't function the same way,
>> either.
>>
>> I get that you don't like them... but that doesn't explain why
>> they're functionally a bad idea or should be dropped.
>>
>
> Okay I will not get into the exhaustive list that ample discussion can
> be found in the NG and online. But here is a little demo page that
> debunks some of the "virtues" of iframes:
>
introduced those -- and they are not the same thing as html frames, even
though they may share some down-sides. In application, any in-line
structures are not likely to address the issues that would make html frames
useful.
--
best regards,
Neil
Jenn
> In article <htq1qu$l9o$1...@news.eternal-september.org>,
> "Jenn" <no...@noway.atnohow.anyday> wrote:
>
>> dorayme wrote:
>>> In article <hto7q6$23ev$1...@adenine.netfront.net>,
>>
>>>>
>>>> Frames are not the best solution for every page, but there are
>>>> circumstances where they are the best solution.
>>
> I don't think I said this. But I don't mind that much if I did
> (as I did in in fact another possible world)
>
>>
>> ...... speaking of frames......... that reminds me that pictures can
>> be framed ... and oh .. yeah ... some of us like to take pictures
>> that go into frames... and.. um... some are even really good at
>> creating images to put into frames....... yeah!
>>
>> Hey... speaking of creating images.. did you notice the thread about
>> the Tennis Match game? <hint hint> :)
>
> Yes, I did notice this. I am afraid I am not much one for games
> these days, only play occasional chess and sudoku. Plus, I would
> be unlikely to be so boldly off-topic in this usenet group. You
> are braver than me.
hahaha hey ... I've already been read the riot act in previous
discussions.. what more is there to fear by suggesting a bit of fun in a
place that is so serious? I had brought it up in previous discussions. ;)
It's not so off topic to discuss image placement within code, and people do
go off topic here quite often, anyway.
> btw, I mention this following because I know you like a chat: I'm
> not bad at draughts but almost never play it! I was helped by a
> madmen who had been locked up in a ward for the criminally insane
> for the greater part of a decade and he told me he had met some
> Australian draughts champion in there and that helped him
> strengthen his game.
Surely it never hurts to be a little bit influenced by madmen who could show
us all how to lighten up and enjoy what we do from time to time? :) What
harm is there is having a little bit of fun now and then?
--
Jenn (from Oklahoma)
Jonathan N. Little
Except the issues I list apply to 'frames' as well...
Neil Gould
> Neil Gould wrote:
>> Jonathan N. Little wrote:
>
>>> Okay I will not get into the exhaustive list that ample discussion
>>> can be found in the NG and online. But here is a little demo page
>>> that debunks some of the "virtues" of iframes:
>>>
>> Jonathan, I have not been referring to iframes in my comments -- you
>> introduced those -- and they are not the same thing as html frames,
>> even though they may share some down-sides. In application, any
>> in-line structures are not likely to address the issues that would
>> make html frames useful.
>>
>
> Except the issues I list apply to 'frames' as well...
>
most of the issues you've raised about iframes.
-- you don't have to know ahead of time what the size of the content will
be, unless your design demands it, then it isn't much of a puzzle, is it?
-- even with ie, the frame's background will be whatever you set it to be,
etc.
I don't understand why you insist that they are the same or should be
regarded equally.
--
best regards,
Neil
freemont
> I try to stay away from
> folks' "back end", since they are so varied and unpredictable.
*cough*
We just had a son Tuesday. Talk about an unpredictable back end. :-o
--
⁂ "Because all you of Earth are idiots!"
¯`·.¸¸.·´¯`·-> ※freemont※ <-·´¯`·.¸¸.·´¯
Neil Gould
> On Sat, 29 May 2010 09:27:06 -0400, Neil Gould writ:
>
>> I try to stay away from
>> folks' "back end", since they are so varied and unpredictable.
>
> *cough*
>
> We just had a son Tuesday. Talk about an unpredictable back end. :-o
>
most interesting and challenging experiences that life has to offer!
--
best regards,
Neil
(I'm waiting for my son and grandson to get here)
Jonathan N. Little
> Jonathan N. Little wrote:
>> Neil Gould wrote:
>>> Jonathan N. Little wrote:
>>
>>>> Okay I will not get into the exhaustive list that ample discussion
>>>> can be found in the NG and online. But here is a little demo page
>>>> that debunks some of the "virtues" of iframes:
>>>>
>>> Jonathan, I have not been referring to iframes in my comments -- you
>>> introduced those -- and they are not the same thing as html frames,
>>> even though they may share some down-sides. In application, any
>>> in-line structures are not likely to address the issues that would
>>> make html frames useful.
>>>
>>
>> Except the issues I list apply to 'frames' as well...
>>
> Not universally, and there are accommodations within the frames model for
> most of the issues you've raised about iframes.
Eh? Like what?
>
> -- you don't have to know ahead of time what the size of the content will
> be, unless your design demands it, then it isn't much of a puzzle, is it?
How? You must define the frames in row cols or % ahead of time. If the
content is larger than defined you get scrollbars just like iframe.
>
> -- even with ie, the frame's background will be whatever you set it to be,
> etc.
Only if it is defined within the individual frames. Don't believe me?
Look at:
<http://www.littleworksstudio.com/temp/usenet/frames>
> I don't understand why you insist that they are the same or should be
> regarded equally.
>
Because basically they are the same, includes done via the browser
rather that via the server. Only difference is who promoted them and one
the sub-windows are block elements and the other replaced inline... But
both have the same shortcomings.
Adrienne Boswell
<freemont...@freemontsoffice.com> writing in news:4c0149e8$0$13643
$c3e...@news.astraweb.com:
> On Sat, 29 May 2010 09:27:06 -0400, Neil Gould writ:
>
>> I try to stay away from
>> folks' "back end", since they are so varied and unpredictable.
>
> *cough*
>
> We just had a son Tuesday. Talk about an unpredictable back end. :-o
Congradulations, and if you don't mind, I would like to give you some
tips that helped me when I had my son six years ago.
1. Don't bother buying baby oil or lotion. Olive oil is better than
baby lotion or baby oil. Olive oil has vitamins in it and if your son
eats it, it's not going to cause any harm. Probably the best thing
about olive oil is what it does for diaper rash - trust me, no matter
how careful you are, your son will eventually get diaper rash. Olive
oil gets rid of mild diaper rash in about two hours, at most over night
for stubborn diaper rash. It also gets rid of cradel cap almost
instantly.
I keep two bottles of olive oil, one plain for the body, and one extra
virgin for cooking. You and your child will smell like a salad for
about a minute or two, but your skin will be nice and soft and
nourished.
2. Don't bother buying baby powder either. Corn starch is much better,
and considerably cheaper.
3. If you are near a Whole Foods or other health food store, get some
Hylands Baby Teething Tablets. Yes, I know your baby was just born, but
you will thank me later when your baby starts teething at four o'clock
in the morning. The great thing about the teething tablets is that you
can give your child one about once an hour, if need be, as opposed to
Orajel which can only be applied four times a day, and only lasts about
5 minutes. Hylands contains Belladonna, so it calms your baby more than
anything else. Having a rough day? Take a baby tablet or two, and
you'll be feeling calmer, too.
4. Sign Language videos. I started my son on Signing Time American Sign
Language [http://signingtime.com/] videos when he was about 4 months
old, the ideal time to start is 6 months. The videos will enchant your
child, and are not dumbed down, so parents can learn, too. My son was
able to sign "more" so it was recognisable at 6 months, at one year, he
was quite prolific. Signing "more" holding an item of clothing meant he
wanted to get dressed or change his clothes.
The best thing about your child learning sign language is that you will
virtually eliminate the "terrible twos". Children are frustrated
because they cannot talk, so cannot express their desires, leading to
temper tantrums. With the signing, your child has the ability to sign
what they want, and your only tantrum is if you just do not want to do
what your child wants.
Signing does not impede spoken language at all, in fact, it might help
its development. When my son started talking, he would say "please" and
then sign "please" just in case I had not understood that spoken word.
5. Make sure to not feed your son honey, maple syrup, or light or dark
corn syrup before he is a year old. These foods are often sources of
Clostridium botulinum (C. botulinum) spores, which can cause Botulism -
and that, left untreated, can kill your baby.
6. On that note, I gave my son plain yogurt as his first solid food when
he was four months old, and continued to add yogurt to his baby food. I
made my own in by cooking fruits and vegetables until they were soft,
then putting them in the food processor, then into ice trays, when
frozen, put into a plastic bag and warming it in the microwave. Home
made baby food has more taste, is less expensive, and you know what
you're getting because you made it. There are baby food making kits,
but just a blender is really all you need.
freemont
> Gazing into my crystal ball I observed freemont
> <freemont...@freemontsoffice.com> writing in news:4c0149e8$0$13643
> $c3e...@news.astraweb.com:
>
>> On Sat, 29 May 2010 09:27:06 -0400, Neil Gould writ:
>>
>>> I try to stay away from
>>> folks' "back end", since they are so varied and unpredictable.
>>
>> *cough*
>>
>> We just had a son Tuesday. Talk about an unpredictable back end. :-o
>
> Congradulations, and if you don't mind, I would like to give you some
> tips that helped me when I had my son six years ago.
>
[interesting baby tips]
Thanks a bunch, for the tips and the congratulations. :-)
This is actually my third, my wife's first. But the advice is welcome.
The olio tip is especially interesting. :-)
<http://lewispaulthomas.net/images/ejt_thinking.png>
dorayme
"Jenn" <no...@noway.atnohow.anyday> wrote:
> dorayme wrote:
> > In article <htq1qu$l9o$1...@news.eternal-september.org>,
> > "Jenn" <no...@noway.atnohow.anyday> wrote:
> >
> >> dorayme wrote:
> >>> In article <hto7q6$23ev$1...@adenine.netfront.net>,
> >>
> >>>>
...
> >> Hey... speaking of creating images.. did you notice the thread about
> >> the Tennis Match game? <hint hint> :)
> >
> > Yes, I did notice this. I am afraid I am not much one for games
> > these days,... Plus, I would
> > be unlikely to be so boldly off-topic in this usenet group. You
> > are braver than me.
>
> hahaha hey ... I've already been read the riot act in previous
> discussions.. what more is there to fear by suggesting a bit of fun in a
> place that is so serious?
You have less to lose so far. My situation is different, people
from all over the world - via alt.html - send me pigs and sheep
and chickens and dark-chocolate-coated liquorice, and this has
given me a lifestyle I only dreamt about before I came to earth.
Please Jenn, I cannot jeopardise this by any pursuits that would
lower my reputation further. I am at a tipping point, any lower
and the whole enterprise collapses. I do not have a simple
arithmetic relation with my audience, rather it is chaotic, and
the least thing could have the biggest effects to my detriment.
--
dorayme
dorayme
"Neil Gould" <ne...@myplaceofwork.com> wrote:
> dorayme wrote:
> >
> > All the best arguments against frames are exhausted in the set
> > that you suppose inadequate.
> >
> My issue with those arguments is that they are mostly a matter of
> preference, rather than of technical inadequacy of the frames element, yet
> they are presented as such. The same approach could be taken for any HTML
> element, and even more so for CSS.
>
When people argue against frames, they argue on technical
grounds. That does not mean that these grounds relate to failures
of frames to do what they were designed to do. For example, if
you assign a left navigation frame to be 20% in a frameset, the
result will never be 1% or 100%. But it is highly misleading to
say that the arguments are about mere preferences and not
technical.
The bookmarking problem needs some technical knowledge to
understand, it is a technical argument. There is no mystery in
this. If people present a lot of good reasons not to do something
and someone does it because they prefer it, that does not mean it
is a matter of preference, it might well mean that someone is not
altogether preferring optimally
> > What is your reason to be obviously
> > working hard to remove frames from some site you are working on
> > as you mention below?
> >
> Largely because the old code os cumbersome, and can be managed more
> efficiently with server-side code and CSS (e.g. the cache and faster
> computers that you mentioned), so while I was at it, I restrict the use of
> frames to those pages that can't be presented adequately without them.
>
I am curious to know what sort of pages cannot be presented
adequately without frames.
By the way, I think Jonathan going on about iframes really does
confuse the issue (however right he might be to relate the two in
general). There *may* be good and *different* reasons to use
these two and you were talking about normal good old fashioned
document frames that have framesets.
--
dorayme
Jenn
> In article <htra0r$cn5$1...@news.eternal-september.org>,
> "Jenn" <no...@noway.atnohow.anyday> wrote:
>
>> dorayme wrote:
>>> In article <htq1qu$l9o$1...@news.eternal-september.org>,
>>> "Jenn" <no...@noway.atnohow.anyday> wrote:
>>>
>>>> dorayme wrote:
>>>>> In article <hto7q6$23ev$1...@adenine.netfront.net>,
>>>>
>>>>>>
> ...
>>>> Hey... speaking of creating images.. did you notice the thread
>>>> about the Tennis Match game? <hint hint> :)
>>>
>>> Yes, I did notice this. I am afraid I am not much one for games
>>> these days,... Plus, I would
>>> be unlikely to be so boldly off-topic in this usenet group. You
>>> are braver than me.
>> hahaha hey ... I've already been read the riot act in previous
>> discussions.. what more is there to fear by suggesting a bit of fun
>> in a place that is so serious?
> You have less to lose so far. My situation is different, people
> from all over the world - via alt.html - send me pigs and sheep
> and chickens and dark-chocolate-coated liquorice, and this has
> given me a lifestyle I only dreamt about before I came to earth.
Hey ... I really like dark-chocolate ... <hint hint> :)
> Please Jenn, I cannot jeopardise this by any pursuits that would
> lower my reputation further. I am at a tipping point, any lower
> and the whole enterprise collapses. I do not have a simple
> arithmetic relation with my audience, rather it is chaotic, and
> the least thing could have the biggest effects to my detriment.
... by all means balance the weight so it does not TIP ...
--
Jenn (from Oklahoma)
Adrienne Boswell
$c3e...@news.astraweb.com:
>>> We just had a son Tuesday. Talk about an unpredictable back end. :-o
>>
>> Congradulations, and if you don't mind, I would like to give you some
>> tips that helped me when I had my son six years ago.
>>
> [interesting baby tips]
>
> Thanks a bunch, for the tips and the congratulations. :-)
>
> This is actually my third, my wife's first. But the advice is welcome.
> The olio tip is especially interesting. :-)
>
><http://lewispaulthomas.net/images/ejt_thinking.png>
>
Ahhh.. so cute!
Neil Gould
> In article <htr4ve$u1k$1...@speranza.aioe.org>,
> "Neil Gould" <ne...@myplaceofwork.com> wrote:
>
>> dorayme wrote:
>>>
>>> All the best arguments against frames are exhausted in the set
>>> that you suppose inadequate.
>>>
>> My issue with those arguments is that they are mostly a matter of
>> preference, rather than of technical inadequacy of the frames
>> element, yet they are presented as such. The same approach could be
>> taken for any HTML element, and even more so for CSS.
>>
>
> When people argue against frames, they argue on technical
> grounds.
>
the qualifier "mostly", above. Also, as I had written before, there are
accommodations within the frames element for many of the issues presented in
those arguments.
> The bookmarking problem needs some technical knowledge to
> understand, it is a technical argument.
>
If one wants a page to be "bookmarkable", a frameset may not be the easiest
way to accommodate that. However, in a good design, this is not an issue,
because the frameset page *is* bookmarkable, and sub-pages can be made
accessible as desired. In short, if one has a reason to use framesets,
bookmarking is not really a problem, it's just more work. However, there are
instances where one might not want sub-pages to be bookmarkable, anyway
(which is exactly the case with some of the pages on the site I'm re-doing),
and in those cases, frames are a lot less work.
> I am curious to know what sort of pages cannot be presented
> adequately without frames.
>
Pages where the context needs to be better controlled than one can do with
CSS or simple HTML code. I admit that this respresents a very small
percentage of web pages, but that doesn't invalidate the need.
> By the way, I think Jonathan going on about iframes really does
> confuse the issue (however right he might be to relate the two in
> general). There *may* be good and *different* reasons to use
> these two and you were talking about normal good old fashioned
> document frames that have framesets.
>
Exactly. He really doesn't like frames, does he? ;-)
--
Best regards,
Neil
Neil Gould
> Neil Gould wrote:
>>> Except the issues I list apply to 'frames' as well...
>>>
>> Not universally, and there are accommodations within the frames
>> model for most of the issues you've raised about iframes.
>
> Eh? Like what?
>
those accommodations concisely.
>> -- you don't have to know ahead of time what the size of the content
>> will be, unless your design demands it, then it isn't much of a
>> puzzle, is it?
>
> How? You must define the frames in row cols or % ahead of time.
>
Not for all frames in a frameset, you don't. And, for the case where it must
be defined, only the dimmest bulbs won't know the answer to the question.
I'm beginning to understand why you think frames and iframes are the same,
and conclude that it's best to just disagree about that and move on.
--
best regards,
Neil
Jonathan N. Little
> Jonathan N. Little wrote:
>> Neil Gould wrote:
>>>> Except the issues I list apply to 'frames' as well...
>>>>
>>> Not universally, and there are accommodations within the frames
>>> model for most of the issues you've raised about iframes.
>>
>> Eh? Like what?
>>
> If you really don't know, the W3C HTML 4.0 spec is a good read, and explains
> those accommodations concisely.
I have read it, I think it is you that lack the understanding. Okay
let's take one of the issues that I raised for example. The stylesheet.
You cannot attach a single stylesheet to the outer frameset to
universally style the framed-assembled document. Each frame must have
its own stylesheet or reference. Unlike with server-side where the
document is assembled as a single document you can have a single
background image under all parts, where this is not an option with frames.
>
>>> -- you don't have to know ahead of time what the size of the content
>>> will be, unless your design demands it, then it isn't much of a
>>> puzzle, is it?
>>
>> How? You must define the frames in row cols or % ahead of time.
>>
> Not for all frames in a frameset, you don't. And, for the case where it must
> be defined, only the dimmest bulbs won't know the answer to the question.
Excuse me? If you have more than one frame in a frame set and to do not
define something in the rows and cols attributes ( a number for pixels,
a % of window, or a *ratio) the default is 100% and only one frame will
be visible.
<http://www.w3.org/TR/html401/present/frames.html#edef-FRAMESET#h-16.2.1.1>
"If the rows attribute is not set, each column extends the entire length
of the page. If the cols attribute is not set, each row extends the
entire width of the page. If neither attribute is set, the frame takes
up exactly the size of the page."
Don't believe me try it.
<frameset>
<frame src="include1.html">
<frame src="include2.html">
<frame src="include3.html">
</frameset>
Only include1.html will show....
>
> I'm beginning to understand why you think frames and iframes are the same,
> and conclude that it's best to just disagree about that and move on.
>
No I don't think you do. Maybe you need to do your homework.
dorayme
"Neil Gould" <ne...@myplaceofwork.com> wrote:
> dorayme wrote:
> > In article <htr4ve$u1k$1...@speranza.aioe.org>,
> > "Neil Gould" <ne...@myplaceofwork.com> wrote:
> >
> >> dorayme wrote:
> >>>
> >>> All the best arguments against frames are exhausted in the set
> >>> that you suppose inadequate.
> >>>
> >> My issue with those arguments is that they are mostly a matter of
> >> preference, rather than of technical inadequacy of the frames
> >> element, yet they are presented as such. The same approach could be
> >> taken for any HTML element, and even more so for CSS.
> >>
> >
> > When people argue against frames, they argue on technical
> > grounds.
> >
> I did not mean to imply that *none* of the arguments are technical, hence
> the qualifier "mostly", above. Also, as I had written before, there are
> accommodations within the frames element for many of the issues presented in
> those arguments.
>
Here is a link by a former subscriber to this usenet group that
is one of the best in regard to these 'accomodations':
<http://www.markparnell.com.au/articles/frames.php>
> > I am curious to know what sort of pages cannot be presented
> > adequately without frames.
> >
> Pages where the context needs to be better controlled than one can do with
> CSS or simple HTML code.
What would be examples of such pages?
--
dorayme
Neil Gould
> Neil Gould wrote:
>> Jonathan N. Little wrote:
>>> Neil Gould wrote:
>>>>> Except the issues I list apply to 'frames' as well...
>>>>>
>>>> Not universally, and there are accommodations within the frames
>>>> model for most of the issues you've raised about iframes.
>>>
>>> Eh? Like what?
>>>
>> If you really don't know, the W3C HTML 4.0 spec is a good read, and
>> explains those accommodations concisely.
>
> I have read it, I think it is you that lack the understanding. Okay
> let's take one of the issues that I raised for example. The
> stylesheet. You cannot attach a single stylesheet to the outer
> frameset to universally style the framed-assembled document. Each
> frame must have
> its own stylesheet or reference. Unlike with server-side where the
> document is assembled as a single document you can have a single
> background image under all parts, where this is not an option with
> frames.
>
frames. But, that is hardly the same as saying that *nothing* should be done
with frames. Is not the whole idea of having various HTML elements to best
accommodate a design? If a design requires a single large background image,
then perhaps frames are not the way to go for that page. OTOH, since each
frame document is a complete HTML document, it is no real burden to refer
them all to the same stylesheet, and if the background image is a small,
repeated graphic, typical of many pages, it's no problem whatsoever to
display a continuous background.
>>>> -- you don't have to know ahead of time what the size of the
>>>> content will be, unless your design demands it, then it isn't much
>>>> of a puzzle, is it?
>>>
>>> How? You must define the frames in row cols or % ahead of time.
>>>
>> Not for all frames in a frameset, you don't. And, for the case where
>> it must be defined, only the dimmest bulbs won't know the answer to
>> the question.
>
> Excuse me?
>
I now think that it is the *misuse* of frames that has lead to your opinions
about them. We can move on to other topics.
--
best regards,
Neil
Neil Gould
> In article <htu4ud$vm0$1...@speranza.aioe.org>,
> "Neil Gould" <ne...@myplaceofwork.com> wrote:
>
>> dorayme wrote:
>>> In article <htr4ve$u1k$1...@speranza.aioe.org>,
>>> "Neil Gould" <ne...@myplaceofwork.com> wrote:
>>>
>>>> dorayme wrote:
>>>>>
>>>>> All the best arguments against frames are exhausted in the set
>>>>> that you suppose inadequate.
>>>>>
>>>> My issue with those arguments is that they are mostly a matter of
>>>> preference, rather than of technical inadequacy of the frames
>>>> element, yet they are presented as such. The same approach could be
>>>> taken for any HTML element, and even more so for CSS.
>>>>
>>>
>>> When people argue against frames, they argue on technical
>>> grounds.
>>>
>> I did not mean to imply that *none* of the arguments are technical,
>> hence the qualifier "mostly", above. Also, as I had written before,
>> there are accommodations within the frames element for many of the
>> issues presented in those arguments.
>>
>
> Here is a link by a former subscriber to this usenet group that
> is one of the best in regard to these 'accomodations':
>
> <http://www.markparnell.com.au/articles/frames.php>
>
>>> I am curious to know what sort of pages cannot be presented
>>> adequately without frames.
>>>
>> Pages where the context needs to be better controlled than one can
>> do with CSS or simple HTML code.
>
> What would be examples of such pages?
>
The control or disabling of bookmarking, A/B comparisons, complex relations
between page components where a static display and positioning is important,
etc.
--
Best regards,
Neil
Jonathan N. Little
> Jonathan N. Little wrote:
>> Neil Gould wrote:
> To be clear, I am not claiming that one can or should do all things with
> frames. But, that is hardly the same as saying that *nothing* should be done
> with frames.
To be clear I did not state "*nothing* should be done with frames". I
just stated that the reasons many use to advocate for using frames
simplicity for document assembly and maintenance just are not true
compared to server-side when you have a web-server involved. Now for
local file systems where you don't have web-server or intranet
application, then *maybe* yes. Although pre-processor is a better option
in IMO. But frames like JavaScript are browser dependent and for online
web application browser-independent solutions like server-side are
superior from the start.
> Is not the whole idea of having various HTML elements to best
> accommodate a design? If a design requires a single large background image,
> then perhaps frames are not the way to go for that page.
A single large background image was only an example, colors, fonts, etc
do not apply to the individual frames, they are all independent.
<http://www.littleworksstudio.com/temp/usenet/frames>
Shows the main stylesheet does not effect the frames. You would have to
have a stylesheet for each frame. This was the management issue that I
mentioned, duplication is not efficient form of management.
> OTOH, since each
> frame document is a complete HTML document, it is no real burden to refer
> them all to the same stylesheet, and if the background image is a small,
> repeated graphic, typical of many pages, it's no problem whatsoever to
> display a continuous background.
>
>>>>> -- you don't have to know ahead of time what the size of the
>>>>> content will be, unless your design demands it, then it isn't much
>>>>> of a puzzle, is it?
>>>>
>>>> How? You must define the frames in row cols or % ahead of time.
>>>>
>>> Not for all frames in a frameset, you don't. And, for the case where
>>> it must be defined, only the dimmest bulbs won't know the answer to
>>> the question.
>>
>> Excuse me?
>>
> I now think that it is the *misuse* of frames that has lead to your opinions
> about them. We can move on to other topics.
>
Partly. But it is the basic underlying aspect that:
1) Server-side is browser-independent whereas frames are
browser-dependent, for online use browser-independent trumps
browser-dependent (JavaScript is a great example for this)
2) Server-side is not more complicated to implement than frames as many
claim.
3) With server-side true modular document assembly can be done without
having to duplicate anything. True efficiency in management and maintenance.
4) Server-side is more flexible and does not have to rely on a grid
layout as frames, so if the content changes or font size is enlarged not
scrollbars. You can also do flexible liquid layout that will work on
various devices like cell phones. Cell phones and other small devices
are now a credible component of online visitors, a trend that will not
reverse
So yes, if confronted with the two options for an online web site in
general server-side is superior and generally the better choice. You
still have not supplied a compelling reason for using frames.
Neil Gould
> Neil Gould wrote:
>> Jonathan N. Little wrote:
>>> Neil Gould wrote:
>
>> To be clear, I am not claiming that one can or should do all things
>> with frames. But, that is hardly the same as saying that *nothing*
>> should be done with frames.
>
> To be clear I did not state "*nothing* should be done with frames". I
> just stated that the reasons many use to advocate for using frames
> simplicity for document assembly and maintenance just are not true
> compared to server-side when you have a web-server involved. Now for
> local file systems where you don't have web-server or intranet
> application, then *maybe* yes. Although pre-processor is a better
> option
> in IMO. But frames like JavaScript are browser dependent and for
> online
> web application browser-independent solutions like server-side are
> superior from the start.
>
fact use both, frequently together.
>> Is not the whole idea of having various HTML elements to best
>> accommodate a design? If a design requires a single large background
>> image, then perhaps frames are not the way to go for that page.
>
> A single large background image was only an example, colors, fonts,
> etc
> do not apply to the individual frames, they are all independent.
>
Just as are any two or more web pages. Certainly, you're not advocating a
single web page for your entire application? That's pretty limiting.
> <http://www.littleworksstudio.com/temp/usenet/frames>
>
> Shows the main stylesheet does not effect the frames. You would have
> to have a stylesheet for each frame. This was the management issue
> that I mentioned, duplication is not efficient form of management.
>
And, just what is stopping you from referencing THE SAME style sheet for
each page in the frameset?
>> OTOH, since each
>> frame document is a complete HTML document, it is no real burden to
>> refer them all to the same stylesheet, and if the background image
>> is a small, repeated graphic, typical of many pages, it's no problem
>> whatsoever to display a continuous background.
>>
>>>>>> -- you don't have to know ahead of time what the size of the
>>>>>> content will be, unless your design demands it, then it isn't
>>>>>> much of a puzzle, is it?
>>>>>
>>>>> How? You must define the frames in row cols or % ahead of time.
>>>>>
>>>> Not for all frames in a frameset, you don't. And, for the case
>>>> where it must be defined, only the dimmest bulbs won't know the
>>>> answer to the question.
>>>
>>> Excuse me?
>>>
>> I now think that it is the *misuse* of frames that has lead to your
>> opinions about them. We can move on to other topics.
>
> Partly. But it is the basic underlying aspect that:
>
> 1) Server-side is browser-independent whereas frames are
> browser-dependent, for online use browser-independent trumps
> browser-dependent (JavaScript is a great example for this)
>
Server-side scripts still have to deliver content client-side via HTML/CSS,
and that is where things become browser-dependent. I don't see any way
around that, nor do I see that as an issue unique to frames.
(snip)
First, you were conflating frames and iframes to argue against the use of
frames, and now you're conflating server-side and client-side code. Without
HTML, server-side scripts display nothing in browsers. I don't expect to
convince you to accept frames as a practical component of HTML, and you
certainly aren't convincing or even confusing me with this kind of approach,
so, let's just move on, please?
--
best regards,
Neil
Jonathan N. Little
> Jonathan N. Little wrote:
>> A single large background image was only an example, colors, fonts,
>> etc
>> do not apply to the individual frames, they are all independent.
>>
> Just as are any two or more web pages. Certainly, you're not advocating a
> single web page for your entire application? That's pretty limiting.
>
>> <http://www.littleworksstudio.com/temp/usenet/frames>
Apparently you are unaware of a front-end controller and templating.
>> 1) Server-side is browser-independent whereas frames are
>> browser-dependent, for online use browser-independent trumps
>> browser-dependent (JavaScript is a great example for this)
>>
> Server-side scripts still have to deliver content client-side via HTML/CSS,
> and that is where things become browser-dependent. I don't see any way
> around that, nor do I see that as an issue unique to frames.
Yes, but as far as the browser (client-side) it is one static page, with
frames the assembly is done client-side by the browser.
>
> (snip)
>
> First, you were conflating frames and iframes to argue against the use of
> frames, and now you're conflating server-side and client-side code. Without
> HTML, server-side scripts display nothing in browsers. I don't expect to
> convince you to accept frames as a practical component of HTML, and you
> certainly aren't convincing or even confusing me with this kind of approach,
> so, let's just move on, please?
>
Also apparently you do not understand the connection between frames and
iframes, nor the differences between server-side and client-side code. I
agree this is all futile.
Neil Gould
> Neil Gould wrote:
>> Jonathan N. Little wrote:
>
>>> A single large background image was only an example, colors, fonts,
>>> etc
>>> do not apply to the individual frames, they are all independent.
>>>
>> Just as are any two or more web pages. Certainly, you're not
>> advocating a single web page for your entire application? That's
>> pretty limiting.
>>
>>> <http://www.littleworksstudio.com/temp/usenet/frames>
>
> Apparently you are unaware of a front-end controller and templating.
>
>>> 1) Server-side is browser-independent whereas frames are
>>> browser-dependent, for online use browser-independent trumps
>>> browser-dependent (JavaScript is a great example for this)
>>>
>> Server-side scripts still have to deliver content client-side via
>> HTML/CSS, and that is where things become browser-dependent. I don't
>> see any way around that, nor do I see that as an issue unique to
>> frames.
>
> Yes, but as far as the browser (client-side) it is one static page,
> with frames the assembly is done client-side by the browser.
>
Whether it is "one static page" depends on how the browser deals with the
new stream. Some won't update without flashing the page if they aren't
caching the repeated content, so it's still a browser-dependent approach if
presentation is driving the structural decisions.
Since you can not dispute the points I've raised about server-side code,
your assertion that I don't understand it makes no sense. As I have used a
variety of server-side technologies for more than a couple of decades, I'm
pretty sure I know what's going on, and not going on there. There is a
difference between a lack of understanding and a lack of agreement.
--
best regards,
Neil
dorayme
"Neil Gould" <ne...@myplaceofwork.com> wrote:
Not sure I understand the last few (in relation to frames being
superior) but I note the first argument *for* frames that I am
not sure I have heard of: to make things unbookmarkable. This is
a bit bold considering it is usually considered that the breaking
of bookmarking is the strongest argument against frames!
--
dorayme
Neil Gould
part of such arguments.
As for the other examples, it turns out that frames are much better
supported by browsers for making one portion of the screen static while
another portion changes than CSS. Though this is unimportant for the
majority of web pages, there are applications where such a presentation is
desirable, and the examples are a few such applications.
--
Hope this helps,
Neil
Adrienne Boswell
<ne...@myplaceofwork.com> writing in news:hu83ts$qo4$1...@speranza.aioe.org:
One more thing that only frames can do, framesets can be resized, unless
the author has used the noresize attribute.
dorayme
Adrienne Boswell <arb...@yahoo.com> wrote:
The argument that cautions against frames is that it does not
allow natural bookmarking, which is something that is generally
desirable. It is not an argument that excludes the rare cases
where users are not inclined to pull their hair out, kick the cat
or throttle their mother in law upon finding they cannot bookmark
or use the back or forward buttons as they might be expecting.
> > As for the other examples, it turns out that frames are much better
> > supported by browsers for making one portion of the screen static
> > while another portion changes than CSS. Though this is unimportant for
> > the majority of web pages, there are applications where such a
> > presentation is desirable, and the examples are a few such
> > applications.
> >
I am not as confident as you that Jonathan Little and others
could not produce pages using includes and CSS positioning that
are well supported by browsers which appear to have a section
stay still throughout changes - without the downsides of document
frames.
>
> One more thing that only frames can do, framesets can be resized...
Yes, this has always been a neat feature (the user drags the
edges of the members of the frameset with a mouse. And sometimes
needed because, for one, I don't think you can specify frame dims
in em units and this can militate against truly fluid design.
--
dorayme
Neil Gould
>> "Neil Gould" wrote:
>>> As for the other examples, it turns out that frames are much better
>>> supported by browsers for making one portion of the screen static
>>> while another portion changes than CSS. Though this is unimportant
>>> for the majority of web pages, there are applications where such a
>>> presentation is desirable, and the examples are a few such
>>> applications.
>>>
>
> I am not as confident as you that Jonathan Little and others
> could not produce pages using includes and CSS positioning that
> are well supported by browsers which appear to have a section
> stay still throughout changes - without the downsides of document
> frames.
>
for just this purpose, I was brought up-to-date on how different browsers
rendered the box model and the viewport. It took a lot of CSS hacks to even
come close to replicating the presentation of some of those pages in
different browsers. Frames required no hacks, and both CSS and HTML can be
validated. That said, I suspect that for the vast majority of pages, one can
get "close enough" that it wouldn't matter.
Server-side code is a non-issue when it comes to this kind of presentation,
since it has no information about what is going on client-side. It's great
for dynamic content, but can't have any impact on box model rendering beyond
elementary presumptions based on header-sniffing, and that approach would
take a lot of code to do very little.
--
best regards,
Neil
dorayme
"Neil Gould" <ne...@myplaceofwork.com> wrote:
> dorayme wrote:
> >> "Neil Gould" wrote:
> >>> As for the other examples, it turns out that frames are much better
> >>> supported by browsers for making one portion of the screen static
> >>> while another portion changes than CSS. Though this is unimportant
> >>> for the majority of web pages, there are applications where such a
> >>> presentation is desirable, and the examples are a few such
> >>> applications.
> >>>
> >
> > I am not as confident as you that Jonathan Little and others
> > could not produce pages using includes and CSS positioning that
> > are well supported by browsers which appear to have a section
> > stay still throughout changes - without the downsides of document
> > frames.
> >
> Having recently converted a site to CSS that originally depended on frames
> for just this purpose, I was brought up-to-date on how different browsers
> rendered the box model and the viewport. It took a lot of CSS hacks to even
> come close to replicating the presentation of some of those pages in
> different browsers. Frames required no hacks, and both CSS and HTML can be
> validated. That said, I suspect that for the vast majority of pages, one can
> get "close enough" that it wouldn't matter.
>
Well, OK. It is always hard to get the very exact same thing,
pixel for pixel, across browsers. And we might have some vague
notion of what is acceptable leeway for best practice among
reasonable website makers. The question then is, when you do
without frames, either because you never use them or convert
existing, can we work within this leeway without frames Mostly,
I agree with you, we can.
> Server-side code is a non-issue when it comes to this kind of presentation,
> since it has no information about what is going on client-side. It's great
> for dynamic content, but can't have any impact on box model rendering beyond
> elementary presumptions based on header-sniffing, and that approach would
> take a lot of code to do very little.
Not sure I follow this. We never really know what is going on on
the user's machine. Not sure why this ignorance is an argument in
favour of frames? There is a large and useful subset of CSS that
is reliably interpreted by all modern browsers. True, some older
IE need watching carefully for misbehaviour. But note, even if
you use frames, the documents that are srcd for the frames are
just html and css and IE can just as easily muck those up - the
point is that IE will cause trouble wherever it can and frames
are not like a wooden cross to a vampire on this matter.
--
dorayme
Neil Gould
> "Neil Gould" <ne...@myplaceofwork.com> wrote:
>
>> Server-side code is a non-issue when it comes to this kind of
>> presentation, since it has no information about what is going on
>> client-side. It's great for dynamic content, but can't have any
>> impact on box model rendering beyond elementary presumptions based
>> on header-sniffing, and that approach would take a lot of code to do
>> very little.
>
> Not sure I follow this. We never really know what is going on on
> the user's machine. Not sure why this ignorance is an argument in
> favour of frames?
>
difference in the context of whether to use frames. The HTML is what
matters, so introducing server-side code into the discussion may be
misleading to those unfamiliar with it.
> There is a large and useful subset of CSS that
> is reliably interpreted by all modern browsers. True, some older
> IE need watching carefully for misbehaviour. But note, even if
> you use frames, the documents that are srcd for the frames are
> just html and css and IE can just as easily muck those up - the
> point is that IE will cause trouble wherever it can and frames
> are not like a wooden cross to a vampire on this matter.
>
No need to single IE out for this perspective. Other browsers do similarly
odd things with the box model and viewport. At least Microsoft provided a
method of singling out IE versions so that an appropriate and valid CSS
modifier can be applied without having to hack the main file into
non-compliance.
--
best regards,
Neil