HTML & ALL Current Tools are really back to ASSEMBLY language, Whatever happend to Libraries/Functions/Reuse and highlevel stuff ?

Michael Stemper wrote:

In article <c7**********@s0b1a68.ssa.gov>, Mel writes:
Take a look at what we are doing ! we create TAGS, things like <H1>
etc. and although there are tools (dreamweaver and the like), they
are all at the lowest level of programming (something like assembly
as oposed to C++ etc.).

Hardly. It's pretty obvious that you:
a. Never programmed in assembly language for a living
b. Don't understand what the tags are doing for you.

When somebody writes some HTML, they're doing something that's
incredibly high-level, leaving huge amounts of implementation details
to the user agent.

[snip]

I'll speak as someone who *has* programmed in assembly language for a living.
(And lots of other languages. And, where necessary, invented my own
languages).

My target is that, at some time in the future, perhaps within 5 years, my HTML
code & CSS code should be "untouched by human hands" when published. And
preferably "unseen by human eyes" when published. And that both the CSS &
strict-(X)HTML will validate at W3C, and work well.

There is no merit in know the abstract syntax of HTML or CSS. (All those
pointy-brackets & curly-brackets, the specific names of the tags, attributes,
properties, values, upper/lower case, single/double quotes, etc). That is what
software should do. Not people.

People should be able to focus in a higher-level of abstraction. I would still
expect to know, in 5 years time, unfortunately, the *elements* within a
document tree, and, somehow, the principles of the CSS specification. But the
idea that someone needs to know that it is "color" not "colour", and that #090
is a sort of darkish-green colour, is just plain silly! Use a colour-picker
for that.

Even that is low level! Unfortunately, no page-layout language even appears to
be on the horizon. We may be stuck with this low level of abstraction for the
next decade. But it would be better than using pointy or curly brackets!
Elements matter, not tags. "Table", not <table ...>...</table>. "Image", not
<img ...>.

I use Dreamweaver. It gives some pointers to possible future directions. For
example, in Standard Mode, Design View, you still handle the elements. You
have to say "insert an image", "make this a header 1", etc. But you don't need
to know what the corresponding HTML looks like. Dreamweaver understands the
correspondence between yout requirement and the code. Or you can say "add
another column here", and let DW put in all the necessary <td>...</td>s. Or
"render this as style "species"", and DW will ensure that you get <span
class="species">...</span>.

This is higher than assembler. Much of it is in visual terms. But lower than a
true page-development & site-development language, where perhaps it should be
possible to have a dialogue about what a site navigation region should look &
act like. Fortunately, Dreamweaver extensions are filling some of the gaps. It
is getting near the stage where it is possible to have a sensible dialogue
about what the navigation menu should look like, and how it should behave, and
have the extension generate suitable HTML, CSS, and JS, that works
cross-browser.

--
Barry Pearson
http://www.Barry.Pearson.name/photography/
http://www.BirdsAndAnimals.info/
http://www.ChildSupportAnalysis.co.uk/

Jul 20 '05 #8

Harlan Messinger wrote:
[snip]

HTML isn't code, it's data.

Sigh!

Go to the W3C home page, and type
HTML code
into the search box. Then see if you still believe that. (Hint - I just did
that).

I've been programming computers, and building data, since about 1966/7. And
developing HTML since about 1995/6. And I would not like to make such a
categorical statement. Code is often seen as data that is supplied to a
processing engine. Data output by a compiler becomes code input to a
processor. So why isn't data, output by an authoring tool, code input to a
browser? I'm not saying one way or the other - it depends on what terminology
you choose to adopt. But HTML gets represented by code sets. (At this point,
Alan Flavell leaps to the attack! And if not, why not?)

Now, if you distinguished between *instruction-code* & data, you *may* be a
bit closer. But I wouldn't attempt to defend either point of view there. They
don't matter enough to defend.

And the only way I know to estimate how floated elements will behave under a
variety of conditions, such as different text sizes & viewport widths, is to
"dry run" the HTML as "instruction code" according to criteria identified by
the CSS. I have to treat it as some sort of sequential dynamic execution, or
at least emulation. Or else preview it, and let the test-browser run the code
for me!

--
Barry Pearson
http://www.Barry.Pearson.name/photography/
http://www.BirdsAndAnimals.info/
http://www.ChildSupportAnalysis.co.uk/

Jul 20 '05 #9

Harlan Messinger

"Barry Pearson" <ne**@childsupportanalysis.co.uk> wrote in message
news:suRmc.1276$iz2.432@newsfe1-win...

Harlan Messinger wrote:
[snip]
HTML isn't code, it's data.
Sigh!

Go to the W3C home page, and type
HTML code
into the search box. Then see if you still believe that. (Hint - I just

did that).

I've been programming computers, and building data, since about 1966/7. And developing HTML since about 1995/6. And I would not like to make such a
categorical statement. Code is often seen as data that is supplied to a
processing engine. Data output by a compiler becomes code input to a
processor. So why isn't data, output by an authoring tool, code input to a
browser?

You're entirely right. I was hoping no one would get all sophisticated on
me. :-)

With "real" programming, lower-level code is a means to an end. If you can
arrive correctly at that end by using higher-level code, then it really
doesn't matter how the compiler or interpreter broke your higher-level code
down at the lower levels. If

select ssn, lastName, firstName from Employees where departmentID = 45

is executed correctly and efficiently, then we *really* don't care how the
data engine did it.

With HMTL, *we care very much* what the HTML code/data looks like. Obviously
we do: we keep talking about the semantics of it, the *meaning* of the
different parts of a document, and this all has to be accounted for *at the
HTML level*.

With a C++ or SQL statement, when you move the program to another machine,
it's the higher-level code that you move. The code's portability is at the
higher level. You recompile it, or run that machine's version of the
interpreter on it. With HTML, it's the HTML that has to be the same on every
machine. If you encapsulated it in a higher-level language, its portability
would still be at the HTML level--that is, unless someone came up with a
standard for the higher-level--and a new user agents were built to read
*that*.

And we know what today's WYSIWYG editors do with HTML they generate: it's
all presentational, and even if it isn't, it's a mess, and that's
*important* to us.

After all, every time someone comes here with a question about a code sample
that was obviously generated by FrontPage or Dreamweaver, isn't that at
least part of where the trouble lies?

Jul 20 '05 #10

Keith Bowes

Michael Stemper wrote:

In article <c7**********@s0b1a68.ssa.gov>, Mel writes:

Take a look at what we are doing ! we create TAGS, things like <H1> etc.
and although there are tools (dreamweaver and the like), they are all at the
lowest level of programming (something like assembly as oposed to C++ etc.).

Hardly. It's pretty obvious that you:
a. Never programmed in assembly language for a living
b. Don't understand what the tags are doing for you.

When somebody writes some HTML, they're doing something that's incredibly
high-level, leaving huge amounts of implementation details to the user
agent.

For instance, when you put (to use your example):
<H1>Moose Bites versus Llama Bites</h1>
you're doing both of the following:
1. You're indicating that the page in question compares moose and
llama bites. This enables computers in a different part of the
country to be aware that you have information available to them
on that subject.
2. You're indicating to the user agent that the words "Moose Bites
versus Llama Bites" are very important, and should be presented
to the user in such a way that the user will know that these are
a high-level description of the contents of your page.

You do all of this in a completely platform-independent manner. That's
a lot of bang for very few bytes.

Bravo! And have you seen XUL? <button> and the like is so much easier
than, say, the Windows API in which you have to call a function with,
IIRC, eleven parameters, process messages (WM_COMMAND, WM_PAINT, etc),
keep track of handles, processes, device contexts, etc, ... Definitely
not a step backwards.

