By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
440,304 Members | 3,174 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 440,304 IT Pros & Developers. It's quick & easy.

HTML Editor

P: n/a
I'm new to HTML and want to learn the basics by learning to code by hand
(with the assistance of an HTML editor to eliminate repetitive tasks).
Can anyone recommend a good, basic HTML editor that's a step beyond
Notepad (not a WYSIWYG tool). Thanks.
Jul 20 '05 #1
Share this Question
Share on Google+
71 Replies


P: n/a
tomy_baseo wrote:
I'm new to HTML and want to learn the basics by learning to code by
hand (with the assistance of an HTML editor to eliminate repetitive
tasks). Can anyone recommend a good, basic HTML editor that's a step
beyond Notepad (not a WYSIWYG tool). Thanks.


A question - why not a WYSIWYG tool as well? (I can fully understand an answer
"because it costs too much"!)

The reason I ask is that I use Dreamweaver (4), which has a design-view
(WYSIWYG) mode, and code-view mode, and a split-screen mode. It can be very
useful to be able to type in the design-view section and see the code appear
as you type in the code-view section, and vice-versa.

I am not trying to "sell" D4. It has its faults. I haven't tried enough others
to be confident in a specific recommendation. But I can confidently say that
it is possible to learn a lot by watching what code a WYSIWYG editor produces.
And also useful to get a rapid feedback from the code you write.

(Personally, the main reason I chose D4 was because I was told it had adequate
site-management. It appears to meet my needs).

--
Barry Pearson
http://www.Barry.Pearson.name/photography/
http://www.BirdsAndAnimals.info/
http://www.ChildSupportAnalysis.co.uk/
Jul 20 '05 #2

P: n/a
"tomy_baseo" a crit dans le message de news:
I'm new to HTML and want to learn the basics by learning to code by hand
(with the assistance of an HTML editor to eliminate repetitive tasks).
Can anyone recommend a good, basic HTML editor that's a step beyond
Notepad (not a WYSIWYG tool). Thanks.


PSPad is a very nice (and free) tool :
http://www.pspad.com/index_en.html
--
Vincent Gardet
Jul 20 '05 #3

P: n/a
On Fri, 24 Oct 2003, Barry Pearson wrote:
A question - why not a WYSIWYG tool as well?
In HTML, "what you get" is a marked-up logical structure. Is that
what you see?

If you meant "why not a graphical previewing editor?", that might be
different.
(I can fully understand an answer "because it costs too much"!)


Like Mozilla Composer, you mean? :-}

And I can partially understand the answer: "because, in relation to
the WWW, the term WYSIWYG doesn't really mean what it says, and
everyone knows that it really means a graphical previewing editor".

But I don't agree with it: large numbers of casual[1] web authors
really _do_ believe that they are doing DTP, and then get
unnecessarily confused and dispirited when they find out what the web
is _really_ doing to their creations.

As someone else said, WYSINWOG. And as I said, WYSIJOPR.

cheers

[1] I suppose I have to stress once again that this doesn't mean you,
bearing in mind the number of occasions that you've appeared to take
some general remark of mine as if it was an affront to you personally.
Jul 20 '05 #4

P: n/a
"tomy_baseo" <to********@sbcglobal.net> wrote in message
news:Bz***************@newssvr23.news.prodigy.com. ..
I'm new to HTML and want to learn the basics by learning to code by hand
(with the assistance of an HTML editor to eliminate repetitive tasks).
Can anyone recommend a good, basic HTML editor that's a step beyond
Notepad (not a WYSIWYG tool). Thanks.


Personally, I like Macromedia Homesite (formerly owned by Allaire). The
interface is similar to Dreamweaver, and has some helpful methods for
creating elements in your code, but it's not a WYSIWYG tool (though it does
allow you to switch between editing mode and a view of what the output looks
like). Great tool.
Regards,
Peter Foti

Jul 20 '05 #5

P: n/a
Alan J. Flavell wrote:
On Fri, 24 Oct 2003, Barry Pearson wrote:
A question - why not a WYSIWYG tool as well?
In HTML, "what you get" is a marked-up logical structure. Is that
what you see?


Fair comment. But remember that Dreamweaver is using the styles at the same
time, and can even edit the styles, so it isn't JUST the mark-up you are
seeing. It is having a stab at what the combined mark-up & styles would look
like under a range of conditions. And I observe that what I see in D4 is often
somewhat like what I see later in my set of browsers with their default
settings. After all, if I have table mark-up, and a CSS that specifies sizes &
colours, D4 is entitled to make a good guess about what lots of people will
see. Now some UAs may render that as the smell of dog poo or the taste of
unoaked Chardonney, but perhaps with the right extension even that can be
previewed. (I don't think I'll take the dog poo extension!)

(Since version 4 is limited in its ability to display the document styled
according to the styles in use, the more I put into the CSS, the less like
WYSIWYG it actually looks).
If you meant "why not a graphical previewing editor?", that might be
different.
OK, but I think where this is leading is that nothing in the world is
"WYSIWYG" except the absolutely final rendering. DTP isn't - you may print it
on a B&W printer, or run the electronic version through a speech-generator. In
other words, the term "WYSIWYG" always implicitly needs qualifying. And with
the web it needs a bit more qualification that when the term is used in other
contexts. I see no reason to scrap the term in all circumstances, and little
reason to scrap the term in this case.
(I can fully understand an answer "because it costs too much"!)


Like Mozilla Composer, you mean? :-}


I'd forgotten that! I must try the editors I have in UAs. I guess the one you
mention is the one I have in Netscape 7.1? And there is another in Amaya (hm!)
And I can partially understand the answer: "because, in relation to
the WWW, the term WYSIWYG doesn't really mean what it says, and
everyone knows that it really means a graphical previewing editor".
See above - I don't think it ever literally means what it says, even away from
the WWW. Different qualifications apply in different cases.
But I don't agree with it: large numbers of casual[1] web authors
really _do_ believe that they are doing DTP, and then get
unnecessarily confused and dispirited when they find out what the web
is _really_ doing to their creations.

As someone else said, WYSINWOG. And as I said, WYSIJOPR.
I found WYSIJOPR (only) in a German page on the web, where the English version
of this term was given. So I used Google to translate the whole page, and the
English translation of the English term became: "What You lake Is Just One
Possible Rendering"! Chuckle!
cheers

[1] I suppose I have to stress once again that this doesn't mean you,
bearing in mind the number of occasions that you've appeared to take
some general remark of mine as if it was an affront to you personally.


I am affronted by that casual remark!

(No I'm not - I just like clarity, and sometimes that means challenging things
where I think people might make the wrong link between what I said and
someone's response. I've had some astonishing things attributed to me that
have turned out to be other people's responses).

--
Barry Pearson
http://www.Barry.Pearson.name/photography/
http://www.BirdsAndAnimals.info/
http://www.ChildSupportAnalysis.co.uk/
Jul 20 '05 #6

P: n/a
On Fri, 24 Oct 2003 01:50:25 GMT, tomy_baseo wrote:

Can anyone recommend a good, basic HTML editor that's a step beyond
Notepad (not a WYSIWYG tool). Thanks.


Try out TopStyle Pro <http://www.bradsoft.com/topstyle/>.
For me it's the best HTML/CSS - editor for Windows at the moment,
especially if you want to learn _correct_ HTML.



--
Eckhard Rotte.
Jul 20 '05 #7

P: n/a
On Fri, 24 Oct 2003, Barry Pearson wrote:
As someone else said, WYSINWOG. And as I said, WYSIJOPR.
I found WYSIJOPR (only) in a German page on the web,


I know the one you mean; but Google Groups earliest reference is
Pi**********************************...us06 .cern.ch
from June 1996.
of this term was given. So I used Google to translate the whole page, and the
English translation of the English term became: "What You lake Is Just One
Possible Rendering"! Chuckle!


I get the joke ;-)

You heard the one about the "hydraulic ram" that ended up translated
via Russian and back to "male water sheep" ?
Jul 20 '05 #8

P: n/a
"Eckhard Rotte" <us********@erotte.de> wrote in message
news:pk****************************@40tude.net...
On Fri, 24 Oct 2003 01:50:25 GMT, tomy_baseo wrote:

Can anyone recommend a good, basic HTML editor that's a step beyond
Notepad (not a WYSIWYG tool). Thanks.


Try out TopStyle Pro <http://www.bradsoft.com/topstyle/>.
For me it's the best HTML/CSS - editor for Windows at the moment,
especially if you want to learn _correct_ HTML.


That reminds me, TopStyle is included with Homesite. But there may have
been newer versions of TopStyle released since the last version of Homesite.

-Peter
Jul 20 '05 #9

P: n/a
On Fri, 24 Oct 2003 11:59:16 -0400, Peter Foti wrote:

That reminds me, TopStyle is included with Homesite. But there may have
been newer versions of TopStyle released since the last version of Homesite.


There's a Version of Topstyle Lite included with Homesite which contains a
small subset of the feature set of TopStyle Pro. At first, Top Style is a
CSS Editor but it has become a more than fully featured HTML-Editor since
Version 3.0. I'm not sure, but you would miss a lot of HTML features in TS
Lite.

--
Eckhard Rotte.
Jul 20 '05 #10

P: n/a
On Fri, 24 Oct 2003 01:50:25 GMT, tomy_baseo <to********@sbcglobal.net>
wrote:
I'm new to HTML and want to learn the basics by learning to code by hand
(with the assistance of an HTML editor to eliminate repetitive tasks).
Can anyone recommend a good, basic HTML editor that's a step beyond
Notepad (not a WYSIWYG tool). Thanks.


I use NoteTab myself. Others that have been recommended here in the past
include Textpad, Arachnophilia, Matizha Sublime, HTML-kit, UltraEdit and
Stones Webwrite.

HTH

--
Stephen Poley

http://www.xs4all.nl/~sbpoley/webmatters/
Jul 20 '05 #11

P: n/a
Barry Pearson wrote:
tomy_baseo wrote:
I'm new to HTML and want to learn the basics by learning to code by
hand (with the assistance of an HTML editor to eliminate repetitive
tasks). Can anyone recommend a good, basic HTML editor that's a step
beyond Notepad (not a WYSIWYG tool).
A question - why not a WYSIWYG tool as well?


Because HTML and WYSIWYG are mutually exclusive?
The reason I ask is that I use Dreamweaver (4), which has a design-view
(WYSIWYG) mode,
What does WYSIWYG have to do with HTML, given the variety of HTML
user-agents? Put it another way: what is the relationship between
what D4 shows you in WYSIWYG mode and what Lynx shows you?
and code-view mode, and a split-screen mode. It can be very
useful to be able to type in the design-view section and see the code appear
as you type in the code-view section, and vice-versa.


But D4 is not a web browser, is it? So how is it helpful to see how
the editor renders the code? It seems far more useful for the op to
use a text editor and swap to a real browser, one used by surfers, to
see what the code does.

--
Brian
follow the directions in my address to email me

Jul 20 '05 #12

P: n/a
Stephen Poley wrote:
On Fri, 24 Oct 2003 01:50:25 GMT, tomy_baseo <to********@sbcglobal.net>
wrote:
I'm new to HTML and want to learn the basics by learning to code by hand
(with the assistance of an HTML editor to eliminate repetitive tasks).
Can anyone recommend a good, basic HTML editor that's a step beyond
Notepad (not a WYSIWYG tool). Thanks.


I use NoteTab myself. Others that have been recommended here in the past
include Textpad, Arachnophilia, Matizha Sublime, HTML-kit, UltraEdit and
Stones Webwrite.


all of which have a range of good features

the best bet is try a few and stay with the one(s) that has the feature
set that you need and the interface you feel comfortable with...when it
comes down to it as long as the software is competently programmed it's
very much a matter of your working process and your taste

--
eric
www.ericjarvis.co.uk
all these years I've waited for the revolution
and all we end up getting is spin
Jul 20 '05 #13

P: n/a
Alan J. Flavell wrote:
On Fri, 24 Oct 2003, Barry Pearson wrote:
> As someone else said, WYSINWOG. And as I said, WYSIJOPR.


I found WYSIJOPR (only) in a German page on the web,


I know the one you mean; but Google Groups earliest reference is
Pi**********************************...us06 .cern.ch
from June 1996.

[snip]

I agree with Paul Savage's response to your article above. No application is
truly WYSIWYG if we are pedantic. So should we stop using the term for Word,
DTP, everything else? I also have to disagree with your "WYSIJOPR". WISIJTPR.
I run with a calibrated CRT monitor attached to my laptop. I always see 2
possible renderings for everything I do! (Sorry for that).

"WYSIWYG" always needs qualification. Perhaps the mistake is that IT literate
people like myself sometimes forget to add the qualification. Fair comment.
But there are lots of other shortcuts that people here & elsewhere make.
People talk about "tableless layout", or "content versus presentation". These
are probably understood among experienced people, but implicitly carry a lot
of ifs & buts with them. And I suspect that even experienced people would not
agree the full set of qualifications.

I believe there is a significant difference between "WYSIWYG editor" &
"Graphical Preview editor" that justifies the use of WYSIWYG here, as
elsewhere. What I mean by "WYSIWYG editor" is one where the editing can be
done within a representation of the possible rendering. I can type into what
looks on screen like a table cell, and see the possible rendering change
directly as I do so. (And I can optionally also see the mark-up change). I can
click on the style selection panel, and see the colour of that cell change on
the screen. (And also see class="..." suddenly appear in the <td>). The colour
of that cell on the screen matches the RGB colour in the CSS, so is a good
clue about how another system that has a plausible rendering of CSS colours
will show it.

