Online documentation for Geko/Mozilla browsers???

I rely heavily on MSDN for documentation when it comes to
HTML/DHTML/JavaScript/CSS but as a result I often have problems getting my
stuff to work in Netscape/Mozilla/Firefox. I like the MSDN online
documentation
(http://msdn.microsoft.com/library/de...uthor/dhtml/re
ference/objects.asp) because it has complete lists of DHTML objects,
properties, methods, collections and event and for each element you can
easily view all the applicable attributes/propertes, behaviors, collections,
events, filters, methods, objects and styles. And it is a all very well
cross-referenced so for example if you are looking at an event you can see
all the elements that it applies to.

Is there any online equivalent for Mozilla/Geko based browsers?

I have explored the Gecko DOM reference at
http://www.mozilla.org/docs/dom/domref but frankly this sucks. I cannot find
a complete list of all HTML elements and all attributes/properties, methods,
events, styles etc. I'm thinking there has got to be some decent
documentation like that on MSDN out there., can anybody point me in the
right direction?

On Fri, 12 Nov 2004, Aidan wrote:
[color=blue]
> I rely heavily on MSDN for documentation when it comes to
> HTML/DHTML/JavaScript/CSS[/color]

That's a very clear statement of your problem, then! Don't you
believe that MSIE is capable of browsing properly-composed WWW pages?
If so, then you have plenty of company - but i'm not sure that I'd
want to join them.
[color=blue]
> (http://msdn.microsoft.com/library/de...uthor/dhtml/re
> ference/objects.asp) because it has complete lists of DHTML objects,[/color]

What are you trying to achieve?
[color=blue]
> cross-referenced so for example if you are looking at an event you
> can see all the elements that it applies to.[/color]

And it gives you how much advice on complying with portability
guidelines; WAI guidelines; what happens when MSIE users have read
MS's security advisories and disabled active content...?
[color=blue]
> Is there any online equivalent for Mozilla/Geko based browsers?[/color]

Why should there be? Mozilla is designed to browse properly-made WWW
pages.

What are you trying to achieve? Have you considered trying to
communicate with the WWW?

In comp.infosystems.www.authoring.html Aidan said:
[color=blue]
> I rely heavily on MSDN[/color]

your peepee will fall off

What is the accepted way to share a message across multiple newsgroups?
http://smjg.port5.com/faqs/usenet/xpost.html

--
the facts and opinions expressed by brucies
l i t t l e v o i c e s
are not necessarily the same as those held by brucie.

"Alan J. Flavell" <flavell@ph.gla.ac.uk> wrote in message
news:Pine.LNX.4.61.0411130034070.22282@ppepc56.ph. gla.ac.uk...
[color=blue]
> What are you trying to achieve?
>[/color]

Just the basics like to see what properties, events, styles, etc. are
applicable for a given tag?

"brucie" <shit@usenetshit.info> wrote in message
news:p46qhcqe2yi8.dlg@usenetshit.info...
[color=blue]
> What is the accepted way to share a message across multiple newsgroups?
> http://smjg.port5.com/faqs/usenet/xpost.html[/color]

brucie, you are a serious geek, I only posted seperately because my
newsgroup app. was having a problem. And don't even think about getting on
my case because I'm using Outlook Express:)

Aidan wrote:
[color=blue]
> "Alan J. Flavell" <flavell@ph.gla.ac.uk> wrote
>[color=green]
>> What are you trying to achieve?[/color]
>
> Just the basics like to see what properties, events, styles, etc.
> are applicable for a given tag?[/color]

http://www.w3schools.com/ ?

--
-bts
-This space intentionally left blank.

"Beauregard T. Shagnasty" <a.nony.mous@example.invalid> wrote in message
news:ICdld.2509$zk7.2124@twister.nyroc.rr.com...
[color=blue]
>
> http://www.w3schools.com/ ?
>[/color]

This actually looks promising, I'll have to try it out next week.
thanks,
Aidan

Aidan wrote:[color=blue]
> "brucie" <shit@usenetshit.info> wrote in message
> news:p46qhcqe2yi8.dlg@usenetshit.info...[color=green]
>>What is the accepted way to share a message across multiple newsgroups?
>>http://smjg.port5.com/faqs/usenet/xpost.html[/color]
>
> brucie, you are a serious geek, I only posted seperately because my
> newsgroup app. was having a problem.[/color]

Well, that's your problem. It's always best to follow the guidlines,
and not to whinge about it when someone informs you of them.
[color=blue]
> And don't even think about getting on my case because I'm using Outlook Express:)[/color]

That's your choice, no-one is going to get on your case for it. You
have a right to risk using whatever insecure and/or inferior software
you like.

--
Lachlan Hunt
http://lachy.id.au/
http://GetFirefox.com/ Rediscover the Web
http://SpreadFirefox.com/ Igniting the Web

Aidan wrote:[color=blue]
> I rely heavily on MSDN for documentation when it comes to
> HTML/DHTML/JavaScript/CSS[/color]

DHTML is a marketing term created by Microsoft to describe it's
non-standard, and inferior support and mixture of HTML, CSS and JavaScript.
[color=blue]
> but as a result I often have problems getting my
> stuff to work in Netscape/Mozilla/Firefox. I like the MSDN online
> documentation[/color]

That's most likely because you are using non-standard, proprietary MSIE
extensions that should never be used.
[color=blue]
> (http://msdn.microsoft.com/library/de...uthor/dhtml/re
> ference/objects.asp) because it has complete lists of DHTML objects,
> properties, methods, collections and event and for each element...[/color]

What you need is a quick reference to the standardised Document Object
Model. There is a good one available in the DevEdge sidebar [1], which
I rescued after devedge went down.
[color=blue]
> Is there any online equivalent for Mozilla/Geko based browsers?[/color]

Yes, they're called the standards.
[color=blue]
> I have explored the Gecko DOM reference at
> http://www.mozilla.org/docs/dom/domref but frankly this sucks.[/color]

The Gecko DOM reference includes a few extensions, but you should
generally stick to the standardised objects, methods and properties. I
agree it's not the best documentation, but can still be useful on the
odd occasion that it's needed.
[color=blue]
> I cannot find a complete list of all HTML elements[/color]

HTML 4.01 index of elements
http://www.w3.org/TR/html401/index/elements.html
[color=blue]
> and all attributes/properties,[/color]

HTML 4.01 index of attributes:
http://www.w3.org/TR/html401/index/attributes.html
[color=blue]
> methods, events,[/color]

The DOM
http://www.w3.org/DOM/
[color=blue]
> styles etc.[/color]

CSS1, CSS2, and CSS2.1
http://www.w3.org/TR/REC-CSS1
http://www.w3.org/TR/CSS2/
http://www.w3.org/TR/CSS21/

There are quick references for all those including HTML, DOM, CSS, and
more in the DevEdge sidebar [1].
[color=blue]
> I'm thinking there has got to be some decent documentation like that on MSDN out there.[/color]

Well, I wouldn't call MSDN descent, I've never had much luck deciphering
the good stuff from the bad. It's much better if you avoid MSDN all
together and just stick with the standards.

[1] http://lachy.id.au/blogs/log/2004/10/devedge-sidebar
--
Lachlan Hunt
http://lachy.id.au/
http://GetFirefox.com/ Rediscover the Web
http://SpreadFirefox.com/ Igniting the Web

"Alan J. Flavell" <flavell@ph.gla.ac.uk> wrote
[color=blue][color=green][color=darkred]
>>> What are you trying to achieve?[/color][/color][/color]

Aidan wrote:
[color=blue][color=green]
>> Just the basics like to see what properties, events, styles, etc.
>> are applicable for a given tag?[/color][/color]