I have nothing against Java per say, but remember we placed
MAN-ON-THE-MOON with assembly language and PDB computers.

Now, you sound as if you're sticking up for assembly language, when before
you were asking why we haven't advanced beyond it.

And he misspelled per se.

Jul 20 '05 #11

Harlan Messinger wrote:

"Barry Pearson" <ne**@childsupportanalysis.co.uk> wrote in message
news:suRmc.1276$iz2.432@newsfe1-win...
Harlan Messinger wrote:
[snip]
> HTML isn't code, it's data.
Sigh!
Go to the W3C home page, and type
HTML code
into the search box. Then see if you still believe that. (Hint - I
just did that).

I've been programming computers, and building data, since about
1966/7. And developing HTML since about 1995/6. And I would not like
to make such a categorical statement. Code is often seen as data
that is supplied to a processing engine. Data output by a compiler
becomes code input to a processor. So why isn't data, output by an
authoring tool, code input to a browser?

You're entirely right. I was hoping no one would get all
sophisticated on me. :-)

I'm an engineer, not a philosopher. Just basic, not sophisticated!
With "real" programming, lower-level code is a means to an end. If
you can arrive correctly at that end by using higher-level code, then
it really doesn't matter how the compiler or interpreter broke your
higher-level code down at the lower levels. If
select ssn, lastName, firstName from Employees where departmentID
= 45
is executed correctly and efficiently, then we *really* don't care
how the data engine did it.
If that code is according to specification, OK.
With HMTL, *we care very much* what the HTML code/data looks like.
Obviously we do: we keep talking about the semantics of it, the
*meaning* of the different parts of a document, and this all has to
be accounted for *at the HTML level*.
I don't think you are arguing that it isn't code. Perhaps you are arguing that
it *also* needs to obey certain principles. But perhaps you need to relax a
bit, and see what T B-L said in 1993: "Typical rendering is described for many
elements. This is not a mandatory part of the standard but is given as
guidance for designers and to help explain the uses for which the elements
were intended". In the early days, the uses of elements were described in
terms of their rendering, not their semantics.
(An Internet Draft of "A Representation of Textual Information and
MetaInformation for Retrieval and Interchange". (Tim Berners-Lee, Daniel
Connolly)).
With a C++ or SQL statement, when you move the program to another
machine, it's the higher-level code that you move. The code's
portability is at the higher level. You recompile it, or run that
machine's version of the interpreter on it.
Not necessarily, of course. You may move the lower level code to another
machine. That latter machine may emulate the first machine. It may be a
microcoded engine instead of a hard engine. Code portability may be at a
number of levels.
With HTML, it's the HTML
that has to be the same on every machine. If you encapsulated it in a
higher-level language, its portability would still be at the HTML
level--that is, unless someone came up with a standard for the
higher-level--and a new user agents were built to read *that*.
I don't have a problem with that. The HTML conforms to the interface
specification. You can think of it as a high level language. Or a lower level
language emulated by a package (such as a browser) on the client system. I
don't even know a reliable way of categorising these levels. I prefer to think
of the HTML as being part of an interface specification.
And we know what today's WYSIWYG editors do with HTML they generate:
it's all presentational, and even if it isn't, it's a mess, and that's
*important* to us.
I would need to know what you considered a WYSIWYG editor to be in order to
comment. I see a lot of confusing stuff on this topic.

I use Dreamweaver MX2004. Macromedia don't call it is WYSIWYG editor. (I
happen to think that Standard Mode, Design View, really is a WYSIWYG editor,
but that is just me!). I know that you can use Standard Mode, Design View,
(WYSIWYG-like), and output valid HTML 4.01 Strict plus the accompanying CSS2
stylesheet. (Or variants of XHTML, of couse). I, and many others, do this
every day. I can't imagine how you could even detect that it was output by
Dreamweaver - it doesn't sign the code.

I also know that, of course, that I can get an Accessibility report on any
given page, in terms of 508 & WAI Guidelines. So, if I can be bothered to
navigate through the "noise" that those guidelines throw up, I can get clues
about whether that page will be accessible to blind & other handicapped
people.
After all, every time someone comes here with a question about a code
sample that was obviously generated by FrontPage or Dreamweaver,
isn't that at least part of where the trouble lies?

Do you know of a tool that can't generate bad code if the author goes that
way?

Here is a clue, for *anyone* here who thinks they know what sort of code
Dreamweaver outputs, but hasn't used the product. A quick overview:

DW has two HTML-development modes. Standard Mode & Layout Mode. Each mode has
two views. Code View & Design View. (And, in either mode, the author can have
a "split screen" showing both views).

"Layout Mode" is used by novices to generate complex pages. I guess those
novices won't use Code View, so they will use Layout Mode, Design View. It is
a bit like a canvas on which you can place boxes & other objects. It generates
complex, fragile, layout tables. They have lots of colspans & rowspans, and
height & width attributes. I think it can put spacer-GIFs in as well.
Knowledgeable authors don't use Layout Mode. I only looked at it recently to
see what it was like, in order to respond to people talking about DW. It isn't
representative.

Knowledgeable authors use Standard Mode, in some chosen mixture of Code View &
Design View. Code View is an intelligent (X)HTML editor. Design View is a
CSS2-aware WYSIWYG-like editor, generating precisely the elements that the
author chooses. (Such authors also use one of the DW CSS-editing capabilities,
or a 3rd-party CSS editor, of course). As I said, I can't imagine how you
could even detect that its output was generated by DW. Unless you use one of
the options that leaves clues. (For example, DW templates result in HTML
comments to identify editable areas).

I suspect that when you see a problem page generated by DW, it will nearly
always have been generated in Layout Mode. The problem isn't with DW. It is
with the fact that here is an author who may not understand the basics of
HTML. With a lesser tool, they could probably not output a workable page. With
Layout Mode, they can output a complex but fragile page. Which probably
actually looks OK to people using browsers at their default settings. Hence,
perhaps, to 80% of users in the world. Gosh.

If you think of DW as perhaps 3 different HTML-editors, chosen according to
the author's needs, integrated together, you may have a better understanding
of it.

--
Barry Pearson
http://www.Barry.Pearson.name/photography/
http://www.BirdsAndAnimals.info/
http://www.ChildSupportAnalysis.co.uk/

Jul 20 '05 #12

Harlan Messinger

"Barry Pearson" <ne**@childsupportanalysis.co.uk> wrote:

I suspect that when you see a problem page generated by DW, it will nearly
always have been generated in Layout Mode. The problem isn't with DW. It is
with the fact that here is an author who may not understand the basics of
HTML. With a lesser tool, they could probably not output a workable page. With
Layout Mode, they can output a complex but fragile page. Which probably
actually looks OK to people using browsers at their default settings. Hence,
perhaps, to 80% of users in the world. Gosh.

If you think of DW as perhaps 3 different HTML-editors, chosen according to
the author's needs, integrated together, you may have a better understanding
of it.

I've seen garbage on a number of occasions that was explained by "It's
from Dreamweaver", and wasn't aware that it might depend on the mode
in which it's used. Now I'll have to investigate further. Thanks.

--
Harlan Messinger
Remove the first dot from my e-mail address.
Veuillez ôter le premier point de mon adresse de courriel.

Jul 20 '05 #13

Hi, Mel, I am with you :)

But I went even further - I've created WYSIWYG editor by myself (Hey, guys!
Guns down!) :))))))
I did it for my wife initially who lives in the Net and wants to publish her
stuff there and
don't-even-want-to-know-what-the-hell-your-html-is-I-just-want-my-text-to-be
-HERE-THACIT!

