Definition and Usage

The http-equiv attribute provides an HTTP header for the information/value of the content attribute.

The http-equiv attribute can be used to simulate an HTTP response header.


Differences Between HTML 4.01 and HTML5

Using http-equiv is no longer the only way to specify the character set of an HTML document:

  • HTML 4.01: <meta http-equiv="content-type" content="text/html; charset=UTF-8">
  • HTML5: <meta charset="UTF-8">

Syntax

<meta http-equiv="content-type|default-style|refresh">

Attribute Values

ValueDescription
content-typeSpecifies the character encoding for the document.

Example:

<meta http-equiv="content-type" content="text/html; charset=UTF-8">

default-styleSpecified the preferred style sheet to use.

Example:

<meta http-equiv="default-style" content="the document's preferred stylesheet">

Note: The value of the content attribute above must match the value of the title attribute on a link element in the same document, or it must match the value of the title attribute on a style element in the same document.

refreshDefines a time interval for the document to refresh itself.

Example:

<meta http-equiv="refresh" content="300">

Note: The value "refresh" should be used carefully, as it takes the control of a page away from the user. Using "refresh" will cause a failure in W3C's Web Content Accessibility Guidelines.




source - http://www.w3schools.com/Tags/att_meta_http_equiv.asp









정의

http-equiv 속성은 meta 요소에서 정의된 명령(사항)을 먼저 실행한 후에 페이지를 로딩합니다. 이를 프라그마 디렉티브pragma directive라고 합니다.

속성 값

속성 값은 나열 속성입니다.

키워드설명
content-language전처리될 기본 언어를 지정할 수 있습니다. 선언하지 않는 경우 기본언어가 존재하지 않는것으로 간주합니다.
content-type이 속성은 문자 인코딩을 선언합니다. content속성의 문자열 “text/html”와 아스키,대문자 구별없이 일치해야 합니다. 그뒤 리터럴 문자열 charset이 따라와야 하고 문자인코딩에 해당하는 이름이 있어야 합니다. XML에서는 http-equiv속성을 사용할 수 없습니다.
default-style대체 스타일시트 집합의 이름을 설정합니다.
refresh리다이렉트처럼 페이지를 지정한 시간이후에 새로고침을 할 수 있습니다. 값은 유요한 정수로만 구성되어야 합니다. 새로고침되기까지 시간을 초 단위로 나타냅니다.
set-cookiehttp쿠키를 설정할 수 있습니다. 이 속성은 올바르지 않기때문에 실제 http헤드를 사용해야 합니다.

예제

예제1 - content-language 속성

<meta http-equiv="content-language" content="ko" />

예제2 - content-type 속성

<meta http-equiv="Content-Type" content="text/html; charset=euc-kr">

예제3 - default-style 속성

 <meta http-equiv="content-style-type" content="text/css">

예제4 - refresh 속성

<meta http-equiv="refresh" content="10, www.naver.com">

10초뒤 www.naver.com으로 페이지를 이동합니다.

이밖에도 다음과 같은 속성 값들을 사용할 수 있습니다.

지정 시간 이후에는 웹문서 캐쉬(cache) 금지:

2011년 5월 2일 이후부터 웹문서 캐쉬를 금지합니다.

<meta http-equiv="expires" content="wed, 02 may 2011 00:00:01 GMT">

문자 형식 지정

HTML은 ISO코드, 완성형 코드등의 다양한 문자셋을 지정합니다. 일반적으로 ISO 코드를 많이 사용합니다.

<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-5">

스크립트 형식 지정

스크립트 형식에는 text/javascript(자바스크립트) 와 VBScript(비쥬얼베이직 스크립트)가 있습니다.

<meta http-equiv="Content-Script-Type" content="text/javascript">

스타일시트 형식 지정

<meta http-equiv="Content-Style-Type" content="text/css">

웹문서를 들어오거나 나갈때 효과주기

속성값이 Page-Enter, Page-Exit는 웹문서를 들어오거나 나갈 때 한쪽 모서리 부터 서서히 드러나거나 사라지는 효과를 줍니다.

