HTML Editor

[Alan J. Flavell]

Re: HTML Editor

On Sat, 25 Oct 2003, Barry Pearson wrote:
[color=blue]
> 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?[/color]

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.
[color=blue]
> "WYSIWYG" always needs qualification. Perhaps the mistake is that IT
> literate people like myself sometimes forget to add the
> qualification.[/color]

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.
[color=blue]
> I believe there is a significant difference between "WYSIWYG editor" &
> "Graphical Preview editor"[/color]

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

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.

[Brian]

Re: HTML Editor

Barry Pearson wrote:[color=blue]
> Brian wrote:
>
> In a qualified specialist-jargon sense, it is reasonable to use the
> term WYSIWYG.[/color]

It is ludicrous to claim wysiwg in an html authoring environment,
especially in shop-talk. Professional web authors presumably know better.
[color=blue][color=green]
>> 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?[/color]
>
> 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.[/color]

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.
[color=blue]
> We mustn't get too focused on the exceptional cases.[/color]

What is exceptional about Lynx? I use it. Am I then exceptional?
[color=blue]
> 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; }.[/color]

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

[Barry Pearson]

Re: HTML Editor

Brian wrote:[color=blue]
> Barry Pearson wrote:[color=green]
>> Brian wrote:
>>
>> In a qualified specialist-jargon sense, it is reasonable to use the
>> term WYSIWYG.[/color]
>
> It is ludicrous to claim wysiwg in an html authoring environment,
> especially in shop-talk. Professional web authors presumably know
> better.[/color]

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

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.
[color=blue][color=green]
>> We mustn't get too focused on the exceptional cases.[/color]
>
> What is exceptional about Lynx? I use it. Am I then exceptional?[/color]

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".
[color=blue][color=green]
>> 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; }.[/color]
>
> 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.[/color]

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/

[Alan J. Flavell]

Re: HTML Editor

On Sat, 25 Oct 2003, Barry Pearson wrote:
[color=blue]
> Brian wrote:[/color]
[color=blue][color=green]
> > It is ludicrous to claim wysiwg in an html authoring environment,[/color][/color]
[...]
[color=blue]
> 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.[/color]

I recognise that a subset of web authors refuse to perceive the
illogicality of the term in relation to HTML. Now what?
[color=blue][color=green][color=darkred]
> >> We mustn't get too focused on the exceptional cases.[/color]
> >
> > What is exceptional about Lynx? I use it. Am I then exceptional?[/color]
>
> In the sense in which I was using the term - yes.[/color]

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.
[color=blue]
> You are not at that time part of what I was calling the "large
> population of similarity".[/color]

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

Hmmm, interesting.

[Barry Pearson]

Re: HTML Editor

Alan J. Flavell wrote:[color=blue]
> On Sat, 25 Oct 2003, Barry Pearson wrote:[/color]
[snip][color=blue]
> 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.[/color]
[snip][color=blue]
> 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.[/color]
[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 undifferentiate d 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/

[Barry Pearson]

Re: HTML Editor

Alan J. Flavell wrote:[color=blue]
> On Sat, 25 Oct 2003, Barry Pearson wrote:
>[color=green]
>> 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?[/color]
>
> 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.[/color]

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).
[color=blue][color=green]
>> "WYSIWYG" always needs qualification. Perhaps the mistake is that IT
>> literate people like myself sometimes forget to add the
>> qualification.[/color]
>
> 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.[/color]

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

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!
[color=blue][color=green]
>> I believe there is a significant difference between "WYSIWYG editor"
>> & "Graphical Preview editor"[/color]
>
> 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.[/color]

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

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 "plausibili ty 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/

[Brian]

Re: HTML Editor

Barry Pearson wrote:[color=blue]
>
> Although this is about editing HTML, it is about editing HTML in
> the context of the CSS it refers to,[/color]

Well, that's not what the op asked.
[color=blue]
> and the UAs that are likely to render it. So it is irrelevant what
> HTML itself is intended for.[/color]

Really?!
[color=blue]
> 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,[/color]

The distinction is lost on me.
[color=blue]
> it is to be combined with CSS and rendered accordingly (whether
> they know it or not).[/color]

But it may be rendered in a medium that they never imagined, whether
they know it or not.
[color=blue]
> Does anyone believe that their mark-up was actually created without
> reference to intended or envisaged presentation?[/color]

Of course it is meant for presentation. Just not for any one
particular presentation.
[color=blue]
> Why did they cluster that content together,[/color]

Because it should be presented together. Why else?
[color=blue]
> if not to present it within a single box?[/color]

i.e., a visual presentation. That's one of many possibilities.
[color=blue]
> Why did they add those extra <div>s, if not to provide the extra
> hooks to the control of the presentation, the CSS?[/color]

A good test is to turn off css and see if your document organization
can still be discerned.
[color=blue]
> (Have a look at the last few lines of HTML in the CSS Zen Garden).[/color]

Special case, where the purpose of the site is to demonstrate what css
can do. So the markup is a little over the top.
[color=blue]
> 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).[/color]

What evidence would you have anyone present, short of their own claims?
[color=blue]
> 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.[/color]

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

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.
[color=blue]
> WYSIWYG editors are here to stay, because they support the
> majority.[/color]

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.
[color=blue]
> How do we ensure that they also support minorities?[/color]
[color=blue]
> how do we believe WYSIWYG editors should be developed so that they
> achieve all our other aims? Clean, strict, mark-up?[/color]

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

[Barry Pearson]

Re: HTML Editor

Brian wrote:[color=blue]
> Barry Pearson wrote:[color=green]
>>
>> Although this is about editing HTML, it is about editing HTML in
>> the context of the CSS it refers to,[/color]
>
> Well, that's not what the op asked.[/color]

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][color=blue][color=green]
>> 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,[/color]
>
> The distinction is lost on me.[/color]

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