If somebody will have any objections with such motivation just give me your
e-mail.
I'll pass it to my wife. She will explain you better her point of view. Be
prepared, though, ... helmet, goggles, etc.

Seriously: 99% Internet users are non-professionals. It is not fair that
they cannot publish their stuff.

Andrew Fedoniouk.

Oops! Editor is http://blocknote.net and sure I am not selling it in this
auditorium! :)

Jul 20 '05 #14

Harlan Messinger wrote:

"Barry Pearson" <ne**@childsupportanalysis.co.uk> wrote:

[snip]

If you think of DW as perhaps 3 different HTML-editors, chosen
according to the author's needs, integrated together, you may have a
better understanding of it.

I've seen garbage on a number of occasions that was explained by "It's
from Dreamweaver", and wasn't aware that it might depend on the mode
in which it's used. Now I'll have to investigate further. Thanks.

These are some sites that impressed me when referenced on the
macromedia.dreamweaver newsgroup. I was mainly impressed by the graphic
design, (which may not go down well here, because they are fixed width!). But
I think they illustrate that Dreamweaver is a professional-class tool that
happens to have options for beginners to use. And the latter then have enough
rope to hang themselves! And often do.
http://www.nozzon.com/testing/new.asp
http://www.great-web-sights.com/
http://www.projectseven.com/

The author of the 2nd one uses Design View a lot. The author of the 3rd tends
to use mostly Code View. Both of them are long-established professionals.

The 3rd illustrates the last part of the *long* subject of this thread. They
supply extensions to Dreamweaver commercially, and could be classed among
"libraries/reuse", etc. It can be tricky to build a component industry when
everyone in the world downloads the results of what you do! How would you sell
interesting CSSs? But selling bolt-ons to an authoring tool, as the 3rd site
above does, is a constructive approach. They do some super robust & accessible
extensions for menus & positioning of components, etc. (Some excellent ones
are free). There are several such companies, and other companies sell
templates which then act as starter-kits. These move authoring away from being
a "craft industry". (It happens with other professional-class tools, such as
Photoshop).

Unfortunately, Dreamweaver doesn't make you (well, me) a better graphics
designer! Here are my own limited designs. I tend to use mostly Code View when
developing templates, and mostly Design View when adding content to pages
spawned from the templates. I'm only showing these to illustrate that
flexible-width layouts can also be authored using Dreamweaver. (I think it is
the use of images that often constrain the flexibility - for example, my
sidebar is fixed, because I use a background photograph).
http://www.barry.pearson.name/articles/templates/

--
Barry Pearson
http://www.Barry.Pearson.name/photography/
http://www.BirdsAndAnimals.info/
http://www.ChildSupportAnalysis.co.uk/

Jul 20 '05 #15

On Sat, 8 May 2004, Barry Pearson wrote:

These are some sites that impressed me when referenced on the
macromedia.dreamweaver newsgroup. I was mainly impressed by the graphic
design, (which may not go down well here, because they are fixed width!).
There's nothing like throwing the baby out with the bathwater in the
interests of visual attraction! However, just consider what that
"visual attraction" looks like in less-usual presentation situations.
But I think they illustrate that Dreamweaver is a professional-class
tool

No argument there. Current experience suggests that only a few
dedicated amateurs understand how to combine their visual design
skills[1] with the flexible design strengths of the WWW. But
professional designers may come to gain these abilities too, given
time and motivation.

[1] Which, of course, I don't have, so I'm just speaking as an
interested observer in this regard.

If the "professional" design tools (contrary to all your protestations
that DW doesn't influence the designer's options!) serve to reinforce
their suboptimal design approach - such as fixed widths - it's going
to take longer for them to realise that there's something left to
learn.

There are few visually-designed pages that can't be improved by taking
unnecessary presentation specifications out. Most of the times that
I've tried it, there's been little or no change to the appearance in
the mainstream situation, but the behaviour in less-usual presentation
situations has been much improved. Which is why I'm inclined to say
that one of the most important aspects of WWW design is knowing how
much of what *could* be specified in HTML and CSS to leave out, so
that the browser can get on with doing what -it- does best, having
much better knowledge of the specific presentation situation.

ttfn

Jul 20 '05 #16

Stephen Poley

On Sat, 8 May 2004 10:17:33 +0100, "Barry Pearson"
<ne**@childsupportanalysis.co.uk> wrote:

These are some sites that impressed me when referenced on the
macromedia.dreamweaver newsgroup. I was mainly impressed by the graphic
design, (which may not go down well here, because they are fixed width!).
Well, indeed.
http://www.nozzon.com/testing/new.asp
http://www.great-web-sights.com/
http://www.projectseven.com/

I do occasionally come across sites where there is some point to using a
fixed-width design (though the site that I was going to cite as an
example now only gives me a blank page - heaven only knows what the
people in charge have done.)

But these, particularly the second and third of your list, are perfect
examples of pointless fixed-width designs. There is absolutely no good
reason for the text to run off the right-hand side of my browser window,
and turning them into a variable-width layout would be trivial.

--
Stephen Poley

http://www.xs4all.nl/~sbpoley/webmatters/

Jul 20 '05 #17

Stan Brown

"Mel" <me**********@ssa.gov> wrote in
comp.infosystems.www.authoring.html:

other than the "your take on spam piece", does my posting makes sense to you
?
or am i complete alone in this wonderland ?

Usually when someone can't be bothered to capitalize, spell, and
punctuate correctly, their thoughts are muddled too.

Add your choice to post upside-down, and ...

--
Stan Brown, Oak Road Systems, Cortland County, New York, USA
http://OakRoadSystems.com/
HTML 4.01 spec: http://www.w3.org/TR/html401/
validator: http://validator.w3.org/
CSS 2 spec: http://www.w3.org/TR/REC-CSS2/
2.1 changes: http://www.w3.org/TR/CSS21/changes.html
validator: http://jigsaw.w3.org/css-validator/

Jul 20 '05 #18

Shawn K. Quinn

Andrew Fedoniouk wrote:

Seriously: 99% Internet users are non-professionals. It is not fair that
they cannot publish their stuff.

Sure they can. HTML is not hard to learn, at all.

--
Shawn K. Quinn

Jul 20 '05 #19

Stephen Poley wrote:

On Sat, 8 May 2004 10:17:33 +0100, "Barry Pearson"
<ne**@childsupportanalysis.co.uk> wrote:
These are some sites that impressed me when referenced on the
macromedia.dreamweaver newsgroup. I was mainly impressed by the
graphic design, (which may not go down well here, because they are
fixed width!).
Well, indeed.
http://www.nozzon.com/testing/new.asp
http://www.great-web-sights.com/
http://www.projectseven.com/

I do occasionally come across sites where there is some point to
using a fixed-width design (though the site that I was going to cite
as an example now only gives me a blank page - heaven only knows what
the people in charge have done.)

My photograph pages are fixed because my "landscape" photographs are normally
700px wide. So I also make associated pages, such as thumbnail galleries, the
same width. (I use 5-per-row, with "landscape" thumbnails 125px wide, and some
space around them).

Most of my other pages are variable. A few use a "max-width" effect.
But these, particularly the second and third of your list, are perfect
examples of pointless fixed-width designs. There is absolutely no good
reason for the text to run off the right-hand side of my browser
window, and turning them into a variable-width layout would be
trivial.

I think they were both, until recently, flexible width. And they are both the
websites of people who make their living from the web, and have for many
years. Somewhere, there is a message there.