"Beauregard T. Shagnasty" <a.nony.mous@example.invalid> posted:
[color=blue]
> http://www.w3schools.com/ ?[/color]

Considering that some of what they preach is seriously misleading, or just
plain wrong, I'd be advocating something else. (I'd only gone a little bit
into that site before discovering numerious serious flaws (the basics),
never mind going in depth into it.)

Such as actually reading the HTML specifications to work out what's
appropropriate with each HTML element, likewise for the CSS specifications
(both available from the W3C website at <http://www.w3.org/>). And a far
more accurate (than W3Schools) assistive sort of website, such as the the
WDG's one at <http://www.htmlhelp.com/>.

--
If you insist on e-mailing me, use the reply-to address (it's real but
temporary). But please reply to the group, like you're supposed to.

This message was sent without a virus, please delete some files yourself.

Tim <tim@mail.localhost.invalid> wrote in
news:1b1skrz0xainb.iyvkc03ggn2p.dlg@40tude.net:
[color=blue]
> "Beauregard T. Shagnasty" <a.nony.mous@example.invalid> posted:
>[color=green]
>> http://www.w3schools.com/ ?[/color]
>
> Considering that some of what they preach is seriously misleading, or
> just plain wrong, I'd be advocating something else. (I'd only gone a
> little bit into that site before discovering numerious serious flaws
> (the basics), never mind going in depth into it.)[/color]

The worst part is that people think it's the W3C's site.

Tim wrote:
[color=blue]
> "Beauregard T. Shagnasty" <a.nony.mous@example.invalid> posted:
>[color=green]
> > http://www.w3schools.com/ ?[/color]
>
> Considering that some of what they preach is seriously misleading, or just
> plain wrong, I'd be advocating something else.[/color]

From http://www.w3schools.com/html/html_intro.asp :

1. 'All Web pages contain instructions for display'.

2. 'The most common display instructions are called HTML
tags'.

3. 'HTML tags look like this This is a Paragraph'.

Those blunders are hardly compatible with their praiseworthy
if oddly expressed mission 'to develop ... online Web
tutorials based on W3C Web standards'. I daren't venture
any further.

HAGW!

--
Jock

On Sat, 13 Nov 2004 20:55:13 -0000, John Dunlop
<usenet+2004@john.dunlop.name> wrote:
[color=blue]
> From http://www.w3schools.com/html/html_intro.asp :
>
> 1. 'All Web pages contain instructions for display'.[/color]

Not inaccurate, just misleading. The elements do affect rendering - the
browser by default applies different presentations depending on the
markup. They do later explain that CSS what we should use to style the
display.
[color=blue]
> 2. 'The most common display instructions are called HTML
> tags'.[/color]

Well, they ARE tags. The "instructions" business is, again, misleading.
Yet this is the strongest candidate for an actual error from the 3 you
cited.
[color=blue]
> 3. 'HTML tags look like this This is a Paragraph'.[/color]

They indeed do look like that. What else would they look like?

I think what your real beef is - as is mine - is that they focus on the
tag but not on the element. Knowing what a tag is, that's important.
Knowing what an element is makes all that tag knowledge relevant.

Neal wrote:
[color=blue]
> On Sat, 13 Nov 2004 20:55:13 -0000, John Dunlop
> <usenet+2004@john.dunlop.name> wrote:
>[color=green]
> > From http://www.w3schools.com/html/html_intro.asp :
> >
> > 1. 'All Web pages contain instructions for display'.[/color]
>
> Not inaccurate, just misleading.[/color]

Their statement is incorrect, though I didn't say so in my
previous article; I called it a blunder. 'Instructions for
display' isn't equivalent to 'commands for display', but it
is likewise incorrect. Tags are not instructions*. If they
were, HTML would be a programming language.

(Rarely, pages might contain instructions in the form of
processing instructions; they are the exception, however,
not the rule.)
[color=blue]
> The elements do affect rendering - the browser by default applies
> different presentations depending on the markup.[/color]

OK.
[color=blue]
> They do later explain that CSS what we should use to style the
> display.[/color]

That's good to hear. I didn't read that far.
[color=blue][color=green]
> > 2. 'The most common display instructions are called HTML
> > tags'.[/color]
>
> Well, they ARE tags. The "instructions" business is, again, misleading.[/color]

That's putting it mildly. Tags are not instructions.
[color=blue]
> Yet this is the strongest candidate for an actual error from the 3 you
> cited.[/color]

It is erroneous to call tags what they are not.
[color=blue][color=green]
> > 3. 'HTML tags look like this This is a Paragraph'.[/color]
>
> They indeed do look like that. What else would they look like?[/color]

Sorry, my fault; the formatting I saw** was lost upon
quoting their blunder. The markup for this particular one
goes like:

<li>HTML tags look like this This is a
Paragraph.</li>

That's a fully-fledged element. To say 'HTML tags look like
this' and then give an element -- its start-tag, content,
and end-tag lumped together -- is terribly vague. How are
folk who are unfamiliar with MLs to discern which parts are
the tags when the concept of start-tags, content, and end-
tags hasn't yet been introduced?

If marked up sensibly, with CODE, this statement would
almost be passable, though far from ideal.
[color=blue]
> I think what your real beef is - as is mine - is that they focus on the
> tag but not on the element.[/color]

I had no relish for slogging my way through their tutorial,
so I didn't find out whether they focus on tags or elements.
[color=blue]
> Knowing what a tag is, that's important. Knowing what an element is
> makes all that tag knowledge relevant.[/color]

OK.

HAGW! Neal.

* http://groups.google.com/groups?th=ab17b0e6c25348f6

** Oh my, examples marked up with only B elements -- not
exemplary markup at all. There might be no discernable
difference between the example and the surrounding text,
since B elements need not be rendered as bold text style.

--
Jock

On Sat, 13 Nov 2004, John Dunlop wrote:
[color=blue]
> Tags are not instructions*.[/color]

Strongly agree
[color=blue]
> If they were, HTML would be a programming language.[/color]

Er, no, sorry. A "programming" language is something else.

It might be a page definition language. But without any kind of
iteration or conditional constructs - or something that's
Turing-equivalent to it - I couldn't accept it as "programming".
[color=blue][color=green]
> > The elements do affect rendering - the browser by default applies
> > different presentations depending on the markup.[/color]
>
> OK.[/color]

But only indirectly. Indexing robots can also be properly-behaved
HTML clients, but their "rendering" of the marked-up content is
fundamentally different from that kind of client which happens to be a
visual browser.

And there could be other kinds of client in-between (clients which
process the marked-up content in various ways, and present various
kinds of views of it).
[color=blue]
> <li>HTML tags look like this This is a
> Paragraph.</li>
>
> That's a fully-fledged element. To say 'HTML tags look like
> this' and then give an element -- its start-tag, content,
> and end-tag lumped together -- is terribly vague.[/color]

Agreed. It's also abuse of the markup, since there is a proper
structural element for marking-up markup, and most certainly isn't
it.

As indeed was shown later in your posting, sorry.

The trouble with that kind of over-simplified presentation is that
although it makes the topic seem easy by appealing to the beginner's
expectations, it also reinforces fundamental misunderstanding of the
intentions - misses the very *principle* which HTML was invented for
(viz. displaying the same content on a wide range of different display
situations), and teaches the beginner a lot of misleading crap which,
if they're in the least serious about the topic, they're going to have
to un-learn before long. I don't care for that kind of approach.

Real HTML isn't hard, except for those who are incapable of even a
modicum of abstract thought; anyone who isn't prepared to start in the
way that they ought to go on, would be better off not starting with it
at all.