I accept that if the document is rendered by a speech-reader, it won't
resemble that. Ditto for a Word document, DTP, PDF document, etc. I have
colour-coded graphs in one on-line paper where I explain how someone viewing
in monochrome can decode the graph. So it is useful to keep in mind the
qualifications. But - in that latter example, I put that explanation into the
original Word document in case it was photocopied on a monochrome copier. This
is a general issue, not confined to web authoring.

--
Barry Pearson
http://www.Barry.Pearson.name/photography/
http://www.BirdsAndAnimals.info/
http://www.ChildSupportAnalysis.co.uk/
Jul 20 '05 #14

P: n/a
Brian wrote:
Barry Pearson wrote:
tomy_baseo wrote:
I'm new to HTML and want to learn the basics by learning to code by
hand (with the assistance of an HTML editor to eliminate repetitive
tasks). Can anyone recommend a good, basic HTML editor that's a step
beyond Notepad (not a WYSIWYG tool).


A question - why not a WYSIWYG tool as well?


Because HTML and WYSIWYG are mutually exclusive?


"WYSIWYG" is both marketing-speak and specialist jargon. As marketing-speak it
has the deficiences that are noted here. It ALWAYS needs qualification,
whether used in a WWW context of any other. As specialist jargon, it is
convenient shorthand that is as valid for the WWW as elsewhere. (After all,
Ventura Publisher was - is? - a respectable DTP package that used mark-up and
stylesheets, and also offered WYSIWYG capability. As far as I know, no
knowledgeable person claimed that it guaranteed that you would eventually get
what you saw at editting time. Knowledgeable people would roll on the floor
laughing at that!)

I see no reason why using a WYSIWYG web-page editor isn't at least equivalent
to giving that web page yet another preview or test or validation. None of
these methods are perfect - validating at W3C doesn't ensure that pages will
render as you want, nor does testing in Firebird. There is an interesting
difference - the editor KNOWS that you are developing the web page, and could
in theory apply appropriate development-time checks that a typical browser
wouldn't apply. (Indeed, Dreamweaver tells me in yellow about tag-errors that
some browsers would tolerate).

Some (perhaps all?) WYSIWYG web-page editors use the CSS identified by the
HTML to render the document in the WYSIWYG window. So they are going further
than making guesses about how the mark-up may render. In a qualified
specialist-jargon sense, it is reasonable to use the term WYSIWYG. As much as
for any other application where the term is used. (If you would prefer to see
the word never to be used in ANY context, that is a different discussion).
The reason I ask is that I use Dreamweaver (4), which has a
design-view (WYSIWYG) mode,


What does WYSIWYG have to do with HTML, given the variety of HTML
user-agents? Put it another way: what is the relationship between
what D4 shows you in WYSIWYG mode and what Lynx shows you?


The same relationship as your "swap to a real browser, one used by surfers",
in your paragraph below! That could mean IE, Opera, Firebird, Netscape, etc.
Yet surely many of us here go ahead and try those browsers anyway, even though
they don't tell us what Lynx shows.

We mustn't get too focused on the exceptional cases. Yes, some users will be
blind, and use UAs that speak the material. Others won't be using CSSs. Some
may use a monochrome screen. But that doesn't stop us writing a style in a CSS
that says { color: #FF0000; }. We know "only" most, and not all, users & their
UAs will exploit that declaration - but we go ahead anyway. And we probably
validate it, preview it, etc. We may run it past the colour contrast check. I
check my colours on a calibrated monitor, even though few users will be using
calibrated monitors. It all helps to "control the controllables".
and code-view mode, and a split-screen mode. It can be very
useful to be able to type in the design-view section and see the
code appear as you type in the code-view section, and vice-versa.


But D4 is not a web browser, is it? So how is it helpful to see how
the editor renders the code? It seems far more useful for the op to
use a text editor and swap to a real browser, one used by surfers, to
see what the code does.


A WYSIWYG editor can have advantages far greater than previewing. They
typically allow the editing to be applied to the WYSIWYG rendering itself. You
then (say) type directly into what appears to be a table-cell on the screen.
Or type into the middle of a heading, and quickly gauge whether it is too
verbose. The ability to go directly to the part of the page to be edited using
the visual similarity with the eventual display on a screen is very useful.
If, for some reason, I edit the code directly, I get an almost (not quite)
real time graphical preview, which I find vey useful. It certainly tells me if
I'm editing the wrong bit of the HTML! And, of course, I can get directly to
the right place in the HTML by selecting the approriate place in the WYSIWYG
view - Dreameaver (and I guess others) keeps the state, including the
position, of the 2 views in step. Click on one, see where it is in the other.

THEN I also preview. F12 previews in IE in about 2 seconds. Control+F12
previews in Firebird in about 5 seconds. But previewing is a different concept
from WYSIWYG editing.

--
Barry Pearson
http://www.Barry.Pearson.name/photography/
http://www.BirdsAndAnimals.info/
http://www.ChildSupportAnalysis.co.uk/
Jul 20 '05 #15

P: n/a
On Sat, 25 Oct 2003, Barry Pearson wrote:
I agree with Paul Savage's response to your article above. No application is
truly WYSIWYG if we are pedantic. So should we stop using the term for Word,
DTP, everything else?
I would make the distinction based upon the design aims of the format.
DTP software is created for the very purpose of producing the desired
visual result - albeit, as you say, the content can nevertheless be
used in other ways. The WWW formats were created specifically as an
antidote to DTP software - to facilitate making content available to a
wide range of different presentation situations, with no guarantee of
visual similarity. So the pretence that anything resembling HTML can
be created purely by visual manipulation of the rendered result (which
is what the term WYSIWYG promises to naive beginners) is a fraud.
"WYSIWYG" always needs qualification. Perhaps the mistake is that IT
literate people like myself sometimes forget to add the
qualification.
But with DTP software, it scarcely needs that qualification. Nobody
would be so silly as to expect that by telling the package to print
red, you'd get red text on a black-and-white printer, so they know
that "what you get" will differ from what the designer saw, in that
kind of respect. But the format and the package are still aimed
specifically at producing a consistent visual result.

But large numbers of folk get alarmed and dispirited when, having
"designed" their web pages on the promised WYSIWYG basis, they then
find out what _really_ happens to their pages out on the WWW.
I believe there is a significant difference between "WYSIWYG editor" &
"Graphical Preview editor"
I don't have a good term for it, to be honest. "Direct manipulation
editor" is another term I've seen used. Problem is that HTML was
designed precisely to NOT achieve this, and it seems to me little
short of fraud to present it to naive beginners as such.
What I mean by "WYSIWYG editor" is one where the editing can be
done within a representation of the possible rendering. I can type into what
looks on screen like a table cell, and see the possible rendering change
directly as I do so. (And I can optionally also see the mark-up change).


Yeah, and I've seen folks indenting their paragraphs of text, and seen
the editor producing four-fold-nested blockquotes as the result.
That's fraud. I've seen them making their heading texts big, and the
WYSIWYG editor spitting out <font size...> tags with no hint of
heading markup. I've seen them inserting extra vertical white space,
and the WYSIWYG editor dutifully spitting out
<br>
<br>
<br>
until they've had enough. That's fraud too, though rather more
subtle fraud.

Jul 20 '05 #16

P: n/a
Barry Pearson wrote:
Brian wrote:

In a qualified specialist-jargon sense, it is reasonable to use the
term WYSIWYG.
It is ludicrous to claim wysiwg in an html authoring environment,
especially in shop-talk. Professional web authors presumably know better.
What does WYSIWYG have to do with HTML, given the variety of HTML
user-agents? Put it another way: what is the relationship
between what D4 shows you in WYSIWYG mode and what Lynx shows
you?


The same relationship as your "swap to a real browser, one used by
surfers", in your paragraph below! That could mean IE, Opera,
Firebird, Netscape, etc. Yet surely many of us here go ahead and
try those browsers anyway, even though they don't tell us what Lynx
shows.


Opera is a web user agent. D4 is not a web user agent. Anyways, you
missed the point: WYSIWYG does not produce what Lynx users see.
We mustn't get too focused on the exceptional cases.
What is exceptional about Lynx? I use it. Am I then exceptional?
Yes, some users will be blind, and use UAs that speak the material.
Others won't be using CSSs. Some may use a monochrome screen. But
that doesn't stop us writing a style in a CSS that says { color:
#FF0000; }.


The op asked for an html editor. You're speaking about css. The only
possible use for an editor as you describe it would be a css editor,
one which takes an html document, applies css styles based on
manipulation of the elements. But even there, it's more useful to
preview it in an actual user-agent than an editor's windows.

--
Brian
follow the directions in my address to email me

Jul 20 '05 #17

P: n/a
Brian wrote:
Barry Pearson wrote:
Brian wrote:

In a qualified specialist-jargon sense, it is reasonable to use the
term WYSIWYG.


It is ludicrous to claim wysiwg in an html authoring environment,
especially in shop-talk. Professional web authors presumably know
better.


For reasons I've stated in 2 or 3 articles in the last day or so, I believe it
is perfectly sensible. I recognise that a subset of web authors thinks the
term is wrong. But my reading of what has been said in the past is that a
subset of web authors thinks the term is OK. In other words - we are talking
about opinions. Let's not pretend otherwise.

I don't know what all professional web authors think about this. The original
poster here is presumably not one of them.
What does WYSIWYG have to do with HTML, given the variety of HTML
user-agents? Put it another way: what is the relationship
between what D4 shows you in WYSIWYG mode and what Lynx shows
you?


The same relationship as your "swap to a real browser, one used by
surfers", in your paragraph below! That could mean IE, Opera,
Firebird, Netscape, etc. Yet surely many of us here go ahead and
try those browsers anyway, even though they don't tell us what Lynx
shows.


Opera is a web user agent. D4 is not a web user agent. Anyways, you
missed the point: WYSIWYG does not produce what Lynx users see.


A WYSIWYG editor does, of course, produce what Lynx users see. If I use a
WYSIWYG editor, a Lynx user will see something as a result of what the editor
produces. Now - I accept that what Lynx users see is not what I saw when I was
editing! (Which I assume is what you mean). And neither is it what someone
using a text editor saw when editing. (Which was HTML as text). Both of us are
having to apply mental tranformations.
We mustn't get too focused on the exceptional cases.


What is exceptional about Lynx? I use it. Am I then exceptional?


In the sense in which I was using the term - yes. You are not at that time
part of what I was calling the "large population of similarity".
Yes, some users will be blind, and use UAs that speak the material.
Others won't be using CSSs. Some may use a monochrome screen. But
that doesn't stop us writing a style in a CSS that says { color:
#FF0000; }.


The op asked for an html editor. You're speaking about css. The only
possible use for an editor as you describe it would be a css editor,
one which takes an html document, applies css styles based on
manipulation of the elements. But even there, it's more useful to
preview it in an actual user-agent than an editor's windows.


I'm taking about an HTML editor. I use D4 to edit HTML, not CSS. (I've
configured D4 to call notepad to edit CSS, because D4 is pretty flaky). But it
renders the HTML I am editing in the "design view" (the WYSIWYG view) using
the CSS for the page I am editing. So, for example, if the mark-up is for a
table with just CSS styles and no other mark-up attributes, I see the table
with those styles applied, and can directly edit the contents of the table,
add extra rows, change the classes, etc. (D4 doesn't render it perfectly. I
don't know what later versions, or other WYSIWYG editors, manage. Netscape
Composer appears to make a better job).

And it is certainly very valuable to be able to do such editing on the
rendered display. At least, it is for me and many others. I get the best of
both worlds, plus the advantages of the combination. I can:

- go directly to the right place in the HTML by clicking on the WYSIWYG view
(super!);

- see the mark-up appear as I change the WYSIWYG view (a good check because D4
can produce dodgy code, just as I can myself!);

- select the mark-up I think I need to edit, and see from the selection in the
WYSIWYG view whether I have found the right place in the mark-up;

- change the mark-up and very rapidly see the effect on the rendered view (not
quite real time in D4, it needs an extra click, but faster than using a
preview browser).

I don't think of these as a replacement for later previewing in proper UAs.
They are productivity aids, that enable me to get a lot of things right fast.
Some things I get nearly right fast then tweak the HTML to complete the job.
And sometimes D4 struggles and I have to spot this and sort it out. I have
built up some knowledge of what it can do and what it can't.

--
Barry Pearson
http://www.Barry.Pearson.name/photography/
http://www.BirdsAndAnimals.info/
http://www.ChildSupportAnalysis.co.uk/
Jul 20 '05 #18

P: n/a
On Sat, 25 Oct 2003, Barry Pearson wrote:
Brian wrote:
It is ludicrous to claim wysiwg in an html authoring environment, [...]
For reasons I've stated in 2 or 3 articles in the last day or so, I
believe it is perfectly sensible. I recognise that a subset of web
authors thinks the term is wrong.
I recognise that a subset of web authors refuse to perceive the
illogicality of the term in relation to HTML. Now what?
We mustn't get too focused on the exceptional cases.


What is exceptional about Lynx? I use it. Am I then exceptional?


In the sense in which I was using the term - yes.


I don't disagree. The users of text-mode browsers form a tiny (but
discerning!) minority. The key point to note is not their numbers,
but the principle which they - and other diverse clients - illustrate.
You are not at that time part of what I was calling the "large
population of similarity".
The whole point of inventing HTML was to make the same content
accessible to diverse client situations. If makes you more
comfortable to define those diverse situations as "exceptions" then I
can't stop you doing it. But if it wasn't for them, there would have
been no need for HTML, and we could have had the quasi-DTP language
that the Mosaic Communications Corporation had decided we needed. A
sort-of fullblown outbreak of the HTML3.2 disease, let's say.