I also note that quite a few other noted websites are fixed width, after being
flexible width earlier. These are fixed width, although I'm not sure if they
all used to be flexible width.
http://www.notestips.com/80256B3A007F2692/1/TAIO-5TT34F
http://www.9rules.com/whitespace/des...id_layouts.php
http://www.alistapart.com/
http://www.simplebits.com/
http://www.zeldman.com/

This debate will run & run! Because there is no "formal" way of resolving it.
It is a matter of opinion & preference. I think it will have to be resolved,
if at all, in the marketplace & the courts. If commercial sites lose business
because of it, they may change. If authors insist on schemes that defy the
marketplace, they will lose employment. If people with visual disabilities
take matters to court under 508 or DDA, etc, the message may get around.
Authoring tools that make flexible-width layouts easier may thrive.

Perhaps things will change because of the increasing range of ppi of screens.
From around 72ppi for older laptops, towards 200ppi (or more?) for top-end
screens. But - perhaps this isn't simply resolved by flexible-width layouts.
That doesn't solve the image-width problem. Perhaps it needs better scaling. I
wish I knew.

--
Barry Pearson
http://www.Barry.Pearson.name/photography/
http://www.BirdsAndAnimals.info/
http://www.ChildSupportAnalysis.co.uk/

Jul 20 '05 #20

Alan J. Flavell wrote:

On Sat, 8 May 2004, Barry Pearson wrote:
These are some sites that impressed me when referenced on the
macromedia.dreamweaver newsgroup. I was mainly impressed by the
graphic design, (which may not go down well here, because they are
fixed width!).
There's nothing like throwing the baby out with the bathwater in the
interests of visual attraction! However, just consider what that
"visual attraction" looks like in less-usual presentation situations.

I've just replied to Stephen Poley. Please treat that as a partial response to
you too. Think of some of those "less usual" situations:

- A person using a speaking browser. Width becomes irrelevant.

- A person who chooses to ignore the author's CSS. These become flexible-width
pages. Have a look at the following without CSS, and note that you get a
*large* "skip navigation image, which may be quite effective.

- A person who uses Opera, and views those pages at about 120% to 150%. On my
PC, they become about full width.

I think this is a bit like the "don't use px for fonts" debate. I suspect that
the people who might be most impacted by it will often know of the avoidance
actions. (Do people with visual disabilities who know they need large text
really use IE without getting into the "Accessibility" dialogue and overriding
the px value?)

But I think they illustrate that Dreamweaver is a professional-class
tool

No argument there. Current experience suggests that only a few
dedicated amateurs understand how to combine their visual design
skills[1] with the flexible design strengths of the WWW. But
professional designers may come to gain these abilities too, given
time and motivation.

[1] Which, of course, I don't have, so I'm just speaking as an
interested observer in this regard.

Chuckle! I don't have them either. (Which I find puzzling, given that I can
take a pretty good photograph. It appears to need a different area of the
brain).

But what is the motivation? I talked about the marketplace and the courts. I
won't repeat the arguments here. I believe there are many people "out there"
who are fully aware of the nature of the web, and its users, and who believe
that the best compromise is a fixed-width layout. And can it be proved that
they are always wrong? It is arrogant to assume that those publishers &
designers & marketers are ignorant about what their audience wants, or at
least will accept.
If the "professional" design tools (contrary to all your protestations
that DW doesn't influence the designer's options!) serve to reinforce
their suboptimal design approach - such as fixed widths - it's going
to take longer for them to realise that there's something left to
learn.
If you create a new document in DW and put stuff in and mark it up with
standard structural mark-up, you will get a flexible width page, as in the
early-1990s. (And this will apply if you use simple CSSs instead of
Transitional HTML). The default appears to be flexible, and making things
fixed takes extra work, as far as the HTML / CSS are concerned. The use of
fixed width layouts needs extra CSS (if not HTML) work. So why do people do
it?

- If they use Layout Mode (which implies that they are beginners), they will
be led down that path. It is like drawing on a canvas. (I don't know if there
is a variant that doesn't put px values in. I've only spent a short time
looking at it).

- Another reason may be that people think it is the right way to go. Perhaps
they see a lot of fixed width layouts on the web. Perhaps they read some of
the arguments in favor of fixed width layouts. Who knows?

- But it often comes down to pixel-oriented content. Images, photographs,
whatever. And, in spite of what some claim, it is easier to make a fixed-width
layout when these images significant. Getting a match between the image, and
especially features within the image, and the rest of the design, obviously
becomes easier if the 2 can be locked together.
There are few visually-designed pages that can't be improved by taking
unnecessary presentation specifications out. Most of the times that
I've tried it, there's been little or no change to the appearance in
the mainstream situation, but the behaviour in less-usual presentation
situations has been much improved. Which is why I'm inclined to say
that one of the most important aspects of WWW design is knowing how
much of what *could* be specified in HTML and CSS to leave out, so
that the browser can get on with doing what -it- does best, having
much better knowledge of the specific presentation situation.

I don't agree with that where images are concerned. I work with largish
images, typically photographs, quite a bit, and find it a good idea to match
up the various image & non-image sizes.

(I doubt if you want me to point out that the easiest way to get a flexible
width layout that adapts to user circumstances is to use a simple layout table
without attempting to control the sizes! It will adapt to content, including
user's choice of text size. It will use as much of the viewport as it can to
reduce vertical scrolling. While also trying to avoid any horizontal
scrolling).

--
Barry Pearson
http://www.Barry.Pearson.name/photography/
http://www.BirdsAndAnimals.info/
http://www.ChildSupportAnalysis.co.uk/

Jul 20 '05 #21

Neal

On Sat, 8 May 2004 14:48:17 +0100, Barry Pearson
<ne**@childsupportanalysis.co.uk> wrote:

I think they were both, until recently, flexible width. And they are
both the
websites of people who make their living from the web, and have for many
years. Somewhere, there is a message there.

The message might be "You can fool some of the people all of the time..."

Jul 20 '05 #22

Neal

On Sat, 8 May 2004 15:44:36 +0100, Barry Pearson
<ne**@childsupportanalysis.co.uk> wrote:

I think this is a bit like the "don't use px for fonts" debate. I
suspect that
the people who might be most impacted by it will often know of the
avoidance
actions. (Do people with visual disabilities who know they need large
text
really use IE without getting into the "Accessibility" dialogue and
overriding
the px value?)

Just because you're disabled doesn't mean you have the know-how or the
support to get things going your way. It's a little like saying, "Well, if
you had to use a wheelchair to get around, wouldn't you bring a ramp with
you so you can get up and down any stairs you encounter?"

Jul 20 '05 #23

Neal wrote:

On Sat, 8 May 2004 14:48:17 +0100, Barry Pearson
<ne**@childsupportanalysis.co.uk> wrote:
I think they were both, until recently, flexible width. And they are
both the websites of people who make their living from the web,
and have for many years. Somewhere, there is a message there.

The message might be "You can fool some of the people all of the
time..."

I see a number of things happening here:

- A vast number of websites world-wide that have fixed-width layouts, and
remain so even when they are re-engineered. (BBC, The Times, many others).

- A number of websites developed by professionals and/or experts that have
fixed-width layouts. Some of which have been re-engineered that way from
earlier flexible-width layouts.

- A steady increase, year by year, in the amount of pixel-oriented content,
such as images, used in websites. Combined with increasing attempts to ensure
that this content matches the other content.

- Some serious discussion taking place about the potential benefits of
fixed-width layouts. And scrutiny being brought to bear on flexible-width
layouts.
http://www.9rules.com/whitespace/des...d_vs_fixed.php
http://www.9rules.com/whitespace/des...id_layouts.php
http://www.notestips.com/80256B3A007F2692/1/TAIO-5TT34F
http://www.simpleydone.com/elementar...id_layouts.php