On Sat, 13 Nov 2004 20:55:13 -0000, John Dunlop
<usenet+2004@john.dunlop.name> wrote:
[color=blue]
>Those blunders are hardly compatible with their praiseworthy
>if oddly expressed mission 'to develop ... online Web
>tutorials based on W3C Web standards'.[/color]

The XML lessons are just as bad. It's not a site I feel happy about
recommending.
--
Smert' spamionam

Alan J. Flavell wrote:
[color=blue]
> On Sat, 13 Nov 2004, John Dunlop wrote:[/color]
[color=blue][color=green]
> > If [tags were instructions], HTML would be a programming language.[/color]
>
> Er, no, sorry. A "programming" language is something else.[/color]

Thank you. I stand corrected. I'm not entirely sure why I
wrote that now.

HAGW!

--
Jock

On Sat, 13 Nov 2004 14:32:21 +1030, Tim <tim@mail.localhost.invalid>
wrote:
[...][color=blue]
>"Beauregard T. Shagnasty" <a.nony.mous@example.invalid> posted:[color=green]
>> http://www.w3schools.com/ ?[/color][/color]
[color=blue]
>Considering that some of what they preach is seriously misleading, or just
>plain wrong, I'd be advocating something else...[/color]

I recall that I tried to point out that fact several years ago when they
where "fresh on the web" but did not get much response for that.

It's good to see that some one else has found out the same (finally:-)

[...]
[color=blue]
>...a far more accurate (than W3Schools) assistive sort of website,
>such as the the WDG's one at <http://www.htmlhelp.com/>.[/color]

Yep; full agreement on that, but also don't forget about John Alsop and
his work at...

http://www.westciv.com/style_master/...als/index.html
http://www.westciv.com/style_master/.../css_tutorial/

....it plays in the same quality league as 'htmlhelp' as far as I my
judgment goes.

--
Rex

John Dunlop wrote:[color=blue]
> Neal wrote:[color=green][color=darkred]
>> > 1. 'All Web pages contain instructions for display'.[/color][/color][/color]

To be more specific: a UA sees a tag, which signals an element, which
switches the UA to use some default rendering. In a sense, "instructions
for display" makes sense as a description of what the tag is in the eyes
of the UA.

However, I'm in full agreement that this isn't the best way to word the
concept, as it's really confusing.

All the same, w3schools isn't all that bad, in the end. Yes, there are
errors. None of these errors are so critical that they result in the
student being hopelessly incapable of creating semantic HTML.
[color=blue]
> Tags are not instructions.[/color]

One could argue that the presence of a tag instructs the UA to use a
particular method to make the semantic role of the element clear to the
user. We don't know for certain what will happen, but in many cases we
know for certain that something will happen to make the semantics clear to
the user.

In this light, we can loosely say that tags are, in part, instructive to
the UA. While the cited statement leaves a lot to be desired, I don't
think it's patently wrong. Again, I writhe this off to poor wording, and
fact is no one is going to be limited in their ability to do basic HTML if
they are a little foggy here. Ideally, the student would have a better
description. Perhaps we should craft a tutorial of our own...
[color=blue]
> To say 'HTML tags look like
> this' and then give an element -- its start-tag, content,
> and end-tag lumped together -- is terribly vague. How are
> folk who are unfamiliar with MLs to discern which parts are
> the tags when the concept of start-tags, content, and end-
> tags hasn't yet been introduced?[/color]

I don't have the page up, but I'd assume they do mention that the tag
begins with < and ends with >, which would make this clear. It may be they
don't - my main complaint with w3schools is the tendency to be too concise
and not offer enough demonstration and illustration.

On Sun, 14 Nov 2004 01:53:34 -0500, Neal <neal413@yahoo.com> wrote:
[color=blue]
>John Dunlop wrote:[color=green]
>> Neal wrote:[color=darkred]
>>> > 1. 'All Web pages contain instructions for display'.[/color][/color]
>
>To be more specific: a UA sees a tag, which signals an element, which
>switches the UA to use some default rendering.[/color]

That is a false view.

According to the CSS1 spec, all user agents will have a default style
sheet, or at least behave as if they had one.

From the CSS1 spec...
"HTML authors need to write style sheets only if they want
to suggest a specific style for their documents. Each User
Agent (UA, often a "web browser" or "web client") will have
a default style sheet that presents documents in a reasonable
-- but arguably mundane -- manner. Appendix A contains a
sample style sheet to present HTML documents as suggested
in the HTML 2.0 specification [3]."

(has any one else noticed that they keep changing the words in that
document without telling us about it?)

Judging from that CSS1 statement it could be argued that every browser
ever produced from day one of the www has a default style sheet on
board.
[color=blue]
>In a sense, "instructions for display" makes sense as a description[/color]

No, it does not! Markup is NOT presentation. Please do not propagate
such false information...

http://www.css.nu/markup/markup-tagsoup.html

--
Rex

On Sun, 14 Nov 2004 00:39:42 +0000, "Alan J. Flavell"
<flavell@ph.gla.ac.uk> wrote:
[color=blue]
>It might be a page definition language. But without any kind of
>iteration or conditional constructs - or something that's
>Turing-equivalent to it - I couldn't accept it as "programming".[/color]

Why ever not ? Where's the definition of programming that says it
must have conditionals or iterations ?

Ever used any engineering CNC machines ? Plenty of "programming"
there, and very few conditionals.

--
Smert' spamionam

On Sun, 14 Nov 2004 13:09:31 +0100, Jan Roland Eriksson
<jrexon@newsguy.com> wrote:
[color=blue]
> No, it does not! Markup is NOT presentation. Please do not propagate
> such false information...[/color]

I feel as you haven't read what I wrote, and simply focused on a few
statements.

My point is exactly what you say above - markup does not indicate a
particular presentation.

For example:

"The presentation of phrase elements depends on the user agent. Generally,
visual user agents present EM text in italics and STRONG text in bold
font. Speech synthesizer user agents may change the synthesis parameters,
such as volume, pitch and rate accordingly."

The text above does not set a single presentation for em or strong.
However, if it's going to be clear to the user that a word is emphasized,
a UA must do *something* to render it. If the UA does nothing special in
the way of rendering em, then the element may as well have been ignored,
as the user will have no rendered means of knowing it is emphasized. (And
of course, other elements can be similarly described.)

It must be stressed, of course, that how a UA renders em is not known to
the author. We are applying the em element for the purpose of emphasizing
a word, not to force a particular rendering effect. Attempts to do that
are not only doomed to fail (because we have no way of knowing exactly
what rendering effect the UA will use), but are simply not the correct
approach to HTML, which is application of elements based on the semantics
of their content.

The above is really standard. I don't suspect anyone's going to argue it.

If I use em, I can (almost) guarantee the browser will use some special
rendering for it. I can say the same for h1, ol, etc. If it did not, the
UA would be incompletely rendering the content, as these elements,
semantically applied, are as important to comprehension of the content as
inflection and tone are to a listener.

Now, the sentence in question was "All Web pages contain instructions for
display" - which I suspect most here interpret as an erroneous directive
to use h1 for big bold text, em for italics, etc. And some probably see
"instruction" and think it's saying that tags are programming commands,
which of course they are not. Still, I read it a little differently. And a
warning - everything following is absolutely inconsequential to actual
authoring.

If the UA is going to render the semantic elements at all, and assuming
we're talking about a visual rendering, the elements will have some sort
of visual difference from surrounding content. (Again, what that
difference is, we as authors do not know.)

How does the browser know how to present this? It refers to its default
"stylesheet" which sets particular renderings for particular elements. So,
when the browser is going through my document, and it encounters an em
tag, which implies there is em element content about to begin, it must
refer to its list of styles, find what applies to em, and apply it to the
contents of the em element. It must do this when it encounters a tag.