<meta http-equiv="Page-Enter" content="RevealTrans(Duration=10, Transition=50)">
<meta http-equiv="Page-Exit" content="RevealTrans(Duration=10, Transition=50)">

참조

기준 명세를 바탕으로 명세 번역과 레퍼런스 제작이 이루어졌습니다. 최근 내용은 최신 명세를 확인해 주세요.



출처 - http://html5ref.clearboth.org/html5:attribute:http-equiv_meta










4.2.5 The meta element

Categories:
Metadata content.
Contexts in which this element can be used:
If the charset attribute is present, or if the element's http-equiv attribute is in the encoding declaration state: in a head element.
If the http-equiv attribute is present but not in the encoding declaration state: in a head element.
If the http-equiv attribute is present but not in the encoding declaration state: in a noscript element that is a child of a head element.
If the name attribute is present: where metadata content is expected.
Content model:
Empty.
Content attributes:
Global attributes
name — Metadata name
http-equiv — Pragma directive
content — Value of the element
charset — Character encoding declaration
Tag omission in text/html:
No end tag.
Allowed ARIA role attribute values:
none
Allowed ARIA state and property attributes:
Global aria-* attributes
DOM interface:
interface HTMLMetaElement : HTMLElement {
           attribute DOMString name;
           attribute DOMString httpEquiv;
           attribute DOMString content;
};

The meta element represents various kinds of metadata that cannot be expressed using the titlebaselinkstyle, and script elements.

The meta element can represent document-level metadata with the name attribute, pragma directives with the http-equiv attribute, and the file's character encoding declaration when an HTML document is serialized to string form (e.g. for transmission over the network or for disk storage) with the charset attribute.

Exactly one of the namehttp-equiv, and charset, attributes must be specified.

If either name or http-equiv is specified, then the content attribute must also be specified. Otherwise, it must be omitted.

The charset attribute specifies the character encoding used by the document. This is a character encoding declaration. If the attribute is present in an XML document, its value must be anASCII case-insensitive match for the string "UTF-8" (and the document is therefore forced to use UTF-8 as its encoding).

The charset attribute on the meta element has no effect in XML documents, and is only allowed in order to facilitate migration to and from XHTML.

There must not be more than one meta element with a charset attribute per document.

The content attribute gives the value of the document metadata or pragma directive when the element is used for those purposes. The allowed values depend on the exact context, as described in subsequent sections of this specification.

If a meta element has a name attribute, it sets document metadata. Document metadata is expressed in terms of name-value pairs, the name attribute on the meta element giving the name, and the content attribute on the same element giving the value. The name specifies what aspect of metadata is being set; valid names and the meaning of their values are described in the following sections. If a meta element has no content attribute, then the value part of the metadata name-value pair is the empty string.

The name and content IDL attributes must reflect the respective content attributes of the same name. The IDL attribute httpEquiv must reflect the content attribute http-equiv.

4.2.5.1 Standard metadata names

This specification defines a few names for the name attribute of the meta element.

Names are case-insensitive, and must be compared in an ASCII case-insensitive manner.

application-name

The value must be a short free-form string giving the name of the Web application that the page represents. If the page is not a Web application, the application-name metadata name must not be used. Translations of the Web application's name may be given, using the attribute to specify the language of each name.

There must not be more than one meta element with a given language and with its name attribute set to the value application-name per document.

User agents may use the application name in UI in preference to the page's title, since the title might include status messages and the like relevant to the status of the page at a particular moment in time instead of just being the name of the application.

To find the application name to use given an ordered list of languages (e.g. British English, American English, and English), user agents must run the following steps:

  1. Let languages be the list of languages.

  2. Let default language be the language of the Document's root element, if any, and if that language is not unknown.

  3. If there is a default language, and if it is not the same language as any of the languages is languages, append it to languages.

  4. Let winning language be the first language in languages for which there is a meta element in the Document that has its name attribute set to the value application-name and whoselanguage is the language in question.

    If none of the languages have such a meta element, then abort these steps; there's no given application name.

  5. Return the value of the content attribute of the first meta element in the Document in tree order that has its name attribute set to the value application-name and whose language iswinning language.