This matter hasn't been settled. There is no consensus, even among experts
and/or professionals. There is no trend that I can see of a consensus
emerging. One of the above says: "Liquid vs. Fixed width layouts is one of
those holy war type discussions that designers always seem to get into at one
time or another".

My own experience is that, when I have discussed the problem of the width of
my photographs, I get responses that appear to be based on ideology rather
than practical experience. I suspect that, for some people, the answer is
"flexible width", and if someone thinks this gives them a problem, it is
because they have the wrong requirements. Well ... that is too arrogant to
take seriously.

Your own response above gives no indication that you actually have a clue
about the nature of the discussion. Perhaps you have, but until you (and
others) provide evidence that you have read and analysed even the arguments
raised in the last months or a year, the suspicion may be that you are on
auto-pilot.

--
Barry Pearson
http://www.Barry.Pearson.name/photography/
http://www.BirdsAndAnimals.info/
http://www.ChildSupportAnalysis.co.uk/

Jul 20 '05 #24

Neal wrote:

On Sat, 8 May 2004 15:44:36 +0100, Barry Pearson
<ne**@childsupportanalysis.co.uk> wrote:
I think this is a bit like the "don't use px for fonts" debate. I
suspect that the people who might be most impacted by it
will often know of the avoidance actions. (Do people with
visual disabilities who know they need large text really use
IE without getting into the "Accessibility" dialogue and
overriding the px value?)

Just because you're disabled doesn't mean you have the know-how or the
support to get things going your way. It's a little like saying,
"Well, if you had to use a wheelchair to get around, wouldn't you
bring a ramp with you so you can get up and down any stairs you
encounter?"

It is nothing like that. See what you said: "know-how".

I need reading glasses. I would prefer that everyone adapted to my problem, so
that I didn't have to wear them. That is unrealistic. So I took some pretty
elementary steps to equip mself with the knowledge to combat the problem.

My perception of people who *know* they have a physical disability is that
they tend to be more aware of methods of combatting that disability than the
general population are. They also tend to have support groups that others
don't even know about. And if they are unaware of those, perhaps society has a
problem. If someone with a serious visual disability, who needs to be able to
see large text, doesn't know about the "Accessibility" dialogue of IE, I would
classify that as a failure of society.

People will *never* attempt to cater for every problem. I will *never* publish
my websites in Gujarati. I cannot make my photographs visible to blind people.
I may never be able to convey even the simplest idea to a politician with an
ideological objection to the facts I show. We have to draw the line somewhere,
and then let people adapt to us.

We can argue about where the line should be drawn, but disabled people must
*also* expect to adapt. And, given the dominance of "px" values for fonts on
the web, they *will* have to adapt to them, or suffer. And there is nothing
you or I can do to change that.

--
Barry Pearson
http://www.Barry.Pearson.name/photography/
http://www.BirdsAndAnimals.info/
http://www.ChildSupportAnalysis.co.uk/

Jul 20 '05 #25

> ... HTML is not hard to learn, at all.

Sorry, but professional will never say that.

Andrew Fedoniouk.
http://terrainformatica.com

Jul 20 '05 #26

Neal

On Sat, 08 May 2004 18:31:46 GMT, Andrew Fedoniouk
<ne**@terrainformatica.com> wrote:

... HTML is not hard to learn, at all.

Sorry, but professional will never say that.

Easy to learn, difficult to master.

Jul 20 '05 #27

Daniel R. Tobias

"Barry Pearson" <ne**@childsupportanalysis.co.uk> wrote in message news:<8s*************@newsfe5-gui.server.ntli.net>...

I don't agree with that where images are concerned. I work with largish
images, typically photographs, quite a bit, and find it a good idea to match
up the various image & non-image sizes.

Of course, using fixed-pixel-width layouts does *not* accomplish this,
since there is the possibility of the users having different text
sizes nevertheless (even if you attempt to force pixel sizes for the
fonts too; Mozilla, at least, still lets you resize the text in this
case).

--
Dan

Jul 20 '05 #28

Brian

Barry Pearson wrote:

I think this is a bit like the "don't use px for fonts" debate.
I suspect that the people who might be most impacted by it will
often know of the avoidance actions.

People will *never* attempt to cater for every problem. I will
*never* publish my websites in Gujarati.

That is not an accessibility issue, but one of content. A translation of
a document would require either (a) additional content on the same page,
or (b) a separate document. By contrast, letting the reader choose their
font size requires no additional content.

HTML/www cannot produce translations for us. But they do provide very
flexible reading situations, unless the author tries to prevent that
flexibility.
We have to draw the line somewhere, and then let people adapt to us.
On the www, with HTML, there is often nothing to adapt. Just get out of
the user's way, as a recent poster in ciwa* aptly put it. In the case of
fixed font size, which is what we're discussing at the moment, don't set
a font size at all, and you're done.
We can argue about where the line should be drawn, but disabled
people must *also* expect to adapt.
We can set exactly the same expectation to adapt for all visual readers,
whether someone has excellent vision, uses glasses to read the
newspaper, or suffers from a more severe visual disability: by not
setting a font-size, each reader need only configure their browser.
given the dominance of "px" values for fonts on the web, they *will*
have to adapt to them, or suffer. And there is nothing you or I can
do to change that.

For other authors' sites, of course not. But for sites that I author,
there is something very simple that I can do. Or rather, not do. And in
not doing it, I make it easier for everyone, not just the visually impaired.

--
Brian (remove "invalid" from my address to email me)
http://www.tsmchughs.com/

Jul 20 '05 #29

On Sat, 8 May 2004, Barry Pearson wrote:

My own experience is that, when I have discussed the problem of the width of
my photographs, I get responses that appear to be based on ideology rather
than practical experience.
It comes as no surprise to see -you- saying that. In spite of being
aware of the risk, I think you are mistaken.
I suspect that, for some people, the answer is "flexible width", and
if someone thinks this gives them a problem, it is because they have
the wrong requirements.
well, irrespective of what you or I might say it ought to do, the web
goes on and does pretty much what it does.

One thing I've noticed is that browsers pretty much understand what to
do with pixel-sized objects, and don't need all that much help from
authors to get it right, beyond a bit of border space.

I've seen authors who arrogantly demanded that the caption had to be
at the right of the picture, and it looked great on my screen
(135dpi), but it was way off the right hand edge of my colleague's
(around 70dpi).

I've seen another site where the caption was in much the same place on
my screen, but on my colleague's it had helpfully moved itself below
the picture in order to fit itself comfortably into the place
available. That might or might not be what the author intended, but
I'm willing to give him the benefit of the doubt when the results come
out "right", and in my opinion it did the right thing in the
circumstances. And, surprise surprise, it's quite easy to do using
the web's own features. Whereas DTP-like layout calls for all kinds
of kludges and tricks if it's to behave as the (misguided) author
intended in spite of the variations in display situation.

On our videoconferencing PC, you might have had the picture on the
primary display and its caption on the other screen, which is amusing
but not very useful.
Well ... that is too arrogant to take seriously.
It's a possible bargaining chip; but when an author sees an unusual
presentation situation and plaintively whines "that isn't what I
intended", then I'd have to say he might get better results if he
revised his intentions - in the direction of the flexibility which was
(at least as a principle, albeit the details have changed radically
since) - designed into the web in from the very start.
Your own response above gives no indication that you actually have a clue
about the nature of the discussion. Perhaps you have, but until you (and
others) provide evidence that you have read and analysed even the arguments
raised in the last months or a year, the suspicion may be that you are on
auto-pilot.