I'm driving down the street, and I see a sign that says "Speed Limit
20MPH". That is an instruction - and to be a compliant driver, I must
reduce the speed of my vehicle. What speed I choose, that's up to me. But
it must be appropriate for the conditions, just as what rendering the UA
chooses must be appropriate for the element, the start of which was
signaled by the opening tag.

In the sense that a road sign is an instruction for me to change how my
vehicle is operating, a tag is also an instruction for the UA to be aware
there's an element imminent, and to apply whatever rendering it is set up
to apply.

I am not implying that the sentence cited is a good one for a beginner.
And I am in no way supporting anything but semantic usage of HTML. But
seen in the way I described, the statement that the tag is an instruction
for guiding page rendering, while awkward and controversial, is not
categorically wrong.

As authors, we can bet that the UA will, sure as a sunrise, render things
differently if we use an em tag in our document. We just don't have any
clue *what* the UA will do, so that knowledge is useless. So the statement
is now not only somewhat accurate and awkward, but totally unimportant to
the author!

"Andy Dingley" <dingbat@codesmiths.com> wrote in message
news:imtep05acem0k82mjka7n5rmtpngtr4qvg@4ax.com...[color=blue]
> On Sun, 14 Nov 2004 00:39:42 +0000, "Alan J. Flavell"
> <flavell@ph.gla.ac.uk> wrote:
>[color=green]
>>It might be a page definition language. But without any kind of
>>iteration or conditional constructs - or something that's
>>Turing-equivalent to it - I couldn't accept it as "programming".[/color]
>
> Why ever not ? Where's the definition of programming that says it
> must have conditionals or iterations ?
>
> Ever used any engineering CNC machines ? Plenty of "programming"
> there, and very few conditionals.[/color]

Yeah, ladder diagrams: been there, done that. But the SGML-focused people
somehow can't get it through their heads that programming is much broader
than might be implied by the features of popular procedural and
object-oriented languages.

Neal <neal413@yahoo.com> wrote:
[color=blue]
> The text above does not set a single presentation for em or strong.
> However, if it's going to be clear to the user that a word is
> emphasized, a UA must do *something* to render it.[/color]

You have chosen a particular case, the em and strong elements, for which
the good old HTML 2.0 specification _required_ that they be rendered
differently from normal text and from each other. Note that there is no
such requirement in later HTML specifications.

For headings, for example, there never was any requirement that they be
rendered any differently from normal text. If you ask me, that was a
mistake, but maybe the requirement was regarded as self-evident.

For many other elements, there is no reason why they _should_ necessarily
affect rendering the least.
[color=blue]
> Now, the sentence in question was "All Web pages contain instructions
> for display"[/color]

Which is incorrect, even under a liberal interpretation. Even if we
assume that elements should be rendered "differently", it's not a matter
of instructions.
[color=blue]
> I am not implying that the sentence cited is a good one for a
> beginner.[/color]

For a beginner, it is completely and categorically wrong. For someone who
already knows HTML, it is either wrong or useless.
[color=blue]
> As authors, we can bet that the UA will, sure as a sunrise, render
> things differently if we use an em tag in our document.[/color]

No we can't. The version of Lynx I'm using shows em elements in normal
text. Some speaking browsers I've used speak em elements in normal style,
or so slightly different from normal style that I cannot hear a
difference. (A blind person once told me that in his opinion, any
emphasis inside text is just disturbing, especially when the speach rate
is high. I guess one reason is that the kind of emphasis that a
synthesizer could generate from marked-up emphasis is rather unnatural as
compared with the flow of normal human speech.)

--
Yucca, http://www.cs.tut.fi/~jkorpela/
Pages about Web authoring: http://www.cs.tut.fi/~jkorpela/www.html

On Sun, 14 Nov 2004 11:26:26 -0500, "C A Upsdell"
<cupsdell0311XXX@-@-@XXXrogers.com> wrote:
[color=blue][color=green]
>> Ever used any engineering CNC machines ? Plenty of "programming"
>> there, and very few conditionals.[/color]
>
>Yeah, ladder diagrams: been there, done that.[/color]

I wasn't thinking of ladder logic and PLCs, as that certainly has
conditionals. Being a declarative language, iteration isn't a common
part of ladder logic, although enumeration may be (on some platforms).

I was thinking more of CNC machining centres, right back to the
punched tape era (which is still ongoing).

--
Smert' spamionam

"Andy Dingley" <dingbat@codesmiths.com> wrote in message
news:089fp0pvchcievsuo5uo6pjp66sp3tr81n@4ax.com...[color=blue]
> On Sun, 14 Nov 2004 11:26:26 -0500, "C A Upsdell"
> <cupsdell0311XXX@-@-@XXXrogers.com> wrote:
>[color=green][color=darkred]
>>> Ever used any engineering CNC machines ? Plenty of "programming"
>>> there, and very few conditionals.[/color]
>>
>>Yeah, ladder diagrams: been there, done that.[/color]
>
> I wasn't thinking of ladder logic and PLCs, as that certainly has
> conditionals. Being a declarative language, iteration isn't a common
> part of ladder logic, although enumeration may be (on some platforms).[/color]

But the 'conditionals' in ladder diagrams don't resemble conditional logic
as seen in conventional programming languages: they are more like events
triggering state changes in a state machine. At least that's the way it was
when I used low-end Siemens PLCs a long time back.

On Sun, 14 Nov 2004 13:58:58 -0500, "C A Upsdell"
<cupsdell0311XXX@-@-@XXXrogers.com> wrote:
[color=blue]
>But the 'conditionals' in ladder diagrams don't resemble conditional logic
>as seen in conventional programming languages:[/color]

No, because it's not a conventional programming language. It's an
asynchronous declarative language and these are themselves obscure.
Within that constraint, there's nothing particularly odd about their
conditional behaviour.

As they clearly do have some conditional behaviour, they mean that
ladder-logic can't be a useful counter-example for a statement "All
programming languages have conditional statements"

Are HPGL or Gerber-<whatever> programming languages ?

--
Smert' spamionam

On Sun, 14 Nov 2004 11:21:52 -0500, Neal <neal413@yahoo.com> wrote:
[color=blue]
>I feel as you haven't read what I wrote, and simply focused on a few
>statements.[/color]

Welcome to Usenet, historical successor to the Platonic Symposium

"Andy Dingley" <dingbat@codesmiths.com> wrote in message
news:bpsfp0lsn5vi1e545d9qm13ucupelb2h8d@4ax.com...[color=blue]
> On Sun, 14 Nov 2004 13:58:58 -0500, "C A Upsdell"
> <cupsdell0311XXX@-@-@XXXrogers.com> wrote:
>[color=green]
>>But the 'conditionals' in ladder diagrams don't resemble conditional logic
>>as seen in conventional programming languages:[/color]
>
> No, because it's not a conventional programming language. It's an
> asynchronous declarative language and these are themselves obscure.
> Within that constraint, there's nothing particularly odd about their
> conditional behaviour.
>
> As they clearly do have some conditional behaviour, they mean that
> ladder-logic can't be a useful counter-example for a statement "All
> programming languages have conditional statements"[/color]

And ladder diagrams have statements? When I used it, it was entirely
graphic.

"John Dunlop" <usenet+2004@john.dunlop.name> wrote in
comp.infosystems.www.authoring.html:[color=blue]
>From http://www.w3schools.com/html/html_intro.asp :
>
>1. 'All Web pages contain instructions for display'.[/color]

Well, what's wrong with that? Web pages do contain markup that gives
instructions for display. Sure, we might phrase it more precisely,
but what exactly is the harm with the phrasing as given?
[color=blue]
>2. 'The most common display instructions are called HTML
> tags'.[/color]