author

The value must be a free-form string giving the name of one of the page's authors.

description

The value must be a free-form string that describes the page. The value must be appropriate for use in a directory of pages, e.g. in a search engine. There must not be more than onemeta element with its name attribute set to the value description per document.

generator

The value must be a free-form string that identifies one of the software packages used to generate the document. This value must not be used on pages whose markup is not generated by software, e.g. pages whose markup was written by a user in a text editor.

Here is what a tool called "Frontweaver" could include in its output, in the page's head element, to identify itself as the tool used to generate the page:

<meta name=generator content="Frontweaver 8.2">
keywords

The value must be a set of comma-separated tokens, each of which is a keyword relevant to the page.

This page about typefaces on British motorways uses a meta element to specify some keywords that users might use to look for the page:

<!DOCTYPE HTML>
<html>
 <head>
  <title>Typefaces on UK motorways</title>
  <meta name="keywords" content="british,type face,font,fonts,highway,highways">
 </head>
 <body>
  ...

Many search engines do not consider such keywords, because this feature has historically been used unreliably and even misleadingly as a way to spam search engine results in a way that is not helpful for users.

To obtain the list of keywords that the author has specified as applicable to the page, the user agent must run the following steps:

  1. Let keywords be an empty list.

  2. For each meta element with a name attribute and a content attribute and whose name attribute's value is keywords, run the following substeps:

    1. Split the value of the element's content attribute on commas.

    2. Add the resulting tokens, if any, to keywords.

  3. Remove any duplicates from keywords.

  4. Return keywords. This is the list of keywords that the author has specified as applicable to the page.

User agents should not use this information when there is insufficient confidence in the reliability of the value.

For instance, it would be reasonable for a content management system to use the keyword information of pages within the system to populate the index of a site-specific search engine, but a large-scale content aggregator that used this information would likely find that certain users would try to game its ranking mechanism through the use of inappropriate keywords.

4.2.5.2 Other metadata names

Extensions to the predefined set of metadata names may be registered in the WHATWG Wiki MetaExtensions page[WHATWGWIKI]

Anyone is free to edit the WHATWG Wiki MetaExtensions page at any time to add a type. These new names must be specified with the following information:

Keyword

The actual name being defined. The name should not be confusingly similar to any other defined name (e.g. differing only in case).

Brief description

A short non-normative description of what the metadata name's meaning is, including the format the value is required to be in.

Specification
A link to a more detailed description of the metadata name's semantics and requirements. It could be another page on the Wiki, or a link to an external page.
Synonyms

A list of other names that have exactly the same processing requirements. Authors should not use the names defined to be synonyms, they are only intended to allow user agents to support legacy content. Anyone may remove synonyms that are not used in practice; only names that need to be processed as synonyms for compatibility with legacy content are to be registered in this way.

Status

One of the following:

Proposed
The name has not received wide peer review and approval. Someone has proposed it and is, or soon will be, using it.
Ratified
The name has received wide peer review and approval. It has a specification that unambiguously defines how to handle pages that use the name, including when they use it in incorrect ways.
Discontinued
The metadata name has received wide peer review and it has been found wanting. Existing pages are using this metadata name, but new pages should avoid it. The "brief description" and "specification" entries will give details of what authors should use instead, if anything.

If a metadata name is found to be redundant with existing values, it should be removed and listed as a synonym for the existing value.

If a metadata name is registered in the "proposed" state for a period of a month or more without being used or specified, then it may be removed from the registry.

If a metadata name is added with the "proposed" status and found to be redundant with existing values, it should be removed and listed as a synonym for the existing value. If a metadata name is added with the "proposed" status and found to be harmful, then it should be changed to "discontinued" status.

Anyone can change the status at any time, but should only do so in accordance with the definitions above.