Erm, those who live in grass houses should not stow thrones (or
something). When's your next "history of tables for layout"
dissertation due?

Jul 20 '05 #30

Alan J. Flavell wrote:

On Sat, 8 May 2004, Barry Pearson wrote:
My own experience is that, when I have discussed the problem of the
width of my photographs, I get responses that appear to be based on
ideology rather than practical experience.
It comes as no surprise to see -you- saying that. In spite of being
aware of the risk, I think you are mistaken.
I suspect that, for some people, the answer is "flexible width", and
if someone thinks this gives them a problem, it is because they have
the wrong requirements.

well, irrespective of what you or I might say it ought to do, the web
goes on and does pretty much what it does.

Indeed. Many millions of websites. Many 100s of millions of users. Perhaps 99%
pages with table layout. Vast numbers of fixed-width layouts, including many
by undoubted experts. Less than 1% of pages validate. Publishers & authors
world-wide, especially virtually all of the people who actually pay money to
keep the web going, working to their sets of rules. People with purist notions
about HTML & CSS, a microscopic number compared with with publishers & users,
working to another set of rules.

That's the web. Technical experts can't hope to control it. However, they can
influence its development by helping the publishers & users achieve *their*
aim. And that is simple. Websites exist to communicate with the audience.
Everything else is a means to that end. Focus on that communication.
One thing I've noticed is that browsers pretty much understand what to
do with pixel-sized objects, and don't need all that much help from
authors to get it right, beyond a bit of border space.
Indeed. The trick is to synchronise what browsers do with pixel-oriented
objects, with what they do with the rest. It is a pity that the specifications
& technologies for pixel-oriented objects are so limited, (or perhaps just
tardy). If we had adequately-scalable pixel-oriented objects, we wouldn't be
having this discussion.
I've seen authors who arrogantly demanded that the caption had to be
at the right of the picture, and it looked great on my screen
(135dpi), but it was way off the right hand edge of my colleague's
(around 70dpi).

I've seen another site where the caption was in much the same place on
my screen, but on my colleague's it had helpfully moved itself below
the picture in order to fit itself comfortably into the place
available. That might or might not be what the author intended, but
I'm willing to give him the benefit of the doubt when the results come
out "right", and in my opinion it did the right thing in the
circumstances. And, surprise surprise, it's quite easy to do using
the web's own features. Whereas DTP-like layout calls for all kinds
of kludges and tricks if it's to behave as the (misguided) author
intended in spite of the variations in display situation.
It is a pity that experts, here & elsewhere, are so dismissive of the problems
faced by people trying to build pages combining pixel-oriented with other
material. It is a pity that some people here think "desk top publishing" is a
term of scorn, instead of accepting that the web is the greatest desk top
publishing capability the world has ever known.

The world can exist with experts scorning DTP, while fighting publishers who
doing what they can, with the aid of the incredibly pixel-oriented nature of
CSS, to achieve their concept of DTP. Or we can do the sensible thing, and
devise a new concept of DTP that works to the strengths of the web while
satisfying the aims of the publishers.