Again, what's wrong with that? Sure, we can quibble about "most
common", and "usual" or similar would have been a better choice.
Still, if someone relies on the above, what wrong actions will he be
led to take?
[color=blue]
>3. 'HTML tags look like this This is a Paragraph'.[/color]

And are you telling us that this is NOT an example of HTML tags?
[color=blue]
>Those blunders are hardly compatible with their praiseworthy
>if oddly expressed mission 'to develop ... online Web
>tutorials based on W3C Web standards'. I daren't venture
>any further.[/color]

Maybe I'm slow today, but your first two examples seem at worst to
contain venial sins, and your third example looks just fine to me.

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

"Aidan" <aidan.nospam.curran@agile.com> wrote in
comp.infosystems.www.authoring.html:[color=blue]
>brucie, you are a serious geek, I only posted seperately because my
>newsgroup app. was having a problem.[/color]

Then fix it. Don't inconvenience thousands of people because your
software is misconfigured.

And when you're called on it, as Brucie quite properly did, don't
post a non-apology that says, in essence, that you feel justified in
your actions because you can't be bothered to fix your software.

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

From http://www.w3schools.com/html/html_intro.asp :[color=blue][color=green]
>> 1. 'All Web pages contain instructions for display'.[/color][/color]

Stan Brown <the_stan_brown@fastmail.fm> wrote:[color=blue]
> Well, what's wrong with that? Web pages do contain markup that gives
> instructions for display. Sure, we might phrase it more precisely,
> but what exactly is the harm with the phrasing as given?[/color]

It's the difference between nouns and verbs.

HTML doesn't tell the browser to do anything. There are no verbs. There are
no instructions.

HTML tells the browser (or other user agent) what things are. It contains
nouns (and adjectives). It's data. It's markup.

Beginners are better off if they learn basic concepts correctly, so that
they don't need to unlearn them later.
--
Darin McGrew, mcgrew@stanfordalumni.org, http://www.rahul.net/mcgrew/
Web Design Group, darin@htmlhelp.com, http://www.HTMLHelp.com/

"It said 'Insert disk #3', but only two will fit..."

"Darin McGrew" <mcgrew@stanfordalumni.org> wrote in message
news:cnb3jl$fuf$1@blue.rahul.net...[color=blue]
> From http://www.w3schools.com/html/html_intro.asp :[color=green][color=darkred]
>>> 1. 'All Web pages contain instructions for display'.[/color][/color]
>
> Stan Brown <the_stan_brown@fastmail.fm> wrote:[color=green]
>> Well, what's wrong with that? Web pages do contain markup that gives
>> instructions for display. Sure, we might phrase it more precisely,
>> but what exactly is the harm with the phrasing as given?[/color]
>
> It's the difference between nouns and verbs.
>
> HTML doesn't tell the browser to do anything. There are no verbs. There
> are
> no instructions.
>
> HTML tells the browser (or other user agent) what things are. It contains
> nouns (and adjectives). It's data. It's markup.[/color]

I do not think that it is unreasonable to view tags as verbs. For example,
 could be interpreted as 'render-content-as-paragraph'.

As for arguing that mark-up is data: one could also reasonably say that
(for example) the source code for a perl script is data for a perl compiler,
or that written words are data for the human brain. Whether we see a tag as
an instruction, or as a datum, or (for example) as a trigger for a state
machine, depends completely on how we personally look at the tag.

Stan Brown wrote:[color=blue]
> "John Dunlop" wrote:[color=green]
>> From http://www.w3schools.com/html/html_intro.asp :[/color]
>[color=green]
>> 1. 'All Web pages contain instructions for display'.[/color]
>
> Well, what's wrong with that? Web pages do contain markup that gives
> instructions for display.[/color]

No, they contain descriptions of the content.
[color=blue]
> Sure, we might phrase it more precisely, but what exactly is the harm
> with the phrasing as given?[/color]

IMHO, it's a core concept of the web that rendering is done on the
client end, not on the authoring end. HTML authors don't write display
instructions in their documents, they write descriptions of various
parts of the document. (Some authors might think they can author the
display using and the like, but they will fail on at least some
user-agents.)

Honestly, I'm a bit surprised that you've missed that point.
[color=blue][color=green]
>> 2. 'The most common display instructions are called HTML tags'.[/color]
>
> Again, what's wrong with that?[/color]

That's a terrible way to describe tags. Tags are the delimiters of an
HTML element.
[color=blue][color=green]
>> 3. 'HTML tags look like this This is a Paragraph'.[/color]
>
> And are you telling us that this is NOT an example of HTML tags?[/color]

It's an example of an opening tag, element content, and a closing tag.
The example cited does distinguish between tags and content.

--
Brian (remove "invalid" to email me)

I wrote:[color=blue][color=green]
>> HTML doesn't tell the browser to do anything. There are no verbs. There
>> are no instructions.
>>
>> HTML tells the browser (or other user agent) what things are. It contains
>> nouns (and adjectives). It's data. It's markup.[/color][/color]

C A Upsdell <cupsdell0311XXX@-@-@XXXrogers.com> wrote:[color=blue]
> I do not think that it is unreasonable to view tags as verbs. For example,
> could be interpreted as 'render-content-as-paragraph'.[/color]

You could interpret the lines painted on a road as "drive here" and "don't
drive here" instructions, as verbs. But I think it makes more sense to
interpret them as the boundaries between traffic lanes, as nouns.

If you interpret tags as instructions, then it won't make sense why you
can't do something like this:

bold paragraph bold-italic new paragraph italic
--
Darin McGrew, mcgrew@stanfordalumni.org, http://www.rahul.net/mcgrew/
Web Design Group, darin@htmlhelp.com, http://www.HTMLHelp.com/

"It said 'Insert disk #3', but only two will fit..."

Darin McGrew wrote:[color=blue]
> If you interpret tags as instructions, then it won't make sense why you
> can't do something like this:
>
> bold paragraph bold-italic new paragraph italic[/color]

Sure it will. You also need to mention that and refer to inline
and refers to block, and that the elements must be properly nested,
and never block inside inline, etc... W3Schools does discuss this as I
recall, though I have not checked recently.

Certasinly if that one line was all that was said about elements, the
learner would probably get it wrong. But I'm assuming it is NOT all that
is said.

Stan Brown wrote:
[color=blue]
> "John Dunlop" <usenet+2004@john.dunlop.name> wrote in
> comp.infosystems.www.authoring.html:[/color]
[color=blue][color=green]
> >From http://www.w3schools.com/html/html_intro.asp :
> >
> >1. 'All Web pages contain instructions for display'.[/color]
>
> Well, what's wrong with that?[/color]

The notion that tags are 'instructions for display'. The
statement, which proceeded from the theory that tags are
instructions, is 'seriously misleading' and 'just plain
wrong' in my book; though I don't care to speculate whether
W3Schools preach or even propound that theory. Supposing
for a moment that tags are in fact instructions for display,
I'd cheerfully agree with them.
[color=blue]
> Web pages do contain markup that gives instructions for display.[/color]

Then it is here we disagree.

[ ... ]
[color=blue][color=green]
> >3. 'HTML tags look like this This is a Paragraph'.[/color]
>
> And are you telling us that this is NOT an example of HTML tags?[/color]

I'm suggesting that it is unnecessarily vague to say 'tags
look like this' and then give an example of them in use
without further explanation, or emphasis even. I do
apologise though because my quote left out the B element
with which they marked up the example, and also the full
stop they curiously included as part of it.

[ ... ]

Cheers!

--
Jock

Neal <neal413@yahoo.com> writes:
[color=blue]
> Darin McGrew wrote:[/color]
[color=blue][color=green]
>> If you interpret tags as instructions, then it won't make sense why you
>> can't do something like this:
>>
>> bold paragraph bold-italic new paragraph italic[/color]
>
> Sure it will.[/color]

