Netscape & New HTML
Gavin Adams
new tags. :) Are these tags in the 2.0 spec or is MCC trying to redfine HTML?
I actually like some of the new formatting directives, and I'm curious what
editors people are using.
Gavin Adams
-----------------------------------------------------------
Digital Consulting Sandia National Laboratories
Gavin...@aqo.mts.dec.com gad...@sandia.gov
+1 505 343 7200 +1 505 844 3897
-----------------------------------------------------------
Marc Andreessen
Adams) wrote:
> Taking a look at some "Netscape Friendly" HTML, I've noticed a whole bunch of
> new tags. :) Are these tags in the 2.0 spec or is MCC trying to redfine HTML?
(a) Just a friendly suggestion that MCom is a better abbreviation
for our company than MCC, as MCC already refers to MCC of Austin,
TX and MacWeb/WinWeb fame.
(b) The new tags (documented for the time being in
http://home.mcom.com/home/services_docs/html-extensions.html)
are extensions to HTML as implemented in NCSA Mosaic for X 2.4
and being codified as HTML 2.0. These extensions are the
result of a year and a half of a very large volume of requests to
Eric and I (the original NCSA Mosaic for X authors) for expanded
document layout and formatting control and address many of the specific
demands of the hundreds (thousands?) of document authors from whom
we've received feedback over that period of time. I can't count the
number of times people have requested text flowing around images,
control over font sizes, centering, etc. -- and we hope these new
extensions at least go partway to fulfilling many of those needs.
Cheers,
Marc
--
Marc Andreessen
Mosaic Communications Corp.
Mountain View, CA
ma...@mcom.com
Earl Hood
In article <marca-13109...@boulanger.mcom.com>,
Marc Andreessen <ma...@mcom.com> wrote:
>> Taking a look at some "Netscape Friendly" HTML, I've noticed a whole bunch of
>> new tags. :) Are these tags in the 2.0 spec or is MCC trying to redfine HTML?
>(b) The new tags (documented for the time being in
> http://home.mcom.com/home/services_docs/html-extensions.html)
> are extensions to HTML as implemented in NCSA Mosaic for X 2.4
> and being codified as HTML 2.0. These extensions are the
> result of a year and a half of a very large volume of requests to
> Eric and I (the original NCSA Mosaic for X authors) for expanded
> document layout and formatting control and address many of the specific
> demands of the hundreds (thousands?) of document authors from whom
> we've received feedback over that period of time. I can't count the
> number of times people have requested text flowing around images,
> control over font sizes, centering, etc. -- and we hope these new
> extensions at least go partway to fulfilling many of those needs.
Questions/concerns:
I'm unclear if the html working group is aware of these 'enhancements'
to HTML.
I find it disturbing that with all the effort to standardize HTML, an
organization goes and implements their own extensions. I thought the
big push for a standard for HTML was to prevent additions/extensions
from being added on "whims", but enhancements would go through a formal
process so features of HTML do not become proprietary.
Are these enhancements part of the proposed standard for HTML 3.0? Is
there an SGML DTD that incorporates these features? Have these
enhancements been suggested to the (2.0) working group? To the
developers of HTML 3.0?
Excuse me if I'm showing massive ignorance here, I do not have the time
to keep up will all the going-ons of HTML development.
--ewh
P.S. Some of the enhancements are nice, while others are
questionable.
The Goddess of All
by WinWeb, Mosaic, Cello and whatever else is out there? will these
enhancments appear to cause errors on the other browsers? if this is the
case, i think i will stick with things that can be seen across as many
possible platforms as possible.
marianne
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*
* gu...@mcs.net *
* "...the world gets crazy when you're insane..." <k.hall> *
* {home page: http://www.mcs.net/~gumby/home.html } *
* {Indigo Girls: http://www.mcs.net/~gumby/HTML/IG/ig-page.html } *
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*
Glenn Davis
> by WinWeb, Mosaic, Cello and whatever else is out there? will these
> enhancments appear to cause errors on the other browsers? if this is the
> case, i think i will stick with things that can be seen across as many
> possible platforms as possible.
>
Personally, I think that WinWeb, Mosaic, and Cello will have to bow to
market pressure and include these new enchancements. I'm sure
there will be much discussion of this at the WWW conference in Chicago
next week.
However, even if they don't you can design for both easily. The
enhancements are ignored by those browsers, but show up under Mozilla
(NetScape). My Cool Site of the Day page has been NetScape Enhanced
for over a week, but standard Mosaic/Cello/WinWeb/Lynx users have seen
nothing out of the ordinary on it. But by simply including a few of
the NetScape enhancements I was able to really visually enhance the
page graphically for Mozilla users. The difference is striking and
with very little extra work.
Glenn
() ()
gda...@infi.net \\(o o)// Cool Site of the Day
----------------o00-=(_)=-00o-------------------------------------------------
http://www.infi.net/cool.html
Marc Andreessen
> Will these new html enhancements be seen ONLY on Netscape browsers and ignored
> by WinWeb, Mosaic, Cello and whatever else is out there? will these
> enhancments appear to cause errors on the other browsers? if this is the
> case, i think i will stick with things that can be seen across as many
> possible platforms as possible.
We've tried really hard to make sure the enhancements supported by
Netscape 0.9 layer very transparently and cleanly on top of HTML as
implemented by NCSA Mosaic for X 2.4 and not cause problems in other
browsers. Browsers that cleanly ignore tags and attributes they don't
understand shouldn't have problems (errors, etc.). At least a few
network sites (including the Cool Page of the Day at infi.net [I think])
are already serving pages that use the enhancements but also work
fine with old browsers.
We're publishing details on the enhancements with no restrictions
whatsoever, so other browsers can certainly support these enhancements
if they choose.
Eric W. Sink
(Marc Andreessen) wrote:
> (b) The new tags (documented for the time being in
> http://home.mcom.com/home/services_docs/html-extensions.html)
> are extensions to HTML as implemented in NCSA Mosaic for X 2.4
> and being codified as HTML 2.0.
The IETF working group standardizing HTML 2.0 has a draft available at
the following URL:
http://www.hal.com/~connolly/html-spec/
HTML 2.0 does not contain the tags Marc refers to.
Any questions regarding HTML 2.0 or follow-on HTML standards can be
referred to the HTML working group at htm...@oclc.org.
--
Eric W. Sink
Spyglass, Inc.
er...@spyglass.com
Tim Pierce
>I find it disturbing that with all the effort to standardize HTML, an
>organization goes and implements their own extensions. I thought the
>big push for a standard for HTML was to prevent additions/extensions
>from being added on "whims", but enhancements would go through a formal
>process so features of HTML do not become proprietary.
You may be interested in this blurb from Gary Wolf's Mosaic
article in the October WIRED:
The reason [SPRY's Chris] Wilson and other Mosaic
developers have not heard much from Mosaic Communications
lately, Andreessen admits, is that a unified standard is
not of first importance to the company. "Our major
concern is our products," he says. "On top of that, we
would like to be in an open environment, where other
browsers could read our documents. It makes companies and
consumers more willing to buy in. But it can't be our
primary concern."
--
"A person who dies of lung cancer at age 70 will not be hospitalized later
with another disease," said a study released Thursday by [Canada's] Imperial
Tobacco touting the benefits of early death in smokers on the health-care
system. (Reuters, in the Chicago _Tribune_, 9/3/94)
Earl Hood
Tim Pierce <twpi...@midway.uchicago.edu> wrote:
>
>>I find it disturbing that with all the effort to standardize HTML, an
>>organization goes and implements their own extensions. I thought the
>>big push for a standard for HTML was to prevent additions/extensions
>>from being added on "whims", but enhancements would go through a formal
>>process so features of HTML do not become proprietary.
>
>You may be interested in this blurb from Gary Wolf's Mosaic
>article in the October WIRED:
>
> The reason [SPRY's Chris] Wilson and other Mosaic
> developers have not heard much from Mosaic Communications
> lately, Andreessen admits, is that a unified standard is
> not of first importance to the company. "Our major
> concern is our products," he says. "On top of that, we
> would like to be in an open environment, where other
> browsers could read our documents. It makes companies and
> consumers more willing to buy in. But it can't be our
> primary concern."
This statement is contradictory. How does Andreessen expect for "other
browsers" to read "our documents", when their documents contain markup
that is not part of the standard HTML spec? Yet, they are advocating
an open environment. The reason for an HTML standard is to advocate an
open environment and not proprietary HTML hybrids that only a specific
set of software understands.
Plus, users may become disgruntled when later revisions of the HTML
standard includes markup to handle the features that MCom has added,
but the markup is not the same. Users will have to spend time and
effort to translate MCom HTML to standard HTML. As a provider of HTML
documents, I plan to stick with the standard inorder to avoid future
maintenance headaches.
--ewh
Earl Hood
Marc Andreessen <ma...@mcom.com> wrote:
>
>We're publishing details on the enhancements with no restrictions
>whatsoever, so other browsers can certainly support these enhancements
>if they choose.
What about editors, validators, and other HTML tools? I thought the
standardization of HTML was to prevent the continual chaotic growth
of HTML and prevent the headache of software developers trying to
keep up with all the changes to HTML.
Do you expect for HTML software developers to update their software
everytime someone changes HTML w/o a formal standarization process? To
me, MCom's enhancements will limit users to what HTML tools they can
use; which contridicts the concept of an "open environemt". Not all
people author HTML with a plain ol' text editor, and many people like
to validate their documents before publishing them. Where's the DTD?
--ewh
Marc Andreessen
> In article <marca-13109...@boulanger.mcom.com>, ma...@mcom.com
> (Marc Andreessen) wrote:
>
> > (b) The new tags (documented for the time being in
> > http://home.mcom.com/home/services_docs/html-extensions.html)
> > are extensions to HTML as implemented in NCSA Mosaic for X 2.4
> > and being codified as HTML 2.0.
>
> The IETF working group standardizing HTML 2.0 has a draft available at
> the following URL:
>
> http://www.hal.com/~connolly/html-spec/
>
> HTML 2.0 does not contain the tags Marc refers to.
I'm sorry, I see now that my statement was ambiguous in meaning.
I was trying to say this: Netscape supports HTML as implemented
in NCSA Mosaic for X 2.4 and as is being codified into HTML 2.0,
plus the extensions documented for the time being in
http://home.mcom.com/home/services_docs/html-extensions.html.
Cheers,
Marc
> Any questions regarding HTML 2.0 or follow-on HTML standards can be
> referred to the HTML working group at htm...@oclc.org.
>
> --
> Eric W. Sink
> Spyglass, Inc.
> er...@spyglass.com
--
Phillip M. Hallam-Baker
|>In article <37l3dt$9...@imagine.convex.com>, Earl Hood <eh...@convex.com> wrote:
|>
|>>I find it disturbing that with all the effort to standardize HTML, an
|>>organization goes and implements their own extensions. I thought the
|>>big push for a standard for HTML was to prevent additions/extensions
|>>from being added on "whims", but enhancements would go through a formal
|>>process so features of HTML do not become proprietary.
|>
|>You may be interested in this blurb from Gary Wolf's Mosaic
|>article in the October WIRED:
|>
|> The reason [SPRY's Chris] Wilson and other Mosaic
|> developers have not heard much from Mosaic Communications
|> lately, Andreessen admits, is that a unified standard is
|> not of first importance to the company. "Our major
|> concern is our products," he says. "On top of that, we
|> would like to be in an open environment, where other
|> browsers could read our documents. It makes companies and
|> consumers more willing to buy in. But it can't be our
|> primary concern."
Well I wouldn't necessarily assume that the original statement was quite the
same. My comment lost a certain important piece of context.
There is a standards body for the Web, the World Wide Web Organisation based at
CERN and MIT. Now it may be that it moves a little slowly but making standards
takes time to do it properly, for HTTP the IETF has to be consulted, for HTML
there is the IETF, Open/SGML and ICADD. The last being very important because
they are the people making sure the blind and deaf users don't lose out.
The HTML variant is not that drastic. At least they didn't have an incompatible
tables implementation or worse bastardise HTML+ maths. The real question is
whether they will be supporting the features of standard HTML. Will they
go for conformance certification when it gets started?
Mind you they really could have looked up in the SGML handbook and found out
what an SGML comment really looks like :-)
--
Phillip M. Hallam-Baker
Not Speaking for anyone else.
Wayne Wilson
> standardization of HTML was to prevent the continual chaotic growth
> of HTML and prevent the headache of software developers trying to
> keep up with all the changes to HTML.
>
> Do you expect for HTML software developers to update their software
> everytime someone changes HTML w/o a formal standarization process? To
> me, MCom's enhancements will limit users to what HTML tools they can
> use; which contridicts the concept of an "open environemt".
I have somewhat mixed feeling about standards processes and progres.
One test that could be used in evaluating MCOM's enhancements, would
be to see if they are incompatible with other browsers. For example,
I notice that one of the enhancements caused centering in Netscape,
but no centering in AIR Moaic, but otherwise the document was
useable, just not as 'designed' by the author. However, I have founc
this to be case ever since I have been able to use more than one
browser. Cello, for example, always seems to look completly differnt
than NCSA Mosaic. Finally, if users are allowed to change fonts,
sizes and colors, the issue of 'as designed' by author begins to look
fuzzy. So a test that shows useability might be a good indicator of
whether an enhancement is incompatible and will lead to fractionation.
Peter Flynn
In article <37l3dt$9...@imagine.convex.com>, Earl Hood <eh...@convex.com> wrote:
>I find it disturbing that with all the effort to standardize HTML, an
>organization goes and implements their own extensions. I thought the
>big push for a standard for HTML was to prevent additions/extensions
>from being added on "whims", but enhancements would go through a formal
>process so features of HTML do not become proprietary.
Despite what Marc says, the extensions are NOT a part of HTML 2.0 and
are in the nature of unsupported experimental matter. Some of them
look like nice ideas, others I'm less sure about (a polite way of
saying they suck :-)
This is only to be expected, as user demand for "any damn thing so
long as it looks cute and impresses the hell out of people" will
always outweight demand from more "serious" users who want something
robust, stable, well-defined and portable between platforms and
browsers.
Tim is quite right to cite the blurb from Gary Wolf's Mosaic article
in the October WIRED:
The reason [SPRY's Chris] Wilson and other Mosaic developers have
not heard much from Mosaic Communications lately, Andreessen
admits, is that a unified standard is not of first importance to
the company. "Our major concern is our products," he says. "On
top of that, we would like to be in an open environment, where
other browsers could read our documents. It makes companies and
consumers more willing to buy in. But it can't be our primary
concern."
MCom is a commercial company in the USA: of course they want an
advantage which will get them ahead of their competitors. It may even
make them a few fast bucks (which they well deserve for their hard
work) but trying to push the development of the standard their way
when they have little expertise in SGML is going to bugger up the
whole Web for everyone else, and long term is a poor investment of
their expertise.
<*sigh*> Sometimes people _never_ learn...
///Peter
--
Peter Flynn | pfl...@curia.ucc.ie | ...persuade users that spreading
Computer Centre | +353 21 276871 x2609 | fonts across the page like peanut
University College | +353 21 277194 (fax) | butter across hot toast is not the
Cork, Ireland | Opinions are my own. | route to typographic excellence...
Marc Andreessen
> CERN and MIT.
Is it? I thought HTML was being standardized under the auspices of
IETF now.
> Now it may be that it moves a little slowly but making standards
> takes time to do it properly, for HTTP the IETF has to be consulted, for HTML
> there is the IETF, Open/SGML and ICADD. The last being very important because
> they are the people making sure the blind and deaf users don't lose out.
How does this work? What does "consulted" mean?
> The HTML variant is not that drastic. At least they didn't have an incompatible
> tables implementation or worse bastardise HTML+ maths. The real question is
> whether they will be supporting the features of standard HTML.
> Will they
> go for conformance certification when it gets started?
Sounds fantastic to me -- I'm looking forward to information being available
on (a) anything beyond HTML 2.0 (aka "standard practice) or (b) any
conformance certification -- today there's *nothing*.
The HTML+ Internet Draft is long since expired (right?); there is no
HTML 3.0 spec, or even a proposal (Dave Raggett told us on Oct 3, "I
am about to start writing the first draft for HTML 3.0"). Someone at
CERN is "investigating" style sheets (Dave Raggett, Sep 9).
Some people seem to be assuming that we're deliberately forking the road
here, but folks, there isn't a whole lot out there right now in terms of
innovation happening in design-by-committee environments, and I am finding
it hard to figure out how to move forward with new functionality for
which customers are pounding down our doors at any reasonable rate of
speed without simply doing what it takes to get the functionality
working and in parallel openly documenting the results (as happened with
both inlined images and forms in Mosaic the first time around). Ideas as
always are welcome.
Marc
Marc Andreessen
> Despite what Marc says, the extensions are NOT a part of HTML 2.0
As I noted in a separate followup, my statement was ambiguous
and I did not intend to imply that.
> This is only to be expected, as user demand for "any damn thing so
> long as it looks cute and impresses the hell out of people" will
> always outweight demand from more "serious" users who want something
> robust, stable, well-defined and portable between platforms and
> browsers.
Charming, and a bit nonlinear; Peter, are you ever going to
actually acknowledge that most real content providers are highly,
highly concerned with the appearance of their documents?
Or are you always going to pretend that people who insist on
divorcing appearance from content at all times are anything but
a tiny but highly vocal minority in the real world?
> but trying to push the development of the standard their way
> when they have little expertise in SGML is going to bugger up the
> whole Web for everyone else
Yup, that's exactly what happened when we added inlined images
to NCSA Mosaic in the exact same manner we added these extensions
to Netscape, isn't it?
> <*sigh*> Sometimes people _never_ learn...
Well, that's certainly true.
Mike Meyer
> We're publishing details on the enhancements with no restrictions
> whatsoever, so other browsers can certainly support these enhancements
> if they choose.
I'm curious - do the new enhancements include <LI> not needing to be
in a list of some kind, did that change in HTML while I wasn't
looking, or is the HTML on the MCOM home page bogus?
<mike
Rick Hawes
: > Despite what Marc says, the extensions are NOT a part of HTML 2.0
: > <*sigh*> Sometimes people _never_ learn...
Let us not forget that Netscape IS a commercial product. With all
the competition for browsers based on the same code, that does the same
thing from product to product, with nearly identical interfaces, how
better to distinguish Mcom's product than by going one-up and
introducing some unique new features that a substantial number of people
have been demanding since the inaugural release of Mosaic. And their use
does not break any of the other similar products. Sounds like real good
standard marketing to me. And, it's free....
Rick
--
===========================================================================
| ri...@teleport.COM Public Access User - Not affiliated with TECHbooks |
| Public Access UNIX and Internet at (503) 220-1016 (2400-14400, N81) |
===========================================================================
Mike Ruxton (CHS)
>Marc
I have not (yet) used NetScape. But there is obviously a concern that it
somehow is breaking the intent of HTML as a markup language. I'm not sure
how it might do this, although insisting on a particular font for certain
features might be a violation. So i have a question:
Do NetScape's extensions to HTML(+/2.0) break with the intent of HTML?
Also, I agree that committees can be arduous and frustrating and slow and
many other things. But they have their uses. Standards have their uses. It
is unclear to me whether MCom is trying to be faithful to the spirit of
markup in general, or trying to become the standard-governing body
themselves (i.e. capturing the market).
I am no expert in SGML or even HTML, and I am sure that they are not
perfect or self-consistent. I can think of at least one feature I have not
been able to find (end of page) which I think of as markup, while the
first person I discussed this with thought that this was implicit as end
of html page. These things need some thought to decide on the appropriate
representation. Committees help do this, as long as ego does not interfere
with decision making. (I'm not painting either side here as egoistic).
So, what process was used to decide whether an extension to HTML should be
done one way or another? Was some vetting process in force, or was it
ad hoc? Were there guidelines for conforming with the intentions of
markup?
I realize that WWW is a growing thing, and conventions and standards don't
always address the future particularly well. My questions are an attempt
to clarify what NetScape has attempted, and why.
Sincerely
--
rux...@agcrr.bio.ns.ca
_-=-_-=-_-=-_-=-_-=-_-=-_-=-_-=-_-=-_-=-_-=-_-=-_-=-_-=-_
Nothing will ever be attempted if all possible objections
must first be overcome. --- Samuel Johnson
Tim Pierce
Marc Andreessen <ma...@mcom.com> wrote:
>Charming, and a bit nonlinear; Peter, are you ever going to
>actually acknowledge that most real content providers are highly,
>highly concerned with the appearance of their documents?
So what?
>Or are you always going to pretend that people who insist on
>divorcing appearance from content at all times are anything but
>a tiny but highly vocal minority in the real world?
So what?
Since when has the wisdom of the marketplace, or the Dollar
as Almighty Oracle, ever represented the proper technical
path to take?
>> but trying to push the development of the standard their way
>> when they have little expertise in SGML is going to bugger up the
>> whole Web for everyone else
>
>Yup, that's exactly what happened when we added inlined images
>to NCSA Mosaic in the exact same manner we added these extensions
>to Netscape, isn't it?
I'm curious to know how Marc suggests that text-based
browsers like Lynx should interpret differently-sized fonts
within a line.
David Staschover
: Plus, users may become disgruntled when later revisions of the HTML
: standard includes markup to handle the features that MCom has added,
: but the markup is not the same. Users will have to spend time and
: effort to translate MCom HTML to standard HTML. As a provider of HTML
: documents, I plan to stick with the standard inorder to avoid future
: maintenance headaches.
What I find *very* annoying is that I create an html page one way, using
WinMosaic as my testing client, only to find that when I view it using
Winweb, Cello or Air Mosaic, it comes out differently. There are so many
inconsistancies currently with the html browsers that are out there. It
doesn't seem to be a standard at all anyway... Each browser has its own
quirks..
David Staschover
d...@panix.com
Garrett Blythe
> >> when they have little expertise in SGML is going to bugger up the
> >> whole Web for everyone else
> >
> >Yup, that's exactly what happened when we added inlined images
> >to NCSA Mosaic in the exact same manner we added these extensions
> >to Netscape, isn't it?
>
> I'm curious to know how Marc suggests that text-based
> browsers like Lynx should interpret differently-sized fonts
> within a line.
As you fully already know, Lynx, DosLynx, and other text browsers
ignore tags that they can't handle. Was <H1> ever larger in Lynx
than any other character? These browsers will continue to function
as they always have, doing the best they can for their own
environement. What more could you ask from their authors? ;>
garrett
--
bly...@mcom.com
Garrett Arch Blythe
Code Connoisseur
Mosaic Communications Corporation
http://mosaic.mcom.com/people/blythe
Tim Pierce
> [I said:]
>
>> I'm curious to know how Marc suggests that text-based
>> browsers like Lynx should interpret differently-sized fonts
>> within a line.
>
>As you fully already know, Lynx, DosLynx, and other text browsers
>ignore tags that they can't handle. Was <H1> ever larger in Lynx
>than any other character?
I'm sorry, but I couldn't find a point in the spec that
demanded that characters within <H1> tags must appear larger
than normal text. If you can point me to it, I would
appreciate it a great deal.
The point is that just about everything, if not actually
everything, in the existing HTML standards can still be
implemented on platforms ranging all the way to plain text
browsers. Implementing font-change tags in an HTML
extension limits that to a much smaller hardware population,
and is sheer lunacy in this case.
Eric Bina
> What I find *very* annoying is that I create an html page one way, using
> WinMosaic as my testing client, only to find that when I view it using
> Winweb, Cello or Air Mosaic, it comes out differently. There are so many
> inconsistancies currently with the html browsers that are out there. It
> doesn't seem to be a standard at all anyway... Each browser has its own
> quirks..
Umm... As it has been explained to me, this is supposed to be a good
thing. It is a different format on each browser, but the same
text (and images). SGML explicitly doesn't want you to expect or
be able to make a document that will look the same on all browsers.
(Note, it might look the same if you are lucky, but you are explictly
denied control in this area)
In many ways this is the root of the argument.
It reminds me of people arguing over gun control :-)
Eric Bina
eb...@mcom.com
Earl Hood
In article <marca-14109...@boulanger.mcom.com>,
Marc Andreessen <ma...@mcom.com> wrote:
>Some people seem to be assuming that we're deliberately forking the road
>here, but folks, there isn't a whole lot out there right now in terms of
>innovation happening in design-by-committee environments, and I am finding
>it hard to figure out how to move forward with new functionality for
>which customers are pounding down our doors at any reasonable rate of
>speed without simply doing what it takes to get the functionality
>working and in parallel openly documenting the results (as happened with
>both inlined images and forms in Mosaic the first time around). Ideas as
>always are welcome.
There is 'resistance' to MCom's additions since there appears to be a
lack of thought into some of the additions provided. Plus, a disregard
for SGML syntax rules (as pointed out by someone in the html-wg) causes
a major problem since HTML is supposed to be an SGML application.
I think if MCom went more along the lines like:
o <P ALIGN="CENTER">, <H1 ALIGN="RIGHT">, etc, for aligning
text. The CENTER element is poor style.
o Instead of a FONT element to control point sizes, provide
elements which imply point size/font chages: COPYRIGHT,
SUBSCRIPT, SUPERSCRIPT, etc.
o Since NetScape uses its own fonts, is NetScape going to
get in the font provider business. As you stated, you are
trying to answers demands from publishers. Well different
publishers have different font requirements. And personally,
I do not prefer Netscapes fonts for my documents.
Since WWW is a multiplatform environment, and each platform
has their own font specification, letting users decide font
choices is more desireable. Otherwise, NetScape will have to
provide various fonts to satisfy users along with
publishers.
o Provide a DTD defining the additions made.
I'd recommend looking at other SGML DTDs (Docbook, TEI) and see what
they did. These DTDs are used to publish for hardcopy devices, and
therefore, should address some the formatting rules that publishers
have been demanding of you.
If the changes MCom mades appear to be well thought out (and some
appear to be) and along the lines of what the HTML working group is
trying to accomplish, you will get more success in speeding up the
developement of HTML.
After some thought, I think what MCom did is good. It is good in
the sense that it shook people up and might accelarate the
developement of HTML. Even though some of the ehancements are
very questionable, it is a start.
--ewh
----
Earl Hood | CONVEX Computer Corporation
eh...@convex.com | 3000 Waterview Parkway
Phone: (214) 497-4387 | P.O. Box 833851
FAX: (214) 497-4500 | Richardson, TX 75083-3851
R. Stewart Ellis
Yeah. I wonder what HotMetal does with some of the non-standard, illegal
stuff? :}
--
R.Stewart(Stew) Ellis, Assoc.Prof., (Off)313-762-9765 ___________________
Humanities & Social Science, GMI Eng.& Mgmt. Inst. / _____ ______
Flint, MI 48504 el...@nova.gmi.edu / / / / / /
Gopher,chimera,nn,tin,jove,modems, free code is best!/________/ / / / /
R. Stewart Ellis
>In article <gadams.37...@sandia.gov>, gad...@sandia.gov (Gavin
>Adams) wrote:
>> Taking a look at some "Netscape Friendly" HTML, I've noticed a whole bunch of
>> new tags. :) Are these tags in the 2.0 spec or is MCC trying to redfine HTML?
[...]
>(b) The new tags (documented for the time being in
> http://home.mcom.com/home/services_docs/html-extensions.html)
> are extensions to HTML as implemented in NCSA Mosaic for X 2.4
> and being codified as HTML 2.0. These extensions are the
This is ambiguous. Does it mean what it says, that the extensions are
implemented in NCSA Mosaic for X 2.4 and are being codified as HTML 2.0? or
that it extends HTML as implemented in NCSA Mosaic, which extensions are
being codified as HTMO 2.0?
What I want to know is what other browsers will be able to interpret the new
stuff.
[...]
Nicolas Pioch
[comp.infosystems.www.misc]
| Yeah. I wonder what HotMetal does with some of the non-standard, illegal
| stuff? :}
As if anybody cared about hotmetal :)
-- N.
Roger R. Espinosa
I apologize in advance if someone mentions this along the way in this
thread -- my homebrew USENET reader sometimes barfs on the treading,
mostly due to intercepting nonstandard "References" line due to a lot of
homebrew and chaotic don't-adhere-to-standards newsreaders out there.
Anyway. :-)
In article <1994Oct15.1...@midway.uchicago.edu>,
twpi...@quads.uchicago.edu (Tim Pierce) wrote:
> In article <37ot4a$8...@flop.mcom.com>, Garrett Blythe <bly...@mcom.com> wrote:
>
> >As you fully already know, Lynx, DosLynx, and other text browsers
> >ignore tags that they can't handle. Was <H1> ever larger in Lynx
> >than any other character?
>
> I'm sorry, but I couldn't find a point in the spec that
> demanded that characters within <H1> tags must appear larger
> than normal text. If you can point me to it, I would
> appreciate it a great deal.
>
> The point is that just about everything, if not actually
> everything, in the existing HTML standards can still be
> implemented on platforms ranging all the way to plain text
> browsers. Implementing font-change tags in an HTML
> extension limits that to a much smaller hardware population,
> and is sheer lunacy in this case.
What's bugged me about HTML from Day One is how similar in *appearance*
it is to using the UNIX *ROFF tools. It's bugged me mostly because I
could do things in ROFF that you can't do in HTML, like centering text,
changing font, etc, and I won't pretend that I fully understand the need
for SGML. Suffice it to say that ROFF was never structured ;-) so I
didn't complain too much.
My only point here is that in ROFF, you could do all these things that
would look one way when you TROFF'ed the document to a postscript
printer (say), and it would *still* be displayed on your VT100 using
NROFF. Everything -- including maps and equations -- could be displayed
on VT100/postscript (they did NOT look anything alike, but we're not
arguing about that, are we?)
So there's nothing stopping LYNX from still working -- as long as
documents are (mostly) designed not to depend too much on page layout.
And *nothing* *no text* *anywhere* is totally independent of page layout
-- not from your LaTEX document to your ASCII FAQ -- and if some
advanced HTML lets you make itty-bitty 7-point fonts, and you use them
to make a poetic point, then hey, Lynx *won't* be able to do it justice.
I'd say *fonts* are less a problem right now than needing to do anything
snazzy with images (and then duplicating it in text...)
As for extending a standard...see above bugged point on ROFF ;-) It's
*hard* waiting for something for a couple of years now to catch up what
we all already know what to do -- e.g. page layout. On the other hand...
see earlier posts griping about XMosaic's wacky-sometimes-HTML-
willingness-to-parse-anything, causing grief for anyone else...
Roger
David Staschover
I wrote:
: > What I find *very* annoying is that I create an html page one way, using
: > WinMosaic as my testing client, only to find that when I view it using
: > Winweb, Cello or Air Mosaic, it comes out differently. There are so many
: > inconsistancies currently with the html browsers that are out there. It
: > doesn't seem to be a standard at all anyway... Each browser has its own
: > quirks..
Eric replied:
: Umm... As it has been explained to me, this is supposed to be a good
: thing. It is a different format on each browser, but the same
: text (and images). SGML explicitly doesn't want you to expect or
: be able to make a document that will look the same on all browsers.
: (Note, it might look the same if you are lucky, but you are explictly
: denied control in this area)
Specifically, the example I had in mind, was an html document, which
basically said:
TEXT
<img src=...>
In Mosaic, the text came first, and in Winweb, the image came first..
Looks like winweb went out of its way to reverse it :)
There are people who put alot of work into creating creative web pages,
only to be disappointed when another browser ruins their concept..
This happens to me all of the time..
I understand the reasoning, it's just annoying..
Maybe I'll switch to Acrobat..
=====================================================================
David Staschover | d...@panix.com | This space left
Long Beach NY | 7324...@compuserve.com | intentionally blank
=====================================================================
Richard Sexton
>Since when has the wisdom of the marketplace, or the Dollar
>as Almighty Oracle, ever represented the proper technical
>path to take?
Two words for you, buddy: "microsoft" and "windows". I chose a technical
path to take and developed Amiga software.
You may now stop laughing.
The fellows at Intuit, sleezy whores that they are chose a tehnical
decision to write for "Microsoft" and "Windows". They're millionairs,
as of last week.
>I'm curious to know how Marc suggests that text-based
>browsers like Lynx should interpret differently-sized fonts
>within a line.
So what?
Evolve, dammit.
--
Richard J. Sexton, ``Daydreaming must end now.'' VRx Network Services
Toronto, CANADA ric...@panchax.gryphon.com
Richard Sexton
>
>The point is that just about everything, if not actually
>everything, in the existing HTML standards can still be
>implemented on platforms ranging all the way to plain text
>browsers. Implementing font-change tags in an HTML
>extension limits that to a much smaller hardware population,
>and is sheer lunacy in this case.
Kinda depends which side of the font.fence you're sitting on
to determine which camp is guilty of lunacy, eh ?
Eamon Daly
: >I'm curious to know how Marc suggests that text-based
: >browsers like Lynx should interpret differently-sized fonts
: >within a line.
: So what?
: Evolve, dammit.
some of us can't afford to.
unless you'd like to pay for my new connection
kit.
i am really curious as to how netscape pages
appear on the various HTML-spec browsers. has
someone a URL so i may see for myself?
--
<sigh>
my handwriting's pretty bad... sorry about the signature.
<a href="http://acs2.bu.edu:3000/"> . . </a>
Thomas Boutell
Marc Andreessen <ma...@mcom.com> wrote:
>
>We've tried really hard to make sure the enhancements supported by
>Netscape 0.9 layer very transparently and cleanly on top of HTML as
>implemented by NCSA Mosaic for X 2.4 and not cause problems in other
>browsers. Browsers that cleanly ignore tags and attributes they don't
>understand shouldn't have problems (errors, etc.). At least a few
>network sites (including the Cool Page of the Day at infi.net [I think])
>are already serving pages that use the enhancements but also work
>fine with old browsers.
>
>We're publishing details on the enhancements with no restrictions
>whatsoever, so other browsers can certainly support these enhancements
>if they choose.
BINGO.
The right question to ask about any nifty enhancement to HTML is this:
"Does it prevent text-based browsers from presenting the document
understandably?"
If the answer is no, or if you can redesign the enhancement to make sure
the answer is no, then there is no reason not to go ahead and
add the enhancement.
Have a look at a NetScape-enhanced web page using another browser.
Don't have any problems understanding it, now do you?
If they had added free text placement at arbitrary locations
on the page, I would be throwing large objects in the general
direction of Mountain View, Calif. But they didn't do that.
They added a whole mess of really snazzy visual touches
without damaging the essentially linear nature of HTML.
Will the new tags become part of the standard? Sure they
will. The next release of any browser that wants to stay
afloat will include most or all of them.
A better question to ask of Mosaic Communications Corp.
is whether they will document their enhancements for
security and transaction processing, allowing other
browsers to use them and preventing a Tower of
Commercial WWW Babel from being constructed
out of straw and promptly burnt down by
Microsoft.
Now, excuse me while I finish packing and get to the airport.
It's going to be a fun week.
-T
Hey Marc, can we have a statically linked linux binary? I know
it's not a high-volume item, but jeez, do I have to boot Windows just to
play with this glorious toy at home? Windows is something I suffer
with at work, y'know? (Sniff)
--
bou...@netcom.com, purveyor of fine World Wide Web pages and tools.
Drop by comp.infosystems.www.users and learn about the web.
<a href="http://sunsite.unc.edu/boutell/index.html"><em>Thomas Boutell</em></A>
Kartik Subbarao
>Richard Sexton (ric...@interlog.com) wrote:
>: >I'm curious to know how Marc suggests that text-based
>: >browsers like Lynx should interpret differently-sized fonts
>: >within a line.
>
>: So what?
>: Evolve, dammit.
>
>some of us can't afford to.
Tough. Then get left behind in the dust.
Bill Arnett
> Marc Andreessen <ma...@mcom.com> wrote:
>We're publishing details on the enhancements with no restrictions
>whatsoever, so other browsers can certainly support these enhancements
>if they choose.
Just think what would happen if every browser implementor took that
attitude: we would have dozens of new little goodies none of which were
implemented by a majority of the browsers. How would a careful content
provider choose which goodies to use and which to avoid? Answer: he goes
with the common subset which then becomes the de facto standard. But he's
usually wrong (or out of date) about which goodies are in which browsers.
So his documents will be screwed up (or at least not what he intended) in
some environments. The less careful provider just tests with one browser
and ends up with an even worse mess. There will be many, many more of the
latter.
Making your "enhancements" backward compatible is necessary but not
sufficient. Unless the vast majority of browsers implement them, the user
will not see what the provider intended. Its bad enough already (I sure
wish mcom would fix the spacing of inline images in <ol></ol> lists). If
we all started using your new features things would look great with
Mozilla but not so great with everything else. I refuse to believe that
you intend such a result even though it might be an effective marketing
strategy.
If you don't like the way the standards committees are handling HTML why
don't you start up your own standards group comprised of the current
implementors? At this time there aren't really that many. Your influence
would be great. You could probably get everything Mozilla has done agreed
to in an hour or two. Then you could publish the "Interim Commerical HMTL
Standard" (or some such mumbo jumbo) and submit it to the IETF (or
whatever). While the IETF is arguing about it we could all enjoy a
standard environment in which to build our WWW content.
--
Bill Arnett bi...@netcom.com
San Jose, CA USA ftp://ftp.netcom.com/pub/billa/billa.html
Alex Lopez-Ortiz
> In article <marca-14109...@gator1.mcom.com>,
> Marc Andreessen <ma...@mcom.com> wrote:
> >
> >We've tried really hard to make sure the enhancements supported by
> >Netscape 0.9 layer very transparently and cleanly on top of HTML as
> >implemented by NCSA Mosaic for X 2.4 and not cause problems in other
> >browsers. Browsers that cleanly ignore tags and attributes they don't
> >understand shouldn't have problems (errors, etc.). At least a few
> >network sites (including the Cool Page of the Day at infi.net [I think])
> >are already serving pages that use the enhancements but also work
> >fine with old browsers.
> >
> >We're publishing details on the enhancements with no restrictions
> >whatsoever, so other browsers can certainly support these enhancements
> >if they choose.
>
> BINGO.
>
> The right question to ask about any nifty enhancement to HTML is this:
>
> "Does it prevent text-based browsers from presenting the document
> understandably?"
>
> If the answer is no, or if you can redesign the enhancement to make sure
> the answer is no, then there is no reason not to go ahead and
> add the enhancement.
WRONG!
There are other design considerations that need to be taken into account
before enhancing a system.
Some of the NetScape "enhancements" go counter to the philosophy of
HTML and SGML and in that sense they are "patches" rather than enhacements.
Alex
--
Alex Lopez-Ortiz alop...@neumann.UWaterloo.ca
Department of Computer Science University of Waterloo
Waterloo, Ontario Canada
http://daisy.uwaterloo.ca/~alopez-o/home.html
Marc Andreessen
> A better question to ask of Mosaic Communications Corp.
> is whether they will document their enhancements for
> security and transaction processing, allowing other
> browsers to use them and preventing a Tower of
> Commercial WWW Babel from being constructed
> out of straw and promptly burnt down by
> Microsoft.
That is precisely the correct question to ask, and the answer
is "yes".
Cheers,
Marc Andreessen
> Making your "enhancements" backward compatible is necessary but not
> sufficient. Unless the vast majority of browsers implement them, the user
> will not see what the provider intended. Its bad enough already
Yeah, I know. The world has gone straight downhill since we added
inlined images to Mosaic without official committee approval.
Mike Meyer
> In article <billa-15109...@billa.slip.netcom.com>, bi...@netcom.com (Bill Arnett) wrote:
>
> > Making your "enhancements" backward compatible is necessary but not
> > sufficient. Unless the vast majority of browsers implement them, the user
> > will not see what the provider intended. Its bad enough already
>
> Yeah, I know. The world has gone straight downhill since we added
> inlined images to Mosaic without official committee approval.
Considering that Mosaic's implementation of inlined images is one of
the major causes of ugly documents on the net, your comment rings very
close to true, no matter how sarcastic you were being.
No, I'm not talking about pages that include gobs of images just
because they can. I'm talking about all the pages that include images
with no consideration of other browsers, because you never bothered to
do anything with the ALT tag.
Of course, I really can't blame the ALT tag on you. Someone else
probably invented it, as the best solution to the design flaws of IMG,
as opposed to being able to do something real about it, ala IMAGE.
Note that the original implementation of IMG included "horrible
errors" according to you (at least, I assume that you're the "I"
mentioned in the description of these extensions) which leads to more
attributes for it, which people who didn't make those horrible errors
are going to have to figure out how to deal with.
I see no indications that these new ad hoc tags were any better
designed or implemented, and see no reason to expect better results
from them. So we'll probably get an increase in the number of pages
that are ugly in browser but Mo*.
<mike
Tim Pierce
Marc Andreessen <ma...@mcom.com> wrote:
>Yeah, I know. The world has gone straight downhill since we added
>inlined images to Mosaic without official committee approval.
Your point being?
Jamie Zawinski
>
> Hey Marc, can we have a statically linked linux binary? I know
> it's not a high-volume item, but jeez, do I have to boot Windows just to
> play with this glorious toy at home? Windows is something I suffer
> with at work, y'know? (Sniff)
You wouldn't believe how many requests we've been getting for a Linux version.
We'll have one just as soon as I get it installed on my machine...
-- Jamie
Snowhare
: In article <marca-14109...@boulanger.mcom.com>,
: Marc Andreessen <ma...@mcom.com> wrote:
: >Charming, and a bit nonlinear; Peter, are you ever going to
: >actually acknowledge that most real content providers are highly,
: >highly concerned with the appearance of their documents?
: So what?
: >Or are you always going to pretend that people who insist on
: >divorcing appearance from content at all times are anything but
: >a tiny but highly vocal minority in the real world?
: So what?
Tim - as charming as "So what?" is - it represents a total lack of
content. "And so's your mother". I know you - you can do much better than
that.
: Since when has the wisdom of the marketplace, or the Dollar
: as Almighty Oracle, ever represented the proper technical
: path to take?
Since the market determines ultimately whether anyone will USE a
technical solution. "Code Purists" create monstrosities that
are worthless to the one audience that matters - the people who have to
use it. Pascal did not become a useful (or particularly used) language
until its "purity" was heavily "corrupted" by people who needed to
actually get work done. Its "purity" was an active impediment to doing
anything useful with it.
HTML purists appear dedicated to the proposition that the browser
should determine all of the final layout - with virtually *no* regard for
what the document creator wanted. My - and many others - solutions to
this DEFECT in HTML are bandwidth intensive: inline images that are
*exactly* what I wanted. If I want a grey 48 point italicized word
centered between small graphics images - the HTML purists left me no
option but to create a huge GIF file rather than two tiny gifs and
about 20 bytes of text. Because I can't control the final layout
otherwise.
Has Netscape tromped on the "standards" peoples toes? Yes.
Was it a good or a bad thing? Time (and the market) will tell.
Personally - I am VERY impressed with Netscape. It has delivered what
NCSA has been vaguely promising for a long time in a solid, useful and
mostly bug free package. I had nearly despaired of finding a useful web
browser:
Lynx - No graphics. Odd interpretations of conventional HTML.
I have written legitimate HTML that makes text vanish
en mass under lynx. The offending HTML?
<HEAD>Blahblah</HEAD>!
MacWWW - Ugh. Lynx in a plain Mac wrapper - minus the useful
features.
NCSA Mosaic - What works is obsolete; what isn't obsolete, doesn't work.
MacWeb - Haven't tried it yet. *Was* next on my list to try.
Netscape Mosaic - Killer app. The only problem I have had to date is that
the temporary folder settings doesn't work: Everything
ends up in Netscape's home folder (a real problem in a
networked environment). And the caching is not as
effective as I would like. Graphics seem to be fully
cached, text doesn't seem to cache as well - it seems
to be reloading text a lot of the time.
--
Benjamin Franz
Snowhare
: Some of the NetScape "enhancements" go counter to the philosophy of
And there are many who feel the "philosophy of HTML and SGML" of taking
away creative/artistic control of display from the author of a document is a
major defect in HTML and SGML. I want my document to look the way *I*
designed it.
--
Benjamin Franz
Bill Arnett
(Marc Andreessen) wrote:
> In article <billa-15109...@billa.slip.netcom.com>,
bi...@netcom.com (Bill Arnett) wrote:
>
> > Making your "enhancements" backward compatible is necessary but not
> > sufficient. Unless the vast majority of browsers implement them, the user
> > will not see what the provider intended. Its bad enough already
>
> Yeah, I know. The world has gone straight downhill since we added
> inlined images to Mosaic without official committee approval.
That was then, this is now. Back then when there were only a couple of
browsers and a few hundred people who had ever heard of WWW it was OK, in
fact it was desireable, to experiment and see what works. But now you
have a much different situation. There are millions of people and real
money involved. That fact alone forces you to slow down and move
cautiously and to consider social as well as technical factors. WWW will
be with us for decades. A few more weeks now to get it right will be well
worth it in the long run.
As one of the "founding fathers" of WWW you have a special responsibililty
to the community. You have a rare opportunity to significantly influence
the course of the development of what could become a dominant factor in
our whole society. Don't mess it up with hasty, or worse arrogant,
decisions and sarcastic postings.
BTW, I am no SGML/HTML expert. I am quite willing to defer to those who
are. What I object to is the unilateral nature of these changes. Further
on in the posting you quoted, I suggested a quickie standards approach.
What say you to that?
Tim Pierce
Snowhare <snow...@xmission.com> wrote:
>Tim Pierce wrote:
>
>: >Or are you always going to pretend that people who insist on
>: >divorcing appearance from content at all times are anything but
>: >a tiny but highly vocal minority in the real world?
>
>: So what?
>
>Tim - as charming as "So what?" is - it represents a total lack of
>content.
Only to those who aren't reading for it.
The question at hand is whether the HTML extensions that
Mosaic Communications Corp. has implemented are wise or
proper additions to the standard. Marc's response to these
questions is to invoke the customers knocking down his door
and the HTML purists who don't live in the "real world" --
an incredibly snide allegation, I might add, for someone who
put himself where he is now through working at a university.
(!)
This dialogue gives me the impression that Marc and Jim
Clark view their current enterprise as not unlike managing a
doughnut shop. There are several other doughnut shops in
the neighborhood, so to produce a competitive product they
perform a lot of hard work and come up with a better-baked
doughnut.
Bully for them.
The problem is that we're not working in doughnuts; we're
not working in a marketplace of goods and artifacts. We
deal in communication, connectivity, and compatibility.
What Marc and Jim view as simply producing a better, more
competitive product in this case has dramatic effects on
those issues of communication, connectivity, and
compatibility. If we were producing doughnuts these issues
wouldn't be present, because I don't have to worry about my
powdered sugar being compatible with his honey frosting, or
my flour having the same endianness as his.
Marc has not only produced a more competitive product. He
has forced the issue of HTML platform compatibility. If
people use his HTML extensions to the point that their pages
begin to look meaningless on other platforms, then it hardly
matters whether NetScape itself is a superior product.
The short form of all this, when someone brings up the
demand of the consumers, is, "So what?" I hope you
understand why I do not feel motivated to produce all this
effort on each of those occasions.
>HTML purists appear dedicated to the proposition that the browser
>should determine all of the final layout - with virtually *no* regard for
>what the document creator wanted.
That's exactly right. What the HTML document creator
"wants" in terms of appearance is minimal. Your criticism
of HTML is identical to every other I've ever heard -- you
don't like it because it's not a page description language.
That's great. I don't like my Toyota either because it's
not a Cessna, but you don't see me firing off letters to
Toyota demanding that they put wings on it.
>My - and many others - solutions to
>this DEFECT in HTML
It's not a defect in HTML. It is a defect in your incorrect
expectations of the language.
If Mosaic and their customers wish to implement Display
PostScript in the World-Wide Web to achieve their desired
effects, I think that's an excellent idea. I object to the
fact that their co-option of HTML is likely to make the
language less usable for my purposes.
Marc Andreessen
> BTW, I am no SGML/HTML expert. I am quite willing to defer to those who
> are. What I object to is the unilateral nature of these changes. Further
> on in the posting you quoted, I suggested a quickie standards approach.
> What say you to that?
I'm very interested in participating in any standards process that
results in at least moderately rapid innovation in directions that
make sense. (Well over a year of committee discussion has resulted in
no new capabilities beyond what NCSA Mosaic supports, and a good chunk
of that we added without permission, because users were demanding it.)
Failing such standards processes, we will introduce new capabilities as they
are requested by our users and required by our customers, and then document
them openly so others can create other implementations and do anything else
they choose. I fail to see what is unreasonable about that path; if we
don't follow it, we may as well just call the whole company off and hold
our going-out-of-business sale now.
Bill Arnett
One of the new enhancements is the VSPACE modifier to the IMG tag. This
allows the html writer to control the vertical spacing around an image.
Prior to the advent of Netscape, I created a couple of hundred instances
of html constructs like this:
<ol>
<li> <img alt="" align=middle src="foo.gif"> foo
<li> <img alt="" align=middle src="bar.gif"> bar
</ol>
It looked just fine in all browsers I had access to. Then along came
Netscape. By default Netscape renders the two images with no vertical
space between them which is extremely ugly and often, in my case, even
misleading as it makes it appear that the two images are one. The "easy"
solution is to change it to:
<ol>
<li> <img alt="" align=middle vspace=2 src="foo.gif"> foo
<li> <img alt="" align=middle vspace=2 src="bar.gif"> bar
</ol>
which is, no doubt, OK with all the other browsers out there but its a LOT
OF WORK for me which I will have to undo and do again if the final
standard does not accept this syntax. More seriously, it is an example of
Netscape NOT being totally backward compatible as it is so loudly
proclaimed to be. (BTW, I reported this as a bug at about the beta 7
level.)
Now, I'm sure that a little tweaking can fix this (and curiously, it only
fails with align=middle). Perhaps its just plain a bug and not due the
the language chanage after all. But the point remains that changing the
html language without careful review can cause a lot of trouble in
unanticipated ways.
Michael Lee
I'm going to propose something obnoxious.
Some people want a markup language that is a physical markup. "Let us serve
Postscript" or an *roff style.
Some people want a markup language that is a logical markup.
There are good but different reasons for both. So why not have both? Two
HTML variants, HTPML and HTLML, for lack of better names. They could be
distinct MIME types, and browsers react differently to both of them. Yes,
I've made everyone's life a lot more complicated, but then you could choose
the "style" of document that works best for your purpose. They could both
be based on HTML, so an older browser could treat them as HTML, ignoring
what it doesn't understand. The physical one could be as specific as
necessary, down the the color of the backdrop for all I care. The logical
one could do whatever logical requirements are necessary to allow
applications that want to take advantage of logical markup (Information
Retrieval services spring to mind).
Yes, it does mean three languages (because HTML wouldn't go away), but
that's what we're looking at anyways, with MCom's additions, HTML+, HTML
2, HTML 3 and whatever.
The two lines of thought are so directly opposed, I can't see how _one_
markup language will do the job.
Just some random thoughts...
--
Michael G. P. Lee "The path to the web becomes deeper and wider"
mich...@coyote.cs.wisc.edu - October Project, "Paths of Desire"
mgl...@students.wisc.edu
<A HREF="http://coyote.cs.wisc.edu:1213/">My home page</A>
Shiva Shenoy
Yes! Thanks, Thanks....Do consider including TERM support in the Linux binary.
--
----------------------------------------------------------------------
Shiva Shenoy Aerospace Engineering and Engineering Mechanics
she...@iastate.edu 2066 Black Engineering Building
http://www.public.iastate.edu/~aeem/ Iowa State University
Office: (515)294-0092 Ames, Iowa 50011, USA
Tim Pierce
Marc Andreessen <ma...@mcom.com> wrote:
>Failing such standards processes, we will introduce new capabilities as they
>are requested by our users and required by our customers, and then document
>them openly so others can create other implementations and do anything else
>they choose.
I'm curious about something. Why, in order to implement
line centering, did you choose to create a new <CENTER> tag,
rather than merely implementing a <P ALIGN=CENTER> tag as
implemented in the HTML+ draft? Granted, it isn't standard,
but it's certainly closer to a standard than what you've
done. Wouldn't that be more consistent with such practice
as already exists?
marduk
I think all web page authors should do the community a favor by not
supporting unstandardized HTML tags and parameters. This is the only
we are going to convince the makers of WWW browsers that what we want
and need is an open standard, and not a hundred WWW browsers that
support their own version of HTML.
If vendors have ideas in which to improve HTML, they should try having
it contributed to the open standard *before* implementing a
proprietary format on their browsers.
Just my $.02,
Marduk
Earl Hood
Snowhare <snow...@xmission.com> wrote:
>Alex Lopez-Ortiz wrote:
>: Some of the NetScape "enhancements" go counter to the philosophy of
>: HTML and SGML and in that sense they are "patches" rather than enhacements.
>
>And there are many who feel the "philosophy of HTML and SGML" of taking
>away creative/artistic control of display from the author of a document is a
>major defect in HTML and SGML.
Let's remind ourselves of a few things before we go on:
o WWW does NOT equal HTML
o WWW (thru HTTP, FTP, gopher) allows the abiltity to provide
all types of data: images, video, audio, text, etc, and yes,
HTML.
HTML was designed to allow information providers using the WWW to
serve hypertext documents easily w/o learning a complex markup
language.
Now, for those who like complete control in how their documents will
look, then use PostScript (or some other language) that will serve your
needs. Nothing is stopping WWW clients from directly supporting
PostScript or other page description languages. So, instead of
'bastardizing' a language that people tend to forget what its intent
is, use another launguage. Remember, HTML is ONLY one of the many
content-types that the HTTP protocal (WWW) supports. You have a
choice.
I'm not advocating that HTML stay static. I welcome enhancements to
HTML that improve it as a markup language, but HTML is (will be) a
standard. And changes to it should be officially approved. You don't
see people make arbitary changes other standards: ANSI C,
MIME, TCP/IP, etc, just to suit a particular need: "Oh, people
have been demanding set operations, like Pascal, in C, so I decided
to add the support to our compiler."
Standards serve a purpose: interoperablility. If you are not
satisified with HTML, choose something else. It's not like there are
no other document description languages available.
>I want my document to look the way *I* designed it.
Then don't use HTML. HTML is structured language that allows some
formatting hints (more formatting markup exists in HTML+). The beauty
of HTML, is that it is simple (compared to other document description
languages) to render and leaves all the tough descisions about fonts,
color, etc, to the client (which makes HTML documents small and and
less time to transmit). Since WWW connects machines of all types, HTML
allows quick and easy dissemination of information.
--ewh
P.S. BTW, nothing prevents one using SGML as a typesetting markup
language. However, since such languages already exist (PostScript,
TeX), it is not normally used for such a purpose.
----
Earl Hood | CONVEX Computer Corporation
eh...@convex.com | 3000 Waterview Parkway
Phone: (214) 497-4387 | P.O. Box 833851
FAX: (214) 497-4500 | Richardson, TX 75083-3851
Kartik Subbarao
From everything I've read here, it is NOT proprietary in the least bit.
Don't try to confuse MCom with some other company beginning with M.
-Kartik
Ken McCarthy
Organization: NETCOM On-line Communication Services (408 261-4700 guest)
Marc Andreessen (ma...@mcom.com) wrote:
> I'm very interested in participating in any standards process that
> results in at least moderately rapid innovation in directions that
> make sense. (Well over a year of committee discussion has resulted in
> no new capabilities beyond what NCSA Mosaic supports, and a good chunk
> of that we added without permission, because users were demanding it.)
> Failing such standards processes, we will introduce new capabilities as they
> are requested by our users and required by our customers, and then document
> them openly so others can create other implementations and do anything else
> they choose. I fail to see what is unreasonable about that path; if we
> don't follow it, we may as well just call the whole company off and hold
> our going-out-of-business sale now.
To people worried about standards at this early stage in the game:
The original standard for electricity in the home was DC. JP Morgan
was the first lucky consumer to get this service - it almost
burned his house down several times - courtesy of Thomas Edison who
complained *bitterly* when Tesla and Westinghouse had the gall to
offer AC to the public. Aren't you glad they just went ahead and
offered AC without Edison's permission, approval, or blessing?
Why on earth would anyone want to formalize NCSA Mosaic as a standard? My
understanding is it was a first try and nobody expected it to take off
so quickly, so massively. Do you really want to let historical
"accidents" set our standards for us esp. when the original tool makers
stand by eager, ready, and capable of making *massive* improvements? Does it
make sense to handcuff Marc & co. and unnecessarily delay the improvements
people have been asking for? How long would you propose they wait?
Some of the things I'm reading here are a little like the complaints of
the guy who is to getting dimes, suddenly getting a dollar and
bitching because now he has to make change.
My hope is that they will continue to annoy and dismay us with unauthorized
improvements!
Ken McCarthy
E-Media
Peter Flynn
HTML purists appear dedicated to the proposition that the browser
should determine all of the final layout - with virtually *no* regard for
what the document creator wanted.
Wrong, wrong, wrong. No-one I know on the "purist" side has even said
this. All that's needed is for the stuff to be implemented in a sane
and rational way, to let those people who want control over the
appearance to be able to do it properly, eg <h1 placement=center>
rather than a <center> tag on its own, which is pointless.
this DEFECT in HTML are bandwidth intensive: inline images that are
*exactly* what I wanted. If I want a grey 48 point italicized word
centered between small graphics images - the HTML purists left me no
option but to create a huge GIF file rather than two tiny gifs and
about 20 bytes of text. Because I can't control the final layout
otherwise.
Right. you should be able to say
<p placement=center><img src="file1.gif"><hilite color=gray
shape=italic size=48>word</hilite><img src="file2.gif"></p>
or something like it (you'd have to have a way to specify what you
mean by "center" though, if the images are different widths: does it
mean "center the word in the screen-width regardless of the widths of
the images" or "center the word in the remaining space between the two
images").
I've been trying to explain for years that SGML (and therefore HTML)
is perfectly capable of this and anything else you want. OK, so there
is a need to control what goes in the spec to _some_ degree, otherwise
we'd end up with a kitchen sink.
What seems strange is for a company with as many good people as MCom
to go off at a tangent and invent a new lanmguage which is not
compatible with HTML.
Has Netscape tromped on the "standards" peoples toes? Yes.
Was it a good or a bad thing? Time (and the market) will tell.
Sure.
Personally - I am VERY impressed with Netscape. It has delivered what
NCSA has been vaguely promising for a long time in a solid, useful and
mostly bug free package. I had nearly despaired of finding a useful web
browser:
NetScape is an excellent browser, I have nothing but praise for
it. It's the weird language they propose as the extensions that I
think needs looking at.
Lynx - No graphics.
This is silly. Lynx is a character-mode browser, of course it doesn't
do graphics. This is a bit like complaining that a car won't behave
like an aeroplane.
Odd interpretations of conventional HTML.
I have written legitimate HTML that makes text vanish
en mass under lynx. The offending HTML?
<HEAD>Blahblah</HEAD>!
Yes, there are still some oddities...
///Peter
--
Peter Flynn | pfl...@curia.ucc.ie | ...persuade users that spreading
Computer Centre | +353 21 276871 x2609 | fonts across the page like peanut
University College | +353 21 277194 (fax) | butter across hot toast is not the
Cork, Ireland | Opinions are my own. | route to typographic excellence...
Alex Lopez-Ortiz
> snow...@xmission.com (Snowhare) writes:
>
> >Alex Lopez-Ortiz wrote:
> >: Some of the NetScape "enhancements" go counter to the philosophy of
> >: HTML and SGML and in that sense they are "patches" rather than enhacements.
>
> >And there are many who feel the "philosophy of HTML and SGML" of taking
> >away creative/artistic control of display from the author of a document is a
> >major defect in HTML and SGML. I want my document to look the way *I*
> >designed it.
>
>
>
> There are good but different reasons for both. So why not have both? Two
> HTML variants, HTPML and HTLML, for lack of better names.
That is a step in the right direction. What is actually needed is a way
to allow authors bigger control over the physical interpretation of a
tag, or even let them define their own tags together with their page layout
interpretation (or physical markup) if needed. There are several other
reasons why authors should be given the freedom to define their own
tags, but I won't go into them just yet.
That way we would know that all tags (or at least most of them) denote
content, and btw, they may have a very specific physical representation
when viewed.
> They could be
> distinct MIME types, and browsers react differently to both of them. Yes,
> I've made everyone's life a lot more complicated, but then you could choose
> the "style" of document that works best for your purpose. They could both
> be based on HTML, so an older browser could treat them as HTML, ignoring
> what it doesn't understand. The physical one could be as specific as
> necessary, down the the color of the backdrop for all I care. The logical
> one could do whatever logical requirements are necessary to allow
> applications that want to take advantage of logical markup (Information
> Retrieval services spring to mind).
>
> Yes, it does mean three languages (because HTML wouldn't go away), but
> that's what we're looking at anyways, with MCom's additions, HTML+, HTML
> 2, HTML 3 and whatever.
I'm working in something of the sort.
> The two lines of thought are so directly opposed, I can't see how _one_
> markup language will do the job.
Right! We need two languages, content tagging on top of a page description
language.
> Just some random thoughts...
Within the next few months, I'll make available a beta version of the
implementation of some of those "random thoughts".
If you would like to receive a copy of it (is in Motif) send e-mail.
Alex Lopez-Ortiz
As it has been pointed elsewhere, making a rigamarole of HTML is not
the way to satisfy your legitimate demand.
Let's keep content and page layout tags separate!
Mike Meyer
> I'm very interested in participating in any standards process that
> results in at least moderately rapid innovation in directions that
> make sense. (Well over a year of committee discussion has resulted in
> no new capabilities beyond what NCSA Mosaic supports, and a good chunk
> of that we added without permission, because users were demanding it.)
That's not true - lots of browser have capabilities that NCSA Mosaic
doesn't support; some even have capabilities that NetScape apparently
doesn't support. They even managed to do it while working WITH the
standards process. Their authors now get to decide whether they are
going to duplicate functionality to support the current kludges, or
have providers who don't know any better try and convince people to
quit using their browser.
Even if this statement is true, consider who's at fault. You - both
personally, and the company - are amongst the major players of the
game. What have you - either personally, or the company - done to
further the standards process?
> Failing such standards processes, we will introduce new capabilities as they
> are requested by our users and required by our customers, and then document
> them openly so others can create other implementations and do anything else
> they choose. I fail to see what is unreasonable about that path; if we
> don't follow it, we may as well just call the whole company off and hold
> our going-out-of-business sale now.
Nothing is unreasonable about the path, if your highest priority is
making as much money as possible. If the WWW community is of any
concern, you should be working with the standards process, not against
it.
<mike
Peter Flynn
>I'm curious - do the new enhancements include <LI> not needing to be
>in a list of some kind, did that change in HTML while I wasn't
>looking, or is the HTML on the MCOM home page bogus?
If that's the case, then it must also be okay to have more than one <DT>
before a <DD> within a glossary. Netscape simply shows more than one
term before the definition. But other browsers like Lynx get confused by
this and drop text on the floor. Whole links within MCOM pages are
inaccessible by non-Netscape browsers because of this, and I don't think
that was intended.
Think again.
Eric Hagen
: In <JWZ.94Oc...@neon.mcom.com> j...@mcom.com (Jamie Zawinski) writes:
: >Thomas Boutell <bou...@netcom.com> wrote:
: >> Hey Marc, can we have a statically linked linux binary? I know
: >> it's not a high-volume item, but jeez, do I have to boot Windows just to
: >> play with this glorious toy at home? Windows is something I suffer
: >> with at work, y'know? (Sniff)
: >You wouldn't believe how many requests we've been getting for a Linux version.
: >We'll have one just as soon as I get it installed on my machine...
: > -- Jamie
: Yes! Thanks, Thanks....Do consider including TERM support in the Linux binary.
: --
YES!
I will add my own blessing to a linux binary, The Mosaic 2.4 binary that
has been released intergrated the support for a regular network
connection, PPP and SLIP, and TERM. Needless to say the Linux group is
not to be overlooked.
Eric
ja...@the-wire.com
>Some people seem to be assuming that we're deliberately forking the road
>here, but folks, there isn't a whole lot out there right now in terms of
>innovation happening in design-by-committee environments, and I am finding
>it hard to figure out how to move forward with new functionality for
>which customers are pounding down our doors at any reasonable rate of
>speed without simply doing what it takes to get the functionality
>working and in parallel openly documenting the results (as happened with
>both inlined images and forms in Mosaic the first time around). Ideas as
>always are welcome.
Marc, as an end user of Netscape, all I can say is: "Keep up the good work."
Your program is going to cut my online costs quite substantially. As far as
I'm concerned, *you people* have set the standard. Let the others catch up.
The only complaint I have about your program is that I get a total system
crash if I try to paste into the open new url box *while* another html load is
still going on. Minor in my estimation as all I have to do is avoid above
scenario.
- Jack
Bill Spurlock
>: Plus, users may become disgruntled when later revisions of the HTML
>: standard includes markup to handle the features that MCom has added,
>: but the markup is not the same. Users will have to spend time and
>: effort to translate MCom HTML to standard HTML. As a provider of HTML
>: documents, I plan to stick with the standard inorder to avoid future
>: maintenance headaches.
I'll second this notion here. I will not encourage any of my current or
perspective clients to go with the MCom HTML. In the event that these
additions to HTML do become a part of the standatd HTML, then at that time I
will rethink my position.
Bill Spurlock
SpiderWEB Graphics
Zeus Paleologos
> You may be interested in this blurb from Gary Wolf's Mosaic
> article in the October WIRED:
> The reason [SPRY's Chris] Wilson and other Mosaic
> developers have not heard much from Mosaic Communications
> lately, Andreessen admits, is that a unified standard is
> not of first importance to the company. "Our major
> concern is our products," he says. "On top of that, we
> would like to be in an open environment, where other
> browsers could read our documents. It makes companies and
> consumers more willing to buy in. But it can't be our
> primary concern."
Of course. An attempt to enforce standards on an immature technology
will always fail. At some point, one of two things will likely happen:
A particular implementation of the technology will dominate and will
then become the standard de facto. Or, the purveyors of competing
implementations will negotiate something formal that everyone needs
and can live with. Ultimately, the marketplace will decide.
--
"Past success guarantees only opportunity, not future results." --ZP
Mike Meyer
> Odd interpretations of conventional HTML.
> I have written legitimate HTML that makes text vanish
> en mass under lynx. The offending HTML?
> <HEAD>Blahblah</HEAD>!
>
> Yes, there are still some oddities...
Wait a minute - what's odd about this? <HEAD> isn't supposed to
contain text to be displayed. Your HTML isn't legitimate, and Lynx is
on perfectly valid ground to fail to display said text. No, Mosaic may
display it, but "Works in Mosaic" and "is legitimate HTML" have never
been synonyms.
<mike
Liam R. E. Quin
> Taking a look at some "Netscape Friendly" HTML, I've noticed a whole
> bunch of new tags. :) Are these tags in the 2.0 spec or is MCC trying
> to redfine HTML?
[...]
el...@nova.gmi.edu (R. Stewart Ellis) writes:
> Yeah. I wonder what HotMetal does with some of the non-standard, illegal
> stuff? :}
It rejects it, of course. HoTMetaL PRO will include a filter that will
automatically delete such spurious markup so that you can produce documents
that conform to the HTML 2.0 draft.
To be fair, I have asked Marc Andreeson for the DTD they are using (if it
even exists); if we get a reply soon enough, it's _possible_ that we could
offer support for it. But it's unlikely for this release of HoTMetaL PRO,
we're hoping to ship next week, after many miserable delays...
However...
the whole purpose of standardising something is not to slow down progress;
it is to ensure interoperability.
SGML documents will live on long after RTF and MIF and NetScope are forgotten,
because it's an international standard format. Vendors (including
SoftQuad Inc.) are committed to supporting such standards as SGML.
A standardised HTML will allow conformance testing for interoperability
and longevity of documents.
It is not at all clear to me that we would be serving the WWW community well
by supporting anything other than HTML 2 right now.
Lee
--
Liam Quin, Manager of Contracting, SoftQuad Inc +1 416 239 4801 l...@sq.com
HexSweeper NeWS game;OPEN LOOK+XView+mf-fonts FAQs;lq-text unix text retrieval
SoftQuad HoTMetaL: ftp.ncsa.uiuc.edu:Web/html/hotmetal, and also doc.ic.ac.uk:
packages/WWW/ncsa/..., gatekeeper.dec.com:net/infosys/Mosaic/contrib/SoftQuad/
Casey Barton
>*exactly* what I wanted. If I want a grey 48 point italicized word
>centered between small graphics images - the HTML purists left me no
>option but to create a huge GIF file rather than two tiny gifs and
>about 20 bytes of text. Because I can't control the final layout
>otherwise.
Ok, and suppose I want to view your page on my vt100 terminal? I'm screwed.
Oh, what's that? VT100 is obsolete and composes only a small percentage
of users? Ok.
How about my PDA? If you don't think the Newton and/or it's successors are
going to be a force to be reckoned with in the future of online data access,
you're not thinking straight.
A 48 point font is going to be reasonable on my 1280*1024 windows box,
but how's it going to look on my TV, via the set top internet box?
Listen up: There is *is no* common denominator for computer displays. If
you tailor a page to look just perfect on one person's screen, you're
*guaranteeing* that it's going to look like crap on someone else's.
--
| Casey Barton (a guy) ceba...@napier.uwaterloo.ca (519)746-9832 |
| http://calum.uwaterloo.ca/u/cebarton |
David Carmean
> >Taking a look at some "Netscape Friendly" HTML, I've noticed a whole bunch of
> >new tags. :) Are these tags in the 2.0 spec or is MCC trying to redfine HTML?
> >I actually like some of the new formatting directives, and I'm curious what
> >editors people are using.
> >Gavin Adams
> >-----------------------------------------------------------
> >Digital Consulting Sandia National Laboratories
> >Gavin...@aqo.mts.dec.com gad...@sandia.gov
> >+1 505 343 7200 +1 505 844 3897
> >-----------------------------------------------------------
> Yeah. I wonder what HotMetal does with some of the non-standard, illegal
> stuff? :}
It won't load it, even with rules checking off. (I tried with MS-Windows
version.)
> --
> R.Stewart(Stew) Ellis, Assoc.Prof., (Off)313-762-9765 ___________________
> Humanities & Social Science, GMI Eng.& Mgmt. Inst. / _____ ______
> Flint, MI 48504 el...@nova.gmi.edu / / / / / /
> Gopher,chimera,nn,tin,jove,modems, free code is best!/________/ / / / /
--
David L. Carmean, WB6YZM. | I am just an advertisement--
car...@coyote.rain.org, | for a version--of myself!
usap...@ibmmail.com (work) | --David Byrne
Gary Goldberg
: Why on earth would anyone want to formalize NCSA Mosaic as a standard? My
: so quickly, so massively. Do you really want to let historical
: "accidents" set our standards for us esp. when the original tool makers
: stand by eager, ready, and capable of making *massive* improvements? Does it
: make sense to handcuff Marc & co. and unnecessarily delay the improvements
: people have been asking for? How long would you propose they wait?
I haven't seen anyone mention this, but perhaps the problem is that
NetScape is a commerical product, publicly released betas notwithstanding.
If a new version of Mosaic came out, with the source code, containing
these enhancements, I would imagine there would be less outcry, because
then you know everyone who wants it could get it. Even without the source
code, as long as everyone could get it.
As it stands now, even if Netscape gets 25% market penetration, only a
quarter of the available audience can read the enhanced documents
properly.
Please don't misunderstand me - I think the netscape beta is a fine
product and I'm making plans to purchase the final release. But I want my
documents to
as widely available as possible, even down to the schools if Mr. Gore gets
his way. To me, that dictates that I follow the specs.
Of course, if the developers of the other browsers (Lynx, Mac/WinWeb,
Mosaic, etc., are planning to update with these extensions soon, it
changes the whole complexity of the situation. I'm most concerned with de
facto standards. -G
--
.sig under construction - do not use 2-way radios during daylight.
Gary Goldberg KA3ZYW o...@digimark.net (301) 249-6501
DigiMark [Bowie, MD] WWW: http://www.digimark.net/ in...@digimark.net
Jamie Zawinski
>
> Whole links within MCOM pages are inaccessible by non-Netscape browsers
> because of this, and I don't think that was intended.
>
> Think again.
Boy, I think for Halloween I'll just go as "Mosaic Communications."
That sure seems to scare the pants off of Peter here.
Once more, with feeling: one of our top priorities was to be compatible
with existing browsers, in particular, NCSA xmosaic.
Hell, doing otherwise doesn't even make good *business sense*, especially
in the case of the content on our server. Can you see any benefit to
making people not already using our product be unable to *find out* about
our product?? "Think again" indeed!
-- Jamie (not to be confused with SATAN)
Bryan Oakley
>
> One of the new enhancements is the VSPACE modifier to the IMG tag. This
> allows the html writer to control the vertical spacing around an image.
> Prior to the advent of Netscape, I created a couple of hundred instances
> of html constructs like this:
> It looked just fine in all browsers I had access to. Then along came
> Netscape. By default Netscape renders the two images with no vertical
> space between them which is extremely ugly and often, in my case, even
> misleading as it makes it appear that the two images are one. The "easy"
> solution is to change it to:
> which is, no doubt, OK with all the other browsers out there but its a LOT
> OF WORK for me which I will have to undo and do again if the final
> standard does not accept this syntax. More seriously, it is an example of
> Netscape NOT being totally backward compatible as it is so loudly
> proclaimed to be. (BTW, I reported this as a bug at about the beta 7
> level.)
Perhaps it is your document that is buggy. (warning: I'm of the "content-
is-best, presentation-is-up-to-the-browser" camp). You obviously depended
on the implementation of a specific set of browsers and "hard-coded" your
document to look good for them. Along comes an (arguably) improved browser
that chooses different, maybe better maybe worse method of rendering and
your hard-coded document is coming back to haunt you.
This is exactly why writing for presentation is bad. The HTML spec never
said that vertical space is required between images and text, or images
and images or whatever.
I guess I'm invitin' flames, but gosh, we all need a bit more patience
with this technology.
But then again, I throw in the odd <P> where it doesn't belong myself.
If only browsers would support robust style sheets so I could decide for
myself that I prefer 1/2 line of whitespace between <LI>'s instead of
whatever the browser implementor wanted...
Ade Rixon
> understanding is it was a first try and nobody expected it to take off
> so quickly, so massively. Do you really want to let historical
> "accidents" set our standards for us esp. when the original tool makers
> stand by eager, ready, and capable of making *massive* improvements? Does it
> make sense to handcuff Marc & co. and unnecessarily delay the improvements
> people have been asking for? How long would you propose they wait?
Why formalise the second try then? Another historical "accident". Marc has
already admitted to mistakes in his first attempt (eg. with the img
directive); why formalise the mistakes he's bound to make (by human nature)
in his second go?
HTML is too important to let one person or company set the pace and then
force the rest of us to live with their errors. I sympathise that the
current rate of progress is far too slow; if companies didn't go ahead and
produce their own ideas then we would never have had much of the technology
we take for granted in computing today. On the other hand, it worries me
that these ideas can be adopted impatiently and without too much question
- without proper standards control, you end up with a de-facto disaster
like MS-DOS. :-)
The extensions that Marc has made mostly answer real needs - no SGML
cultist is going to tell me I shouldn't be able to centre text in my own
documents - but we shouldn't accept them as they are. What are the real
needs and has Marc answered them effectively? From some of the comments
made here, I don't believe he has.
> My hope is that they will continue to annoy and dismay us with unauthorized
> improvements!
You're crazy.
Ade_
/
--
| Ade Rixon,Systems Support,UW Aberystwyth | http://www.dcs.aber.ac.uk/~ajr/ |
No, I do not have an attitude problem - it's my attitude and your problem.
Snowhare
: Snowhare <snow...@xmission.com> wrote:
: >*exactly* what I wanted. If I want a grey 48 point italicized word
: >centered between small graphics images - the HTML purists left me no
: >option but to create a huge GIF file rather than two tiny gifs and
: >about 20 bytes of text. Because I can't control the final layout
: >otherwise.
: Ok, and suppose I want to view your page on my vt100 terminal? I'm screwed.
Wrong. As my Anime page <http://www.cc.utah.edu/~bf6515/anime.html> actually
reads:
<img src="anime/anime.gif" alt="Anime">
I actually write to accomodate most people - but I want people to be able to
see what I wanted in the first place if they have a reasonable setup. But I
am not going to sweat overly much about people using antique setups. If
you want to see what my style is, checkout
<URL http://www.xmission.com/~snowhare/>
: Oh, what's that? VT100 is obsolete and composes only a small percentage
: of users? Ok.
For WEB BROWSERS I think this is true.
: How about my PDA? If you don't think the Newton and/or it's successors are
: going to be a force to be reckoned with in the future of online data access,
: you're not thinking straight.
Tell you what - if your PDA displays less than 80 columns - I am flat out
not going to worry about it. It is a toy. Even a 1984 Apple //c could do
80 columns - on a TV screen. If your system can't support that 10 years
later - too bad. Really. I'm not going to support Model 48 teletypes either.
: A 48 point font is going to be reasonable on my 1280*1024 windows box,
: but how's it going to look on my TV, via the set top internet box?
Pretty good actually. (Hint: TVs display LARGE stuff well - it is the
fine lines that screw them up). I am only displaying 5 letters.
: Listen up: There is *is no* common denominator for computer displays. If
: you tailor a page to look just perfect on one person's screen, you're
: *guaranteeing* that it's going to look like crap on someone else's.
Sure. But I test on several platforms. I write so that if you are using
Mosaic (NCSA or Netscape) it looks as great as your colorspace allows. I
provide the INFORMATION required for a great display - if your system
isn't up to it - it will display what it can - but you *will* miss some
good stuff. And I won't feel bad for you.
--
Benjamin Franz
Joern Clausen
: (Marc is welcoming ideas, so ...)
: In article <marca-14109...@boulanger.mcom.com>,
: Marc Andreessen <ma...@mcom.com> wrote:
: >Some people seem to be assuming that we're deliberately forking the road
: >here, but folks, there isn't a whole lot out there right now in terms of
: >innovation happening in design-by-committee environments, and I am finding
: >it hard to figure out how to move forward with new functionality for
: >which customers are pounding down our doors at any reasonable rate of
: >speed without simply doing what it takes to get the functionality
: >working and in parallel openly documenting the results (as happened with
: >both inlined images and forms in Mosaic the first time around). Ideas as
: >always are welcome.
Then the right way is to get these committees working again. I don't know,
but if these committees are registered at the IETF, there is no problem in
joining them, and if necessary, to revive them. This would have been a much
better way than to release a new (commercial!!!) product and see and wait
what's happening to the standards.
: If the changes MCom mades appear to be well thought out (and some
: appear to be) and along the lines of what the HTML working group is
: trying to accomplish, you will get more success in speeding up the
: developement of HTML.
: After some thought, I think what MCom did is good. It is good in
: the sense that it shook people up and might accelarate the
: developement of HTML. Even though some of the ehancements are
: very questionable, it is a start.
I don't expect this to accelerate the development, I expect this to totally
confuse things. Now we will end up with different definitions, each one
claiming to be "the standard". I haven't tried NetScape (yet), and I am
not sure, if I will, so I can only judge from what I have read here.
Even if some of the tags are as poorly designed, as Earl mentioned before,
then it is nearly impossible to remove them in later verions of any HTML
definition, because this program (due to the high availability, and despite
of the fact, that it will be commercial) has the potential to define a new
pseudo-standard. And we all know, how long we have to stick to so-called
standards, no matter how dumb they are (just look how long DOS user have to
live with 8+3 character filenames).
If MCom really wants to improve HTML, they should take NetScape off of the
net, get the HTML work group working and rerelease NetScape, when they have
agreed on a new standard.
--
Joern Clausen "What do you think will be the biggest
jo...@techfak.uni-bielefeld.de problem in computing in the 90s?"
Universitaet Bielefeld "There are only 17,000 three-letter-
Technische Fakultaet acronyms." [Paul Boutin]
Snowhare
Let me be more specific about what I was doing - I was trying to write a
page that would display my lynx bookmarks file. Something like this:
<html><head><title>Some Stuff</title></head><body>
Bookmarks
For whatever reason, everything after *<BODY>* disappeared. I just tried to
reproduce the problem (I ran into it last week) and wasn't able to refind
the exact combination that did it. It wasn't a very complex page, but it
was a pain for me at the time and was related to the use of <head>. That
isn't the only time I have gotten quirky results from lynx.
--
Benjamin Franz
David Brooks
>Here's one little example of what can go wrong:
Here's another. Images are rendered, quite sensibly, using a color cube.
The result looks different from the same image rendered by the (admittedly
broken) Mosaic rules. And Netscape has two ways of doing the rendering.
What this means is that our graphics people are going to have to check that
images look OK using all three algorithms.
We are assuming that the world will be viewing our pages with a mixture of
Mosaic, Mozilla and other browsers for some time to come. We usually check
they look reasonable and are usable with Mosaic in color and monochrome,
and with Lynx. Now, even if we don't use the Netscape HTML extensions (and
we haven't decided about that yet; centering looks awful tempting) we have
to add tests in Netscape, both color modes and mono.
--
David Brooks dbr...@ics.com
Integrated Computer Solutions http://www.ics.com/~dbrooks
Bill Spurlock
>As one of the "founding fathers" of WWW you have a special responsibililty
>to the community. You have a rare opportunity to significantly influence
>the course of the development of what could become a dominant factor in
>our whole society. Don't mess it up with hasty, or worse arrogant,
>decisions and sarcastic postings.
Boy, do I ever have to agree here!
Bill Spurlock
>Failing such standards processes, we will introduce new capabilities as they
>are requested by our users and required by our customers, and then document
>them openly so others can create other implementations and do anything else
>they choose. I fail to see what is unreasonable about that path; if we
>don't follow it, we may as well just call the whole company off and hold
>our going-out-of-business sale now.
If you cannot see the problem in that, then I would encourage you to hold that
fire sale quickly before any more dammage is done.
It's gonna be one hell of a fine mess when we have 15 or 20 browsers that all
use their own code.
Bill Spurlock
>And there are many who feel the "philosophy of HTML and SGML" of taking
>away creative/artistic control of display from the author of a document is a
>major defect in HTML and SGML. I want my document to look the way *I*
>designed it.
That's fine. No argument here. But I want that doccument that I deisgn to look
good on as many browsers as possible, not just one.
Gavin Adams
>gad...@sandia.gov (Gavin Adams) writes:
>> Taking a look at some "Netscape Friendly" HTML, I've noticed a whole
>> bunch of new tags. :) Are these tags in the 2.0 spec or is MCC trying
>> to redfine HTML?
>[...]
>el...@nova.gmi.edu (R. Stewart Ellis) writes:
>> Yeah. I wonder what HotMetal does with some of the non-standard, illegal
>> stuff? :}
First, thanks for the reply Liam. As a devout user of the net-available
Hotmetal product, Mcom's HTML extensions have put me into a quandry.
>It rejects it, of course. HoTMetaL PRO will include a filter that will
>automatically delete such spurious markup so that you can produce documents
>that conform to the HTML 2.0 draft.
As it should (I guess).
>To be fair, I have asked Marc Andreeson for the DTD they are using (if it
>even exists); if we get a reply soon enough, it's _possible_ that we could
>offer support for it. But it's unlikely for this release of HoTMetaL PRO,
>we're hoping to ship next week, after many miserable delays...
I have a DTD question. Are DTD's just the specification, and if so, could a
"properly formatted" DTD be used as a parser? For example, if Mcom offered a
DTD file with their extensions, that I could place in my Hotmetal directory,
would that work? Does SoftQuad need to do additional work to the file to
support WYSIWYG placement of text and proper formatting?
>However...
>the whole purpose of standardising something is not to slow down progress;
>it is to ensure interoperability.
[snip]
>It is not at all clear to me that we would be serving the WWW community well
>by supporting anything other than HTML 2 right now.
Being on the outside of the HTML/SGML world, I'll let you, the experts, deal
with this. :>
Joe English
>>> but trying to push the development of the standard their way
>>> when they have little expertise in SGML is going to bugger up the
>>> whole Web for everyone else
>>
>>Yup, that's exactly what happened when we added inlined images
>>to NCSA Mosaic in the exact same manner we added these extensions
>>to Netscape, isn't it?
Um, well, yes.
Excerpt from
<URL:http://home.mcom.com/home/services_docs/html-extensions.html>:
(under "<IMG>")
"The rest of the align options are my way of trying to
correct for the horrible errors I made when first
implementing the IMG tag, without destroying the look of
existing documents.
And I won't even *mention* all the things that are
wrong with <form>s...
On the other hand,
In article <1994Oct15.1...@midway.uchicago.edu>,
Tim Pierce <twpi...@midway.uchicago.edu> wrote:
>I'm curious to know how Marc suggests that text-based
>browsers like Lynx should interpret differently-sized fonts
>within a line.
Easy: ignore them. If the author wants a font-size change
to indicate some logical entity like a header, she'll use
an <Hn> tag. If she wants a font size change just because
she wants a different font size -- WHICH IS A PERFECTLY
VALID THING TO WANT -- she'll use <font>. Lynx users don't
lose any information; Netscape users get a flashier display.
Which would you rather have: Users misusing semantic
tags to get a particular presentation (which *does* happen,
e.g., <H6> for fine-print) or the addition of more
purely presentational tags to HTML which allow for graceful
degradation across display devices?
I would certainly rather have the latter, as long as any
new elements are at least structurally consistent.
(I don't think the new <BR> and <IMG> attributes
quite meet this criterion, btw.)
--Joe English
Alex Lopez-Ortiz
>
> The extensions that Marc has made mostly answer real needs - no SGML
> cultist is going to tell me I shouldn't be able to centre text in my own
> documents -
But the answer is not a mixture of page description and content tagging
without any distinction between them.
> but we shouldn't accept them as they are. What are the real
> needs and has Marc answered them effectively? From some of the comments
> made here, I don't believe he has.
Agreed.
Brian Behlendorf
marduk <mar...@tc.cornell.edu> wrote:
>I think all web page authors should do the community a favor by not
>supporting unstandardized HTML tags and parameters. This is the only
>we are going to convince the makers of WWW browsers that what we want
>and need is an open standard, and not a hundred WWW browsers that
>support their own version of HTML.
>
>If vendors have ideas in which to improve HTML, they should try having
>it contributed to the open standard *before* implementing a
>proprietary format on their browsers.
Wired and HotWired will not be supporting unstandard HTML tags, the
definition of standard being "that which is specified in the HTML 2.0
spec and in the proposed HTML 3.0 spec". We hope other large
publishers will follow this lead. There's really nothing in their
extensions that can't be accomplished with a HTML 3.0 browser and
style sheets.
<blink>Brian</blink>
--
--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Your slick hype/tripe/wipedisk/zipped/zippy/whine/online/sign.on.the.ish/oil
pill/roadkill/grease.slick/neat.trick is great for what it is. -- Wired Fan #3
br...@wired.com br...@hyperreal.com http://www.wired.com/~brian/
Bryan Oakley
> results in at least moderately rapid innovation in directions that
> make sense. (Well over a year of committee discussion has resulted in
> no new capabilities beyond what NCSA Mosaic supports, and a good chunk
> of that we added without permission, because users were demanding it.)
> are requested by our users and required by our customers, and then document
> them openly so others can create other implementations and do anything else
> they choose. I fail to see what is unreasonable about that path; if we
> don't follow it, we may as well just call the whole company off and hold
> our going-out-of-business sale now.
> Marc
>
> --
> Marc Andreessen
> Mosaic Communications Corp.
> Mountain View, CA
> ma...@mcom.com
Can I have the fishcam ? $-)
Tim Pierce
Snowhare <snow...@xmission.com> wrote:
>Casey Barton wrote:
>
>: How about my PDA? If you don't think the Newton and/or it's successors are
>: going to be a force to be reckoned with in the future of online data access,
>: you're not thinking straight.
>
>Tell you what - if your PDA displays less than 80 columns - I am flat out
>not going to worry about it.
What? Who said "80 columns?" You said,
>: >If I want a grey 48 point italicized word
>: >centered between small graphics images -
Forty-eight points is forty-eight points is forty-eight
points. A Newton is going to have trouble displaying much
text in a 48-point font simply because its screen is only a
few inches across. Your snazzy web page is just not going
to come across on that platform, and I'm inclined to agree
with him -- the PDA is likely to be an important market to
accommodate in Web-related business.
What is your goal here, Benjamin? Is it to communicate
information, or to show off pretty page layout?
--
"A person who dies of lung cancer at age 70 will not be hospitalized later
with another disease," said a study released Thursday by [Canada's] Imperial
Tobacco touting the benefits of early death in smokers on the health-care
system. (Reuters, in the Chicago _Tribune_, 9/3/94)
Tim Pierce
>Which would you rather have: Users misusing semantic
>tags to get a particular presentation (which *does* happen,
>e.g., <H6> for fine-print) or the addition of more
>purely presentational tags to HTML which allow for graceful
>degradation across display devices?
Tomahto.
jye...@bga.com
> If MCom really wants to improve HTML, they should take NetScape off of the
> net, get the HTML work group working and rerelease NetScape, when they have
> agreed on a new standard.
the computer industry has a long history of "commerce setting the standards"
.. ie: if it becomes a commercial success it becomes a defacto standard
(instead of dejure). like it or not, the driving force in the WWW/HTML world
at the moment is *commerce* (thanks primarily to the feds "getting out if the
business" .. ie: lessing their internet role) and the developers who are
successful will be the ones who set the "standards"
if a successful commercial product causes the industry to mature faster than
committee, then more power to them.
so far, i have used it (NetScape) and i like it ... enough that i am
recommending it for our "standard" browser at work (based on features, speed,
and stability (.. if i can't break a program within 24 hours of install, it's a
good one (grin)) and to all of my home based clients that require SLIP access.
'wolf
Adam Elman
frankly I'm now a bit confused at the argument now raging on this group.
Could somebody please specify what exactly is so poorly designed about the
MCom extensions? The only one I can see that I see design problems with
is the <CENTER> element -- I think adding an "ALIGN" tag to <Hx> and <P>
probably would have been a cleaner approach. Otherwise, I don't see which
of the extensions violate the intentions of SGML or HTML. At worst the
MCom extensions are no worse than tags like <B> or <I> which cannot be
represented on a VT100, and therefore should not be used to denote content
where possible.
I'm not going to comment on the issue of MCom arbitrarily coming up with
their own extensions to HTML. However, I can't find any conflict between
MCom's extensions and the HTML/2.0 spec (as found at
http://www.hal.com/users/connolly/html-spec/HTML_TOC.html) -- there simply
doesn't appear to be any overlap. The HTML/2.0 spec doesn't seem to have
tags to handle what MCom's extensions will handle, either.
Just my 2 cents,
Adam
--
Adam Elman | WWW: http://rescomp.stanford.edu/~elmanad/
ael...@cs.stanford.edu | Finger me or check out my Web page for PGP key!!!
--------------------------------------------------------------------------
"Sometimes I lie awake at night and ask 'Where did I go wrong?' Then a voice answers 'This will take some time to explain...'" -- Peanuts
Mike Ruxton (CHS)
>: Oh, what's that? VT100 is obsolete and composes only a small percentage
>: of users? Ok.
>For WEB BROWSERS I think this is true.
Well, how about FreeNets which are providing general user access through
e.g. public libraries, which typically have VT100 terminals accessing
their holdings database?
This is wide access for users seeking information, web browsers are very
useful for literature searches. And you can't necessarily expect public
libraries to upgrade to graphics based terminals just because they're
the best for browsing the Web.
--
rux...@agcrr.bio.ns.ca
_-=-_-=-_-=-_-=-_-=-_-=-_-=-_-=-_-=-_-=-_-=-_-=-_-=-_-=-_
Nothing will ever be attempted if all possible objections
must first be overcome. --- Samuel Johnson
Brian Behlendorf
>> CERN and MIT.
>
>Is it? I thought HTML was being standardized under the auspices of
>IETF now.
Check out
http://info.cern.ch/hypertext/WWW/Organization/Consortium/W3OSignature.html
Lots of information there about the organization's function, structure, and
motives.
>> The HTML variant is not that drastic. At least they didn't have an incompatible
>> tables implementation or worse bastardise HTML+ maths. The real question is
>> whether they will be supporting the features of standard HTML.
>> Will they
>> go for conformance certification when it gets started?
>
>Sounds fantastic to me -- I'm looking forward to information being available
>on (a) anything beyond HTML 2.0 (aka "standard practice) or (b) any
>conformance certification -- today there's *nothing*.
You're not looking hard enough.
>The HTML+ Internet Draft is long since expired (right?); there is no
>HTML 3.0 spec, or even a proposal (Dave Raggett told us on Oct 3, "I
>am about to start writing the first draft for HTML 3.0").
Check out
http://info.cern.ch/hypertext/WWW/MarkUp/HTMLPlus/htmlplus_1.html
The date at the bottom says November 8th, 1993 - a HEAD shows a
last-modifed date of April 11th, though subpages may have been updated
more recently. I believe this is the spec about to be submitted to
the IETF - someone from W3O could probably say with more authority.
And as I undertand it W3O is being set up so that developers won't
have to go directly through IETF to implement new protocols and
specifications.
>Someone at
>CERN is "investigating" style sheets (Dave Raggett, Sep 9).
Rob Raisch presented a proposal for style sheets several months ago on
www-talk, which I know you're on. You can see it at
http://gummo.stanford.edu/html/hypermail/.www-talk-1993q2.messages/443.html
A few weeks ago Hakon Lie from CERN posted a workable implementation of
this to www-talk, which you can see at
http://info.cern.ch/hypertext/WWW/People/howcome/p/cascade.html
This is really the *right* way to go - take the presentational details
out of HTML and put them in a higher-level mapping in a separate file.
Keeps the HTML from being obfuscated with an endless string of formatting
directives and is a good model for balancing that content-provider-
versus-local-user decision on how the document actually renders.
<P ALIGN=CENTER> is just the most obvious example of how one could
have implemented all your new tags in HTML 3.0 and associated style
sheets. Well, except for <blink>, I suppose.
Brian
John M. Troyer
>> One of the new enhancements is the VSPACE modifier to the IMG tag. This
>> allows the html writer to control the vertical spacing around an image.
>Perhaps it is your document that is buggy.
IMHO it is the decision to default VSPACE to zero that is buggy.
It's nice to be able to change it, and there are times when you'd
want it zero, but it should default to a sensible value, especially since
all non-netscape-aware documents won't have a VSPACE tag.
This shows up particularly in the img align="left" and "right"
YMMV,
David Pool
> >As one of the "founding fathers" of WWW you have a special responsibililty
> >to the community. You have a rare opportunity to significantly influence
> >the course of the development of what could become a dominant factor in
> >our whole society. Don't mess it up with hasty, or worse arrogant,
> >decisions and sarcastic postings.
>
>
> Boy, do I ever have to agree here!
>
>>>>
Not to DOG PILE right about now but what we found that what worked very quickly and to the benifit of the faster players in the market were the working
groups and bake offs we had with the WINSOCK specification. It is going to take a strong effort on all parts to work together to move this market
forward. Servers and clients will have to work independently with one another to ensure massive growth in the networked business communities.
I suggest and will volunteer that we host a WWW bake off to ensure compatabiltiy with clients and servers.
If this is already being done in an organized fashion than we need not, but from all the chat we could use at least a place to compare and test.
Microsoft took over Winsock and adopted it as a WOSA Specification, so we do run a risk?!?!
David Pool
President
SPRY Inc.
Alex Lopez-Ortiz
>
> Which would you rather have: Users misusing semantic
> tags to get a particular presentation (which *does* happen,
> e.g., <H6> for fine-print) or the addition of more
> purely presentational tags to HTML which allow for graceful
> degradation across display devices?
Neither. If the user needs fine print, allow her to define the
tag <legalese fine print> which in particular switches the font
to the size of the smallest atom known in the universe, and
flushes the text to the bottom of the page.
> I would certainly rather have the latter, as long as any
> new elements are at least structurally consistent.
> (I don't think the new <BR> and <IMG> attributes
> quite meet this criterion, btw.)
Agree. If you are going to add them at least be careful.
Eamon Daly
: Well, how about FreeNets which are providing general user access through
: e.g. public libraries, which typically have VT100 terminals accessing
: their holdings database?
as kartik subbarao said to me when i voiced a
similar opinion, "tough. then get left behind in
the dust."
this, folks, is a ridiculous thing to say.
i'm with mike ruxton and tim pierce when they say
that some concessions have to be made for users
who haven't the access some of you net-heads do.
"let them eat cake" is a lousy webmaster
philosophy.
realistically, not everyone has a 14.4 slip
connection on a super-fast hotbox with their
choice of browsers. it all boils down to how much
you want to share your ideas with your audience.
if you want a pretty page, fine. use inline jpegs
and auxillary markup all you like. while people
pass your URL by, i'll still be getting 17,000
home page hits a week from lynx, w3, and mosaic
users alike.
--
<sigh>
my handwriting's pretty bad... sorry about the signature.
<a href="http://acs2.bu.edu:3000/"> . . </a>
Bill Arnett
jo...@TechFak.Uni-Bielefeld.DE (Joern Clausen) wrote:
>...
> I don't expect this to accelerate the development, I expect this to totally
> confuse things. Now we will end up with different definitions, each one
> claiming to be "the standard". I haven't tried NetScape (yet), and I am
> not sure, if I will, so I can only judge from what I have read here.
> Even if some of the tags are as poorly designed, as Earl mentioned before,
> then it is nearly impossible to remove them in later verions of any HTML
> definition, because this program (due to the high availability, and despite
> of the fact, that it will be commercial) has the potential to define a new
> pseudo-standard. And we all know, how long we have to stick to so-called
> standards, no matter how dumb they are (just look how long DOS user have to
> live with 8+3 character filenames).
Right.
> If MCom really wants to improve HTML, they should take NetScape off of the
> net, get the HTML work group working and rerelease NetScape, when they have
> agreed on a new standard.
They don't have to go that far. It would be sufficient to widely publish
a very clear statement that the enhancements are preliminary and subject
to change without notice and that anyone who uses them at this time is on
his own. A somewhat better alternative would be to release a "Netscape
0.9.1" which disabled all the new stuff. But the best thing would be to
do both of the above and then, as you suggest, to quickly convene the
appropriate standards body and get agreement on as much of it as is
possible quickly and then rerelease "Netscape 0.9.2" with the agreed to
stuff enabled again (perhaps with slighlty different syntax per the
agreement).
--
Bill Arnett bi...@netcom.com
San Jose, CA USA ftp://ftp.netcom.com/pub/billa/billa.html
Marco Scheurer
> the net, get the HTML work group working and rerelease NetScape, when
> they have agreed on a new standard.
>
They don't. Centering is probably the most wanted feature lacking from
HTML 1.0. Inventing the <CENTER> tag, when <P ALIGN=CENTER> is available
and standardized upon, is not a mistake. It is not stupidity either. It
can only be deliberate and, imho, malicious.
---
Marco Scheurer (sche...@lithnext.epfl.ch, NeXTMail)
Laboratoire d'Informatique Theorique
Ecole Polytechnique Federale de Lausanne
(Switzerland) (+41) 21 693-2589
Jacqui Caren
>
>>: Plus, users may become disgruntled when later revisions of the HTML
>>: standard includes markup to handle the features that MCom has added,
>>: but the markup is not the same. Users will have to spend time and
>>: effort to translate MCom HTML to standard HTML. As a provider of HTML
>>: documents, I plan to stick with the standard inorder to avoid future
>>: maintenance headaches.
>
>I'll second this notion here. I will not encourage any of my current or
>perspective clients to go with the MCom HTML. In the event that these
>additions to HTML do become a part of the standatd HTML, then at that time I
>will rethink my position.
>
>Bill Spurlock
>SpiderWEB Graphics
I WILL be recommending Mcom netscape for to at least one of our customers.
1) it is the ONLY product (out of at least 10) that give IDENTICAL output under
windows and X.
2) it is a well designed and throught out product. It fits our needs almost
perfectly.
3) we NEED html3 and mcom are the only people I have talked to who are even
considering supplying a commercial product that provides HTML3 features.
Jacqui
--
Jacqui Caren, Paul Ingram Group Ltd. J.C...@ig.co.uk
My opinions are corect... ( and my spelling ? :-)
Jacqui Caren
>In article <billa-15109...@billa.slip.netcom.com>, bi...@netcom.com (Bill Arnett) wrote:
>> Making your "enhancements" backward compatible is necessary but not
>> sufficient. Unless the vast majority of browsers implement them, the user
>> will not see what the provider intended. Its bad enough already
>Yeah, I know. The world has gone straight downhill since we added
>inlined images to Mosaic without official committee approval.
>Marc
Go for it - I think that Mozilla/Netscape is the only decent graphical browser
for X and windows (my core platforms). My requirement is for HTML3.0 (+) features.
I spent a lot of time working with OSI GOSIP (uk and us). Especialliy with X.400.
That was committee based decision making. What is needed right now is simple, clean
and effecient standards - I say standards because standards should be created and then
should continuously evolve. What seems to be happening is that the standards folks talk
in private and the world moves on without them. I need tables and multiple submit forms NOW!!!
not next month or next year (or in the next decade!!!).
Mcom has bit the bullet and produced something that meets peoples needs. No one else
seems interested in doing this. Thier product is technically the best. It works.
Jacqui Caren
Nour Sayd-Ahmad
Snowhare <snow...@xmission.com> wrote:
>
>Lynx - No graphics. Odd interpretations of conventional HTML.
> I have written legitimate HTML that makes text vanish
> en mass under lynx. The offending HTML?
> <HEAD>Blahblah</HEAD>!
Is this legitimate HTML? I thought that *only* things like <TITLE> and
<ISINDEX> are allowed in <HEAD>. All text that is visble must occur
under <BODY>. In which case lynx was correct in not showing the text.
--
INSSOMNIAK
Bill Spurlock
>3) we NEED html3 and mcom are the only people I have talked to who are even
>considering supplying a commercial product that provides HTML3 features.
I doubt that you'll find many would argue this point. The fact remains however
that there is a right and a wrong way to go about implementing HTML3 features.
This is the wrong way. I'll stand by my statement that I will not use the
code and strongly encourge others to do the same.