So, I can show you two different web pages which, when viewed in a
mainstream graphical browser, look well-nigh identical, despite their
underlying structures being extensively different. But when viewed
(or otherwise processed) in what I call "diverse" and you call
"exceptional" situations, they'd be extensively different.

But by your terminology, "what you see" (i.e in the graphical
manipulation/preview window) is "what you got" in both cases, and
the two pages looked the same. So how do you explain their very
different behaviour, if "what you got" was nothing more than "what you
saw"? Not that I expect you to agree with the logic, but there it is,
anyway.
What you are factoring-out as exceptions are what I consider to be the
key feature of the WWW and its core markup - HTML, as opposed to any
presentation-specific electronic publishing options which may be
offered.
I'm taking about an HTML editor. I use D4 to edit HTML, not CSS. (I've
configured D4 to call notepad to edit CSS, because D4 is pretty flaky).


Hmmm, interesting.
Jul 20 '05 #19

P: n/a
Alan J. Flavell wrote:
On Sat, 25 Oct 2003, Barry Pearson wrote: [snip] The whole point of inventing HTML was to make the same content
accessible to diverse client situations. If makes you more
comfortable to define those diverse situations as "exceptions" then I
can't stop you doing it. But if it wasn't for them, there would have
been no need for HTML, and we could have had the quasi-DTP language
that the Mosaic Communications Corporation had decided we needed. A
sort-of fullblown outbreak of the HTML3.2 disease, let's say. [snip] What you are factoring-out as exceptions are what I consider to be the
key feature of the WWW and its core markup - HTML, as opposed to any
presentation-specific electronic publishing options which may be
offered.

[snip]

I'll simply repeat what I said before, which is a vitally important factor
that will always be part of this discussion.

Although this is about editing HTML, it is about editing HTML in the context
of the CSS it refers to, and the UAs that are likely to render it. So it is
irrelevant what HTML itself is intended for. What matters is the context in
which people develop HTML. And for much of the population, whether they are
developing for the web or users of the web, it is to be combined with CSS and
rendered accordingly (whether they know it or not).

I've looked at the HTML of people who are firm advocates of the "don't think
of HTML in terms of presentation" viewpoint. People who are opposed to
table-oriented layout. People who appear, based on (perhaps a superficial
reading of) what they say, to believe in mark-up as being about linking the
content to the appropriate semantic concepts. (This is a list, that is a
paragraph, the other is an undifferentiated block of content awaiting
presentation to be added).

Chuckle! Does anyone believe that their mark-up was actually created without
reference to intended or envisaged presentation? Honestly? Why did they
cluster that content together, if not to present it within a single box? Why
did they add those extra <div>s, if not to provide the extra hooks to the
control of the presentation, the CSS? (Have a look at the last few lines of
HTML in the CSS Zen Garden). I believe few people genuinely develop their
mark-up without views of the likely forms of presentation, which they ensure
will be supported by their mark-up. (I am willing to examine evidence to the
contrary).