No it won't.
[color=blue]
> You also need to mention that and refer to
> inline and refers to block,[/color]

On a descriptive markup level, that's totally irrelevant.
[color=blue]
> and that the elements must be properly nested,[/color]

That's precisely why Darin is referring to *nouns*. Descriptive markup
is all about sticking a name token to entities with unambiguous start-
and end-points. There's no mathematical intersection model in GML.

Browsers consistently handle markup wrong because they treat tags as
verbs (start-tag==do-something,
incorrect-end-tag==recover-from-previous-error).

--
| ) PiÃ¹ Cabernet,
-( meno Internet.
| ) http://bednarz.nl/

"Darin McGrew" <mcgrew@stanfordalumni.org> wrote in message
news:cnb9in$k22$1@blue.rahul.net...[color=blue]
>I wrote:[color=green][color=darkred]
>>> HTML doesn't tell the browser to do anything. There are no verbs. There
>>> are no instructions.
>>>
>>> HTML tells the browser (or other user agent) what things are. It
>>> contains
>>> nouns (and adjectives). It's data. It's markup.[/color][/color]
>
> C A Upsdell <cupsdell0311XXX@-@-@XXXrogers.com> wrote:[color=green]
>> I do not think that it is unreasonable to view tags as verbs. For
>> example,
>> could be interpreted as 'render-content-as-paragraph'.[/color]
>
> You could interpret the lines painted on a road as "drive here" and "don't
> drive here" instructions, as verbs. But I think it makes more sense to
> interpret them as the boundaries between traffic lanes, as nouns.[/color]

Pray tell, what is the essential difference between a stop sign and a
painted line on a road? Both are guides for drivers, and both COULD be
viewed as instructions to drivers.
[color=blue]
> If you interpret tags as instructions, then it won't make sense why you
> can't do something like this:
>
> bold paragraph bold-italic new paragraph italic[/color]

Nonsense. Languages have rules which says what is valid and what is not,
whether the language be HTML markup, perl scripts, C++ code, Inuit, Ameslan,
mathematics, or road signs. (Though valid != correct: 'mice eat elephants'
is syntactically valid, but not correct.)

On Tue, 16 Nov 2004 00:16:22 +0100, Eric B. Bednarz
<bednarz@fahr-zur-hoelle.org> wrote:
[color=blue]
> Neal <neal413@yahoo.com> writes:
>[color=green]
>> Darin McGrew wrote:[/color]
>[color=green][color=darkred]
>>> If you interpret tags as instructions, then it won't make sense why you
>>> can't do something like this:
>>>
>>> bold paragraph bold-italic new paragraph italic[/color]
>>
>> Sure it will.[/color]
>
> No it won't.[/color]

Sure it will.
[color=blue][color=green]
>> You also need to mention that and refer to
>> inline and refers to block,[/color]
>
> On a descriptive markup level, that's totally irrelevant.[/color]

Hmm? If the rules say "no block inside inline" it's entirely relevant.
[color=blue][color=green]
>> and that the elements must be properly nested,[/color]
>
> That's precisely why Darin is referring to *nouns*. Descriptive markup
> is all about sticking a name token to entities with unambiguous start-
> and end-points. There's no mathematical intersection model in GML.
>
> Browsers consistently handle markup wrong because they treat tags as
> verbs (start-tag==do-something,
> incorrect-end-tag==recover-from-previous-error).[/color]

So - how do we disagree? You've talked around it.

I say that the tag is like a speed limit sign. I need to conform to the
zone. Now, I also need to know that the no-selling-drugs zone is in that
zone, and it must nest. Is it impossible to see tags as delimiters of a
zone of semantics, which must nest within another zone of semantics, and
indeed properly?

So what are you saying anyway?

I wrote:[color=blue][color=green]
>> You could interpret the lines painted on a road as "drive here" and "don't
>> drive here" instructions, as verbs. But I think it makes more sense to
>> interpret them as the boundaries between traffic lanes, as nouns.[/color][/color]

C A Upsdell <cupsdell0311XXX@-@-@XXXrogers.com> wrote:[color=blue]
> Pray tell, what is the essential difference between a stop sign and a
> painted line on a road? Both are guides for drivers, and both COULD be
> viewed as instructions to drivers.[/color]

A stop sign is closer to an instruction: stop here. According to the law,
everyone (except emergency vehicles) must follow that instruction.

A painted line is closer to markup, defining a boundary between one lane
and another. Different road users can even use those lanes in different
ways, without violating the law.
[color=blue][color=green]
>> If you interpret tags as instructions, then it won't make sense why you
>> can't do something like this:
>>
>> bold paragraph bold-italic new paragraph italic[/color][/color]
[color=blue]
> Nonsense. Languages have rules which says what is valid and what is not,[/color]

So how do you explain why the above example is invalid, without abandoning
the incorrect "tags as instructions" model and reverting to the correct
"tags as boundaries" model?
--
Darin McGrew, mcgrew@stanfordalumni.org, http://www.rahul.net/mcgrew/
Web Design Group, darin@htmlhelp.com, http://www.HTMLHelp.com/

"Red meat isn't bad for you. Fuzzy blue-green meat is bad for you."

"Darin McGrew" <mcgrew@stanfordalumni.org> wrote in message
news:cnbn5m$thg$1@blue.rahul.net...[color=blue]
>I wrote:[color=green][color=darkred]
>>> You could interpret the lines painted on a road as "drive here" and
>>> "don't
>>> drive here" instructions, as verbs. But I think it makes more sense to
>>> interpret them as the boundaries between traffic lanes, as nouns.[/color][/color]
>
> C A Upsdell <cupsdell0311XXX@-@-@XXXrogers.com> wrote:[color=green]
>> Pray tell, what is the essential difference between a stop sign and a
>> painted line on a road? Both are guides for drivers, and both COULD be
>> viewed as instructions to drivers.[/color]
> A stop sign is closer to an instruction: stop here. According to the law,
> everyone (except emergency vehicles) must follow that instruction.
>
> A painted line is closer to markup, defining a boundary between one lane
> and another. Different road users can even use those lanes in different
> ways, without violating the law.[/color]

A solid centre line says: don't pass here. And a dashed centre line says:
you may pass here.
[color=blue][color=green][color=darkred]
>>> If you interpret tags as instructions, then it won't make sense why you
>>> can't do something like this:
>>>
>>> bold paragraph bold-italic new paragraph italic[/color][/color]
>[color=green]
>> Nonsense. Languages have rules which says what is valid and what is not,[/color]
>
> So how do you explain why the above example is invalid, without abandoning
> the incorrect "tags as instructions" model and reverting to the correct
> "tags as boundaries" model?[/color]

Because one can create any syntactical rules that are self-consistent.
E.g.: a rule saying that "an instruction saying
'render-this-content-as-a-paragraph' cannot be the content of an instruction
saying 'render-this-content-as-bold'". Or a rule saying that "a block begun
by a '{' token in a c/perl/c++/javascript statement must be ended by a '}'
token". (This is much more precisely described using, say, BNF notation.)

Neal <neal413@yahoo.com> writes:
[color=blue]
> Eric B. Bednarz <bednarz@fahr-zur-hoelle.org> wrote:
>[color=green]
>> Neal <neal413@yahoo.com> writes:[/color][/color]
[color=blue][color=green][color=darkred]
>>> Sure it will.[/color]
>>
>> No it won't.[/color]
>
> Sure it will.[/color]

No it will not. Sorry the five minutes is up.
[color=blue][color=green][color=darkred]
>>> You also need to mention that and refer to
>>> inline and refers to block,[/color]
>>
>> On a descriptive markup level, that's totally irrelevant.[/color]
>
> Hmm? If the rules say "no block inside inline" it's entirely relevant.[/color]

