/usr/local/apache/htdocs/lib/public_html/book/WEBMASTER/html20new.txt Библиотека на Meta.Ua Фреймы и др. дополнения, возникшие в HTML 0 и HTML 3
Попробуй новую версию Библиотеки!
Онлайн переводчик

Дополнения, возникшие в новых версиях HTML

Содержимое этого документа на самом деле надо смотреть в режиме

"View --> Document Source"

(иначе ничего полезного не увидите).

Фреймы - поле viewe-ра разбивается на несколько областей, в
каждую из которых грузится независимый документ.

Вообще-то они могут быть и зависимыми. Для этого один из
фреймов именуем, например "firstframe"

А в индексе, который грузится во Второй фрейм, в заголовке
дописываем строку:
Или можно дописать TAGET=firstframe внутри каждого отдельного

Теперь переход по всем ссылка, нажатым во Втором frame, будут
отрисовываться в firstframe. Если же фреймов на viewer'е нет,
то для перехода по ссылке будет запускаться новое окно.

И еще: какой-то глюк - frame лучше называть маленькими
буквами, с Большими Буквами в названии он повел себя как-то

Кроме описания frame в документе ничего не должно быть, иначе
frame не активизируется.

------- So, cut here -------------

This is an HTML2.0 enhanced document. In particular it makes
use of "frames". If your browser happens not to support frames
click here Ў ../unixhelp/httpd.txt


http://home.netscape.com/assist/net_sites/html_extensions_3.html Ў http://home.netscape.com/assist/net_sites/html_extensions_3.html

Netscape works with the Internet Engineering Task Force and the
World Wide Web Consortium to develop standards of the Internet.
Proposals that have been made since HTML 2.0 went into final
review have been grouped together as HTML 3.0. HTML 3.0 is getґ
ting closer to completion and embodies a wide range of useful

Netscape remains committed to supporting HTML 3.0. To that end,
we've gone ahead and implemented several of the more stable
proposals, in expectation that they will be approved. We beґ
lieve that Netscape Navigator 2.0 supports more of the HTML 3.0
specifications than any other commercial client.

In addition, we've also added several new areas of HTML funcґ
tionality to Netscape Navigator that are not currently in the
HTML 3.0 specification. We think they belong there, and as part
of the standards process, we are proposing them for inclusion.


(big print)
The BIG element specifies that the enclosed text should be
displayed, if practical, using a big font (compared with normal

(small print)
The SMALL element specifies that the enclosed text should be
displayed, if practical, using a small font (compared with norґ
mal text).

The SUB element specifies that the enclosed text should be
displayed as a subscript, and, if practical, using a smaller
font (compared with normal text). The ALIGN attribute for SUB
is only meaningful within the MATH element.

The SUP element specifies that the enclosed text should be
displayed as a superscript, and if practical, using a smaller
font (compared with normal text). The ALIGN attribute for SUP
is only applicable within the MATH element.



Netscape Navigator 2.0 supports the left, right, and center
ALIGN attributes of both P and DIV.


Image maps are an important feature of the point-and-click inґ
terface that makes the World Wide Web so popular. The most comґ
mon use of image maps is to allow users to access different
documents by clicking on different areas in an image.

There are several limitations of the current image map impleґ
mentation as it applies to this use. First, it only works over
the HTTP protocol, making it unusable for reading local files
or files accessed via alternate protocols. Second, a server
transaction is required merely to determine where the link is
directed. This can degrade performance noticeably when accessґ
ing distant sites. Third, unlike for normal links, there is no
way for a browser to provide visual feedback to the user by
showing where a portion of an image map leads before the user
actually clicks on it. Lastly, the implementation of image maps
is server-dependent, compromising portability of documents.

While HTML+1 contains provisions for "hypertext buttons" on imґ
ages via use of the FIG element, this method is an unworkable
short-term solution for several reasons. First, complete supґ
port of the FIG element requires significant additional proґ
cessing by the browser. Second, it cannot degrade gracefully on
browsers that do not support it. Third, it requires the map deґ
scription to be specified when the image appears, which is inґ
appropriate for some applications. The extension to support
client-side image maps addresses these issues.


Adding a USEMAP attribute to an IMG element indicates that it
is a client-side image map. The USEMAP attribute can be used
with the ISMAP attribute to indicate that the image can be proґ
cessed as either a client-side or server-side image map. The
argument to USEMAP specifies which map to use with the image,
in a format similar to the HREF attribute on anchors. If the
argument to USEMAP starts with a "#", it is assumed to be in
the same document as the IMG tag. A few examples would be:

You can only click here if your browser supports client-side image maps:

This image map will work regardless:
USEMAP="maps.html#map2" ISMAP>

Clicking here will take you to a page with an error message if
you don't have client-side image map support:

The different regions of the image are described using a MAP
element. The map describes each region in the image and indiґ
cates where it links. The basic format for the MAP element is
as follows:

The name specifies the name of the map so that it can be referґ
enced by an IMG element. The shape gives the shape of this
area. Currently supported shapes include rectangles (RECT),
polygons (POLY), circles (CIRCLE), and default (DEFAULT), but
the syntax is defined in a way that allows other shapes to be
added. If the SHAPE tag is omitted, SHAPE="RECT" is assumed.
The COORDS tag gives the coordinates of the shape, using image
pixels as the units. For a rectangle, the coordinates are given
as "left,top,right,bottom". The rectangular region defined inґ
cludes the lower right corner specified (i.e. to specify the
entire area of a 100-by-100-pixel image, the coordinates would
be "0,0,99,99"). Circles are defined as a center point and then
a radius (a total of three numbers).

The NOHREF tag indicates that clicks in this region should perґ
form no action. An HREF tag specifies where a click in that
area should lead. Note that a relative anchor specification
will be expanded using the URL of the map description as a
base, rather than using the URL of the document from which the
map description is referenced. If a BASE tag is present in the
document containing the map description, that URL will be used
as the base.

An arbitrary number of AREA tags may be specified. If two areas
intersect, the one that appears first in the map definition
takes precedence in the overlapping region. For example, a butґ
ton bar in a document might use a 160-by-60-pixel image and apґ
pear like this:

This example includes a region encompassing the entire image
with a NOHREF tag, but this is actually redundant. Any region
of the image that is not defined by an AREA tag is assumed to


This syntax provides maximum flexibility to the document author
for dealing with browsers that do not support this extension,
since such browsers will ignore the MAP and AREA elements. If
the document resides on an HTTP server, the server can still
provide ISMAP-style support. Otherwise, the author can choose
to have the image not appear as an anchor at all, or can choose
to have a click anywhere within it lead to another page, perґ
haps providing an equivalent textual list of options.

The demand for a non-HTTP-based mechanism for image maps will
also increase as archives of material in HTML format begins to
appear on CD-ROM. The expected increase in pay-per-access
servers will also lead to users saving copies of documents loґ
cally, which they would then expect to function identically to
those on the original server. The extensions described here
could serve as a basis to satisfy these needs.


1. Ragget, Dave, HTML+ Discussion Document


Previously, form input was limited to input boxes and other
simple elements like checkboxes and radio buttons. Now you can
write forms that ask for files as input. A new ENCTYPE atґ
tribute on the FORM tag allows you to write forms that take
files as input. An example of such a form would be:

Send this file:

Войти под своим именем

Текст сообщения:
Введите код:  

добавить сайт | реклама на портале | контекстная реклама | контакты Copyright © 1998-2019 <META> Все права защищены