Conformance checkers may use the information given on the WHATWG Wiki MetaExtensions page to establish if a value is allowed or not: values defined in this specification or marked as "proposed" or "ratified" must be accepted, whereas values marked as "discontinued" or not listed in either this specification or on the aforementioned page must be reported as invalid. Conformance checkers may cache this information (e.g. for performance reasons or to avoid the use of unreliable network connectivity).

When an author uses a new metadata name not defined by either this specification or the Wiki page, conformance checkers should offer to add the value to the Wiki, with the details described above, with the "proposed" status.

Metadata names whose values are to be URLs must not be proposed or accepted. Links must be represented using the link element, not the meta element.

4.2.5.3 Pragma directives

When the http-equiv attribute is specified on a meta element, the element is a pragma directive.

The http-equiv attribute is an enumerated attribute. The following table lists the keywords defined for this attribute. The states given in the first cell of the rows with keywords give the states to which those keywords map. Some of the keywords are non-conforming, as noted in the last column.

StateKeywordNotes
Content Languagecontent-languageNon-conforming
Encoding declarationcontent-type
Default styledefault-style
Refreshrefresh
Cookie setterset-cookieNon-conforming

When a meta element is inserted into the document, if its http-equiv attribute is present and represents one of the above states, then the user agent must run the algorithm appropriate for that state, as described in the following list:

Content language state (http-equiv="content-language")

This feature is non-conforming. Authors are encouraged to use the lang attribute instead.

This pragma sets the pragma-set default language. Until such a pragma is successfully processed, there is no pragma-set default language.

  1. If the meta element has no content attribute, then abort these steps.

  2. If the element's content attribute contains a "," (U+002C) character then abort these steps.

  3. Let input be the value of the element's content attribute.

  4. Let position point at the first character of input.

  5. Skip whitespace.

  6. Collect a sequence of characters that are not space characters.

  7. Let candidate be the string that resulted from the previous step.

  8. If candidate is the empty string, abort these steps.

  9. Set the pragma-set default language to candidate.

This pragma is almost, but not quite, entirely unlike the HTTP Content-Language header of the same name. [HTTP]

encoding declaration state (http-equiv="content-type")

The encoding declaration state is just an alternative form of setting the charset attribute: it is a character encoding declarationThis state's user agent requirements are all handled by the parsing section of the specification.

For meta elements with an http-equiv attribute in the Encoding declaration state, the content attribute must have a value that is an ASCII case-insensitive match for a string that consists of: the literal string "text/html;", optionally followed by any number of space characters, followed by the literal string "charset=", followed by one of the labels of the character encodingof the character encoding declaration.

A document must not contain both a meta element with an http-equiv attribute in the encoding declaration state and a meta element with the charset attribute present.

The encoding declaration state may be used in HTML documents and in XML Documents. If the encoding declaration state is used in XML Documents, the name of the character encoding must be an ASCII case-insensitive match for the string "UTF-8" (and the document is therefore forced to use UTF-8 as its encoding).

The encoding declaration state has no effect in XML documents, and is only allowed in order to facilitate migration to and from XHTML.

Default style state (http-equiv="default-style")

This pragma sets the name of the default alternative style sheet set.

  1. If the meta element has no content attribute, or if that attribute's value is the empty string, then abort these steps.

  2. Set the preferred style sheet set to the value of the element's content attribute. [CSSOM]

Refresh state (http-equiv="refresh")