I prefer the latter. Unfortunately, despite decades in the IT business, I have
never used DTP, so I have only a general idea about it. But that perhaps means
that I am uncluttered by its detail, while appreciating its objectives. I have
started to translate some of the things I see on paper into a web-equivalent.
For example, (it isn't hard!), the "footnote" translates into the
"right-floated sidenote".
http://www.barry.pearson.name/papers...troduction.htm

The 5-box 3-column layout, (or 4-box 2-column layout, etc), is another
adaptation of the paper-world to the nature of the web. It is scorned by some,
but makes massive sense on the web. (The key is that all the important stuff
is in the first 2 *rows*, and the first row is shallow. Therefore the user
sees the *starts* of all the important stuff on a page within seconds, as part
of the "visual hierarchy". Then it is just a matter of vertical scrolling. A
web-oriented way of doing things that is very different from paper-ways of
doing things).

[snip]
Well ... that is too arrogant to take seriously.

It's a possible bargaining chip; but when an author sees an unusual
presentation situation and plaintively whines "that isn't what I
intended", then I'd have to say he might get better results if he
revised his intentions - in the direction of the flexibility which was
(at least as a principle, albeit the details have changed radically
since) - designed into the web in from the very start.

Or perhaps simply fire an author who proves to be an obstacle! You can be part
of the solution, or part of the problem. It is your choice. Someone can be
found to fill your place.

I am a realist engineer, not a head-banger. I work with business managers,
marketers, and project managers, to achieve the best match to the business
objectives, achieving the marketing qualities, within the constraints (cost,
risk, time) of the project.

I have been on both sides of the bid process, (RFPs, ITTs, etc). It is vitally
important to show that you actually understand the aims of the person who will
be paying the bill. And that you can either satisfy those aims, or show that
you have a better alternative than your competitors. There is a word for
people who simply raise objections: "losers".

Your own response above gives no indication that you actually have a
clue about the nature of the discussion. Perhaps you have, but until
you (and others) provide evidence that you have read and analysed
even the arguments raised in the last months or a year, the
suspicion may be that you are on auto-pilot.

Erm, those who live in grass houses should not stow thrones (or
something). When's your next "history of tables for layout"
dissertation due?

It is "A brief history of tables". In the early days of the web, tables were
intended to layout complex material in rows & columns. It was several years
before the distinction between layout tables & data tables, (whatever those
concepts mean), were publicly discussed. (Table semantics, & the WAI, appeared
visibly in 1997, long after the web had "taken off").
http://www.barry.pearson.name/articl...es/history.htm

The above page shows the date it was last updated. (This is a super
Dreamweaver feature that I use on nearly all my pages). At the moment, this
date is 16th April. I have an update in mind, as a result of a discussion in
another newsgroup, see below. This happens all the time. The page will
continue to evolve, month by month. Currently 10 in the Google search for:
history of tables

This is the exchange that triggered my further research. It wasn't about
tables, it was about the idea that the web was (or wasn't) a visual medium. In
the early stages, it was. This is a copy of my response.

<quote>
Michael Fesser wrote: .oO(Dan Vendel GOF)
The web is a visual media - with extremely few exceptions, right?

It was not intended to be, but today it is.

[snip]

I believe, from the evidence I have seen, that the reverse is the case. From
the start, the web was thought of & implemented as a visual medium. Non-visual
aspects of it, apart from such things as MID files for music, followed a
number of years later. The sources below are also linked to from "A brief
history of tables":
http://www.barry.pearson.name/articl...es/history.htm

For example, the 1989 proposal by Berners-Lee says: "Storage of ASCII text,
and display on 24x80 screens, is in the short term sufficient, and essential";
and there is reference to: "... information display software ...".
http://www.w3.org/History/1989/proposal.html

By 1990, Berners-Lee & Cailliau were describing "Hypertext concepts"
including: "When starting a hypertext browser on your workstation, you will
first be presented with a hypertext page which is personal to you.... Such
references are highlighted and can be selected with a mouse (on dumb
terminals, they would appear in a numbered list and selection would be done by
entering a number)"; and a browser "performs the display of a hypertext node
using the client hardware & software environment".
http://www.w3.org/Proposal.html

First suggestions for stylesheets in 1993 were all about visual styling:
http://ksi.cpsc.ucalgary.ca/archives...sages/443.html

In 1993, Berners-Lee & Connolly made an HTML proposal that included the
revealing statements:
"Typical rendering is described for many elements. This is not a mandatory
part of the standard but is given as guidance for designers and to help
explain the uses for which the elements were intended".
"When writing documents, you should assume that whatever is done it is
designed to have the same sort of effect as the styles above".
http://www.w3.org/MarkUp/draft-ietf-iiir-html-01.txt
Note the first of these - "the uses for which the elements were intended" is
illustrated by "Typical rendering"! So, presumably, the use of "paragraph"
is illustrated by showing how "paragraph" is assumed to be rendered! So much
for the myth of presentation-neutral structural mark-up!

In 1993, Raggett proposed HTML+. It said: "HTML+ .... embodies a pageless
model making it suitable for efficient rendering on a wide range of display
types including VT100 terminals, X11, Windows 3.1 and the Macintosh".
http://www.w3.org/MarkUp/HTMLPlus/htmlplus_4.html

Over the next few years, the web "took off". Browsers were entirely visual.
Extensions to HTML were too. Web sites were designed mainly to be seen, plus
some use of such things as MID files for music. This continued through the
W3C's first publications - one of which was HTML 3.2. In December 1996, CSS1
became a recommendation, entirely for visual purposes, as far as I can tell.

Then, in April 1997, the Web Accessibility Initiative was launched. In
December 1997 the HTML 4 recommendation included table-HTML for accessibility
purposes. And in 1998, IBM announced their Home Page Reader speaking browser.
Accessibility, and non-visual media, were several years later than visual
media. CSS2 (also 1998) included non-visual "styling" for the first time.

See: "Since 1994, HTML has been used a thousand times to control presentation
for every one time it's been used to express meaning alone. The issue of
separate presentation and content in HTML itself is long closed. It was a
noble idea but it's not what happened.... While trying to make visual the
intricacies of HTML in a form useful to web designers I finally realized HTML
is all presentation. For years I'd preached its intent was to code structure
and let automation decide presentation. But the data from a spider program I
wrote to tally tag and attribute use in thousands of web sites made it clear
that HTML is a presentation markup language"
Bob Stein, "graphic design basics"
http://www.graphicdesignbasics.com/article1022.html
</quote>

--
Barry Pearson
http://www.Barry.Pearson.name/photography/
http://www.BirdsAndAnimals.info/
http://www.ChildSupportAnalysis.co.uk/

Jul 20 '05 #31

Daniel R. Tobias wrote:

"Barry Pearson" <ne**@childsupportanalysis.co.uk> wrote in message
news:<8s*************@newsfe5-gui.server.ntli.net>...
I don't agree with that where images are concerned. I work with
largish images, typically photographs, quite a bit, and find it a
good idea to match up the various image & non-image sizes.

Of course, using fixed-pixel-width layouts does *not* accomplish this,
since there is the possibility of the users having different text
sizes nevertheless (even if you attempt to force pixel sizes for the
fonts too; Mozilla, at least, still lets you resize the text in this
case).

Have a look at what I am talking about. Try one of my photograph pages.
http://www.barry.pearson.name/photography/

Yes, the thumbnail galleries *eventually* start to expand sideways as the text
expands. They are built using tables, and tables are a brilliant way for web
pages to adapt to the user's situation, including text size & viewport width.
We should use them more.

Then look at the photograph pages. These can be accessed via the galleries. It
takes longer for these to expand sideways, as the text expands. The photograph
stays the same size, and at first the text just expands & wraps below it.
Eventually the text expands sideways. I'm not concerned about this - I assume
such a user is aware of the issues, and is prepared to live with them.

The above pages use tables, at least part of the time. That is why they
expand. If an author wants to control the width, it is necessary to control
other elements via CSS. *That* is where width-control lies - control of
non-table elements via CSS. Put the contents of a table cell in a <div>, and
control that with (say):

div.widthcontrol1 {
width: 200px;
overflow: auto;
}

I am not advocating this. I prefer the fluid layout achieved easily by
table-layout. But some people want strict control, and they can achieve that
using CSS & non-table elements.

--
Barry Pearson
http://www.Barry.Pearson.name/photography/
http://www.BirdsAndAnimals.info/
http://www.ChildSupportAnalysis.co.uk/

Jul 20 '05 #32

... HTML is not hard to learn, at all.

Sorry, but professional will never say that.

Easy to learn, difficult to master.

I'll agree if you are speaking about HTML 3.2 only.
CSS and JavaScript concepts are difficult even for professional designer.
I never seen in my life visual designer which can do the Art and can explain
me clearly inheritance of object attributes in JavaScript.

Even CSS box model is not that abstract which human would expect and deal
easily.

Cite from my wife (btw: she has bachelor degree in Mechanics):
First and the last her expression in attempt to get the idea:
"Why width of match box is actually not its width but width of the place
inside the box where matches are placed?
Just-show-me-the-guy-who-invented-this" :)

Andrew Fedoniouk.
http://terrainformatica.com

Jul 20 '05 #33

Brian

Barry Pearson wrote:

the thumbnail galleries *eventually* start to expand sideways as the text
expands. They are built using tables, and tables are a brilliant way for web
pages to adapt to the user's situation, including text size & viewport width.
We should use them more.

Still playing that broken record, I see.

--
Brian (remove "invalid" from my address to email me)
http://www.tsmchughs.com/

Jul 20 '05 #34

Bravo, Barry!

The width attribute value of my agree is 120% :)

Andrew Fedoniouk.
http://terrainformatica.com

Jul 20 '05 #35

Neal

On Sat, 08 May 2004 23:17:00 -0400, Brian
<us*****@julietremblay.com.invalid> wrote:

Barry Pearson wrote:
the thumbnail galleries *eventually* start to expand sideways as the
text
expands. They are built using tables, and tables are a brilliant way
for web
pages to adapt to the user's situation, including text size & viewport
width.
We should use them more.

Still playing that broken record, I see.

Hey Brian, did you know that tables were intended for displaying complex
data in rows and columns?

Jul 20 '05 #36

In message <20***********************@mickey.empros.com>, Michael
Stemper <ms******@siemens-emis.com> writes

For instance, when you put (to use your example):
<H1>Moose Bites versus Llama Bites</h1>
you're doing both of the following:
1. You're indicating that the page in question compares moose and
llama bites. This enables computers in a different part of the
country to be aware that you have information available to them
on that subject.

Oddly enough, we have the Web in other countries, too.
--
Andy Mabbett
"The Internet is a reflection of our society[ ...]. If we do not like what we
see in that mirror the problem is not to fix the mirror, we have to fix
society." Vint Cerf

Jul 20 '05 #37

In message <2g************@uni-berlin.de>, Harlan Messinger
<h.*********@comcast.net> writes

HTML isn't code, it's data.

Surely, used properly, it's metadata?
--
Andy Mabbett
"The Internet is a reflection of our society[ ...]. If we do not like what we
see in that mirror the problem is not to fix the mirror, we have to fix
society." Vint Cerf

Jul 20 '05 #38

Brian

Neal wrote:

Brian wrote:
Barry Pearson wrote:
tables are a brilliant way for web pages to adapt to the user's
situation, including text size & viewport width. We should use
them more.

Still playing that broken record, I see.

Hey Brian, did you know that tables were intended for displaying
complex data in rows and columns?

Gosh! No! I wonder if someone will tell me more? ;-)

--
Brian (remove "invalid" from my address to email me)
http://www.tsmchughs.com/

Jul 20 '05 #39

Lauri Raittila

In article Andrew Fedoniouk wrote:

> ... HTML is not hard to learn, at all.

Sorry, but professional will never say that.

Show me professional, who thinks HTML is hard to learn, and I show you
professional, that don't know what HTML is. All you need is good tutor.
Most people never had one.
Easy to learn, difficult to master.
I'll agree if you are speaking about HTML 3.2 only.

