HTML Editor
tomy_baseo
(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.
Barry Pearson
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/
Vincent Gardet
PSPad is a very nice (and free) tool :
http://www.pspad.com/index_en.html
--
Vincent Gardet
Alan J. Flavell
> 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.
Peter Foti
news:Bz%lb.1075$wZ6...@newssvr23.news.prodigy.com...
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
Barry Pearson
> 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).
Eckhard Rotte
> 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.
Alan J. Flavell
> > 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
Pine.HPP.3.91c.96062...@hpplus06.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" ?
Peter Foti
news:pk3n2y54gsyo$.bkz39f02qryf.dlg@40tude.net...
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
Eckhard Rotte
> 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.
Stephen Poley
wrote:
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
Brian
> 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).
>
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
Eric Jarvis
> On Fri, 24 Oct 2003 01:50:25 GMT, tomy_baseo <tomy_...@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
Barry Pearson
> 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
> Pine.HPP.3.91c.96062...@hpplus06.cern.ch
> from June 1996.
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
> 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.
Alan J. Flavell
> 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.
Brian
> 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.
Barry Pearson
> 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.
Alan J. Flavell
> 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.
Barry Pearson
> On Sat, 25 Oct 2003, Barry Pearson wrote:
> 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.
> 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'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
> 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.
Brian
>
> 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.
Barry Pearson
> 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.
Alan J. Flavell
> 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.
Brian
> 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 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 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.
Eric Jarvis
> Barry Pearson wrote:
> >
> > 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 Jarvis
> 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 Jarvis
>
> 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
Jim Ley
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/
Barry Pearson
> 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
> 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
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.
Alan J. Flavell
> > 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.
Barry Pearson
> Barry Pearson wrote:
>> 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 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
> 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!)
Brian
> Brian wrote:
>
>>Barry Pearson wrote:
>
>>If they are using tables for other than tabular data, they are
>>abusing tables.
>>
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
>
> I doubt if you could show that all professional web authors believe
> 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.
Barry Pearson
> Barry Pearson wrote:
>>
[snip]
> 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.
Brian
> Brian wrote:
>
>> 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.
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.
Isofarro
> 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
Alan J. Flavell
[...]
> 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.
Barry Pearson
> 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.
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
> 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.
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).
Brian
>
> 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.
Barry Pearson
> Barry Pearson wrote:
[snip]
>
> 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.
Alan J. Flavell
> > 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.
Barry Pearson
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).
Isofarro
> 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.
VisualVision
> 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]
Barry Pearson
> Barry Pearson wrote:
[snip]
>> 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.
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/
Alan J. Flavell
> 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?
William Tasso
> On Mon, 27 Oct 2003, VisualVision wrote:
>
>> Do you think that is still needed to learn HTML
>
> Btw, it's not polite on usenet to use more than 4 lines of sig.
>
> Since in your case it's clearly commercial advertising,
or considering where the post was made, just common or garden trolling
perhaps.
> I don't see
> any reason to excuse over-stepping that mark. Anyone else?
heh - didn't see it. This poster was already on my skip list - no, I don't
use a kill-filter, just a randomly generated mental list based on recent
postings across many groups.
and yes - I agree 4 lines is the accepted max # of sig lines.
--
William Tasso - http://WilliamTasso.com
Brian
>
> Do you think that is still needed to learn HTML? I don't believe.
One line for the response, 9 for the sig. Not a good s/n ratio.
> 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]
Would you please (a) trim your signature, and (b) fix the sig
delimiter? It's two hypens and a space, "-- " and not "--" as you
have it. Thank you.
Brian
> Brian wrote:
>
>> Barry Pearson wrote:
>
>>> I study all those tutorials about how to achieve 2-column and
>>> 3-column layouts: all you need is these non-validating browser
>>> hacks!
>>
>> 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.
>
No css hack can make a valid html document become invalid. You do
grok "valid (in the technical, sgml sense of that word)," don't you?
> In the meantime, we can rely on basic table-layout methods.
As long as we use your browsers. But I don't always use your
browsers. Sometimes, I use Lynx. So I cannot rely on those methods.
Barry Pearson
> Barry Pearson wrote:
>> Brian wrote:
>>> Barry Pearson wrote:
>>
>>>> I study all those tutorials about how to achieve 2-column and
>>>> 3-column layouts: all you need is these non-validating browser
>>>> hacks!
>>>
>>> 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.
>>
>> CSS hacks, not HTML hacks.
>
> No css hack can make a valid html document become invalid. You do
> grok "valid (in the technical, sgml sense of that word)," don't you?
Whenever I say "valid" or "validate", I mean with reference to the relevant
standards. And my main test is to use the W3C on-line validation services for
CSS & HTML. My target is for all my CSS and all my HTML to validate at W3C
without warnings or errors. I also use various other on-line services, but W3C
represents the go/no-go decision. I validate other sites I am visiting using
those services, because if they don't validate, I could not copy their methods
without modification.
>> In the meantime, we can rely on basic table-layout methods.
>
> As long as we use your browsers. But I don't always use your
> browsers. Sometimes, I use Lynx. So I cannot rely on those methods.
That is not my problem. I am not the one pushing 100,000 high-information
table-layout pages onto the web each day.
Barry Pearson
> 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.
The objective of the user + UA isn't to "judge whether a table is correctly
used or not". That is a problem that doesn't need to be solved. It may even be
insoluble, even to sighted people. It is "opinion".
The objective is to access the content. The task of navigating to content is a
vastly different activity, and orders of magnitude simpler, than the task of
judging whether a table is correctly used or not. If every news article in the
world used <h1> as the heading for the article, the task for the user would be
simple. It isn't. That is a problem. A tableless layout that doesn't use <h1>
might also be a problem.
It is important to focus on what the users are trying to achieve.
Isofarro
> Isofarro wrote:
>> 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.
> [snip]
>
> The objective of the user + UA isn't to "judge whether a table is
> correctly used or not".
Then how are they supposed to read tabular information properly? Or are you
now forbidding it?
> The objective is to access the content. The task of navigating to content
> is a vastly different activity, and orders of magnitude simpler,
Rubbish. Access to content also includes that it is structured properly.
When last did you read and understand a thousand page novel where all the
words in the book were listed alphabetically instead of formed into proper
chapters, sentences and paragraphs? The structure of the content is part of
what makes it accessible.
> If every news
> article in the world used <h1> as the heading for the article, the task
> for the user would be simple. It isn't.
Yes it is. All top-level headers are then spoken in the same tone - easy to
distinguish that from a normal reading voice.
> It is important to focus on what the users are trying to achieve.
Understanding the content rather than receiving it in an unstrutured and
random way.
Isofarro
> CSS hacks, not HTML hacks. The topic of tableless layout & CSS positioning
> is rife with CSS browser hacks.
CSS hacks can be switched off without affecting the structure of the
content, so the accessibility of the content isn't sacrificed, only
improved. You cannot say the same about table-layout debauched websites.
Barry Pearson
> Barry Pearson wrote:
>
>> CSS hacks, not HTML hacks. The topic of tableless layout & CSS
>> positioning is rife with CSS browser hacks.
>
> CSS hacks can be switched off without affecting the structure of the
> content, so the accessibility of the content isn't sacrificed, only
> improved. You cannot say the same about table-layout debauched
> websites.
I believe most table-layout websites I see use sound engineering. They use
tried and tested methods. These work for a huge range of circumstances. They
don't take undue risks with browser-specific hacks or work-arounds. They may
be a bit boring, but they work.
I believe the onus is on tableless-layout advocates to demonstrate that they
can achieve the same penetration and business advantage. It isn't a matter of
evangelising. What matters is whether those people can succeed in practice in
a mass market. If they can, many people will follow. I will follow! So I am
trying to monitor whether or not they are succeeding.
I realise how important it is for those evangelists to talk up a story. But
that isn't enough. Lots of people throughout history have been able to talk up
a good story! Concorde had advocates who could talk up a good story, and for
many years was a brilliant airplane. And now look at what has happened. Is
tableless layout the next VHS or the next Betamax?
I'll watch with interest. And be ready to jump when the time is right.
Isofarro
> Isofarro wrote:
>> Barry Pearson wrote:
>>
>>> CSS hacks, not HTML hacks. The topic of tableless layout & CSS
>>> positioning is rife with CSS browser hacks.
>>
>> CSS hacks can be switched off without affecting the structure of the
>> content, so the accessibility of the content isn't sacrificed, only
>> improved. You cannot say the same about table-layout debauched
>> websites.
>
> I believe most table-layout websites I see use sound engineering.
Certainly doesn't look it. Do you have proof that these table-layout
websites have actually been through accessibility testing (a completed
checklist of something like WCAG would be sufficient).
Brian
>
>>> In the meantime, we can rely on basic table-layout methods.
>>
>> As long as we use your browsers. But I don't always use your
>> browsers. Sometimes, I use Lynx. So I cannot rely on those methods.
>
> That is not my problem. I am not the one pushing 100,000 high-information
> table-layout pages onto the web each day.
No. You're the one advocating using their authoring practices,
though. You're the one telling everying here that we can rely on
table-layout methods, when we cannot.
Brian
>
> I believe most table-layout websites I see use sound engineering.
> They use tried and tested methods. These work for a huge range of
> circumstances. They don't take undue risks with browser-specific
> hacks or work-arounds. They may be a bit boring, but they work.
But they don't. As I have *already* shown you. But of course, as is
so often the case, you choose to ignore that and go on blithely
asserting that "table-layout websites...work."
Barry Pearson
> Barry Pearson wrote:
>> Isofarro wrote:
>>> Barry Pearson wrote:
>>>
>>>> CSS hacks, not HTML hacks. The topic of tableless layout & CSS
>>>> positioning is rife with CSS browser hacks.
>>>
>>> CSS hacks can be switched off without affecting the structure of the
>>> content, so the accessibility of the content isn't sacrificed, only
>>> improved. You cannot say the same about table-layout debauched
>>> websites.
>>
>> I believe most table-layout websites I see use sound engineering.
>
> Certainly doesn't look it. Do you have proof that these table-layout
> websites have actually been through accessibility testing (a completed
> checklist of something like WCAG would be sufficient).
I drive a motor car that is soundly engineered by any plausible standard. It
is a 3-door coupe, needing a bit of agility to get in and out. It works well
for its target market/audience.
By all means try to persuade those news sites, etc, to include the users of
accessibility technology in their target audience, and test for them. I don't
know whether or not they had such users in the target audience. If they were,
I don't know to what extent they tested for them. Perhaps they did test, and
said "good enough". It isn't just the disabled who have problems with those
sites. People with narrow screens also see rather a lot of content that has to
be scrolled a lot. In that case, I doubt if users of those screens were in the
target audience. There is no rule that they had to be.
I believe the problem with news sites is not the use of tables. Even without
the tables, there is lots of stuff on a page that has to be navigated around.
Much, sometimes most, of what is on the page is not the reason for going to
that specific page. I believe the single thing that would help is if there was
a common way to get to the article text with one action. The simplest, and
perhaps most obvious way, would be if each article header was the <h1> element
on the page. Some news sites do exactly that. See example below (on a topic
relevant here). Most sites don't.
http://education.independent.co.uk/further/story.jsp?story=449223
I think predictable hierarchic structure is more important than the
table/tableless debate. I try to ensure that all my inner pages have their
unique content (rather than overheads & navigation) starting at <h1>. (There
are some known exceptions that will be fixed in future, and some pages are
continuations of large sections and so start <h2>). Even the photograph pages
have the photograph as the sole content of an <h1> element, in the expectation
that a blind person can get there immediately and hear the alt-text. (I
suspect that is probably a pointless gesture - I doubt if many blind people go
to my photograph pages).
When a page has unique content, administrative information, all the navigation
links, and the same-on-all-pages site material, rapid access to any one of
these needs some different from tableless layout. I've seen tableless layout
pages that use a list for the navigation links, turned into buttons using CSS.
But how do you get there? Do you put it before the unique content? After? Do
you have to learn this afresh for each new site visited?
Isofarro
> Isofarro wrote:
>> Barry Pearson wrote:
>>> Isofarro wrote:
>>>> Barry Pearson wrote:
>>>>
>>>>> CSS hacks, not HTML hacks. The topic of tableless layout & CSS
>>>>> positioning is rife with CSS browser hacks.
>>>>
>>>> CSS hacks can be switched off without affecting the structure of the
>>>> content, so the accessibility of the content isn't sacrificed, only
>>>> improved. You cannot say the same about table-layout debauched
>>>> websites.
>>>
>>> I believe most table-layout websites I see use sound engineering.
>>
>> Certainly doesn't look it. Do you have proof that these table-layout
>> websites have actually been through accessibility testing (a completed
>> checklist of something like WCAG would be sufficient).
>
> I drive a motor car that is soundly engineered by any plausible standard.
Which is documented through a Quality Assurance process before being
delivered to the public. (There will be a record at the plant where the car
was put together). Now can you _absolutely_ say the same about these
websites? I quite doubt it.
Barry Pearson
Isofarro wrote:
> Barry Pearson wrote:
[snip]
>> It is important to focus on what the users are trying to achieve.
>
> Understanding the content rather than receiving it in an unstrutured
> and random way.
See comments later about structure.
Brian wrote:
> Barry Pearson wrote:
>>>> In the meantime, we can rely on basic table-layout methods.
>>>
>>> As long as we use your browsers. But I don't always use your
>>> browsers. Sometimes, I use Lynx. So I cannot rely on those
>>> methods.
>>
>> That is not my problem. I am not the one pushing 100,000
>> high-information table-layout pages onto the web each day.
>
> No. You're the one advocating using their authoring practices,
> though. You're the one telling everying here that we can rely on
> table-layout methods, when we cannot.
See comments later about accessibility sites using table-layout.
Brian wrote:
> Barry Pearson wrote:
>> I believe most table-layout websites I see use sound engineering.
>> They use tried and tested methods. These work for a huge range of
>> circumstances. They don't take undue risks with browser-specific
>> hacks or work-arounds. They may be a bit boring, but they work.
>
> But they don't. As I have *already* shown you. But of course, as is
> so often the case, you choose to ignore that and go on blithely
> asserting that "table-layout websites...work."
Some sites concerned with accessibility use table-layout. Some sites concerned
with accessibility don't use proper structure. There appears to be an attitude
of "do as I say, not do as I do". I provide some examples below.
I am wondering whether the main obstacle to achieving accessibility on the web
is the "accessibility industry". The people and organisations who should be
providing guidance, but instead appear to be making it look as hard as
possible. Then perhaps the second obstacle to achieving accessibility on the
web are those who promote their own preferences under the heading of
"accessibility". For example, people who claim that a key to accessibility is
tableless layout, when proper examination shows that this still leaves major
issues unsolved.
I'll show examples of the obstacles that the accessibility industry erects,
then examples of how they don't always follow their own guidance.
Here is an incredibly simple page. The HTML is less than 2KB. The overall
page-layout is tableless. It starts with a <h1>. It validates at W3C as 4.01
Strict. Its CSS validates at W3C with no errors or warnings. It is just one
photograph and a few words!
http://www.barry.pearson.name/photography/pictures/birds/bl01_02_37_2.htm
I use the UseableNet extension to Dreamweaver 4 to check pages for
accessibility under the 508 rules. Here is what it says about that page. It is
an extract from the 5KB XML report.
- Non spacer IMG with equivalent ALT [Section 508 1194.22(a); WAI/WCAG 1.0
checkpoint 1.1] -- MANUAL --
- Non spacer IMG needs LONGDESC [Section 508 1194.22(a); WAI/WCAG 1.0
checkpoint 1.1] -- MANUAL -- Non spacer image may need a LONGDESC attribute.
- Color is not essential [Section 508 1194.22(c); WAI/WCAG 1.0 checkpoint
2.1] -- MANUAL --
- Colors are visible [Section 508 1194.22(c); WAI/WCAG 1.0 checkpoint
2] -- MANUAL --
- Style sheets should not be necessary [Section 508 1194.22(d); WAI/WCAG 1.0
checkpoint 6.1] -- MANUAL -- The page uses style sheets to present its
content. There might be browsers unable to understand style sheets or provided
style sheets may conflict with user-specified style information.
- Data table should have headers [Section 508 1194.22(g); WAI/WCAG 1.0
checkpoint 5.1] -- MANUAL -- The page contains a table that might be used to
present data. If this is the case, then the table has to have headers for rows
and columns (i.e. TH elements).
- Data table should have headers [Section 508 1194.22(g); WAI/WCAG 1.0
checkpoint 5.1] -- MANUAL -- The page contains a table that might be used to
present data. If this is the case, then the table has to have headers for rows
and columns (i.e. TH elements).
- Use clear language for site's content [WAI/WCAG 1.0 checkpoint 14.1] --
MANUAL --
- Clarify natural language usage [WAI/WCAG 1.0 checkpoint 4.1] -- MANUAL --
What the heck am I supposed to do with that? I have 337 tableless Strict pages
on the web. No one has paid me to do it. Does anyone believe for a second that
I will bother even to check what all that means? Or that anyone else in the
same situation will bother? Unless someone pays some serious money for me to
bother! That sort of thing simply generates contempt for the accessibility
industry. Not contempt for disabled people - they have my sympathy, especially
because they are being represented in that way! I won't copy here what "Bobby"
says about that page. It is along the same lines, and 6KB in size.
As I said, I use the UseableNet extension to Dreamweaver 4 to check pages for
accessibility under the 508 rules. Here is their home page:
http://www.usablenet.com/
Fascinating! Primarily table-layout with several <h1>s on the page. The <h1>s
appear to be headings for links, not for the main content of the page.
I've mentioned "Bobby". Primarily table-layout. Like a number of Bobby pages,
it has an <h1>. Which says "Bobby". It doesn't identify the unique content of
the page. That starts at <h2>.
http://bobby.watchfire.com/bobby/html/en/advanced.jsp
The Cynthia SaysT portal is a joint Education and Outreach project of
ICDRI..., The Internet Society Disability and Special Needs Chapter... and
HiSoftware...
http://www.contentquality.com/
It has a little but not much table-oriented layout (it is basically simple and
serial), but no <hn> that I have spotted.
The accessibility industry needs to gets its act together. Others need to stop
pursuing their own agendas under the heading of accessibility. Then perhaps we
can move constructively towards a genuinely more accessible web.
I believe that the single most important principle should be "use <h1> for the
start of the page's unique content". That is what I try to do. A nice, simple
rule, that might be cheap to apply across many sites. Even the accessibility
industry's sites could probably manage something so simple!
Barry Pearson
Isofarro wrote:
> Barry Pearson wrote:
[snip]
>> It is important to focus on what the users are trying to achieve.
>
> Understanding the content rather than receiving it in an unstrutured
> and random way.
See comments later about structure.
--
Isofarro
> Some sites concerned with accessibility use table-layout.
List a few table layout websites that meet or exceed Level AA compliance.
<navel-fluff snipped>
Jim Ley
<spam...@spamdetector.co.uk> wrote:
>Barry Pearson wrote:
>
>> Some sites concerned with accessibility use table-layout.
>
>List a few table layout websites that meet or exceed Level AA compliance.
http://web.archive.org/web/20020609044816/http://www.w3.org/
Jim.
--
comp.lang.javascript FAQ - http://jibbering.com/faq/
Brian
>
> Some sites concerned with accessibility use table-layout. Some
> sites concerned with accessibility don't use proper structure.
In both cases, those sites should make corrections.
> There appears to be an attitude of "do as I say, not do as I do".
> The accessibility industry needs to gets its act together. Others
> need to stop pursuing their own agendas under the heading of
> accessibility.
Are the people responsible for those badly coded accessibility sites
participating in this thread? Are they even participants in the ciwa*
groups? If not, then your points looks like a strawman argument from
someone quick to accuse others of using strawman tactics.
> I believe that the single most important principle should be "use
> <h1> for the start of the page's unique content".
Has anyone suggested that using h1 is a bad idea? Or is this
a(nother) strawman argument?
Isofarro
> On Thu, 30 Oct 2003 17:04:06 +0000, Isofarro
> <spam...@spamdetector.co.uk> wrote:
>
>>Barry Pearson wrote:
>>
>>> Some sites concerned with accessibility use table-layout.
>>
>>List a few table layout websites that meet or exceed Level AA compliance.
>
> http://web.archive.org/web/20020609044816/http://www.w3.org/
(I'm ignoring the dynamic main content bit, and focusing on the static /
template-based portions of the page).
Hmmm... It definitely fails checkpoint 3.2:
* validate to published formal grammars
* <http://www.w3.org/TR/WCAG10-TECHS/#tech-identify-grammar>
*
<http://validator.w3.org/check?uri=http%3A%2F%2Fweb.archive.org%2Fweb%2F20020609044816%2Fhttp%3A%2F%2Fwww.w3.org%2F>
because of an invalid attribute on the script element. If it were something
like an unescaped entity in the constantly updated part of the document -
its forgiveable. But not when its a static part of the page.
The more relevant checkpoint: I don't see how it passes checkpoint 3.3
* Use style sheets to control layout and presentation
* <http://www.w3.org/TR/WCAG10/#tech-style-sheets>
Yes, it looks to linearise decently, so checkpoint 5.3 is okay.
Couple of oopsies on the search form:
* Not clear the form is a search form until after the first radio button
* No explicit labels for form fields.
* It would make more sense putting the radio buttons after the text (IMO)
And one more poke at the javascript - the usage of <!-- -->on an
XHTML-Transitional page, should that not be <![CDATA[ ]]>?
Overall, it is a good attempt at an accessible layout - one of the better
ones I've seen. A few little things, but checkpoint 3.3 is, IMO, where it
does fail, because of a tabled-control layout instead of a stylesheet
controlled layout. Am I reading too much into 3.3?
Alan J. Flavell
> And one more poke at the javascript - the usage of <!-- -->on an
> XHTML-Transitional page, should that not be <![CDATA[ ]]>?
That whole area is a horrible mess, which is why the W3C
recommendation is not to attempt using inlined JS in XHTML. Sounds as
if they didn't follow their own good advice on that...
There's a truly heroic formula been posted in several variations, that
is supposed to be compatible with all of the applicable formal rules,
as well as being digestible by both HTML-ish client agents and by
XHTML-ish client agents; but even in its original SGML variant it was
disowned by its author[1], and the XML-ised version is, if anything,
worse.
See for example the thread which includes this posting from Mr.
alt.dev.null himself, message-id: vc9orfo...@corp.supernews.com
cheers
[1] Since he disowned it, may I say who he is? Well, it's in the
record somewhere, so I suppose I can say Arjun Ray.
Isofarro
> See for example the thread which includes this posting from Mr.
> alt.dev.null himself, message-id: vc9orfo...@corp.supernews.com
Ahh, thanks for that reference. I'm going to need it really soon. As part of
evangelising webstandards where I work, I've tried to push developers to
put their javascript in external files, but there are reasons not to do it.
I'll give the above a go - perhaps I get lucky and scare a few developers
into submission. (Well they are Java developers)
Alan J. Flavell
> Alan J. Flavell wrote:
>
> > See for example the thread which includes this posting from Mr.
> > alt.dev.null himself, message-id: vc9orfo...@corp.supernews.com
>
> Ahh, thanks for that reference.
Well, I see the thread got somewhat fragmented in Google. There's
further discussion in the thread which contains
vcivr9a...@corp.supernews.com , just in case you miss it.
I don't think we ever quite got a "right" answer, although some of
the ones we got were "good enough for government work" as our
transpondian friends put it.