Surely the most relentless suppliers of new pages, hour by hour, are the
on-line news services across the world. Google indexes 4,500 of them. They
each presumably average very many new pages each day. Virtually every one of
them that I have seen is table-oriented. (I browse with an extra style of the
form: table { border: 1px dotted #0000FF !important; }. So I see each table on
every page I browse surrounded by a dotted blue line). I don't believe for a
second that they have bought into anyone else's "intentions" about what HTML
"should" be like. They have mostly designed their sites assuming a viewport
width of between 750 & 800 pixels. But they are probably the major suppliers
of new material, and probably one of the main types of material that people
browsing in untypical situations want to see. Their sites actually work quite
well in Opera 7.2's "small screen" mode.

WYSIWYG editors may not be trying to cater for those concerned with some
people's intentions for the web. But if they can cater for the audience that
is also the audience for the major news services in the world, they have won.
They will conform to most of the material on the web. UAs will necessarily
access them, because they will necessarily be able to access the news
services.

I believe that the trick is to recognise this trend, and turn it to advantage.
There are vastly many millions of web sites. There are many 100s of millions
of web users. There are relatively few UA-developers, who have to recognise
the realities jusy mentioned. And some people recommending standards. Somehow,
the trick is for the last 2 groups to become the leaders once again. I don't
know how. But I do know it doesn't include standing on the sidelines saying
"that isn't how the web was intended to be".

WYSIWYG editors are here to stay, because they support the majority. How do we
ensure that they also support minorities? Composer insists on "alt" text Good!
Now, how do we believe WYSIWYG editors should be developed so that they
achieve all our other aims? Clean, strict, mark-up? Support of minority users?
Maximum flexibility so that they don't hold back the evolution of the web? If
we can work this out, it is win - win - win.

--
Barry Pearson
http://www.Barry.Pearson.name/photography/
http://www.BirdsAndAnimals.info/
http://www.ChildSupportAnalysis.co.uk/
Jul 20 '05 #20

P: n/a
Alan J. Flavell wrote:
On Sat, 25 Oct 2003, Barry Pearson wrote:
I agree with Paul Savage's response to your article above. No
application is truly WYSIWYG if we are pedantic. So should we stop
using the term for Word, DTP, everything else?
I would make the distinction based upon the design aims of the format.
DTP software is created for the very purpose of producing the desired
visual result - albeit, as you say, the content can nevertheless be
used in other ways. The WWW formats were created specifically as an
antidote to DTP software - to facilitate making content available to a
wide range of different presentation situations, with no guarantee of
visual similarity. So the pretence that anything resembling HTML can
be created purely by visual manipulation of the rendered result (which
is what the term WYSIWYG promises to naive beginners) is a fraud.


When I compare (say) Ventura Publisher, with mark-up and style sheets, with
the current and developing set of standards at W3C, I don't see the
distinction being as wide as you do. I accept this is an HTML newsgroup,
where, as you say, the later standards exclude presentation control. But that
applied to Publisher too. Then the W3C CSS standards are putting back in an
incredible degree of specification.

In neither case is there a guarantee of anything. But for a vast range of
displays in the world, with people using their browsers at their default
settings (which may be most of them?), there will actually be a considerable
similarity. What I see about the web isn't that there is little similarity
around. It is that there is a large population of similarity, then lots of
minority exceptions. And a WYSIWYG editor is likely to be focused on that
large population of similarity. That is a good start.

I see no fraud, except perhaps by marketers who oversell their product, or
specialists who omit the qualifications because of familiarity. After all, I
preview my pages with IE 6, Netscape 7.1, Firebird 0.7, and Opera 7.1 before
publishing it. Each of them applies the specified stylesheet then shows me
what they do on my system at their default settings. Now - what is the problem
if I manipulate the "design view" of an editor that uses the same stylesheet,
and so it gives me some very good clues about what I will see when I get round
to previewing the page in those browsers? It is undoubtedly a fact that HTML
can be created by visual manipulation of one example of rendering of the
result. Somethings work better than others. In Dreamweaver 4, CSS-positioning
renders as cr*p (for what I want to do). Tables render pretty well, and I can
safely do a lot of work in design view without much risk of having to rework.
I don't know what MX 2004 will do.

I'm not sure whether it is the concept of "direct visual manipulation of one
rendering" that you object to, or the term "WYSIWYG" to describe it. The
concept is undoubtedly valuable for at least person on this planet - me! And I
suspect large numbers of others for similar reasons. (The term is just a
term).
"WYSIWYG" always needs qualification. Perhaps the mistake is that IT
literate people like myself sometimes forget to add the
qualification.


But with DTP software, it scarcely needs that qualification. Nobody
would be so silly as to expect that by telling the package to print
red, you'd get red text on a black-and-white printer, so they know
that "what you get" will differ from what the designer saw, in that
kind of respect. But the format and the package are still aimed
specifically at producing a consistent visual result.


That isn't the only issue with DTP, of course. For example, fonts can be a
problem too. So can paper size. But I think all this says is that the
"population of similarity" is a higher proportion for DTP than for the web. I
aim with the web to produce consistent visual results as far as possible
within the web's large population of similarity. I'm confident that I succeed
well enough for my current purposes. I also accept that there are those
exceptions.
But large numbers of folk get alarmed and dispirited when, having
"designed" their web pages on the promised WYSIWYG basis, they then
find out what _really_ happens to their pages out on the WWW.


Are they dispirited because of what happens in the large population of
similarity, or to the exceptions? If their editor isn't even getting close
with that large population, perhaps there is something wrong with it. Or
perhaps the fault is with the W3C standards, or browser implementation of
them. After all, when I can look at the CSS standards and see that it supports
pixel-level sizing & positioning, 24-bit control of colour, quite a lot of
specification of fonts, etc, if those don't actually work in practice, whose
fault is it? You might as well say that if I type { color: #FF0000; } into
notepad, and that eventually shows up blue or grey or doesn't get spoken by a
speech reader, then notepad is a fraud! But if you see a WYSIWYG editor as a
way of generating HTML & CSS in a combination that W3C suggests/recommends UAs
to render as you want - that sounds OK.

The W3C standards are not semantically-null - the actually imply a rendering.
#FF0000 surely really means "red" on any properly set-up colour display?
Although <table> is a mark-up that formally doesn't have a rendering
associated with it, even W3C suggests possible renderings on different types
of UA. And, surprise surprise, the browers I've used, when there is enough
screen available to them (eg. at least VGA), render tables in just that way at
their default settings. And so does a WYSIWYG editor!
I believe there is a significant difference between "WYSIWYG editor"
& "Graphical Preview editor"


I don't have a good term for it, to be honest. "Direct manipulation
editor" is another term I've seen used. Problem is that HTML was
designed precisely to NOT achieve this, and it seems to me little
short of fraud to present it to naive beginners as such.


But it is important to realise that WYSIWYG editors sometimes/typically/always
use the HTML + CSS in combination for their display. (Dreamweaver does.
Netscape Composer does). So it isn't a matter of what HTML is designed to
achieve, it is a matter of what HTML + CSS is designed to achieve.
What I mean by "WYSIWYG editor" is one where the editing can be
done within a representation of the possible rendering. I can type
into what looks on screen like a table cell, and see the possible
rendering change directly as I do so. (And I can optionally also see
the mark-up change).


Yeah, and I've seen folks indenting their paragraphs of text, and seen
the editor producing four-fold-nested blockquotes as the result.
That's fraud. I've seen them making their heading texts big, and the
WYSIWYG editor spitting out <font size...> tags with no hint of
heading markup. I've seen them inserting extra vertical white space,
and the WYSIWYG editor dutifully spitting out
<br>
<br>
<br>
until they've had enough. That's fraud too, though rather more
subtle fraud.


It is true that editors let you do silly things. In fact, every editor in the
world lets you do the silliest thing of all - write the wrong document! But
they can help you out. For example, I notice that Composer (unlike D4) insists
on having alt text for images. So it was in some sense ensuring that things
would work OK in non-typical browsing conditions. It wouldn't be hard to put
in extra checks for the sort of thing you mention.

But frankly I think these are quibbles. If you argue for editors that apply
more "plausibility checks", then I'll support that. If you say marketers
shouldn't be allowed to use term "WYSIWYG" without qualification - fine. But
if you reject the concept of developing HTML and/or CSS by direct manipulation
of the editor's rendering of the combined HTML + CSS, then you are wrong. I
and others find this a valuable tool. I'm sure such tools will get better with
time.

--
Barry Pearson
http://www.Barry.Pearson.name/photography/
http://www.BirdsAndAnimals.info/
http://www.ChildSupportAnalysis.co.uk/
Jul 20 '05 #21

P: n/a
Barry Pearson wrote:

Although this is about editing HTML, it is about editing HTML in
the context of the CSS it refers to,
Well, that's not what the op asked.
and the UAs that are likely to render it. So it is irrelevant what
HTML itself is intended for.
Really?!
What matters is the context in which people develop HTML. And for
much of the population, whether they are developing for the web or
users of the web,
The distinction is lost on me.
it is to be combined with CSS and rendered accordingly (whether
they know it or not).
But it may be rendered in a medium that they never imagined, whether
they know it or not.
Does anyone believe that their mark-up was actually created without
reference to intended or envisaged presentation?
Of course it is meant for presentation. Just not for any one
particular presentation.
Why did they cluster that content together,
Because it should be presented together. Why else?
if not to present it within a single box?
i.e., a visual presentation. That's one of many possibilities.
Why did they add those extra <div>s, if not to provide the extra
hooks to the control of the presentation, the CSS?
A good test is to turn off css and see if your document organization
can still be discerned.
(Have a look at the last few lines of HTML in the CSS Zen Garden).
Special case, where the purpose of the site is to demonstrate what css
can do. So the markup is a little over the top.
I believe few people genuinely develop their mark-up without views
of the likely forms of presentation, which they ensure will be
supported by their mark-up. (I am willing to examine evidence to
the contrary).
What evidence would you have anyone present, short of their own claims?
Surely the most relentless suppliers of new pages, hour by hour,
are the on-line news services across the world. Google indexes
4,500 of them. They each presumably average very many new pages
each day. Virtually every one of them that I have seen is
table-oriented.
Few include a doc-type, too. But I don't take my cues from them
regarding inclusion of a doc-type. Neither on their choice to abuse
the table element.
I see each table on every page I browse surrounded by a dotted blue
line). I don't believe for a second that they have bought into
anyone else's "intentions" about what HTML "should" be like. They
have mostly designed their sites assuming a viewport width of
between 750 & 800 pixels.
In short, they have done a great many things wrong. Pity the poor
slob who must clean things up as the web matures. Or envy him, since
he's likely to earn a lot of money fixing the mistakes.
WYSIWYG editors are here to stay, because they support the
majority.
I've seen the same arguments made on behalf of a quasi-browser,
quasi-os component. MSIE/Win is used by the majority, that's what
matters. Still, I would not recommend it. It is not a good browser.
Nor would I recommend a wysiwyg editor to someone who wants to create
web documents.
How do we ensure that they also support minorities? how do we believe WYSIWYG editors should be developed so that they
achieve all our other aims? Clean, strict, mark-up?


If select text and make it bold and large, am I trying to make a
heading? If so, which level should it be? Or perhaps I am simply
choosing a presentation to match surrounding text. That's something a
wywsiwy editor cannot determine by my selecting bold and large.

--
Brian
follow the directions in my address to email me

Jul 20 '05 #22

P: n/a
Brian wrote:
Barry Pearson wrote:

Although this is about editing HTML, it is about editing HTML in
the context of the CSS it refers to,


Well, that's not what the op asked.


So what? It is the world that the OP lives in, whether or not the OP happened
to mention it! If you edit HTML, you do so in the context of the CSS it is
likely to be rendered in, and the UAs that are likely to be doing the
rendering. Or else you waste your time.

[snip]
What matters is the context in which people develop HTML. And for
much of the population, whether they are developing for the web or
users of the web,


The distinction is lost on me.


Gosh! The distinction between whether people are developing for the web or are
users of the web is lost on you? Gosh, again!

[snip]
Does anyone believe that their mark-up was actually created without
reference to intended or envisaged presentation?


Of course it is meant for presentation. Just not for any one
particular presentation.


I believe your statement is incorrect. I believe that often people developing
mark-up create it with reference to AN (repeat AN) intended or envisaged
presentation. This certainly appears to be the case when I look at pages in
the category of "tableless layout".
Why did they cluster that content together,


Because it should be presented together. Why else?
if not to present it within a single box?


i.e., a visual presentation. That's one of many possibilities.


Not to them. It is exactly the ONE presentation they envisaged.
Why did they add those extra <div>s, if not to provide the extra
hooks to the control of the presentation, the CSS?


A good test is to turn off css and see if your document organization
can still be discerned.


That is not an answer to the question. Of course they ensure that it degrades!
But they clearly designed it in the first place with an intended presentation.

[snip]
I believe few people genuinely develop their mark-up without views
of the likely forms of presentation, which they ensure will be
supported by their mark-up. (I am willing to examine evidence to
the contrary).


What evidence would you have anyone present, short of their own
claims?


Just show that the mark-up does not contain the basis of the intended
presentation. For example, that there is no adjacency of content related to
the targetted presentation. Or nor extra <div>s beyond what it logically
necessary. Or that the content does not have dimensions that constrain the
final presentation (such as widths). Perhaps demonstrations of massively
different presentation achieved with only changes to the CSS and no change to
the mark-up.

I strongly recommend that you actually look at the content of the web pages
out there. Why are images that size? Why are the forms that size? Why are some
links long, and some links short? Often it is simply because it was always
intended for the pages to look approximately as they do, and whether the
mark-up was in terms of tables or other means is pretty irrelevant. Radical
choices were squeezed out before the mark-up & CSS was developed.
Surely the most relentless suppliers of new pages, hour by hour,
are the on-line news services across the world. Google indexes
4,500 of them. They each presumably average very many new pages
each day. Virtually every one of them that I have seen is
table-oriented.


Few include a doc-type, too. But I don't take my cues from them
regarding inclusion of a doc-type. Neither on their choice to abuse
the table element.


Many (not all) include a DOCTYPE. Typically 4.01 Transitional. Like me, they
tend to put "font" and anything to do with colour in the CSS, and depart from
"Strict" for such reasons as alignment and perhaps some table attributes. So
they are typically between Transitional & Strict.

Who says they are abusing tables? It is often a matter of opinion. (Otherwise
it would be possible to "deprecate" it, which it isn't). I know from personal
experience that it is possible to have a table-oriented page that validates as
XHTML 1.1. So it will not be ruled out in the foreseaable future. And since it
appears to do no harm, why should it be? I've seen table-oriented pages
displayed on a 240-pixel-wide device. I experienced IBM's Home Page Reader
navigating through such tables - perhaps not as well as with some other
formats, but it manages. (Pop-ups are far worse!)

I believe that those sources typically turn to tables because Frames are so
bad. But Frames would be the logical approach if they had been thought out
better. Tableless approaches are no more logical in those cases than
table-oriented approaches.
I see each table on every page I browse surrounded by a dotted blue
line). I don't believe for a second that they have bought into
anyone else's "intentions" about what HTML "should" be like. They
have mostly designed their sites assuming a viewport width of
between 750 & 800 pixels.


In short, they have done a great many things wrong. Pity the poor
slob who must clean things up as the web matures. Or envy him, since
he's likely to earn a lot of money fixing the mistakes.


They are designing pages for the people in this world who matter. The vastly
many millions of web users who want content, unconstrained by the philosophy
of some people who think differently. Why should that be thought wrong? They
probably understand their target audience far more than most.

No one will have to clean things up. This IS what the mature web is turning
out to be. It is probably how most pages will be for the next decade. Perhaps
a lot more than that. All UAs will have to be able to access such pages. So
why should anyone worry? Why should anyone think that anything needs to be
cleaned up, even though it will continue to work?

Just a point that is worth noting. The majority of those news services have
various fancy banners, etc. But when they deliver true content - the
articles - they typically present it black letters on white background, in a
fairly predictable column. These are people/organisations who understand how
to present important information to people - straight, uncluttered, stripped
of artistic distractions. Columnar approach. What people want/need.
WYSIWYG editors are here to stay, because they support the
majority.


I've seen the same arguments made on behalf of a quasi-browser,
quasi-os component. MSIE/Win is used by the majority, that's what
matters. Still, I would not recommend it. It is not a good browser.
Nor would I recommend a wysiwyg editor to someone who wants to create
web documents.


Your choice. I suspect the world will pass you by. I recall people who thought
that machine code programming was the way to do things. Then assembly level
programming. Now visual studio approaches are plausible. The industry seeks
its cost-effective level. I don't detect what might be the next level -
"declarative authoring of the web" - but who knows? But the endeavour won't
stop at text-level editing, of course. When have things stopped at such a
level? The trick is to try to understand what comes next. I think WYSIWYG
editing has a lot of merit as a component of the next level. What do you think
the next level is?
How do we ensure that they also support minorities?

how do we believe WYSIWYG editors should be developed so that they
achieve all our other aims? Clean, strict, mark-up?


If select text and make it bold and large, am I trying to make a
heading? If so, which level should it be? Or perhaps I am simply
choosing a presentation to match surrounding text. That's something a
wywsiwy editor cannot determine by my selecting bold and large.


You make too many assumptions about such editors. If Composer can insist on
"alt" text for images, why can't an editor insist on a hierarchical structure?
I understand that an ISO version of the W3C standards actually insists on
sequenced hierarchical structure. (True? False?) If so, an editor can try to
enforce this. Don't mis-understand WYSIWYG editors. They do structural stuff
too. I can put lots of material into D4 (eg. by copy & paste), then put the
headings in by control+1, control+2, etc. It would be easy for the editor to
be more forceful about this. So such an editor may be a good way of getting
structure into web pages.

--
Barry Pearson
http://www.Barry.Pearson.name/photography/
http://www.BirdsAndAnimals.info/
http://www.ChildSupportAnalysis.co.uk/
Jul 20 '05 #23

P: n/a
On Sat, 25 Oct 2003, Barry Pearson wrote:
I'll simply repeat what I said before, which is a vitally important factor
that will always be part of this discussion.

Although this is about editing HTML, it is about editing HTML in the context
of the CSS it refers to,
Indeed. It's about the structure, as well as about whatever is
rendered on your favourite graphical web browser.
and the UAs that are likely to render it. So it is
irrelevant what HTML itself is intended for.
On the contrary, the HTML is "of the essence". If you mark it up as a
blockquote in order to get it indented, then the result - in your
limited mass-market graphical browser situation - might be
indistinguishable from your intentions; but yet the HTML would be a
fraud, if the text is not in fact a block of text quoted from
elsewhere.
What matters is the context in which people develop HTML. And for
much of the population, whether they are developing for the web or
users of the web, it is to be combined with CSS and rendered
accordingly (whether they know it or not).
Seems to me that you just described a DTP design situation, in which
the aims and benefits of the "separation of content from presentation"
are tossed aside, and the very motivation of the web is nullified.
Just as we see every day in demonstrations of Sturgeon's Law...
Chuckle! Does anyone believe that their mark-up was actually created without
reference to intended or envisaged presentation?
You appear to be refuting a claim that nobody has seriously presented.

[...]
WYSIWYG editors may not be trying to cater for those concerned with some
people's intentions for the web. But if they can cater for the audience that
is also the audience for the major news services in the world, they have won.
Yeah, like Coronation Street has won the TV ratings. But if that's
all that TV is for, then I'd be turning in my licence right now.
WYSIWYG editors are here to stay, because they support the majority.


We haven't even seemed to agree what these mythical "wysiwyg editors"
are, for a start. On the basis of your recent postings, you seem to
believe that a WYSIWYG editor will be presenting a window showing the
structure of HTML markup, which the author will be adjusting to
reflect the logical structure of his content. And yet you claim to be
factoring-out HTML as a part of the equation, with authors knowing
nothing and caring nothing for the nitty detail of the HTML markup,
but caring only for the visual result as the arbiter of the design,
which indeed is what's normally meant by "WYSIWYG" in other fields.

So which is it to be? It surely can't be both at the same time.
Jul 20 '05 #24

P: n/a
Barry Pearson wrote:
Brian wrote:
Barry Pearson wrote:
So what? It is the world that the OP lives in, whether or not the
OP happened to mention it!


Is this one of those "if you don't do like I do, you're not in the
real world" arguments?
Or else you waste your time.
Looks that way.
whether they are developing for the web or users of the web,


The distinction is lost on me.


Gosh! The distinction between whether people are developing for the
web or are users of the web is lost on you? Gosh, again!


I just love your condescending attitude. But your writing is unclear.
I read your earlier post as, "whether they are developing for the web
or [developing for] users of the web," which I submit is closer to
what you wrote. Had you used a parallel contruction, it would have
been clearer.
Who says they are abusing tables?
I did. If they are using tables for other than tabular data, they are
abusing tables. Just like it's abusing <blockquote> to produce an
indentation instead for extended quotations.
It is often a matter of opinion.
If I used a hammer to pound a screw in the wall, and a carpenter
happened by, (s)he'd likely tell me that I'm using the wrong tool for
the job. I could argue that it's a matter of opinion, of course. But
if you're building a house, you should believe the professional, not me.
(Otherwise it would be possible to "deprecate" it, which it isn't).
Of course not. Tables are for tabular data. If they were deprecated,
how would we mark up tabular data?
I know from personal experience that it is possible to have a
table-oriented page that validates as XHTML 1.1.
It's possible to use &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; to
create a margin, and have a document that validates. But it's hardly
an example of good authoring.
So it will not be ruled out in the foreseaable future. And since it
appears to do no harm, why should it be?
Misusing tables creates a less flexible page. Just like misusing
headings for large bold font, or &nbsp; for margin, or blockquote for
indentation, or....
They are designing pages for the people in this world who matter.
They probably understand their target audience far more than most.


Yep. It *is* a "real world" argument.

--
Brian
follow the directions in my address to email me

Jul 20 '05 #25

P: n/a
Brian wrote:
Barry Pearson wrote:

how do we believe WYSIWYG editors should be developed so that they
achieve all our other aims? Clean, strict, mark-up?


If select text and make it bold and large, am I trying to make a
heading? If so, which level should it be? Or perhaps I am simply
choosing a presentation to match surrounding text. That's something a
wywsiwy editor cannot determine by my selecting bold and large.


I don't believe you can ever create a WYSIWYG editor that is anywhere near
as efficient at creating effective html as is a competent human being with
a text based editor

it's very simple...marking up the document requires some understanding of
the concepts involved in the document and their context...the human brain
does that easily...there is no software anywhere on the planet that gets
anywhere near it...at present nobody knows how it could be done even if
every single computer on Earth was networked and set on to the task...it
requires sentience to mark up a document correctly

WYSIWYG css editors are no problem at all...it is possible to work
entirely by algorithms...since all the conceptual work is done whilst
choosing the presentation

however that presupposes well structured html in the first place

--
eric
www.ericjarvis.co.uk
all these years I've waited for the revolution
and all we end up getting is spin
Jul 20 '05 #26

P: n/a
Barry Pearson wrote:
Brian wrote:
Barry Pearson wrote:

Although this is about editing HTML, it is about editing HTML in
the context of the CSS it refers to,


Well, that's not what the op asked.


So what? It is the world that the OP lives in, whether or not the OP happened
to mention it! If you edit HTML, you do so in the context of the CSS it is
likely to be rendered in, and the UAs that are likely to be doing the
rendering. Or else you waste your time.


only if you are entirely obsessed with the visual presentation of the
document to the exclusion of everything else

however I do take the UAs into account...that's precisely why I start by
making conceptually sound html...because the most important UA of all
requires it...Googlebot

--
eric
www.ericjarvis.co.uk
all these years I've waited for the revolution
and all we end up getting is spin
Jul 20 '05 #27

P: n/a
Alan J. Flavell wrote:

On the contrary, the HTML is "of the essence". If you mark it up as a
blockquote in order to get it indented, then the result - in your
limited mass-market graphical browser situation - might be
indistinguishable from your intentions; but yet the HTML would be a
fraud, if the text is not in fact a block of text quoted from
elsewhere.


just a note for those who don't understand why this matters...in theory it
should be possible to search the web for quotes, for example...if you want
an apposite bit of Shakespeare it should be possible to simply ask a
search engine to fetch only text in blockquotes and which cites
Shakespeare...one should be able to search for tables of data that contain
the words "population" and "Morocco" and get population data about
Morocco...we lose a level of functionality of the entire web due to the
fact that html is routinely abused

--
eric
www.ericjarvis.co.uk
all these years I've waited for the revolution
and all we end up getting is spin
Jul 20 '05 #28

P: n/a
On Sun, 26 Oct 2003 07:21:01 -0000, Eric Jarvis <we*@ericjarvis.co.uk>
wrote:
Alan J. Flavell wrote:
might be
indistinguishable from your intentions; but yet the HTML would be a
fraud, if the text is not in fact a block of text quoted from
elsewhere.
just a note for those who don't understand why this matters...in theory it
should be possible to search the web for quotes, for example...if you want
an apposite bit of Shakespeare it should be possible to simply ask a
search engine to fetch only text in blockquotes and which cites
Shakespeare...


Except the HTML vocabulary is not rich enough for this, correctly used
HTML would give us virtually no increase in the ability to search, and
would be trivially misled - remember not everyone in an open system
wants to tell the truth.
one should be able to search for tables of data that contain
the words "population" and "Morocco" and get population data about
Morocco...


Or tables which have data on the population of marmosets in Morocco...

I don't buy searching as a solution to semantic mark-up, the problem
is not finding quotes from shakespeare, it's about finding high
quality reputable versions of quotes from shakespeare - and structured
mark-up doesn't give that, and can't give that.

Jim.
--
comp.lang.javascript FAQ - http://jibbering.com/faq/

Jul 20 '05 #29

P: n/a
Alan J. Flavell wrote:
On Sat, 25 Oct 2003, Barry Pearson wrote:
I'll simply repeat what I said before, which is a vitally important
factor that will always be part of this discussion.

Although this is about editing HTML, it is about editing HTML in the
context of the CSS it refers to,


Indeed. It's about the structure, as well as about whatever is
rendered on your favourite graphical web browser.


Has anyone said otherwise?

[snip]
What matters is the context in which people develop HTML. And for
much of the population, whether they are developing for the web or
users of the web, it is to be combined with CSS and rendered
accordingly (whether they know it or not).


Seems to me that you just described a DTP design situation, in which
the aims and benefits of the "separation of content from presentation"
are tossed aside, and the very motivation of the web is nullified.
Just as we see every day in demonstrations of Sturgeon's Law...


I made explicit reference to CSS for rendering purposes. That implies
separation of mark-up from presentation. In other words, I am talking about
editing mark-up in a context where, because the effect of the CSS can be seen,
there should be less temptation to put presentation into the mark-up. If I put
a joke into the document, I click on the "joke" class, and see green text -
because the CSS selector for "joke" declares green text. Perhaps you assumed
that I would select that text and set "font" in the HTML - but why would I do
that, when it is easier to set the class, because the editor knows about the
classes?

I didn't just describe a DTP design situation. However, I have been told that
Ventura Publisher really does keep good separation between mark-up and styles,
even though it has a WYSIWYG mode. In fact, does Publisher even have the
ability to put presentation into the mark-up?

Note that everything I've said would apply if the WYSIWYG HTML editor simply
didn't even have the capability to put presentation in the mark-up. Would you
object to a WYSIWYG editor that read the DOCTYPE and didn't allow you to
contravene it? So 4.01 Strict or 1.1 would subset out all the controls that
put deprecated features into the mark-up, and directed the person to changing
the CSS instead? Personally I would like such an editor.

[snip]
WYSIWYG editors are here to stay, because they support the majority.


We haven't even seemed to agree what these mythical "wysiwyg editors"
are, for a start. On the basis of your recent postings, you seem to
believe that a WYSIWYG editor will be presenting a window showing the
structure of HTML markup, which the author will be adjusting to
reflect the logical structure of his content. And yet you claim to be
factoring-out HTML as a part of the equation, with authors knowing
nothing and caring nothing for the nitty detail of the HTML markup,
but caring only for the visual result as the arbiter of the design,
which indeed is what's normally meant by "WYSIWYG" in other fields.

So which is it to be? It surely can't be both at the same time.


You may interpret "WYSIWYG" that way, but I've been making it clear in this
thread that I am not talking about that mode. My very first post to this
thread said the following, which set the theme for everything I've said since:

<extract>
A question - why not a WYSIWYG tool as well? ....
The reason I ask is that I use Dreamweaver (4), which has a design-view
(WYSIWYG) mode, and code-view mode, and a split-screen mode. It can be very
useful to be able to type in the design-view section and see the code appear
as you type in the code-view section, and vice-versa.
</extract>

I'm not factoring out HTML as part of the equation. Quite the contrary - I've
talked about the productivity gains of being able to edit both views. I said
nothing about authors knowing nothing and caring nothing about the nitty
detail of the HTML mark-up. Quite the contrary, I've talked repeatedly about
the advantages of being able to see the HTML, and tweak it if desired. I was
deliberately responding the original poster's desire to learn the basics of
HTML when I responded in that very first post:

<extract.
But I can confidently say that
it is possible to learn a lot by watching what code a WYSIWYG editor produces.
And also useful to get a rapid feedback from the code you write.
</extract>

Right from the start I have been talking about the specific advantages of
having and using both views, including a split-screen presentation of both of
them together. I have tried ever since that post to keep coming back to this
effective & productive method of working. I have tried to avoid getting drawn
into discussion of mythical WYSIWYG editors put up as strawmen to be blown
down.

--
Barry Pearson
http://www.Barry.Pearson.name/photography/
http://www.BirdsAndAnimals.info/
http://www.ChildSupportAnalysis.co.uk/
Jul 20 '05 #30

P: n/a
Eric Jarvis wrote:
Barry Pearson wrote:
Brian wrote:
> Barry Pearson wrote:
>>
>> Although this is about editing HTML, it is about editing HTML in
>> the context of the CSS it refers to,
>
> Well, that's not what the op asked.


So what? It is the world that the OP lives in, whether or not the OP
happened to mention it! If you edit HTML, you do so in the context
of the CSS it is likely to be rendered in, and the UAs that are
likely to be doing the rendering. Or else you waste your time.


only if you are entirely obsessed with the visual presentation of the
document to the exclusion of everything else

[snip]

That is either a strawman or wrong. You can gain productivity and be more
effective without being entirely obsessed. Visual presentation is ONE of the
factors. Nothing I have said in this thread has even hinted at excluding
everything else, or even anything else!

Right from my first post in this thread, I have been explicitly talking about
the use of an editor with both an HTML-view mode and a rendered-view mode. I
assert that such an editor is better for many purposes than one with only the
HTML-view mode. After all, the latter has only a subset of the capability.

--
Barry Pearson
http://www.Barry.Pearson.name/photography/
http://www.BirdsAndAnimals.info/
http://www.ChildSupportAnalysis.co.uk/
Jul 20 '05 #31

P: n/a
On Sun, 26 Oct 2003, Barry Pearson wrote:
Indeed. It's about the structure, as well as about whatever is
rendered on your favourite graphical web browser.
Has anyone said otherwise?


I think so, yes. The benefits normally claimed for so-called WYSIWYG
editors is that authors can create web pages without any need to know
or understand HTML, CSS, or the bugs in browsers. They merely shove
their content around the page and (so it's claimed) the editor takes
care of the rest.

But as I was hinting in the last round, you now seem to have taken the
argument full-circle in which you describe the use of editing windows
in which the structure, the HTML markup, etc. can be manipulated and
the results observed in the previewer window.

So, you're taking a full-function web editor and presenting it as
"WYSIWYG". Strange terminology.
I made explicit reference to CSS for rendering purposes. That implies
separation of mark-up from presentation.
Not necessarily: the whole bag of stuff - HTML, CSS, javacrap, "filler
gifs" and suchlike ballast, can be (and in some authoring packages
_is_) handled behind the scenes. There's then no genuinely meaningful
separation of content from presentation: both are subsumed in the
package's aim to guarantee the visual results for the so-called
"target audience". Such software can have no idea whether that
enlarged text is meant to be a heading, or just a short paragraph of
enlarged text, unless the author tells it so, and then we leave the
realm of mere WYSIWYG - as that term is normally understood (but not,
it seems, by you).
Perhaps you assumed that I would select that text and set "font" in
the HTML - but why would I do that, when it is easier to set the
class, because the editor knows about the classes?
I didn't "assume" that you would do anything in particular. It's
about any meaning that there might be left in the term "WYSIWYG".
We haven't even seemed to agree what these mythical "wysiwyg editors"
are, for a start. On the basis of your recent postings, you seem to
believe that a WYSIWYG editor will be presenting a window showing the
structure of HTML markup, which the author will be adjusting to
reflect the logical structure of his content. And yet you claim to be
factoring-out HTML as a part of the equation, with authors knowing
nothing and caring nothing for the nitty detail of the HTML markup,
but caring only for the visual result as the arbiter of the design,
which indeed is what's normally meant by "WYSIWYG" in other fields.

So which is it to be? It surely can't be both at the same time.


You may interpret "WYSIWYG" that way,


Just so.
but I've been making it clear in this thread that I am not talking
about that mode.


OK. EOT.
Jul 20 '05 #32

P: n/a
Brian wrote:
Barry Pearson wrote:

[snip]
Who says they are abusing tables?


I did. If they are using tables for other than tabular data, they are
abusing tables. Just like it's abusing <blockquote> to produce an
indentation instead for extended quotations.
It is often a matter of opinion.


If I used a hammer to pound a screw in the wall, and a carpenter
happened by, (s)he'd likely tell me that I'm using the wrong tool for
the job. I could argue that it's a matter of opinion, of course. But
if you're building a house, you should believe the professional, not
me.


As I said, it is often a matter of opinion. I doubt if you could show that all
professional web authors believe that the way on-line news services use tables
is "abuse". (I suspect that, across the world, they employed many 1000s of
professional web developers for those services!) I discussed this further at:
http://www.barry.pearson.name/articles/table_pages.htm

But that is actually beside the point. My analysis is that there isn't an
ideal mark-up for the article pages of the on-line news services. They had a
design problem to solve, and they did so with a robust, widely supported,
method. It actually works!

They had a visual design in mind. (It would be a cop-out to say "they
shouldn't have had that visual design because it can't be supported properly".
It can be supported, and I think it is a reasonable design). They use variants
of a 5-box 3-column model as described in the article above. Typically, the
banner is a table (or 2). The 3 columns (or 2 or 4) are cells in one row of
another table. The footer at the bottom is another table (or table followed by
other text). What should they have done? In fact, there isn't a good
alternative that I know of, even now, let alone when they started to use it
years ago.

Typically, the banner & left-bar & footer are the same for all articles. So,
should that mark-up be in all articles? Ideally, no. In fact, if Frames had
been designed and supported properly, perhaps that would have been the way to
go. But there were and are problems with support & navigation & bookmarking,
etc. I believe they were right not to rely on Frames. (Did they ever try it?)

How big is that "same in all articles" mark-up? At the BBC site, the banner is
4KB, the left-bar is 5KB, and the footer is 6KB. That is just mark-up size,
not total content size. At The Times, the sizes are, banner 5KB, left-bar
23KB, 4th-bar 5KB, and footer 3KB. And those sizes are not simply because of
use of tables - the BBC left-bar doesn't use tables. Sometimes 1/3rd or 1/2 of
an article is repeated stuff.

So how would we do it nowadays? Would we simply turn those tables into
div-mark-up that can be positioned via CSSs? I hope not, even if all relevant
browsers supported this adequately. Changing tags while keeping vast amounts
of redundant stuff in the mark-up is hardly the next evolutionary step for
on-line news services! And hardly impressive design & authoring.

I wonder whether the next step, perhaps in a few years time when the browser
population of the world is more supportive, might be first to separate out the
repeated mark-up from the per-article mark-up. For example, using
<iframe></iframe> or <object></object> 3 times on the article page. Then the
articles would be cleaner, and the repeated stuff would get cached after the
first time. But - IE doesn't appear to support <object> with type = "html".
And I can't identify whether <iframe> is deprecated or not. In the W3C list of
4.01 tags, iFrame appears to be the only one with "L" for loose but not "D"
for deprecated. What does that mean? (Not deprecated but won't validate as
Strict? I need to do an experiment).
http://www.w3c.org/TR/REC-html40/index/elements.html

This would then mean that article-mark-up would include just 2-boxes 2-columns
instead of the 5, 3 at the moment. And that is an easier problem to solve. Or
they may do something else entirely, using methods I am not familiar with. But
I see no point in merely replacing those tables with an alternative. It isn't
broken - they don't need to fix it.

[snip]
So it will not be ruled out in the foreseaable future. And since it
appears to do no harm, why should it be?


Misusing tables creates a less flexible page. Just like misusing
headings for large bold font, or &nbsp; for margin, or blockquote for
indentation, or....
They are designing pages for the people in this world who matter.
They probably understand their target audience far more than most.


Yep. It *is* a "real world" argument.


And the real world is developing UAs that can handle this sort of use of
tables, sometimes in quite a flexible way. For example, try Opera 7.2 "small
screen" mode, and see how it manages to fluidly put those news service
articles onto a 240-pixel-wide screen. It isn't perfect, but I don't think
they actually spent a lot of effort implementing it. Much of it comes from a
special CSS that treats tables differently.

On-line news services across the world may be putting 100,000 table-oriented
pages per day onto the web. Users across the world want to see them. The
problem is now for UAs to match supply to demand. And as they do so, the
method used by the news services will appear less broken year by year. And for
many people, it doesn't appear to be broken now! And those UAs will remove
some objections to other uses of table-oriented pages too.

--
Barry Pearson
http://www.Barry.Pearson.name/photography/
http://www.BirdsAndAnimals.info/
http://www.ChildSupportAnalysis.co.uk/
Jul 20 '05 #33

P: n/a
Alan J. Flavell wrote:
On Sun, 26 Oct 2003, Barry Pearson wrote:
> Indeed. It's about the structure, as well as about whatever is
> rendered on your favourite graphical web browser.
Has anyone said otherwise?


I think so, yes. The benefits normally claimed for so-called WYSIWYG
editors is that authors can create web pages without any need to know
or understand HTML, CSS, or the bugs in browsers. They merely shove
their content around the page and (so it's claimed) the editor takes
care of the rest.


Fair comment - there appear to be different interpretations of the term. I am
suggesting the use of one type, you are criticising another. We may not
actually be disagreeing much?
But as I was hinting in the last round, you now seem to have taken the
argument full-circle in which you describe the use of editing windows
in which the structure, the HTML markup, etc. can be manipulated and
the results observed in the previewer window.
From my first post in this thread right up to now I have stayed with a
consistent model. Right from the start I talked about being able to edit in
both views.
So, you're taking a full-function web editor and presenting it as
"WYSIWYG". Strange terminology.

[snip]

No I'm not! I've never called the code-editing capability a WYSIWYG editor.
Note what I said in my first post:

tomy_baseo wrote: "... Can anyone recommend a good, basic HTML editor that's a
step beyond Notepad (not a WYSIWYG tool)."

Me: "A question - why not a WYSIWYG tool as well?"

I don't consider the total Dreamweaver editing capability to be WYSIWYG. I
consider it to be an HTML-editor & a WYSIWYG editor - "... as well". I also
said in this thread: "I can type into what looks on screen like a table cell,
and see the possible rendering change directly as I do so. (And I can
optionally also see the mark-up change). I can click on the style selection
panel, and see the colour of that cell change on the screen. (And also see
class="..." suddenly appear in the <td>)".

So I have been discussing the concept of applying classes in the WYSIWYG
editor, and seeing the package put the class attribute into the mark-up. In
fact, that is how I put nearly all my class="..." into the mark-up - while I
am in WYSIWYG editing mode. It really is powerful to (say) select something in
WYSIWYG mode, click on a class-name, and see the style changed in WYSIWYG mode
and also the mark-up being extended with the selector in that way.
(Unfortunately, I don't think D4 can do the same with id="...", so I have been
using classes where perhaps I should have been using ids. Not a felony, honest
guv!)

--
Barry Pearson
http://www.Barry.Pearson.name/photography/
http://www.BirdsAndAnimals.info/
http://www.ChildSupportAnalysis.co.uk/
Jul 20 '05 #34

P: n/a
Barry Pearson wrote:
Brian wrote:
Barry Pearson wrote:
If they are using tables for other than tabular data, they are
abusing tables.
It is often a matter of opinion.

Tables were created for tabular data. That is not a matter of
opinion. If you think it is ok to use them for layout, that is a
matter of opinion.
If I used a hammer to pound a screw in the wall, and a carpenter
happened by, (s)he'd likely tell me that I'm using the wrong tool for
the job. I could argue that it's a matter of opinion, of course. But
if you're building a house, you should believe the professional, not
me.


As I said, it is often a matter of opinion.


Sure. But the carpenter's opinion counts for more, since the
carpenter can build a house that has a chance of withstanding a
rainstorm. The weekend warrior is another matter.
I doubt if you could show that all
professional web authors believe that the way on-line news services use tables
is "abuse".
You ignore what others have already said. But then, you do that on a
regular basis. Since most documents on the web do not validate, do
not even include a dtd, it is not advisable to follow their lead.
Unless you're presenting a "get in the real world" philosophy.
My analysis is that there isn't an
ideal mark-up for the article pages of the on-line news services.
Perhaps your analysis is faulty. What's wrong with what they have?
<p> <ul> <ol> <dl> <blockquote> <abbr> <em> etc. HTML is not perfect,
but as a markup language, it provides quite a lot.

As a test, I searched Google for "news" and went to the first hit,
cnn.com, where I found the following markup:

• <a
href="/2003/WORLD/meast/10/25/sprj.irq.main/index.html">U.S.
helicopter down in Iraq</a><br>

• <a
href="/2003/US/10/25/sprj.irq.dc.protests.ap/index.html">Thousands
march against war</a><br>

On the second hit, the BBC, I found this:

<div class="sabull">
<a href="/2/hi/middle_east/3215137.stm" class="tsl">
Hotel attack divides Iraqis
</a>
</div> <div class="sabull">

On both pages, the markup was used to show bulleted list items. The
authors responsible for such nonsense get no sympathy from me about
HTML's poverty of semantic markup. Only someone actually using HTML
to its fullest can elicit any serious attention.
They had a
design problem to solve, and they did so with a robust, widely supported,
method. It actually works!
In a limited way, I suppose. Just like <blockquote> "works" if one
wants to indent text in graphical browsers. Here's how the BBC list
looks in Lynx:

Hotel attack divides Iraqis
Iraq curfew lifted for Ramadan
Crucifix (generic) Storm over Italy crucifix ruling

Is that third line ("Crucifix...") another list item? It could be.
Checking back in the graphical browser, we find that it is not a list
item. It is a headline, and is in a different column on the page.
How did it wind up beneath the list items in Lynx? A: Abuse of tables
for layout.
They had a visual design in mind.
Yes. And they designed as if the web were dtp, instead of what it
actually is. Tough crap for Lynx users who want to read the BBC web site.
(It would be a cop-out to say "they
shouldn't have had that visual design because it can't be supported properly".
It can be supported,
No, it cannot. Lynx does not render tables. And I doubt that the
results are what the author had in mind.
So how would we do it nowadays? Would we simply turn those tables into
div-mark-up that can be positioned via CSSs? I hope not, even if all relevant
browsers supported this adequately.
Table layouts work only in some browsers. Sensible markup -- p, div,
etc. -- works in all browsers. Even so, you don't think it's the way
to go.
Changing tags while keeping vast amounts
of redundant stuff in the mark-up is hardly the next evolutionary step for
on-line news services! And hardly impressive design & authoring.
I think you've shown that your ideal web is different from that of
others in ciwah. You see it as a visual, graphical medium. All
others are outside of what you called the "large population of
similarity".
I see no point in merely replacing those tables with an alternative. It isn't
broken - they don't need to fix it.
The table element is not broken. The BBC's table layout is broken for
some subset of their readers.
And those UAs will remove
some objections to other uses of table-oriented pages too.


Like ignoring them via Lynx, or turning them off, an option in Opera.
Then users are stuck with avoiding tables for layout, and missing
actual tabular data, or getting tabular data, and the broken layouts
that come with it. That's not the web I'd like to see.

--
Brian
follow the directions in my address to email me

Jul 20 '05 #35

P: n/a
Barry Pearson wrote:

I doubt if you could show that all professional web authors believe
that the way on-line news services use tables is "abuse". I
discussed this further at:
http://www.barry.pearson.name/articles/table_pages.htm


....where I read this:

<quote>
Mostly [table-oriented page formatting] actually does no harm. The
main case where problems arise is where the information is not being
rendered visually (for example, to a blind person). In that case, the
tool used by the blind person may have the wrong behaviour when
handling material without the semantics of tabular data. Another
potential problem is that the positioning of the information is
relatively inflexible.
</quote>

It's hard to know what I can possibly add. Tables for layout does no
harm to a web document, except that blind people cannot correctly read
it. Imagine this analogy: narrow doors do no harm, except that
wheelchair bound people cannot enter the building.

--
Brian
follow the directions in my address to email me

Jul 20 '05 #36

P: n/a
Brian wrote:
Barry Pearson wrote:
[snip] It's hard to know what I can possibly add. Tables for layout does no
harm to a web document, except that blind people cannot correctly read
it. Imagine this analogy: narrow doors do no harm, except that
wheelchair bound people cannot enter the building.


It doesn't stop them accessing the site. It just doesn't always behave in the
best way. Pop-ups can also cause problems, but has that stopped you using
them? (It has stopped me from using them). I wrote my views about table-layout
before I realised what Opera could do with tables on small screens.

Here is a test - have a look at the following in Opera 7.2 in "small screen"
mode, including the photographs:
http://www.julietremblay.com/
It can be made to work. It just needs a bit of extra work, for example
right-click > open to see the photographs. But if you check other posts, you
should find an article in which I pointed out problems accessing that site
with IBM's Home Page Reader, when it hit those pop-ups. I'm sure those
problems can be overcome too. Your web sites are very nice indeed - just not
perfect. (Sorry!)

This is typical of the web as we move from the large population of people
accessing it via screens at least 800 x 600, to the large set of minority
cases. It is though some people believe that if certain principles are
followed, all these minority cases will automatically be catered for. I don't
believe that. Neither do I accept that all those minority cases are in the
target audience. The harsh fact is, blind people have never been in the target
audience for my photographs. Neither have people with small screens, etc. I
have actually tried to provide aids for blind people, but I really wonder why
I am doing so. (Perhaps because it makes ME feel better, which is NOT a good
reason, indeed a bad one).

Tables can cause rendering problems in extreme cases. Who is to say whether
that is a problem with tables, or a problem with UAs? I have seen the view
that you can tell whether something should be a table by whether it can be
linearised. No - that is not part of the definition of tabular data. I believe
UA-developers will gradually overcome these problems, whether or not it is
"formally" their problem at all. Opera can turn tables into a more fluid
design. In time, other UAs will too.

I keep seeing casual statements about correct mark-up. "Use <p></p> if it is
paragraph text". Er ... what is the definition of paragraph text? Try
searching the web for an answer. (Please - I want a reliable answer). "Use
definition lists for question-answer pairs". You should be able to find
arguments about that on the web. (I did). And, here, "what is the definition
of tabular data?". In my article I actually argue that there is case for
saying that some uses of table-layout are tabular data. In which case, if UAs
don't behave right, they are at fault.

I see people criticise the use of tables for layout. I see W3C say it should
be replaced by use CSSs. I study all those tutorials about how to achieve
2-column and 3-column layouts: all you need is these non-validating browser
hacks! I'm trying to build a set of trial web pages that look similar (5-box
3-column) in typically browsers but use different methods - table-layout,
tableless, Frames, iFrames, objects, etc. And, guess what? The most reliable
method of all is turning out to be table-layout. Not only is it reliable, I
can make it validate even at XHTML 1.1. Since I know that table-layout can be
made more fluid via CSS etc, I seriously question views that table-layout is
bad. I suspect that it has contributed significantly to the popularity of the
web. And I think it will be around in a decade, aided by CSSs that will
transform it completely.

I see all of these as tools in the toolbox, or weapons in the armoury. I don't
put screws in with a hammer. But sometimes I have a problem that there doesn't
appear to be a proper tool for. So I use the best tool to hand. And if I use
the same tool that other people use to solve that problem, there is a chance
that we can eventually share a joint evolution.

--
Barry Pearson
http://www.Barry.Pearson.name/photography/
http://www.BirdsAndAnimals.info/
http://www.ChildSupportAnalysis.co.uk/
Jul 20 '05 #37

P: n/a
Barry Pearson wrote:
Brian wrote:
Imagine this analogy: narrow doors do no harm, except that
wheelchair bound people cannot enter the building.
Barry Pearson wrote:

It doesn't stop them accessing the site. It just doesn't always
behave in the best way.


Wheelchair bound people can still visit the shopping plaza. It just
doesn't behave in the best way.
Pop-ups can also cause problems, but has that stopped you using
them?
From creating new sites with them? Yes.
http://www.julietremblay.com/
That site doesn't use tables for layout. Why did you bring it up? To
sling mud? ('Brian uses popups, so his views on tables for layout are
tainted.')
I'm sure those problems can be overcome too. Your web sites are
very nice indeed - just not perfect. (Sorry!)
And you accuse others of resorting to strawman arguments. When did I
claim my sites were perfect?
This is typical of the web as we move from the large population of
people accessing it via screens at least 800 x 600, to the large
set of minority cases. It is though some people believe that if
certain principles are followed, all these minority cases will
automatically be catered for.
As we've pointed out, that's the strength of html: content independent
of the medium.
Tables can cause rendering problems in extreme cases.
Lynx is not an extreme case. It is a user-agent, still in
development, and useful for some people.
I have seen the view that you can tell whether something should be
a table by whether it can be linearised. No - that is not part of
the definition of tabular data.
I'd consult a dictionary for a definition of table.

"An orderly arrangement of data, esp. one in which the data are
arranged in columns and rows in an essentially rectangular form."
(American Heritage Dictionary)
I keep seeing casual statements about correct mark-up. "Use <p></p>
if it is paragraph text". Er ... what is the definition of
paragraph text? Try searching the web for an answer. (Please - I
want a reliable answer).
You don't have a dictionary?
I study all those tutorials about how to achieve 2-column and
3-column layouts: all you need is these non-validating browser
hacks!
Then you are reading the wrong sites. You do not need to create
invalid html markup to create a 3-column layout, or indeed any layout.
On the contrary, one should always start with valid (I mean that in
the technical, sgml sense of that word) markup.
I'm trying to build a set of trial web pages that look similar
(5-box 3-column) in typically browsers but use different methods -
table-layout, tableless, Frames, iFrames, objects, etc. And, guess
what? The most reliable method of all is turning out to be
table-layout. Not only is it reliable, I can make it validate even
at XHTML 1.1.
For the second time: You can use blockquote to create margins and make
it validate to xhtml 1.1. You can use &npsp; &npsp; &npsp; &npsp; for
a text indentation. You can use <br> <br> <br> to create a margin.
None of these are good practice in web authoring.
sometimes I have a problem that there doesn't appear to be a proper
tool for. So I use the best tool to hand.


Tables are not the best tool for layout. CSS is.

--
Brian
follow the directions in my address to email me

Jul 20 '05 #38

P: n/a
Barry Pearson wrote:
Brian wrote:
Barry Pearson wrote:
[snip]
It's hard to know what I can possibly add. Tables for layout does no
harm to a web document, except that blind people cannot correctly read
it. Imagine this analogy: narrow doors do no harm, except that
wheelchair bound people cannot enter the building.


It doesn't stop them accessing the site.


Its makes it difficult for people to access the document. That's why its
listed as a priority 2 problem. There are accessibility implications
whether you chose to recognise them or not.
I have seen
the view that you can tell whether something should be a table by whether
it can be linearised.
Unless you can produce proof that the person you are replying to
specificially states this, then this is just a plain old strawman argument.
No - that is not part of the definition of tabular data.
Tabular data is data with 2 dimensional relationships. Layout ain't one of
them.
I believe UA-developers will gradually overcome these problems,


That's naive. For UA's to be able to tell the difference between proper
tabular data and misuse of tables requires either the complet solving of AI
(I wouldn't hold a breath waiting for that), or someone to go through every
HTML page ever created, and will ever be created and hardcode into the
parsing routine whether the table referred to is misuse for layout or a
proper table.

<navel-gazing snipped>
--
Iso.
FAQs: http://html-faq.com http://alt-html.org http://allmyfaqs.com/
Recommended Hosting: http://www.affordablehost.com/
Web Design Tutorial: http://www.sitepoint.com/article/1010
Jul 20 '05 #39

P: n/a
On Sun, 26 Oct 2003, Barry Pearson wrote:

[...]
So I have been discussing the concept of applying classes in the WYSIWYG
editor,
WYSIWYG doesn't have "classes": what you see is what you get, that's
what the term promises.
and seeing the package put the class attribute into the mark-up.


Class attributes are more than "what you see" (= in the rendered
view). So "what you get" (in the underlying structure) is much _more_
than "what you see" (in the rendered view), and rightly so.

Which seems to make a mockery of the term WYSIWYG.

OK, can we at least agree that your "WYSIWYG" editor does the best job
when it's not being used as a "WYSIWYG" editor?

All I'm trying to say is that you seem to be *doing* the right thing,
but then representing it as being WYSIWYG, which makes no sense to me.
The only thing I don't comprehend is why your insistence on using the
term, when it's been stretched so far that any meaning it might have
had is clearly broken?

But now really EOT, as this isn't getting bread into the mouth of an
ageing sysadmin.
Jul 20 '05 #40

P: n/a
Alan J. Flavell wrote:
On Sun, 26 Oct 2003, Barry Pearson wrote:

[...]
So I have been discussing the concept of applying classes in the
WYSIWYG editor,


WYSIWYG doesn't have "classes": what you see is what you get, that's
what the term promises.

[snip]

A WYSIWYG editor can CERTAINLY allow classes to be applied!

Try one, and see! As I do, a lot. I apply classes to the mark-up using the
WYSIWYG editor. I really, really do! Sorry for your theories, but I do! Sorry.

--
Barry Pearson
http://www.Barry.Pearson.name/photography/
http://www.BirdsAndAnimals.info/
http://www.ChildSupportAnalysis.co.uk/
Jul 20 '05 #41

P: n/a
Brian wrote:
Barry Pearson wrote:
Brian wrote:
Barry Pearson wrote:
Brian wrote ...
If they are using tables for other than tabular data, they are
abusing tables.

It is often a matter of opinion.
Tables were created for tabular data. That is not a matter of
opinion. If you think it is ok to use them for layout, that is a
matter of opinion.


I defy you to supply a definition of "tabular data" that would achieve
consensus. The definition is, and will remain, a matter of opinion. Don't just
quote a dictionary. What does it actually mean? See my article at:
http://www.barry.pearson.name/articles/table_pages.htm

[snip] I doubt if you could show that all
professional web authors believe that the way on-line news services
use tables is "abuse".


You ignore what others have already said. But then, you do that on a
regular basis. Since most documents on the web do not validate, do
not even include a dtd, it is not advisable to follow their lead.
Unless you're presenting a "get in the real world" philosophy.


Perhaps I simply don't agree with what others have already said? Just because
lots of experts say something, it doesn't mean they are right, or that other
people have to fall in line. And I really do disagree with some of the things
that SOME experts say about these matters. I say "SOME" because I don't
believe there is a consensus, even though some people want to convince people
that there is.

You have an opinion on these matters. You are entitled to it. But don't
pretend that it is more than an opinion! I respect your views on a number of
things, but not all.
My analysis is that there isn't an
ideal mark-up for the article pages of the on-line news services.


Perhaps your analysis is faulty. What's wrong with what they have?
<p> <ul> <ol> <dl> <blockquote> <abbr> <em> etc. HTML is not perfect,
but as a markup language, it provides quite a lot.


Perhaps my analysis is faulty. Perhaps yours is. Perhaps W3C's is. These are
matters of opinion. You can't look down a microscope and see the answer
written in the fabric of the universe. It isn't science. I note that you
missed <table> out of the above list! I have seen various discussions about
whether or not X is suitable for a particular mark-up. Few of those
discussions get a clear resolution. They appear to end up as matters of
opinion.

Meanwhile, all those on-line news services are delivering high-quality
content. Using table-layout! And they will probably be delivering 100,000
pages per day for years. Perhaps their success trumps your unsubstantiated
theory?

Those sites are not broken. Yes, you can quibble about the details. Meanwhile,
they push valuable content onto the web that we can access without paying for
it. Gosh - without paying for it! This says more about the web than much of
the philosophy around. VAST number of people and organistions are pushing very
valuable material onto the web without charging for it. All you have to do is
stop quibbling about what they are doing, and revel in all that valuable, but
free, content. Adapt to it. Don't expect it to adapt to you unless you pay.

[snip of quibbles]
They had a
design problem to solve, and they did so with a robust, widely
supported, method. It actually works!


In a limited way, I suppose. Just like <blockquote> "works" if one
wants to indent text in graphical browsers. Here's how the BBC list
looks in Lynx:

Hotel attack divides Iraqis
Iraq curfew lifted for Ramadan
Crucifix (generic) Storm over Italy crucifix ruling


Hm! I won't use Lynx then! Thank you for turning me away from it. (I hope you
didn't pay a lot of money for it?)

If you object to the BBC site, I suggest you ask for your money back. How much
did you pay them? (I live in the UK. I actually know how much I paid them in
total! I have the receipt).
Is that third line ("Crucifix...") another list item? It could be.
Checking back in the graphical browser, we find that it is not a list
item. It is a headline, and is in a different column on the page.
How did it wind up beneath the list items in Lynx? A: Abuse of tables
for layout.
They had a visual design in mind.


Yes. And they designed as if the web were dtp, instead of what it
actually is. Tough crap for Lynx users who want to read the BBC web
site.


Yes. Tough. Perhaps they will evolve. Or perhaps Lynx will evolve. Just as we
hope that NN4.7 users will evolve. But if they don't evolve - it is their
problem. Minority UA users will never be able to dictate to the main content
suppliers. What should anyone believe that they can? "Hey BBC, I use Lynx and
your web site doesn't show up well". "P*ss off!". "OK, anything you say, BBC".
Over to you to think of a counter argument.

The web is like DTP to exactly the extent that Ventura Publisher is like DTP.
Marked-up content plus style sheets. Oh - I'm not sure that Publisher allowed
presentation in the mark-up to the extent that the web does. Does anyone here
know? It may be that some DTP has a clearer separation of mark-up and
presentation than the web does. Oh, well. The web is a little bit of theory,
and a lot of practice. It makes sense to examine the practice, because often
that points to the future.
(It would be a cop-out to say "they
shouldn't have had that visual design because it can't be supported
properly". It can be supported,


No, it cannot. Lynx does not render tables. And I doubt that the
results are what the author had in mind.


I'm sure there are lots of ways of rendering the material in ways that the
designers didn't have in mind. Do the designers care? If not - end of story.
It is valid for a supplier to say "take it or leave it". Perhaps if we did
this more often, people with dodgy UAs would upgrade sooner! Or UAs would
evolve faster.

I believe the people designing & developing the on-line news service sites
were very astute people. I believe they typically had a pretty good idea of
what the audience was like, and what they would see. (For example, the BBC has
a separate "low graphics" parallel site). That is why I am examining so many
of their sites - to see what lessons they have for the rest of us.
So how would we do it nowadays? Would we simply turn those tables
into div-mark-up that can be positioned via CSSs? I hope not, even
if all relevant browsers supported this adequately.


Table layouts work only in some browsers. Sensible markup -- p, div,
etc. -- works in all browsers. Even so, you don't think it's the way
to go.


I have been having trouble with <p> default top & bottom margins in Gekko
browsers. I can't solve all the problems without CSS3. I believe they handle
tables better than <p>. So we will have to differ on that.
Changing tags while keeping vast amounts
of redundant stuff in the mark-up is hardly the next evolutionary
step for on-line news services! And hardly impressive design &
authoring.


I think you've shown that your ideal web is different from that of
others in ciwah. You see it as a visual, graphical medium. All
others are outside of what you called the "large population of
similarity".


Does everyone in ciwah agree with that statement? Are there really none here
who think that perhaps table-layout has some merits in some cases? I would
like to know.
I see no point in merely replacing those tables with an alternative.
It isn't broken - they don't need to fix it.


The table element is not broken. The BBC's table layout is broken for
some subset of their readers.


So are your sites, as I have pointed out. So what? Did those readers have a
contract that gave them a right to view the BBC site? Have they a legal or
commercial right to view it? What law said that people had the right to access
web sites without paying for them, in taxes or by some other means?

I'll spell it out for you - there isn't a law on this planet that requires me
to even to publish to the web. So there cannot be a claim that I should
publish for subset audiences. That is merely wishful thinking. I am in
control. But feedback suggests that some people actually want to see what I
publish. So I talk to those people. I cooperate, but I cannot be dictated to.
And that applies to lots of suppliers.

I don't believe the BBC's site is broken for a subset. I believe possibly a
subset have unreasonable expectations for what they can get from a free site.
I believe those people could adapt if they chose to, or if they were helped.
But I also suspect that much of the criticisms of table-layout sites isn't
coming from the viewers, who are typically happy. It is coming from other
people who have different motives for objecting. Are there any user surveys
about this?
And those UAs will remove
some objections to other uses of table-oriented pages too.


Like ignoring them via Lynx, or turning them off, an option in Opera.
Then users are stuck with avoiding tables for layout, and missing
actual tabular data, or getting tabular data, and the broken layouts
that come with it. That's not the web I'd like to see.


Then pay more money to achieve the web you would like to see! (It will
probably cost you a lot). There are laws of supply and demand. These have not
been rescinded by the web.

If you want news, either accept what the news services give you for nothing,
or pay for a different service. I'm sure they have plenty of happy-enough
customers. And I'm sure they will happily accept lots of money from you to do
extra things.

If you offer material that is in demand, you can dictate the terms. You can
say "use this browser, use this size screen", etc. But if you are in need of
customers that won't accept that, you are the one with the problem. You may
need to change to suit them.

There is no rule that you have to cater for non-paying people. And there is no
rule that all those information suppliers need to cater for non-paying people.
(Unless there are legal constraints).

--
Barry Pearson
http://www.Barry.Pearson.name/photography/
http://www.BirdsAndAnimals.info/
http://www.ChildSupportAnalysis.co.uk/
Jul 20 '05 #42

P: n/a
Barry Pearson wrote:

I defy you to supply a definition of "tabular data" that would
achieve consensus. The definition is, and will remain, a matter of
opinion.
I see. When confronted with arguments against your position, you just
retreat to, "it's all a matter of opinion." How clever.
Don't just quote a dictionary. What does it actually mean?
?? It means what it says in the dictionary. Or, if you feel the
dictionary definition is wanting, give us a better definition.
See my article at:
http://www.barry.pearson.name/articles/table_pages.htm


Oh, I did. Your dismissal of blind people says it all.

--
Brian
follow the directions in my address to email me

Jul 20 '05 #43

P: n/a
Isofarro wrote:
Barry Pearson wrote:

[snip]
I believe UA-developers will gradually overcome these problems,


That's naive. For UA's to be able to tell the difference between
proper tabular data and misuse of tables requires either the complet
solving of AI (I wouldn't hold a breath waiting for that), or someone
to go through every HTML page ever created, and will ever be created
and hardcode into the parsing routine whether the table referred to
is misuse for layout or a proper table.


They don't need that. Remember there is a person involved, who can apply some
non-artificial intelligence. (I suspect that AI might also have trouble
navigating around a typical browser-rendering ON a screen, yet a combination
of a sighted person & UA manages!) I believe the combination of person & UA
will gradually improve. But let's not exaggerate the problems with
table-layout, or underestimate the problems with tableless layout. (Although
people do).

A reader such as IBM Home Page Reader can run in a mode where it "linearises"
the tables, row by row. If that happens to correspond to the desired reading
order, it works. Problems arise in such things as "Table Navigation reading
mode" (Alt + T). If the user (at least, a very inexperienced one like me)
tries to use one of the table modes to navigate around a layout table, then
the results may not make sense. Such a mode is best confined to those tables
that are what the user wants to handle as tabular data. In a 5-box 3-column
layout, the trick appears to be to skip over the first table or so - the
banner. Then navigate to the 2nd cell of the next table, the article column of
the 3 columns or so (perhaps using that table navigation mode!). Even a
sighted person has to spot that leap, and identify the article. I guess
someone using such a reader on a news article for the first time would either
suffer the tedium of listening through the stuff preceding the article, or
have to work out the navigation principles. Since I already know the typical
layout, I can't come to the problem fresh, so I don't know how easy or hard it
is to learn such tricks.

If some other mark-up is used, that hasn't solved the problem. There is still
a lot of mark-up, and it has to be navigated around. It is just as tedious if
the person listens through it all! What is the user most likely to want first?
How does the user then get to the rest later? I assume that the user will want
to start with the article. Perhaps that should always be first in the mark-up?
Or else there should be a navigation aid to get to it quickly? Then how does
the user get to the other stuff, eg. links to related material? In fact - how
does the user even know that those related links exist on that page? With
assistance from the reader, presumably. I think that users would need to learn
the principles of navigating through news articles in tableless layout, just
as they do with table-layout. One thing that helps if the user can rely on it
is the hierarchic-structure mark-up - eg. is there an <h1>? That is, of
course, an independent topic. You can have table-layout with headers, and
tableless without. The user has to discover whether they are there.

The following page is one of the very few tableless layouts I come across each
week. (And I see lots of pages in a week). I have trying to spot its methods.
Perhaps others here can help.
http://www.ukonline.gov.uk/

Looked at with styles, it is a relatively conventional pages. Disable styles,
and it becomes a serial, structured, traditional-looking page. And there is
material in the latter page that there isn't in the former. There appear to be
headings that don't appear in CSS-mode. Are they being hidden with styles?
Also, if you examine the CSSs (lots of them, and quite large in total), you
will spot various browser hacks. Both CSS & HTML validation fail. Producing a
page like that took a massive amount of skill, but I believe the problems I
have just mentioned reveal how immature the whole topic of tableless layout
is. It appears to require lots of knowledge, without adequate tools to
supplement this. Almost like machine-code or assembly-level programming before
we all grew up! The hacks suggest that the browsers in common use are not
really up to the task.

If the latter page didn't use all those special methods & hacks, and was
compared with the simplest table-layout page for the equivalent display, how
much difference would there be? What I notice is that much of the use of
tables on table-layout pages could easily be replaced by other mark-up,
leaving just tables for the gross-level positioning. Eg. some pages use tables
within the columns, some don't. Some use tables to layout elements of complex
graphics, some don't. Yet the problems caused by those inner fine-detail
tables get lumped in with the use of tables at the page-level.

A table-layout news article really has only the following gross-level tables -
a simple table for the banner, a simple one with 3 (say) columns for the
article and side-bars, and a simple one for the footer. I don't believe that
amount of use of tables is much of an issue for readers. A hybrid approach,
with tableless control within that simple gross-level table-layout, would
probably avoid the need for bleeding-edge knowledge and hacks.

--
Barry Pearson
http://www.Barry.Pearson.name/photography/
http://www.BirdsAndAnimals.info/
http://www.ChildSupportAnalysis.co.uk/
Jul 20 '05 #44

P: n/a
On Sun, 26 Oct 2003, Barry Pearson wrote:
WYSIWYG doesn't have "classes": what you see is what you get, that's
what the term promises.

[snip]

A WYSIWYG editor can CERTAINLY allow classes to be applied!


For a moment, I almost started to think you understood what I was
saying, but now I realise I was posting in a foreign language. Maybe
someone else will be able to express what I'm trying to convey to you.
Jul 20 '05 #45

P: n/a
Alan J. Flavell wrote:
On Sun, 26 Oct 2003, Barry Pearson wrote:
> WYSIWYG doesn't have "classes": what you see is what you get,
> that's what the term promises.

[snip]

A WYSIWYG editor can CERTAINLY allow classes to be applied!


For a moment, I almost started to think you understood what I was
saying, but now I realise I was posting in a foreign language. Maybe
someone else will be able to express what I'm trying to convey to you.


Is this some sort of word game? Are you are going to say "what you should have
said is "A WYSIWYG editor can have an accompanying list of the selector-values
from the stylesheet that can be used to directly manipulate what is seen in
the WYSIWYG window""? Did I use the words wrong? Do you have a
misunderstanding about the capabilities of WYSIWYG HTML editors?

There is no doubt whatsoever that the concept I expressed is correct, even if
I used the words wrong in some technical sense. The action of editing in
WYSIWYG mode can look virtually indistinguishable to the action of editing in
Word or PowerPoint, yet surely those count as WYSIWYG? The difference is, when
I select text in Word or Powerpoint, then use the mouse to modify the
appearance of the text on the screen, I don't know what actually happens to
the internal representation. I do know what happens in the Dreamweaver 4
WYSIWYG editing mode. It can put "class="..." attributes into the tags of the
HTML.

I just did the example below for real, and copied the HTML below from the
document I edited. Any Dreamweaver user can confirm this ability. I typed into
the WYSIWYG window. The text appeared in front of me in some appropriate
rendering, just as it does if I type into Word. If I look at the HTML, it
says:

<p>My dog has no nose ...</p>

If I select that text using the standard mouse drag technique, or any of the
traditional WYSIWYG editing techniques such as double-clicking, it look just
as it does if I selected that text in Word or PowerPoint. Then I can click on
the word "joke" in the CSS Styles panel available to me in the WYSIWYG window.
Lo and behold the text has turned green in the WYSIWYG display. The same green
that a preview in a browser with default settings would show it. Or that
someone in Japan browsing with default setting will see when I publish that
page. The WYSIWYG display looks very similar to what those browsers show.
Presumably Dreamweaver has the basics of a browser rendering machine in it,
including CSS support.

If I look at the HTML, it now says one of the following, depending on how much
I selected (the whole paragraph or just "dog"):

<p class="joke">My dog has no nose ...</p>

<p>My <span class="joke">dog</span> has no nose ...</p>

The CSS linked to by that HTML page happens to say:

..joke { color: #008800; }

And, I really do have such a style - that is a real example copied from the
CSS! In what way was my statement "A WYSIWYG editor can CERTAINLY allow
classes to be applied" wrong, given the above facts? (Should I have said
"allow class attributes to be inserted"? Sorry if that mislead you, but I did
make that clear in my earlier posts).

--
Barry Pearson
http://www.Barry.Pearson.name/photography/
http://www.BirdsAndAnimals.info/
http://www.ChildSupportAnalysis.co.uk/
Jul 20 '05 #46

P: n/a
Barry Pearson wrote:
Isofarro wrote:
Barry Pearson wrote: [snip]
I believe UA-developers will gradually overcome these problems,


That's naive. For UA's to be able to tell the difference between
proper tabular data and misuse of tables requires either the complet
solving of AI (I wouldn't hold a breath waiting for that), or someone
to go through every HTML page ever created, and will ever be created
and hardcode into the parsing routine whether the table referred to
is misuse for layout or a proper table.


They don't need that.


Why not? How else do you judge whether a table is correctly used or not. How
else do you judge the author's intent? Perhaps a mind reading device
instead? A browser that uses structure _needs_ to have a way of determining
whether an element is correctly used or not - otherwise tables misused are
an imposition to accessibility - contrary to your position.

Problems arise in such things as "Table
Navigation reading mode" (Alt + T). If the user (at least, a very
inexperienced one like me) tries to use one of the table modes to navigate
around a layout table, then the results may not make sense.


So now tables _are_ making it difficult to access the content properly. That
is an accessibility problem.
--
Iso.
FAQs: http://html-faq.com http://alt-html.org http://allmyfaqs.com/
Recommended Hosting: http://www.affordablehost.com/
Web Design Tutorial: http://www.sitepoint.com/article/1010
Jul 20 '05 #47

P: n/a
tomy_baseo wrote:
I'm new to HTML and want to learn the basics by learning to code by hand
(with the assistance of an HTML editor to eliminate repetitive tasks).
Can anyone recommend a good, basic HTML editor that's a step beyond
Notepad (not a WYSIWYG tool). Thanks.


Do you think that is still needed to learn HTML? I don't believe.
Aldo

--
`,,`,,`,,`, ,`,
http://www.HyperPublish.com Catalogs, CD and sites with 1 tool
http://www.EasyWebEditor.com Create a nice Web site with ease
http://www.1site.info A professional Website quickly
http://www.EBooksWriter.com Exploit the artist inside you!
http://www.PaperKiller.com Create manuals or HTMLHelp quickly
http://www.CdFrontEnd.com Create autorun CD visually

Visual Vision - http://visualvision.com http://visualvision.it
leader in hypertext authoring [ASP members, ESC members]
Jul 20 '05 #48

P: n/a
Brian wrote:
Barry Pearson wrote:

[snip]
I study all those tutorials about how to achieve 2-column and
3-column layouts: all you need is these non-validating browser
hacks!


Then you are reading the wrong sites. You do not need to create
invalid html markup to create a 3-column layout, or indeed any layout.
On the contrary, one should always start with valid (I mean that in
the technical, sgml sense of that word) markup.

[snip]

CSS hacks, not HTML hacks. The topic of tableless layout & CSS positioning is
rife with CSS browser hacks. Below are some examples.

What I find most worrying isn't actually the hacks. It is the attitude of
those concerned. They appear to be evangelists rather than engineers. We still
appear to be at the stage where people get their names known on the web by
being the ones to discover particular hacking techniques. We need methods that
validate (CSS & HTML) and don't have hacks. Until then, I'll assume that the
technology (and some of the evangelists) are immature, and we need a few more
years. Perhaps within a decade it will all be sorted out.

In the meantime, we can rely on basic table-layout methods. Perhaps 100,000
new such pages are published every day. It is a very successful paradigm that
has helped the web to be successful so far.

I'm going to have a trial of Dreamweaver MX 2004. It is supposed to be able to
convert from table-layout to tableless layout. I'll give it a go, because
2/3rds of my published pages are 4.01 Transitional table-layout pages. But I
seriously doubt whether it can overcome the need for hacks. (Indeed, I have
seen a statement that 3-column working really needs CSS3. I don't know why.
But that is many years from being commonly supported).

1. My own sites. I have 337 pages on the web that don't use table-layout and
that also validate as 4.01 Strict. It was a nightmare achieving that.

The simplest possible task, to centre a photograph on the display without
deprecated mark-up, apparently needed CSS that wasn't properly supported.
(This is what I was told). IE 6 didn't handle { margin-left/right: auto; }
properly. But it improperly allowed body { text-align: center; } to centre the
photograph, and other parts of the CSS overrode that. So a simple task needs
browser hacks that affected the rest of the CSS! This was actually not about
tableless layout. It was about CSS-positioning, which is different. I could
probably have used deprecated mark-up to align the <div>s, but that wasn't
what I was after. And that isn't the only CSS browser hack I have had to do. I
relied on veterans of hacking to tell me what to do.

2. "The holy grail". This is a 3-column layout that has been described as
"sweet CSS".
http://glish.com/css/7.asp
It needs IE 5 hacks - that is sad, not sweet! In fact it is worrying that
serious developers would call that "sweet"!
http://glish.com/css/hacks.asp
I have been unable to get the CSS or the mark-up to validate.

3. The UK government site that appeared to have the best achievement of
tableless layout is below. Validating the CSS and the HTML at W3C gives errors
for both.
http://www.ukonline.gov.uk/Home/Homepage/fs/en
One of the style sheets has the following name - guess why?
layout_06_fix_ie51mac.css
Other CSSs have IE (?) browser hacks in them. For example:
div.questionAnswerFix {
voice-family: "\"}\"";
voice-family:inherit;
margin-left: 21px; }
body>div.questionAnswerFix {
margin-left: 21px; }

4. I was told to examine the following web site, as a good example of what can
be done:
http://www.onetruefit.com/
One of its CSSs includes:
@import 'layout_home.css'; /* for everyone but mac ie */
@im\port "layout_home.css"; /* for mac ie5 but not mac ie4.5 */
It didn't validate, and in fact there is a page describing the hacks:
http://www.fivesevensix.com/studies/onetruefit/

--
Barry Pearson
http://www.Barry.Pearson.name/photography/
http://www.BirdsAndAnimals.info/
http://www.ChildSupportAnalysis.co.uk/
Jul 20 '05 #49

P: n/a
On Mon, 27 Oct 2003, VisualVision wrote:
Do you think that is still needed to learn HTML? I don't believe.
[create_a_catalog_i000063.gif]

[create_a_catalog_i00002e.gif]

[create_a_catalog_i00002f.gif]

No, you don't, do you?
leader in hypertext authoring


....and proponent of Sturgeon's Law, it seems.

Btw, it's not polite on usenet to use more than 4 lines of sig.

Since in your case it's clearly commercial advertising, I don't see
any reason to excuse over-stepping that mark. Anyone else?
Jul 20 '05 #50

71 Replies

This discussion thread is closed

Replies have been disabled for this discussion.