HTML4 strict is much easier. My little sister learned basics in about 4
hours. Basics of CSS took 2 hours. Mastering HTML would take maybe 4
hours more, mastering CSS couple of years...
CSS and JavaScript concepts are difficult even for professional designer.
And they aren't HTML.
I never seen in my life visual designer which can do the Art and can explain
me clearly inheritance of object attributes in JavaScript.
And relevance to HTML?
Even CSS box model is not that abstract which human would expect and deal
easily.
And relevance to HTML?
Cite from my wife (btw: she has bachelor degree in Mechanics):
First and the last her expression in attempt to get the idea:
"Why width of match box is actually not its width but width of the place
inside the box where matches are placed?

Because width is short for content-width. IMHO, it should have been named
content-width and width would be different from it. And we wouldn't need
some stupid box-sizing in CSS3. But done is done.

--
Lauri Raittila <http://www.iki.fi/lr> <http://www.iki.fi/zwak/fonts>
I'm looking for work | Etsin työtä

Jul 20 '05 #40

C A Upsdell

> In message <2g************@uni-berlin.de>, Harlan Messinger

<h.*********@comcast.net> writes
HTML isn't code, it's data.

Then it's not Morse Code, but Morse Data? And ASCII (American Standard Code
for Information Interchange) should really be ASDII? And DNA code doesn't
exist, but rather DNA data?

Methinks you use a definition of code that is unreasonably narrow.

Jul 20 '05 #41

On Sun, 9 May 2004, Andrew Fedoniouk wrote:

http://terrainformatica.com

That's quite remarkable. You seem to have created a
reasonably-flexible page design despite your use of invalid
last-millennium markup that looks as if it was aiming to be HTML/3.2:

[...]
<P><A href="htmengine">HtmEngine</A> - <FONT size=2><FONT size=2>
Lightweight HTML WYSIWYG editing component,<BR>layout manager
and HTML print processor. For C++(WTL/MFC), Delphi and .NET</FONT></P>

<P><A href="htmeditor">HtmEditor</A> - <FONT size=2><FONT
size=2>
Lightweight HTML WYSIWYG editor<BR>ActiveX component. For
desktop applications and for the Web.</FONT></P>
[...]

Haven't seen that[1] kind of clutter for ages, at least not in
halfways-current page designs. Quite remarkable; though whether it
really supports Barry's thesis is something that I wouldn't care to
guess.

[1] of course we've seen a different kind of clutter. class=msoNormal
seems to be a popular ingredient...

Jul 20 '05 #42

HTML4 strict is much easier. My little sister learned basics in about 4
hours. Basics of CSS took 2 hours. Mastering HTML would take maybe 4
hours more, mastering CSS couple of years...

"2 hours". Yep, she has these 2 hours. And plenty hours ahead.
One problem: they are passing too quickly.

And don't even try to tell me that she got an idea and imagination to deal
with <IMG align=right> in these two hours.

This is more realistic:
2 years for HTML/CSS + 2 years for networking/JavaScript and other Internet
technologies = Bachelor Degree in such simple thing as HTML and company.
And they aren't HTML.
And relevance to HTML?
And relevance to HTML?

Are you kidding me?

The whole bunch of *Web*Dev* resources is just one permanent cry:
"Use CSS when possible". Did you hear it?

Andrew Fedoniouk.
http://terrainformatica.com

Jul 20 '05 #43

Lauri Raittila

In article Andrew Fedoniouk wrote:

HTML4 strict is much easier. My little sister learned basics in about 4
hours. Basics of CSS took 2 hours. Mastering HTML would take maybe 4
hours more, mastering CSS couple of years...

"2 hours". Yep, she has these 2 hours. And plenty hours ahead.
One problem: they are passing too quickly.

And don't even try to tell me that she got an idea and imagination to deal
with <IMG align=right> in these two hours.

Of course not. But she did get how to use <img> element.
This is more realistic:
2 years for HTML/CSS + 2 years for networking/JavaScript and other Internet
technologies = Bachelor Degree in such simple thing as HTML and company.
Yes. But still, it don't take much more than 8 hours to learn most HTML
strict.

And they aren't HTML.
And relevance to HTML?
And relevance to HTML?

Are you kidding me?

CSS != HTML. Nobody spoke anything about CSS being easy, let alone JS.
The whole bunch of *Web*Dev* resources is just one permanent cry:
"Use CSS when possible". Did you hear it?

Sure. But HTML is not hard, at least in strict form. Neither me or Neil
said CSS would be easy. Even if I used to think so.

Fact is that to make good website, you need to know HTML, maybe some
basics of CSS, and then you need *content*.

--
Lauri Raittila <http://www.iki.fi/lr> <http://www.iki.fi/zwak/fonts>
I'm looking for work | Etsin työtä

Jul 20 '05 #44

> > http://terrainformatica.com

That's quite remarkable. You seem to have created a
reasonably-flexible page design despite your use of invalid
last-millennium markup that looks as if it was aiming to be HTML/3.2:

:)))) Cool! Got one! I was waiting who first will press "Show source
code!"

I am not a web designer. I am C++ programmer.
I've created this web site in 15 minutes in HTML editor which I designed by
myself (http://blocknote.net)
(You can see meta GENERATOR there)
And I had exactly 15 minutes to create it.

26000 users are using my editor in different systems to create fragments of
the mozaic named the Web.
Most of them are happy so far. I can forward you their letters if you wish
to get Barry's point.

Andrew Fedoniouk.
http://terrainformatica.com

Jul 20 '05 #45

On Sun, 9 May 2004, Lauri Raittila wrote:

CSS != HTML. Nobody spoke anything about CSS being easy, let alone JS.

I don't see any reason why authors shouldn't learn HTML (strict)
in order to mark up the structure of their content, and leave the
presentation to a stylesheet designed by a CSS specialist.

There's no reason why content authors *should* need to learn web
presentation, any more than they needed to learn book typography.
That's more efficiently and effectively looked after by their
publisher. Very few authors either wish or are capable of doing their
own typography, and those few that do are welcome to carry it out; but
I'm sure that most authors of content are better served by having a
specialist work on the styles.

all the best

Jul 20 '05 #46

Fact is that to make good website, you need to know HTML, maybe some
basics of CSS, and then you need *content*.

Mostly agree. Only one - "good website" is little bit fuzzy, isn't it?
And, yes, *content* and *idea* are everything.

As a rule one person has an idea/content and another person knows how to
wrap them into HTML.
Too frequently we are loosing *personality* at some point.

Too many "professional" web sites with perfect HTML and banners "W3C
certified" which are not making any tracks in memory.

I am sure you know what I mean.

Andrew Fedoniouk.
http://terrainformatica.com

Jul 20 '05 #47

In message <rt***************@newsfe3-win.server.ntli.net>, Barry
Pearson <ne**@childsupportanalysis.co.uk> writes

My own experience is that, when I have discussed the problem of the
width of my photographs, I get responses that appear to be based on
ideology rather than practical experience.

Speaking of "practical experience", have you viewed you site on a PDA
yet?
--
Andy Mabbett
"The Internet is a reflection of our society[ ...]. If we do not like what we
see in that mirror the problem is not to fix the mirror, we have to fix
society." Vint Cerf

Jul 20 '05 #48

In message <xe***************@newsfe1-gui.server.ntli.net>, Barry
Pearson <ne**@childsupportanalysis.co.uk> writes

Indeed. Many millions of websites. Many 100s of millions of users.
Perhaps 99% pages with table layout.

More violins are played badly than well. I know which I prefer to listen
to.
--
Andy Mabbett
"The Internet is a reflection of our society[ ...]. If we do not like what we
see in that mirror the problem is not to fix the mirror, we have to fix
society." Vint Cerf

Jul 20 '05 #49