Re: OT: HTML (WAS: MF having issues?)

Oliver Wong wrote:
"James J. Gavan" <jgavandeletethis@xxxxxxx> wrote in message news:lUKNf.86659$sa3.61137@xxxxxxxxxxx

It is absolutely BLOODY RIDICULOUS that somebody would design a version of HTML which screws up on :-

> "Bla bla bla" - <em>some guy</em>

Taking COBOL as an example :-

ADD A TO BE GIVING C

That's *exactly* what we expect to happen - and unless he is a space cadet, a developer does not expect the result in variable C to contain the Square Root or a Factorial ! Want to 'enhance' the language/tool - don't *substitute* but come up with an *extension*.


Right, the example above, with the <em> tag (for emphasis), comes from web developers inapporpriately depending on undocumented features. That is, the standard says that the <em> tag should be used for emphasizing text.

But let's say I don't actually read the standards, but just try out the <em> tag to see what it does, and I notice that on my particular browser, the <em> tag displays the text in italics (because the browser implementor decided that italics is a good way to emphasize text, for example). I might say "Oh, so the <em> tag just makes text appear in italics", and then start depending on the fact that it'll render in italics. Maybe in a future version of the browser, the browser implementor will decide "maybe rendering the text in bold is a better indication of emphasis", and so they change it so that <em> now causes text to appear in bold. So now my HTML page may be broken, for example, if it contained text like this:

--------------------------------------

Please type in the text below in italics exactly as they appear.

<em>ADD a TO b GIVING c</em>

--------------------------------------

And then someone viewing this page will not see ANY text in italics at all; only text in bold, and might become very confused.


Don't try and control people from making extensions, PROVIDING they are documented - at some future date a standards body might see the efficacy of incorporating that into an updated standard.

However there is a downside with a product like HTML as you illustrated - how does your Browser get around identifying standard entries and extensions ?


I believe the HTML standard specifies that browsers should always simply ignore any tags that they don't understand. This is to allow potentially infinite forward compatibility. For example, I could have an HTML document as follows:

--------------------------------------

Please use the following Java applet to calculate your shipping fees

<applet code="shippingCalculator.jar">
Unfortunately, your browser does not seem to support applets. You can download Sun's JVM from http://java.sun/com/
</applet>

--------------------------------------

The idea is that browsers who do not recognize the <applet> tag will simply ignore that tag, and display the text without any special formatting (for all it knows, perhaps the <applet> tag is supposed to cause the text to appear in purple on yellow font, underlined).

Browsers that DO recognize the applet tag understand that the appropriate interpretation is actually to not render any content between the opening and closing tag at all (so these browsers will not display the "Unfortunately, your etc." message), and instead to download the "shippingCalculator.jar" file, and execute it as an applet.

However, the W3C (World Wide Web Consortium), strongly discourages browsers from producing extensions, because they argue it will create a fragmented web, where certain pages can only be used by browser A, and other pages can only be used by browser B, whereas the goal of the web is to be accessible to everyone with an Internet connection.

- Oliver

I could foresee problems with HTML - that's why I put the final caveat in my last message.

The only snag with restrictions, made by a 'standards' organization like W3C, is that they have the possibility of inhibiting forward development. It makes sense W3C exists, just like J4. But human nature being what it is, there is the danger that standards bodies can become unbearably over-bureaucratic.

A classic example at the world level is the EU. I don't follow it, just picking up snippets from BBC World News for the most part in summarized form. In Brussels you have an 'artificial' parliament and it seems that the Eurocrats in charge are forever wanting to get member countries to fall into line, tout suite. There was an absurdity about a week back, forgotten what it was - but as an hypothetical example - you can no longer sell UK sausages that contain ...xxxx.

While hopefully it never gets that crass in IT - there could be limiting factors based on rigid standards. As a number-count, there were probably as many, and perhaps more, computer languages created, tried and dropped, prior to your 'creation', equaling the number of years you have had on this earth. So why did the languages come into existence at all ? Was it because they covered new features not part of those already around, or with a germ of an idea the instigator came up against a brick wall when trying to get a committee to go for his ideas.