[snip][color=blue][color=green]
>> Does anyone believe that their mark-up was actually created without
>> reference to intended or envisaged presentation?[/color]
>
> Of course it is meant for presentation. Just not for any one
> particular presentation.[/color]

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".
[color=blue][color=green]
>> Why did they cluster that content together,[/color]
>
> Because it should be presented together. Why else?
>[color=green]
>> if not to present it within a single box?[/color]
>
> i.e., a visual presentation. That's one of many possibilities.[/color]

Not to them. It is exactly the ONE presentation they envisaged.
[color=blue][color=green]
>> Why did they add those extra <div>s, if not to provide the extra
>> hooks to the control of the presentation, the CSS?[/color]
>
> A good test is to turn off css and see if your document organization
> can still be discerned.[/color]

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][color=blue][color=green]
>> 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).[/color]
>
> What evidence would you have anyone present, short of their own
> claims?[/color]

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

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

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.
[color=blue][color=green]
>> WYSIWYG editors are here to stay, because they support the
>> majority.[/color]
>
> 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.[/color]

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 -
"declarativ e 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?
[color=blue][color=green]
>> How do we ensure that they also support minorities?[/color]
>[color=green]
>> how do we believe WYSIWYG editors should be developed so that they
>> achieve all our other aims? Clean, strict, mark-up?[/color]
>
> 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.[/color]

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/

[Alan J. Flavell]

Re: HTML Editor

On Sat, 25 Oct 2003, Barry Pearson wrote:
[color=blue]
> 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,[/color]

Indeed. It's about the structure, as well as about whatever is
rendered on your favourite graphical web browser.
[color=blue]
> and the UAs that are likely to render it. So it is
> irrelevant what HTML itself is intended for.[/color]

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

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...
[color=blue]
> Chuckle! Does anyone believe that their mark-up was actually created without
> reference to intended or envisaged presentation?[/color]

You appear to be refuting a claim that nobody has seriously presented.

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

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.
[color=blue]
> WYSIWYG editors are here to stay, because they support the majority.[/color]

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.

[Brian]

Re: HTML Editor

Barry Pearson wrote:[color=blue]
> Brian wrote:
>[color=green]
>> Barry Pearson wrote:[/color]
>
> So what? It is the world that the OP lives in, whether or not the
> OP happened to mention it![/color]

Is this one of those "if you don't do like I do, you're not in the
real world" arguments?
[color=blue]
> Or else you waste your time.[/color]

Looks that way.
[color=blue][color=green][color=darkred]
>>> whether they are developing for the web or users of the web,[/color]
>>
>> The distinction is lost on me.[/color]
>
> Gosh! The distinction between whether people are developing for the
> web or are users of the web is lost on you? Gosh, again![/color]

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.
[color=blue]
> Who says they are abusing tables?[/color]

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.
[color=blue]
> It is often a matter of opinion.[/color]

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.
[color=blue]
> (Otherwise it would be possible to "deprecate" it, which it isn't).[/color]

Of course not. Tables are for tabular data. If they were deprecated,
how would we mark up tabular data?
[color=blue]
> I know from personal experience that it is possible to have a
> table-oriented page that validates as XHTML 1.1.[/color]

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.
[color=blue]
> So it will not be ruled out in the foreseaable future. And since it
> appears to do no harm, why should it be?[/color]

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

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

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

[Eric Jarvis]

Re: HTML Editor

Brian wrote:[color=blue]
> Barry Pearson wrote:[color=green]
> >
> > how do we believe WYSIWYG editors should be developed so that they
> > achieve all our other aims? Clean, strict, mark-up?[/color]
>
> 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.
>[/color]

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...markin g 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...si nce all the conceptual work is done whilst
choosing the presentation

however that presupposes well structured html in the first place

--
eric

https://www.ericjarvis.co.uk

all these years I've waited for the revolution
and all we end up getting is spin

[Eric Jarvis]

Re: HTML Editor

Barry Pearson wrote:[color=blue]
> Brian wrote:[color=green]
> > Barry Pearson wrote:[color=darkred]
> >>
> >> Although this is about editing HTML, it is about editing HTML in
> >> the context of the CSS it refers to,[/color]
> >
> > Well, that's not what the op asked.[/color]
>
> 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.
>[/color]

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

https://www.ericjarvis.co.uk

all these years I've waited for the revolution
and all we end up getting is spin

[Eric Jarvis]

Re: HTML Editor

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

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...o ne 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

https://www.ericjarvis.co.uk

all these years I've waited for the revolution
and all we end up getting is spin

[Jim Ley]

Re: HTML Editor

On Sun, 26 Oct 2003 07:21:01 -0000, Eric Jarvis <web@ericjarvis .co.uk>
wrote:
[color=blue]
>Alan J. Flavell wrote:[color=green]
>> might be
>> indistinguishab le 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.[/color]
>
>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. ..[/color]

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.
[color=blue]
>one should be able to search for tables of data that contain
>the words "population " and "Morocco" and get population data about
>Morocco...[/color]

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.javas cript FAQ - http://jibbering.com/faq/

[Barry Pearson]

Re: HTML Editor

Alan J. Flavell wrote:[color=blue]
> On Sat, 25 Oct 2003, Barry Pearson wrote:
>[color=green]
>> 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,[/color]
>
> Indeed. It's about the structure, as well as about whatever is
> rendered on your favourite graphical web browser.[/color]

Has anyone said otherwise?

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

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][color=blue][color=green]
>> WYSIWYG editors are here to stay, because they support the majority.[/color]
>
> 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.[/color]

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/