The syntactic rules do not know concepts like 'block' or 'inline',
that's just fairly vague prose in the spec (these name tokens also
appear as declared entities in the DTD, along with a bonus 'flow', but
that's just a comfortable way of referencing a bunch of element types,
with a result that cannot be summarised as simple as 'no block inside
inline').
[color=blue]
> Is it impossible to see tags as
> delimiters of a zone of semantics,[/color]

I wouldn't get too excited about the 'semantics' stuff at parse time,
all what happens is sticking name tokens on instances of element types,
and name tokens are as inpenetrable as you like them; e.g. for all we
know 'P' denotes a parking space. :)
[color=blue]
> which must nest within another zone
> of semantics, and indeed properly?[/color]

We were talking about the differences between verbs and nouns, I
thought. A tag as a 'verb' is about starting a process at the point of
encounter at the time of encounter (the official euphemism for that is
'incremental rendering'); if the instruction to end the process is
correct, erroneous or missing is of minor interest then. And that's how
I interpreted the purpose of Darin's example.

--
| ) PiÃ¹ Cabernet,
-( meno Internet.
| ) http://bednarz.nl/

On Sun, 14 Nov 2004 19:31:44 -0500, "C A Upsdell"
<cupsdell0311XXX@-@-@XXXrogers.com> wrote:

[color=blue][color=green]
>> As they clearly do have some conditional behaviour, they mean that
>> ladder-logic can't be a useful counter-example for a statement "All
>> programming languages have conditional statements"[/color]
>
>And ladder diagrams have statements?[/color]

I used statement in the sense of our text and logical discussion. But
it "the unit of programming is the statement" (which seems a fair
definition), then yes, ladder logic has statements, even if you enter
them graphically.
[color=blue]
> When I used it, it was entirely graphic.[/color]

When I used it, you soldered them.

Or on some kit you used an Allen-Bradly "programmer" - several
thousand quid, when a comparable laptop was around 500.

--
Smert' spamionam

On Mon, 15 Nov 2004 16:14:06 -0500, "C A Upsdell"
<cupsdell0311XXX@-@-@XXXrogers.com> wrote:
[color=blue]
>"Darin McGrew" <mcgrew@stanfordalumni.org> wrote in message
>news:cnb3jl$fuf$1@blue.rahul.net...[color=green]
>> From http://www.w3schools.com/html/html_intro.asp :[color=darkred]
>>>> 1. 'All Web pages contain instructions for display'.[/color][/color][/color]
[color=blue][color=green]
>> Stan Brown <the_stan_brown@fastmail.fm> wrote:[color=darkred]
>>> Well, what's wrong with that? ...[/color][/color][/color]
[color=blue][color=green]
>> It's the difference between nouns and verbs.
>> HTML doesn't tell the browser to do anything.
>> There are no verbs. There are no instructions.
>> HTML tells the browser (or other user agent) what things are.
>> It contains nouns (and adjectives). It's data. It's markup.[/color][/color]
[color=blue]
>I do not think that it is unreasonable to view tags as verbs.[/color]

As for markup languages;
An accepted "standard" for how to "view tags" has been established, at
least twice as can be found in the meta language SGML and later in a
following meta language XML[1] (which in effect just happens to be a
different profile of SGML as compared to e.g. the original "Concrete
Reference Syntax" of SGML).

People accept standards in their life's, not because they want to be
governed by them but because they realize that accepting the conditions
set forth in a standard will make it easier to cooperate with others who
also accepts the same standards.

All parties thus accepts a "limitation" of what they can do and gains
the benefit of a better ground for understanding and cooperation with
others.

Feel free to not accept any specific standards view of some details and
you have also created a "problem" for your self in your cooperation with
those who thinks that the standard makes their life's easier to live.
[color=blue]
>For example, could be interpreted as 'render-content-as-paragraph'.[/color]

The corresponding "standard" says it can not. But feel free to "expand"
on the agreed limitation of the standard, use your interpretation and go
on to find that you have just passed through a time-warp that has placed
you back in the mid 90'ies where you will find yourself struggling hard
with the Mosaic/Netscape confusion of that time, while others have moved
on beyond that part of history.
[color=blue]
>As for arguing that mark-up is data: one could also reasonably say that
>(for example) the source code for a perl script is data for a perl compiler,[/color]

And now it seems that you want a break on whatever "standard" there is
for Perl too. IMMIC it is agreed that e.g. Perl source code contains
program instructions to be carried out by some processor, _and_ on
general terms that a "sequence of programming instructions" contains
constructs that allows for said processor to do conditional execution of
instruction sequences.

The fact that we need a "translator" from a human readable language that
produces ones and zeros for some binary oriented processor is irrelevant
here.

( In a parenthesis ...
As seen from that angle, even a ladder diagram can describe a
conditional execution based on real time input signals, e.g...

| X01 Y01 |
+---[ ]----( )---+
| |
| X01 Y02 |
+---[/]----( )---+
| |

...which clearly describes that either of outputs 'Y01' or 'Y02'
should be set to 'ON' status conditionally depending on whether
input 'X01' is at BOOLEAN status 'ON' or 'OFF'.
I.e. the above represents the ladder construct of...

If 'X01 is ON'
Then 'SET' output Y01 to 'ON' status
Else 'SET' output Y02 to 'ON' status
EndIf

...using an old timers[2] memory of Mitsubishi MEDOC.

End parenthesis ...)

The bigger difference here is that for "Perl source" you can have the
control from start of writing it and all the way up till how it's
executed for whatever purpose it was written.

You produce a mark'ed-up document and place that one on a server some
where and you have lost control of how it will be interpreted as soon as
your FTP client has done its job for you.
[color=blue]
>or that written words are data for the human brain. Whether we see a tag as
>an instruction, or as a datum, or (for example) as a trigger for a state
>machine, depends completely on how we personally look at the tag.[/color]

Still again; Yes you do have the freedom to not accept the limitations
that any given standard specifies for you. The "cost" of that "freedom"
has to be paid by you in the end of course.

[1] Any one who really needs a "tags as verbs based" form of markup,
should have a look at XSL-FO; and same person will also find out rather
quickly that this kind of markup is pretty much useless in practice.

[2] Discussing PLC's further with me here in this forum is OT. But...
As a line of my work for a company at that time, I personally
designed a PLC system in the period of 1997-98.
Personally presented it at the biggest Technical Fair we have
in Sweden, in September 1978.
Later we managed to sell 48+ (basically handmade) systems over
a period of three years, out of which the very first delivered
system is still in use, doing exactly the same thing today as
it was designed to do.
We have over all these years replaced one input card in that
first system as a result of a thunderstorm. (accumulators for
memory backup has also been replaced as they have been worn
out of course)
And all this happened just few years after Allen-Bradley and
Modicon had begun to fight over who was actually the first to
provide a working PLC for General Motors in Detroit :-)

--
Rex