Don't know whether or not you are aware, but the old hands at Xerox PARC are real pissed that Java outshone Smalltalk, saying it was Sun's marketing know-how that did the trick. True or false, it would have been kind of neat if instead of Java there had been a Smalltalk Version 2 which included 'extras' plus any additional features that we see in Java or the 'C' group of languages. Do others like Ada have specific features they can add to the picture ? I realize Java was built from scratch - but can't help wondering if a comparison would show Smalltak and Java are reasonably compatible.

COBOL - Common Business Oriented Language. Think of the name and substitute 'Object' for 'Oriented' or make it COBOOL. Instead of going through the mysteries of each new language that comes along, take a basic brick like COBOL, which is rock solid, get rid of some of its verbosity without going cryptic, and attach or dovetail new features to it; a dreamy thought.

Then you come unstuck - couldn't do it with the same 6 members that COBOL J4 has. You would need something like 50 members, with very different interests,(machine vendors and programmers), different IT disciplines - communications, engineering, mathematical, accounting/inventory etc.. Snag is the bureaucracy would take you back to the EU model.

I wonder what the situation will be when the duet of China and India show their clout in around 2050-2070, taking over the position of Uncle Sam ? The PRC has shown that they aren't dumb - when the British lease was up on Hong Kong, Beijing merrily let Hong Kong carry on 'as is', because they liked the appeal of a money making machine.

So folks could pooh, pooh that thought - both counties urgently need oil/gas - and they are aggressively seeking sources, Arabia, Africa (Nigeria), S. America and up here in the Great White North, until such time as ethanol or hydrogen become practical alternatives. Both have expressed an interest in the Athabasca Tar Sands and after protracted negotiations will probably put up the money for a pipeline to the West Coast in northern B.C.

That leave us here in Alberta with a whole chunk of natural gas - one customer - Uncle Sam. Just not viable to consider shipping natural gas. However LNG (Liquefied Natural Gas), that is gas chilled down to a liquid level - if they want to come up with the money to finance that, (production facilities and piping to the coast) - then ?????

Jimmy
.

Relevant Pages

  • OT: HTML (WAS: MF having issues?)
    ... Even though he is only serving up static HTML pages and has no idea how they work or the fine points of the language, he has a very professional looking site that he built in about an hour. ... Though leading browser makers have been involved in the creation of web standards since W3C was formed, for many years compliance was observed in the breach. ... By releasing browsers that failed to uniformly support standards, manufacturers needlessly fragmented the Web, injuring designers, developers, users, and businesses alike. ... It is not enough for the website to simply "look okay" on any one particular browser; the HTML should be structurally correct, and the tags used for their semantics, rather than how they render in one particular browser. ...
    (comp.lang.cobol)
  • Re: How does Alexa and other sites create "screen shots" of sites?
    ... HTML 4.01 Specification ... supported standards, etc. ... it is not a good browser. ...
    (alt.internet.search-engines)
  • Re: Can you render and image in ASP.NET?
    ... the client (browser). ... the image bytes back to the browser, you will need an tag in the page ... HTML whose source is the ASPX page that constructs the image. ... > Is there any possibility to render images for the web in asp.net? ...
    (microsoft.public.dotnet.framework.aspnet)
  • Re: OT: HTML (WAS: MF having issues?)
    ... But let's say I don't actually read the standards, but just try out the tag to see what it does, and I notice that on my particular browser, the tag displays the text in italics. ... So now my HTML page may be broken, for example, if it contained text like this: ... The idea is that browsers who do not recognize the <applet> tag will simply ignore that tag, and display the text without any special formatting. ...
    (comp.lang.cobol)
  • Re: How does Alexa and other sites create "screen shots" of sites?
    ... HTML 4.01 Specification ... it is not a good browser. ... Sure IE has issues, and yes, Opera might have had less. ... Moreover, your "standards" prayer. ...
    (alt.internet.search-engines)