TechTalks Transcript
The Future of HTML
 Judith Boettcher [JB] |
 Greg Marks [GM] |
 Howard Strauss [HS] |
February 10, 1998
Audio
• Streaming
MP3
• Download
MP3 (Download
Tips)
JB: Welcome to the Expert Event series for the Spring of 1998 on untangling the Web. Whether you are joining us by phone or by Internet audio, you are here because it's time to discuss one of the leading core technologies in your future, the World Wide Web.
This is Judith Boettcher of CREN, one of your hosts for today's session. Today's co-host is Greg Marks from MERIT. Good afternoon, Greg. How's everything going up there?
GM: Everything's going just fine. All the equipment seems to be working and recording away.
JB: All right. Great. Our guest expert today as part of the series is World Wide Web expert Howard Strauss from Princeton University. Howard is the manager of advanced applications at Princeton and a well-known presenter on Web issues and futures. Howard is also the seminar leader for the CREN Virtual Seminar on Untangling the Web. Welcome, Howard. Thanks for being here today.
HS: Thank you, Judith.
JB: All right, great. Greg, would you like to remind folks about how they can join us today?
GM: Yes. You can participate in either of two ways. You can join the phone conference by calling at 734-647-2801. You'll be right in the middle of the conversation. There will be no one to hold you back. Your other option is to join us on the Web at www.cren.net and simply go to the Events page and follow from there.
Whichever way you're joining us, you can feel free to send us e-mail at utw@cren.net to ask us questions or pass along comments or again, you can call us on that phone, 734-647-2801 and ask your question immediately. And the way we'll proceed to is to have Judith and myself asking some questions, and of course, Howard will be responding without any question. At any point that you want to interject a question, whether by e-mail or phone, just do it.
JB: Okay, very good. Thanks, Greg. Howard, now that we're all gathered and set here, let's again focus on one of your very favorite topics, HTML, and what's happening with that. Is there anything new happening with HTML, particularly since we talked the last time here?
HS: Well, there's always something new happening with almost everything on the Web. And I'd like to point out that I know we have all these people out there looking at a website and thinking of either calling in or typing their mail in. And of course, what they're seeing on this website and every other website is a result of HTML. I think you don't think about it much, but all those 110,000,000 websites out there, somebody had to code them. And they had to code them ultimately with HTML.
Some of the new things that are happening are that there's, for one, a new HTML standard, HTML 4.0, which now the World Wide Web Consortium believes is official. So we can actually now go out and look at the official 4.0 standard now. Whether anybody's using that or not right now is quite another question, and we'll handle that a little bit later. So there is a new standard for HTML.
There's also things called cascading style sheets. Dynamic HTML is coming, and, in fact, is part of the HTML 4.0 standard. And something called XML or Extensible HTML is also on the way. Now, all these things have been in the works for a while, but they're getting to be more real with the arrival of HTML 4.0. JB: Isn't a Web standard somewhat of an oxymoron, Howard?
HS: Well, I think it's something that people would like to have, just like you'd like to have all kinds of standards. And in fact, if you look at the W3C -- that's what the World Wide Web Consortium is called, the W3, and I guess instead of writing WWW, they write W3. But in their HTML 4.0 announcement, they've said that HTML 4.0, which is the standard, actually comes in what they're calling three "flavors." There's a strict HTML 4.0 standard, there's a transitional HTML 4.0 standard, and there's a frame-set HTML 4.0 standard, so you can really do the standard three different ways. But beyond that, a lot of people right now are paying no attention whatever to the standard.
JB: Well, some of the things that you were just saying right now, Howard, tends to suggest that perhaps W3Consortium is a body that may be, in fact, in charge of standards? Is that the case?
HS: Well, I think they are. They're accepted as setting the standard for HTML, but of course, if you're a company like Netscape or Microsoft and you see some neat new feature that you could implement and, well, gee, it doesn't happen to be in the standard right now, well, that's not going to slow you down too much. I think what's been happening is people have just said, "Well, we'll add this feature and we'll hope it will be in the next version of HTML." Previously, everybody has said, "We hope this will be in HTML 4.0." I guess people now are saying, "We hope this new feature I add will be in 5.0."
JB: What is the risk that developers, in fact, take if they start using some of the features and capabilities that are not part of an accepted standard? Does that make everybody's machine or their site simply crash when people access it?
HS: No. The rule on HTML--and I'm not really convinced it's a good rule. Sometimes I think it's a wonderful rule and other times I think it's a bizarre rule. But the rule in HTML interpretation, which is what the browsers do -- the browsers interpret the HTML -- is that if you see a tag, and HTML's made up of a bunch of tags, if you see a tag you don't understand, just ignore it.
And so that means that let's say you invent your own tag, Judith. You have the JUDITH tag, for example, which I don't think is implemented in HTML 4.0. If a browser were to see the JUDITH tag, it wouldn't sit there and choke on it and say, "Oh, my God! I don't know what's going on!" It'll just hop over it. It'll say, "I don't know this. I'm going to leave out that part of the document."
So it means if you're in Internet Explorer and you code a tag that is only understood by Netscape Navigator, Internet Explorer will just ignore it. It might leave out a chunk of the document, but it's not going to take your machine down or break the browser or do anything bad like that.
Let me bring up another problem, though, which is sort of related to what you're talking about. Let's suppose you were to go out today and you were to code something using HTML 4.0. And let's say you took one of the new features, cascading style sheets. Wonderful feature, good stuff! And you were to code that. It turns out that most people's browsers today don't understand cascading style sheets, so you have again -- you code all this nice stuff, the browsers ignore it. In the case of cascading style sheets, there's so much stuff there that if you were to code in that, most browsers would hop over most of the important parts of your document. So users would not be too happy looking at that document. So unless you knew that you were using a feature that all your users' browsers could see the thing, then you'd have to think twice about doing this. JB: Howard, there may be some of our folks out there listening who don't immediately know what cascading style sheets actually means. Can you briefly say what that is?
HS: I'll try to do that real briefly, because it's quite a complicated technical area. But a style sheet in HTML is a great deal like a style sheet in a word processor -- where you go off and you describe the basic format of the document. And then what you can do is you can say, "I have a document that's a business letter or a document that's some kind of informal letter and I'll set the fonts and the backgrounds and what headings are going to do" and all that kind of stuff up. And that's what a style sheet is in HTML, too.
This allows you, for example, if you have a company or a university or whatever and you're trying to enforce some standards, instead of having to define HTML, all these features again and again -- what should headings look like, what should the backgrounds look like, what do tables look like? -- you could define that once in a style sheet. And you might have many style sheets. So that's sort of style sheets.
Cascading style sheets add a degree of inheritance to style sheets. That is, we can start with a style sheet and then what I can do is I just have another style sheet that redefines just a few of those things. And if I take the first style sheet and then apply the second style sheet to it, the second style sheet just overrides just a few things in that style sheet. So the style sheets cascade. That sort of clear?
GM: So we have the DNA of style sheets. We have the genes of its inheritance to deal with?
HS: Yeah, or I think it was more of an attempt to put up something that looked more like an object model, using inheritance in the sense that people use inheritance in object-oriented programming. That kind of thing. So it's that you don't have to redefine everything, and if you want to redefine a few things, you don't have to throw out the style sheet.
GM: Now, is the process going to be the same here whether I'm dealing with Netscape Communicator or Internet Explorer, or am I going to be going crazy over all the fine-grained details of cascading style sheets?
HS: Well, if you follow the standard, and if Internet Explorer and Netscape would follow the standard, then everything would run fine.
GM: Lots of conditionals there!
HS: Yes, there are. JB:. Howard, actually, we've gotten a couple of messages from Ken Klingenstein out in the University of Colorado, and he's actually playing the program for his class on network management. And they have a question for you.
HS: Okay.
JB: And that is, can we stop a webpage from recognizing the kind of browser that we have by using HTML?
HS: Could you try that question again?
JB: Can we stop a webpage from recognizing the kind of browser that we have by using HTML?
HS: I don't know how to do that with just HTML. I mean, you can do that with a CGI script. The CGI script, when a browser goes to a CGI script, the browser reports to the CGI script what it is. Now, I could tell Ken's class and other people listening that sometimes the browser lies about that, and that has given us a real problem here in trying to do that where we have a CGI script and we know that the browsers behave differently, and so we want to know which is which. But for example, older versions of IE 4.0 tell the CGI script that they're Netscape, which is kind of nice.
JB: How can they do that?
HS: Well, because the browser is just returning information to the CGI script. It can say anything it wants. I mean, right? It could say, "I'm coming from Greenland" or it could say whatever it wants. There's no stopping it. But the new browsers at least seem to report what they are.
What we'd like to see is even more information reported, not only what browser you are, what version you are. We'd like to know what machine you're running on. I mean, the more information you have -- well, what would really be good is if it didn't matter because all the browsers did exactly the same thing. Then you wouldn't have to bother with all the silliness. But if you do have to bother with all this stuff, at least if the browsers would tell you the truth. But they don't always do.
JB: But you are saying that it is possible to tell a browser that you are someone different than what you actually are, but it may still recognize that you're not who you are? Can it tell whether you're lying?
HS: No, no, no. It's really a matter of whoever coded the browser. I really think the reason that the old versions of Internet Explorer said they were Netscape is that they knew everybody was looking to see if you were a Netscape type browser or if you were a line-at-a-time browser or something like that, and I think they were just being nice. They were saying, "Since everybody's looking for Netscape, I'll let them know that I do all the same things that Netscape does, so think about me as Netscape." Except for the fact that they didn't do things quite the same as Netscape. Now, I really just don't know if you can get that information out of Java Script or out of Java or someplace else like that. I mean, I'm not saying that you can't. I just really don't know and perhaps I'll go dig that up after this conference here. JB: Howard, we have gone over two or three areas that are really quite new. We mentioned dynamic HTML and also XML. Would you like to say something more about the dynamic HTML?
HS: Okay, dynamic HTML normally is used with style sheets, so these things tend to build one on top of another. And it's also normally used with Java Script or some kind of scripting language -- Java Script or VB Script or one of those kind of things. But normally, you think of HTML as putting static information on the screen. That is, once you put some text on the screen, it kind of sits there. It doesn't move around very much. But with dynamic HTML, what you're doing is you're taking advantage of the fact that there's properties of everything that you put on the screen.
For example, with text, one of the properties you really do have is its position on the screen -- its x/y coordinates. And also its font and its size and its color and on and on and on. If you could imagine being able to take all those attributes and changing them after the HTML has appeared on the screen. So I put some letters on the screen, then I decide I'll move them somewhere, or I will change their color or their font or things like that, after they've been put on the screen. Dynamic HTML lets you do these kind of things.
It also lets you position things very, very precisely. If some of the listeners here have ever tried in HTML to get some letter to fit just a little bit over and underneath another letter in HTML, it's a horror. You can't really position things exactly where you want on the screen. But with dynamic HTML, since the position of text or images or anything on the screen is dynamic and you can set it anywhere you want, then you can position things very precisely.
If you can imagine combining that feature with style sheets, where you have a style sheet that not only talks about the font and the color and things like that, but they can talk about precise positioning on the screen, then you can really do things in HTML that look like publication-quality things or like CD-Rom quality things, and that's what we're trying to do here with cascading style sheets and dynamic HTML and Java Script all working together. GM: And where does XML fit in that picture?
HS: XML is an attempt -- XML stands for Extensible HTML -- it's an attempt to make HTML more structured.
Anybody who's played with HTML knows that the rules are kind of loosely enforced, to say the least, and that it doesn't really look like SGML. (SGML is Standardized Generalized Markup Language.) So it's an attempt to put some more structure and rigor into HTML.
And one would assume that what's going to happen is future versions of HTML, maybe HTML 5.0 or something like that, and XML are just going to merge together. Maybe. JB: You kind of anticipated a question that I'm sure many of our listeners, in fact, had, in terms of the relationship between XML and HTML. So in terms of your recommendation, Howard, in terms of staying really current with all this, if people follow the HTML standard, they may well in fact start incorporating some of that XML -- is that fair to say?
HS: Well, I would right now read about XML. I wouldn't be coding it. And in fact, if you want to be really conservative, unless you know a great deal about your user population, if you wanted to be really conservative you would say, "I'm just going to use the features of HTML, I think it's 3.2."
But even there, even with those versions, if you pick up a reference on HTML, you'll see that many of the parameters of options are only supported by either Internet Explorer or Netscape, and often not by both. And sometimes there will be some feature or option that's supported by both, but that's supported in a different way. That is, they'll use a different parameter or a different convention to do that. And very often, I'll wind up coding both of them. That is, I'll go into some tag and I want borders done in some peculiar way in a table and I know that IE does it -- that is Internet Explorer does it differently than Netscape. So I'll code them both, knowing that Internet Explorer will ignore the one it doesn't recognize but that Netscape recognizes, and that Netscape will ignore the Internet Explorer one that it doesn't recognize. And so on either browser, the thing will look the way I want it to look. You can't always do that, though. GM: You mentioned the use of references. Are there particular books or websites for references on HTML that you find useful?
HS: Well, let me just give a website which I think is the most useful website, and that's the World Wide Web Consortium website. I believe that on your website you have a reference to that. But it's www.w3.org. And if you go to the homepage there and you look over to the right edge of it, you'll see that there's a whole bunch of related topics like HTML style sheets, the document object model -- all these things are just typically one link away. And in fact, if you go to the HTML link on the homepage, that will take you to the HTML 4.0 announcement and all the details and flavors and things like that, and you could learn a great deal about it.
As far as a book, the book I like the best -- and I'm sure there's listeners and people looking here who have other favorite books -- but the book I like the best is the O'Reilly book called HTML, the Definitive Guide. That's by Musciano and Kennedy. It's a wonderful book. It's shorter than most HTML books. It tells you what you can use in IE 4.0 and what you can use in Netscape Navigator and what you can't. And it's very, very practical. It doesn't give you a bunch of theory. It just gives you all the stuff you can actually use. GM: And given the current market penetration of both Internet Explorer and Netscape, if you are putting a page up, you basically have to pay a lot of attention to coding for both of them.
HS: Yeah, and in fact, just to give you one more thing to worry about if you're putting a webpage up, you obviously want to know what it's going to look like. Well, I think you want to know what it looks like on Macs and PC's and on screens that support 256 colors and black and white screens and screens of different sizes AND IE 4.0 and Netscape Navigator and possibly older browsers, if you have a big population of them, as we do here at Princeton. So testing a new Web application for us means testing it in probably 50 or 60 different environments. And you would not believe how different it can look on a machine that has a slightly smaller screen or that supports fewer colors or one of hundreds of variations. And if you don't do that testing, your users will do it for you and you'll get people screaming at you. GM: You just mentioned colors. Can you elaborate on the color palettes for both?
HS: Well, colors are a very interesting area in HTML. Obviously, everybody likes to use color, and they like to color the backgrounds and they like to color fonts and things like that. And the whole issue of colors, I think, is a good point to illustrate just how the standard is completely ignored here.
You can code colors, and this is whether you're coding colors for backgrounds or for text. You can code them as three pairs of hexadecimal digits saying how much red, green and blue you want to use for the color. But no rational person does that any more (but you could still do it if you really like hexadecimal pairs of characters). What most people do is they just code the name of a color, and HTML 3.2 had 16 standard colors with names, so these are not too imaginative -- like, "yellow" was one of the names of the colors. So if you wanted a yellow background, you could say that the background color was yellow -- or white or red or whatever.
But Netscape and Internet Explorer support zillions of other colors. These are totally non-standard. I mean, "olive drab," for example, is a color that you could code, or "medium slate blue." Probably something you'd think of, right? Right off the top here. "Saddle brown" is another color. And not only can you have these, for example, "Navajo White," but you can have "Navajo White 1," "Navajo White 2," "Navajo White 4," where they get progressively darker.
So this becomes a real strange thing. I mean, if you're coding Navajo White, it's not in the standard. Everybody codes it, because why should you limit yourself to 16 colors when you know that your users have 256 or millions of colors? Of course, some of your users really only do have 16 colors, and if you pick one of these strange colors, you're going to get some strange effects.
JB: Howard, in terms of the numbers of colors and the restricting them, the general rule is that people generally go ahead and use some of the colors and the color names, and then just kind of trust for luck and for goodness that when the users bring the website up, that it will in fact look all right?
HS: Well, I think if you want to be safe, use one of the 16 standard colors. You know those are going to work, though you may want to take a peek and see what they look like on a black and white or gray scale monitor. When we use colors, which I do every day, that are not in that list -- because how can you resist "Alice Blue" or something like that -- then what we do is we will look at those colors on a variety of monitors.
There's some other interesting tricks that you can use to make it more likely that the colors will work on lots of machines, and when you dash out and buy HTML, the Definitive Guide and look at one of the appendices in the back, they will give you some tricks about looking at every fifty-second color in the hexadecimal list of colors and discovering why those work better than other colors. I'm not going to go into that. But there are some ways to expand your color horizon without having to check every machine in your university.
JB: And do we know how many colors are now supported in the new 4.0 standard?
HS: Actually, I have not looked at that, but you should realize that you can code 16,000,000 using the hexadecimal digits, and that's been part of the standard. The question is, if you're going to use color names, which color names are recognized? No one wants to code a color as something like 44.AD3, which would be a color.
JB: Right. It's more difficult to remember, right, than writing something like "Alice Blue."
HS: Right. You also have no idea what it's going to look like. If somebody came over to you and said, "Okay, give me the hex codes for Alice Blue or give me the hex codes for anything," who would know? I remember white and black because one is all zeroes and one is all F's, though I forget which is which.
JB: Okay. Well, actually, being down here in Florida, something in the color of a seashell would be nice, too. Then seashells come in many different colors, too.
HS: Right. And there's probably a color called Seashell. I could look that up for you. GM: In all the things you've described, working directly in HTML, how much of this is simplified if someone instead switches over to one of the generators or works out of Word 97, for example? Does life get better if one goes that path?
HS: Yeah, I think there's a bit of a trade-off. Actually, there's a huge trade-off here, but life becomes much simpler if you're using something like Word 97 or any one of the other packages that convert things to HTML.
The nice thing is that you never have to even think about colors. You pick colors by how they look on the screen. You move things around on the screen. It's really a what-you-see-is-what-you-get kind of thing. And when you're done, you just say save this thing as HTML and you have HTML without coding a single line of HTML.
The downside is that you can't do everything that you'd want to do. There's a limited number of things that you can do with these HTML generators, and so it's great if you want to do something basic, simple, straightforward. And I think for a lot of people on university campuses, a lot of faculty members and staff who want to get a page or a few pages that look like a document or a document with some pictures and links and things like that, that's really a very good way to go. Why bother with HTML and all these funny wrinkles and things and hope that the HTML they generate at least is going to work on all the browsers? And it pretty much does. They generate a very conservative subset of the HTML they could.
GM: What about the case where the pages change with some frequency? Are any of them to the point that it's relatively easy to edit the output HTML, or is it all really obscure stuff?
HS: Well, you really ought to edit the stuff you input. That is, you ought to edit the thing as a what-you-see-is-what-you-get kind of thing. Editing the output is -- well, it doesn't work all the time. What happens is that when they generate the HTML, they're leaving all kinds of little tracks and clues that might not seem significant to you, but are very significant to the generator. And nine times out of ten, when I fiddle with the output HTML -- which I find hard to resist doing -- then the thing that created it never quite recognizes it again. Isn't there something about if you touch the eggs in a bird's nest, the bird will reject them? I think it's the same kind of principle that applies here. Once the HTML has been touched, then the thing that created it doesn't seem too happy with it.
Some people who are listening perhaps have tried this and they've discovered that they could, in fact, modify the HTML and it works. And it does work sometimes. And if you're very conservative in what you do, it'll work. But if you do enough of it, it'll stop working. Even if you don't modify the HTML, I have seen time and again -- and it's been the experience of many people here -- that if you create something with Word or one of these generators and you edit it a lot, if you make lots of changes, especially lots of big changes -- that is, you create a list and you say, "I'd like this to be a numbered list. Now I'll insert into the middle of this numbered list a bulleted list. Nope, I've changed my mind! I'll change it back to a numbered list. Or I'll put a box around it" -- if you make enough changes, you can confuse these generators.
And they generate HTML a little bit differently than what you would think. Just the other day, I put a document out on the Web and decided at the last moment just to add a couple lines of italicized type right at the top of this thing. That's all I was going to do. I went back to Word, added a couple italicized lines, never even thought to look at it again on the Web. How could this have changed anything? It made the entire document into Italics. Every word of the thing! It did it because of something peculiar it did with a font tag, which I think it should have known better. But it didn't. I had to go in, modify the font tag, and I now never hope to look at the document again with Word. As far as I'm concerned now, it's an HTML document.
So there's some strange things. There's some advantages to coding HTML yourself in terms of control. But again, there's lots of people out there who just want to put out a simple document on the Web. And if that's all you want to do, just use something like Word or WordPerfect or anything that will save things as HTML. It's really the simplest thing to do, and I strongly recommend it to folks here, and I would recommend it to people listening.
JB: So you're really saying, though, Howard, that if you're going to start with a Word document, that you really want to keep your Word document and sometimes then start fresh with that, unless you make a lot of changes on it.
HS: Yeah. And again, before I would convert something to HTML, because fiddling with the thing after it's in HTML or even if it's HTML and you're fiddling with it in Word -- if you fiddle with it enough, it can get it upset. I would do a lot of my editing first as a Word document. When I'm pretty happy with the thing, then convert it, and it should convert pretty well.
JB: Okay. But would some advice be, then, always to keep your master Word document and to make your changes in that and just regenerate and replace in that?
HS: Yeah, we're actually, Judith, in a little corner here because there's actually two ways to build HTML in Word, and I'll just mention these briefly, because they're really quite different.
One way is to start with a Word document -- a .doc document, which is a regular Word document. Do whatever you want with it, and at the very end say Save As HTML. And I think that's what probably most people listening or watching, whatever they're doing, are thinking about.
But there's another way to build HTML with Word and that is to open a document as an HTML document, and you can do that. When you open the document and you get the little opening screen, if you look carefully at the little tabs and look off to the right, you'll see something that says Create an HTML Document or something to that effect. And if you do that, then what you're doing is you're opening a document that from the very beginning is HTML. That actually is a more powerful way to build an HTML document. Also a little bit more technical way to build it.
So if you feel comfortable with doing HTML-like things without really getting in the middle of HTML, that's what you ought to do. If you don't feel comfortable with that, you might want to start with a Word document and then convert it to HTML. In the first case, you're going to have a .doc document which you'll save, and the HTML document -- the .html document that will be created. In the second case, there will never be a .doc document. From the very beginning, it will be an HTML document.
GM: Howard, we have an e-mail from Annie Wolock saying "for a person who's fluent in HTML, what would be a good source of information on both the cascading style sheets and dynamic HTML?"
HS: I would go to the website at w3.org. There's very good information out there, and also it's the very latest information. GM: Great, thanks. If I wanted to put forms up, do I have to do CGI scripting to make that happen? Do I have any options?
HS: Many, many forms do use CGI scripts because what you want to do is you want to take the form and you want to send all the information off to the server and you want some program on the server, which is the CGI script -- the Common Gateway Interface Script --, you want it to do a lot of processing and send stuff back. And traditionally, that's the way forms are always done.
But you don't have to do that. If you don't really need information on the server, if all you need is some processing and you know what the rules are, then you could do the whole thing in JavaScript. Couple examples of that are if you just wanted, say, a loan calculator, where you just wanted somebody to type in the size of the payment, the interest, how long they were going to take to pay off the loan -- well, it's just applying a formula. The formula is well known, we don't have to go off to a server to figure out the formula. The formula can be part of the Javascript. And so somebody can have a little form that looks like a little loan calculator and you would never have to go off to the server.
Or in a case where some people have put up these W-4 calculators, I'm sure that everybody out there has filled out a W-4 or someone's done it for them, telling them how much money is going to be deducted from your pay each pay period, based upon the number of exemptions and all this kind of stuff, dependents, whatever you have. But figuring out what happens if you would add one more exemption or one more dependent or one less, who know? Nobody. I'm not even sure the people in my payroll department really understand this. But people built little W-4 calculators where you can come in, you put your salary in, you put the number of dependents, you write all this information in, and it just calculates it for you.
Now, as soon as somebody says, "Put your salary in," you're going to say, "Oops, security problems!" But this information, because we're not using a CGI script, never goes over to the server, never travels across the line. It never leaves your computer. Unless somebody has a camera looking in your window at your machine, they're never going to be able to see what you typed in, so you don't have to secure this thing. You don't need authentication. It's a very, very nice application.
JB: How do you know whether that is happening locally or going off to the server, Howard? I mean, is there some generalized way to be able to interpret that?
HS: Boy, I'm trying to think of a way you would know without looking at the HTML. The only way I can think of is to look at the HTML and see if the thing's actually going off to the server. Actually, one way you could tell is if it happens real fast, chances are it's not going off to the server.
JB: Well, that's true. But you can't really be offline either, right?
GM: With that and working via modem, you can look at the lights and see if --
HS: Right. But there's nothing obvious on the screen. You can always look at the HTML, and if you could read HTML, it's pretty easy to tell if it's going off to the server or not. If you see a bunch of JavaScript and you don't see something that says Action in the forms tag, well, it's not going off to any server. GM: Say more about JavaScript and how it relates to Java or VB Script.
HS: JavaScript is unfortunately named. It sounds like Java, and it's not. It used to be called Live Script. That was its first name. It was done by Netscape, as I think a lot of folks know, and it's an HTML scripting language. And its purpose is to take HTML and do things with HTML. It doesn't chit-chat with the server or do anything like that.
Java is a real programming language. In fact, it's an object-oriented programming language, a very serious object-oriented programming language. And although it runs on your machine, it's not an HTML scripting language. It sits there and grabs a little area on the screen and does its own thing, totally unrelated to HTML. It comes down from the server. It doesn't live as part of HTML. And it's a totally different language.
If you learned either one, you wouldn't know the other. If you learned Java, you really don't know too much about JavaScript, and vice versa. One other really important point about the difference between the two of them is that Java is a very serious programming language. This is not for children. You really have to be a very serious programmer to do Java programming. But if you've programmed in anything, Basic or anything, if you've coded macros for anything, if you've ever been involved in programming, then you'll discover that JavaScript is pretty easy to pick up.
As for VB Script, VB Script is just Microsoft's HTML scripting language, so it does exactly the same thing as JavaScript, except the syntax of it is very similar to Visual Basic.
JB: Is that why it's called VB Script, by the way?
HS: Yeah, VB is Visual Basic. And in fact, the macro language for all the Office 97 products is VBA, Visual Basic for Applications. That's the macro language. It's kind of nice, actually, but if you know Visual Basic, you know a great deal about Visual Basic for Applications, which is the macro language for Office 97, and you know a great deal about VB Script. But if you look at what's being coded, you'll discover that most scripts, most HTML scripts are done in JavaScript, even a lot of the ones that are coded by Microsoft. Microsoft's going to kill me for mentioning that, but I've looked under the covers at many of the things they've written, and I guess their programmers know JavaScript. JB: Okay. Howard, another topic that often causes developers and Web designers to lose sleep or start eating too much pizza is how to talk to HTML to handle some of the many special characters, such as Less Than, More Than, whatever. Do you have some hints for dealing with those kinds of special characters?
HS: Yeah, I think it's just a matter of knowing that you can't do them the way you think you could. That is, you're coding along happily in HTML and you want to talk about something being less than something else and you code a Less Than character. A Less Than character is the start of an HTML tag. As we mentioned earlier, an HTML tag that's not understood by the browser gets ignored. So you say something is less than something else, and it sees a Less Than and the word something else, and it says, "Oh, there's the something else tag. I have no idea what it is. I think I'll skip it." And so it does. It skips a whole bunch of text. But in your text, where you're expecting to see something is less than something else, you see "something" and then paragraphs of text are missing until it sees a Greater Than, which it thinks ended this tag.
So we need some scheme, some escape mechanism, to say that this special character is not a special character -- I just really want you to print it. And the scheme that's used is we start a special character with an ampersand. Of course, this means we need a special character for an ampersand. I'll talk about that in a second. But it starts with an ampersand, it has a name, and it ends with a semicolon.
So for example, if you want a Less Than to appear as part of your text in HTML, instead of coding a Less Than sign, you code amper LT semicolon. And as I said, this creates a problem for an ampersand. An Ampersand is coded as & And there's a whole bunch of these.
The one that's probably used the most, more than anything else, is the one for a space. People who have coded a lot of HTML soon realize that multiple spaces disappear. So if I code a word and I code hundreds of spaces, then I code another word, the two words only appear on the screen one space apart. But if I really want them to appear two spaces or three spaces apart, I need a special character, which is the space character, which has a name different than you'd expect, I think. It's , which I think stands for non-breaking space. But those things are coded a lot, and if you wanted a couple of them, you would just code , You'd just put as many of them -- just squeeze them right next to each other, as many as you want -- and actually you'll force that many spaces. GM: One of the other topics which I'd like to cover and I don't think was covered in the Virtual Seminar CD, image maps and frames. Is this a part of HTML? How would I learn more about these?
HS: Yeah, I think we have given people two URL's on the website, one for frames and one for image maps. And an interesting thing about frames is that frames were not really part of HTML 3.2, although everybody used them, implemented them, and so forth. And in fact, one of the three flavors of HTML 4.0 is HTML 4.0 Frame Set, which is just pointing out the fact that frames at last are now part of the standard, because they weren't before.
And if you look at how you do frames, what you'll see is you'll see that's the area of HTML and HTML 3.2 with the biggest variations between IE and Netscape. If people will only follow the 4.0 standard, maybe we'll get away from that. It's the reason that when you look in frames with two different browsers, they tended to be a little bit creaky, because there was no standard and people just made this whole thing up. Fortunately, the 4.0 standard took what appears to be the best features and the most common implementations and made them part of the standard. So a lot of what people were doing, at least, are in the standard.
JB: So the browsers should, in fact, be able to handle the frames much more effectively than they have in the past, then?
HS: Right. In the future, they'll be able to do that.
JB: One of the things that we have within -- I'm sorry, I lost what I was going to say, Howard. In terms of the frames, that some of the text is hidden and there's no scroll bars, does the new standard help me to avoid building that kind of frame?
HS: Well, that was never a problem with the standards. That was always a problem with the people who were putting these things together. And I think it's part of a general problem in that I tend to develop on a screen that's 17 inches diagonally, and so does everybody else in the group here. We all have these nice, big screens. And I think that sometimes people forget that these things are going to be viewed on screens that are smaller, or different, or people are going to look at them on laptops and things like that. So a lot of the frame screens were developed on big screens and everybody realized, well, you could see all the text and therefore they let the things out.
There are features in frames, both in the--well, there was no old standard, but there are features in the old non-standard and in the new standard that let users move the edges of the frames around that automatically put scroll bars in when they're necessary. And I think that designers should just consider the fact that people might be looking at these things on very small screens. And even if they're looking at them on big screens, they might have several windows up on their screens, and so for all intents and purposes, they might have the thing inside the small window on a screen, and they should let some of these automatic features--they should not decide I should not see scroll bars. They should make decisions that say I should see scroll bars if I need to see them.
JB: Well, good. Those are some good hints, Howard. GM: Maybe as a last question, as we get near the closing here, with respect to image maps -- if I know that some of my user audience is still running with browsers that can't handle image maps, should I still go ahead and take advantage of them?
HS: Yeah. It turns out there's an ALT feature in these things, so what you can do is you could -- it's not quite as good, but you can at least display some text that says what the thing is. As listeners and people here also realize, that whenever you do almost anything in HTML can display an image and somebody can't see it, you have the option of coding some ALT text that might say something like "This is a picture of a building."
I've just been handed a note from one of my friends here in the building who has been listening in here -- Steven Aubin, in case he's still out there. He's (inaudible) asking if some little bit of research back on the question that was asked earlier about can we determine what browser you're using inside HTML? And he has the word CAN underlined here. He says he can do it with JavaScript -- that you can tell the difference between Netscape and IE. Perhaps we will find out exactly how you do that and put a note about that out on the CREN site.
JB: All right. Sounds good. Sounds like it might link into our session next week as well, Howard.
HS: Two weeks from now.
JB: Two weeks from now, I'm sorry. Yes. Yes. In fact, we probably don't want to close today without making some comment about the announcement that was taking up a fair amount of ink space today in press and all, regarding AOL having increased the pricing of their unlimited service. Were you surprised by that?
HS: I hadn't read that. So you're saying they're not going to --
JB: Oh, they've increased the cost of the unlimited access from $19.95 a month to $21.95 a month, partially because, interestingly enough, they said that their users 18 months ago had started being online about seven hours a month, and now it's up to something like over 20 hours a month. I found that fairly interesting.
HS: Yeah, I think it's going to be interesting to see what all the other services follow along. $19.95 seemed like such a good marketing number, and 21 whatever-it-is sounds like a very strange number. I thought the rule was you had to end things in nine.
JB: Well, it's $21.95, so it's close enough, I guess. Anyway, okay, did we have any other question, Howard or Greg, that we'd like to --
GM: I think we've handled them.
JB: We've handled them all. All right, good. Let's do the little bit of wrap-up then and thank everyone for being here today, and to be sure to use the utw@cren.net for follow-up questions. And Howard, I like your suggestion that we perhaps find a little bit more about the exact answer to how does one tell what browser you are, and follow up on the CREN website on that.
HS: In fact, I have the answer sitting in front of me, but it's more than I think we want to go through. But we'll get something about this out there.
JB:. All right. And I'd like to remind everyone, too, that the next session will be two weeks and two days from today, on Thursday, February 26 at 2:00. Did we do that at 2:00?
GM: 2:30.
JB: 2:30, all right, and the topic will be the future of Java and JavaScript. And the exact time will be up on the Web. Also watch for a similar message about access instructions, the new phone number and new URL just prior to the next Expert Event. If you did not get your own announcement message about this session, you can be sure to send e-mail to cren@cren.net, and we'll add you to the list so you have a little more awareness about when these are coming.
Howard, all the event participants, thanks for being here, and also thanks to everyone who made it possible today. That includes the board of CREN, Corporation for Research in Educational Networking; our guest expert, Howard Srauss from Princeton; Greg Marks at MERIT; C. L. Phillips at UM Online for the audio services; and all of you with us on the phone and on the Web. You were here because it's time. 'bye, Howard, 'bye Greg. Take care.
HS: 'Bye-bye.