"Jan Roland Eriksson" <jrexon@newsguy.com> wrote in message
news:q9ekp0hfi4tsse6e3i86scc939thfelcdn@4ax.com...[color=blue]
> On Mon, 15 Nov 2004 16:14:06 -0500, "C A Upsdell"
> <cupsdell0311XXX@-@-@XXXrogers.com> wrote:
>[color=green][color=darkred]
>>> It's the difference between nouns and verbs.
>>> HTML doesn't tell the browser to do anything.
>>> There are no verbs. There are no instructions.
>>> HTML tells the browser (or other user agent) what things are.
>>> It contains nouns (and adjectives). It's data. It's markup.[/color][/color]
>[color=green]
>>I do not think that it is unreasonable to view tags as verbs.[/color]
>
> As for markup languages;
> An accepted "standard" for how to "view tags" has been established, at
> least twice as can be found in the meta language SGML and later in a
> following meta language XML[1] (which in effect just happens to be a
> different profile of SGML as compared to e.g. the original "Concrete
> Reference Syntax" of SGML).
>
> People accept standards in their life's, not because they want to be
> governed by them but because they realize that accepting the conditions
> set forth in a standard will make it easier to cooperate with others who
> also accepts the same standards.[/color]

[much omitted]

It is my perspective that you have a very rigid view of languages. Perhaps
my 27 years as a software designer have enabled me to think without
blinkers.

30

On Tue, 16 Nov 2004 16:35:56 -0500, "C A Upsdell"
<cupsdell0311XXX@-@-@XXXrogers.com> wrote:
[color=blue]
>"Jan Roland Eriksson" <jrexon@newsguy.com> wrote in message
>news:q9ekp0hfi4tsse6e3i86scc939thfelcdn@4ax.com.. .[/color]

[...]
[color=blue][color=green]
>> People accept standards in their life's, not because they want to be
>> governed by them but because they realize that accepting the conditions
>> set forth in a standard will make it easier to cooperate with others who
>> also accepts the same standards.[/color][/color]

[...]
[color=blue]
>It is my perspective that you have a very rigid view of languages. Perhaps
>my 27 years as a software designer have enabled me to think without
>blinkers.[/color]

No; it has enabled you to get trapped trapped in a corner :-)

--
Rex

(Stan Brown in comp.infosystems.www.authoring.html)
[color=blue]
>"John Dunlop" <usenet+2004@john.dunlop.name> wrote in
>comp.infosystems.www.authoring.html:[color=green]
>>From http://www.w3schools.com/html/html_intro.asp :
>>
>>1. 'All Web pages contain instructions for display'.[/color]
>
>Well, what's wrong with that?[/color]

People will think they are clever because they can write complicated
markup.

Why not say HTML contains properties for text and also grids for
layout? That HTML is just the stuff you put between the paragraphs of
your text? The bloat? :-)
I'd also tell every newbie that actually HTML is called "CSS" today,
and that only one small file was needed of that.

[color=blue]
>[snipp][/color]

Tilman
--
Der statistische Tote ist dir eal. Der stochastische Tote bist du selber.

On Thu, 25 Nov 2004, Tilman Hesse wrote:
[color=blue]
> I'd also tell every newbie that actually HTML is called "CSS" today,[/color]

That would IMHO be perverse. It may indeed be a good idea to say
*something* to compensate for the Netscape-fired belief that HTML
needed to transmogrify from a basically structural-markup language, to
a quasi-DTP language, when there had all along been plans for some
kind of separate style-association language alongside the structural
HTML. (Just that it hadn't always been CSS and only CSS - but I
digress.)

After all, many newcomers may have been exposed as users to the -
originally Netscape-fired - (quasi-)HTML, or may have read some
tutorials which presented that unfortunate view. So it could be a
good idea to present them with some kind of heads-up that they might
do well to unlearn any misguided preconceptions that they may have
been fed.

But the wording that you have used seems to me to be *most*
inadvisable. Sorry.

all the best

Le 13/11/2004 01:13, Aidan a ecrit :[color=blue]
> I rely heavily on MSDN for documentation when it comes to
> HTML/DHTML/JavaScript/CSS but as a result I often have problems getting my
> stuff to work in Netscape/Mozilla/Firefox. I like the MSDN online
> documentation
> (http://msdn.microsoft.com/library/de...uthor/dhtml/re
> ference/objects.asp) because it has complete lists of DHTML objects,
> properties, methods, collections and event and for each element you can
> easily view all the applicable attributes/propertes, behaviors, collections,
> events, filters, methods, objects and styles. And it is a all very well
> cross-referenced so for example if you are looking at an event you can see
> all the elements that it applies to.
>
> Is there any online equivalent for Mozilla/Geko based browsers?
>
> I have explored the Gecko DOM reference at
> http://www.mozilla.org/docs/dom/domref but frankly this sucks. I cannot find
> a complete list of all HTML elements and all attributes/properties, methods,
> events, styles etc. I'm thinking there has got to be some decent
> documentation like that on MSDN out there., can anybody point me in the
> right direction?[/color]

http://developer-test.mozilla.org/

It is still in heavy works, in the past we could use Netscape Devedge
(Netscape 7 being a mozilla distro) but AOHELL closed it recently,
mozilla.org is negociating with them to get all the Devedge content and
put it in the future developer.mozilla.org website.

More generally, Gecko follows standards quite closely so if you code
with standards in mind (and not MSDN in mind ;) ), you shouyld have no
problem.

Pascal

--
Pascal Chevrel - Mozilla Champion
FAQ Mozilla/Netscape en français : http://www.chevrel.org/fr/faq/
Forums SOS online.net: http://forums.chevrelbureau.com/

Online documentation for Geko/Mozilla browsers???

re: Online documentation for Geko/Mozilla browsers???

re: Online documentation for Geko/Mozilla browsers???

re: Online documentation for Geko/Mozilla browsers???

re: Online documentation for Geko/Mozilla browsers???

re: Online documentation for Geko/Mozilla browsers???

re: Online documentation for Geko/Mozilla browsers???

re: Online documentation for Geko/Mozilla browsers???

re: Online documentation for Geko/Mozilla browsers???

re: Online documentation for Geko/Mozilla browsers???

re: Online documentation for Geko/Mozilla browsers???

re: Online documentation for Geko/Mozilla browsers???

re: Online documentation for Geko/Mozilla browsers???

re: Online documentation for Geko/Mozilla browsers???

re: Online documentation for Geko/Mozilla browsers???

re: Online documentation for Geko/Mozilla browsers???

re: Online documentation for Geko/Mozilla browsers???

re: Online documentation for Geko/Mozilla browsers???

re: Online documentation for Geko/Mozilla browsers???

re: Online documentation for Geko/Mozilla browsers???

re: Online documentation for Geko/Mozilla browsers???

re: Online documentation for Geko/Mozilla browsers???

re: Online documentation for Geko/Mozilla browsers???

re: Online documentation for Geko/Mozilla browsers???

re: Online documentation for Geko/Mozilla browsers???

re: Online documentation for Geko/Mozilla browsers???

re: Online documentation for Geko/Mozilla browsers???

re: Online documentation for Geko/Mozilla browsers???

re: Online documentation for Geko/Mozilla browsers???

re: Online documentation for Geko/Mozilla browsers???

re: Online documentation for Geko/Mozilla browsers???

re: Online documentation for Geko/Mozilla browsers???

re: Online documentation for Geko/Mozilla browsers???

re: Online documentation for Geko/Mozilla browsers???

re: Online documentation for Geko/Mozilla browsers???

re: Online documentation for Geko/Mozilla browsers???

re: Online documentation for Geko/Mozilla browsers???

re: Online documentation for Geko/Mozilla browsers???

re: Online documentation for Geko/Mozilla browsers???

re: Online documentation for Geko/Mozilla browsers???

re: Online documentation for Geko/Mozilla browsers???

re: Online documentation for Geko/Mozilla browsers???

re: Online documentation for Geko/Mozilla browsers???

re: Online documentation for Geko/Mozilla browsers???

re: Online documentation for Geko/Mozilla browsers???

re: Online documentation for Geko/Mozilla browsers???

re: Online documentation for Geko/Mozilla browsers???

re: Online documentation for Geko/Mozilla browsers???

re: Online documentation for Geko/Mozilla browsers???

re: Online documentation for Geko/Mozilla browsers???

Similar HTML / CSS bytes

/bytes/development

/bytes/it

/bytes/about