This pragma acts as timed redirect.

  1. If another meta element with an http-equiv attribute in the Refresh state has already been successfully processed (i.e. when it was inserted the user agent processed it and reached the last step of this list of steps), then abort these steps.

  2. If the meta element has no content attribute, or if that attribute's value is the empty string, then abort these steps.

  3. Let input be the value of the element's content attribute.

  4. Let position point at the first character of input.

  5. Skip whitespace.

  6. Collect a sequence of characters that are ASCII digits, and parse the resulting string using the rules for parsing non-negative integers. If the sequence of characters collected is the empty string, then no number will have been parsed; abort these steps. Otherwise, let time be the parsed number.

  7. Collect a sequence of characters that are ASCII digits and "." (U+002E) characters. Ignore any collected characters.

  8. Skip whitespace.

  9. Let url be the address of the current page.

  10. If the character in input pointed to by position is a ";" (U+003B) character or a "," (U+002C) character, then advance position to the next character. Otherwise, jump to the last step.

  11. Skip whitespace.

  12. If the character in input pointed to by position is a "U" (U+0055) character or a U+0075 LATIN SMALL LETTER U character (u), then advance position to the next character. Otherwise, jump to the last step.

  13. If the character in input pointed to by position is a "R" (U+0052) character or a U+0072 LATIN SMALL LETTER R character (r), then advance position to the next character. Otherwise, jump to the last step.

  14. If the character in input pointed to by position is s "L" (U+004C) character or a U+006C LATIN SMALL LETTER L character (l), then advance position to the next character. Otherwise, jump to the last step.

  15. Skip whitespace.

  16. If the character in input pointed to by position is a "=" (U+003D), then advance position to the next character. Otherwise, jump to the last step.

  17. Skip whitespace.

  18. If the character in input pointed to by position is either a "'" (U+0027) character or """ (U+0022) character, then let quote be that character, and advance position to the next character. Otherwise, let quote be the empty string.

  19. Let url be equal to the substring of input from the character at position to the end of the string.

  20. If quote is not the empty string, and there is a character in url equal to quote, then truncate url at that character, so that it and all subsequent characters are removed.

  21. Strip any trailing space characters from the end of url.

  22. Strip any "tab" (U+0009), "LF" (U+000A), and "CR" (U+000D) characters from url.

  23. Resolve the url value to an absolute URL, relative to the meta element. If this fails, abort these steps.

  24. Perform one or more of the following steps:

    In addition, the user agent may, as with anything, inform the user of any and all aspects of its operation, including the state of any timers, the destinations of any timed redirects, and so forth.

For meta elements with an http-equiv attribute in the Refresh state, the content attribute must have a value consisting either of:

In the former case, the integer represents a number of seconds before the page is to be reloaded; in the latter case the integer represents a number of seconds before the page is to be replaced by the page at the given URL.

A news organization's front page could include the following markup in the page's head element, to ensure that the page automatically reloads from the server every five minutes:

<meta http-equiv="Refresh" content="300">

A sequence of pages could be used as an automated slide show by making each page refresh to the next page in the sequence, using markup such as the following:

<meta http-equiv="Refresh" content="20; URL=page4.html">
Cookie setter (http-equiv="set-cookie")

This pragma sets an HTTP cookie. [COOKIES]

It is non-conforming. Real HTTP headers should be used instead.

  1. If the meta element has no content attribute, or if that attribute's value is the empty string, then abort these steps.

  2. Obtain the storage mutex.

  3. Act as if receiving a set-cookie-string for the document's address via a "non-HTTP" API, consisting of the value of the element's content attribute encoded as UTF-8. [COOKIES][RFC3629]

There must not be more than one meta element with any particular state in the document at a time.

4.2.5.4 Other pragma directives

Extensions to the predefined set of pragma directives may, under certain conditions, be registered in the WHATWG Wiki PragmaExtensions page[WHATWGWIKI]

Such extensions must use a name that is identical to an HTTP header registered in the Permanent Message Header Field Registry, and must have behavior identical to that described for the HTTP header. [IANAPERMHEADERS]

Pragma directives corresponding to headers describing metadata, or not requiring specific user agent processing, must not be registered; instead, use metadata names. Pragma directives corresponding to headers that affect the HTTP processing model (e.g. caching) must not be registered, as they would result in HTTP-level behavior being different for user agents that implement HTML than for user agents that do not.

Anyone is free to edit the WHATWG Wiki PragmaExtensions page at any time to add a pragma directive satisfying these conditions. Such registrations must specify the following information:

Keyword

The actual name being defined. The name must match a previously-registered HTTP name with the same requirements.

Brief description

A short non-normative description of the purpose of the pragma directive.

Specification
A link to the specification defining the corresponding HTTP header.

Conformance checkers must use the information given on the WHATWG Wiki PragmaExtensions page to establish if a value is allowed or not: values defined in this specification or listed on the aforementioned page must be accepted, whereas values not listed in either this specification or on the aforementioned page must be rejected as invalid. Conformance checkers may cache this information (e.g. for performance reasons or to avoid the use of unreliable network connectivity).

4.2.5.5 Specifying the document's character encoding

character encoding declaration is a mechanism by which the character encoding used to store or transmit a document is specified.

The following restrictions apply to character encoding declarations:

  • The character encoding name given must be an ASCII case-insensitive match for one of the labels of the character encoding used to serialize the file. [ENCODING]
  • The character encoding declaration must be serialized without the use of character references or character escapes of any kind.
  • The element containing the character encoding declaration must be serialized completely within the first 1024 bytes of the document.

In addition, due to a number of restrictions on meta elements, there can only be one meta-based character encoding declaration per document.

If an HTML document does not start with a BOM, and its encoding is not explicitly given by Content-Type metadata, and the document is not an iframe srcdoc document, then the character encoding used must be an ASCII-compatible character encoding, and the encoding must be specified using a meta element with a charset attribute or a meta element with an http-equivattribute in the encoding declaration state.

A character encoding declaration is required (either in the Content-Type metadata or explicitly in the file) even if the encoding is US-ASCII, because a character encoding is needed to process non-ASCII characters entered by the user in forms, in URLs generated by scripts, and so forth.

If the document is an iframe srcdoc document, the document must not have a character encoding declaration. (In this case, the source is already decoded, since it is part of the document that contained the iframe.)

If an HTML document contains a meta element with a charset attribute or a meta element with an http-equiv attribute in the encoding declaration state, then the character encoding used must be an ASCII-compatible character encoding.

Authors should use UTF-8. Conformance checkers may advise authors against using legacy encodings. [RFC3629]

Authoring tools should default to using UTF-8 for newly-created documents. [RFC3629]

Encodings in which a series of bytes in the range 0x20 to 0x7E can encode characters other than the corresponding characters in the range U+0020 to U+007E represent a potential security vulnerability: a user agent that does not support the encoding (or does not support the label used to declare the encoding, or does not use the same mechanism to detect the encoding of unlabeled content as another user agent) might end up interpreting technically benign plain text content as HTML tags and JavaScript. Authors should therefore not use these encodings. For example, this applies to encodings in which the bytes corresponding to "<script>" in ASCII can encode a different string. Authors should not use such encodings, which are known to include JIS_C6226-1983, JIS_X0212-1990, HZ-GB-2312, JOHAB (Windows code page 1361), encodings based on ISO-2022, and encodings based on EBCDIC. Furthermore, authors must not use the CESU-8, UTF-7, BOCU-1 and SCSU encodings, which also fall into this category; these encodings were never intended for use for Web content. [RFC1345] [RFC1842] [RFC1468][RFC2237] [RFC1554] [CP50220] [RFC1922] [RFC1557] [CESU8] [UTF7] [BOCU1] [SCSU]

Authors should not use UTF-32, as the encoding detection algorithms described in this specification intentionally do not distinguish it from UTF-16. [UNICODE]

Using non-UTF-8 encodings can have unexpected results on form submission and URL encodings, which use the document's character encoding by default.

In XHTML, the XML declaration should be used for inline character encoding information, if necessary.

In HTML, to declare that the character encoding is UTF-8, the author could include the following markup near the top of the document (in the head element):

<meta charset="utf-8">

In XML, the XML declaration would be used instead, at the very top of the markup:

<?xml version="1.0" encoding="utf-8"?>




source - http://www.w3.org/TR/html5/document-metadata.html#attr-meta-http-equiv







'Development > HTML' 카테고리의 다른 글

tr td 차이  (0) 2012.03.28
Tag들  (0) 2012.03.01
정중앙 위치 시키기  (0) 2011.01.31
html - div란?  (0) 2011.01.31
MIME type  (0) 2011.01.09
Posted by linuxism
,