HTML5编程指南：马克·皮格里姆版

需积分: 10 53 浏览量更新于2024-07-26 收藏 5.56MB PDF 举报

"HTML5揭秘——Mark Pilgrim的文字版" HTML5是互联网开发领域的一个重要里程碑，它极大地扩展了HTML（超文本标记语言）的功能，提高了网页的交互性和表现力。《HTML5: Up and Running》是由Mark Pilgrim编著的一本经典教材，专门探讨这个新一代的网页标准。这本书不仅适合初学者作为入门指南，也对有经验的开发者具有极高的参考价值，是提升HTML5技能的必备读物。 HTML5的核心目标是简化开发过程，增强网页的可用性，并提供更好的离线存储、多媒体支持和设备访问能力。书中详细讲解了以下几个关键知识点： 1. **结构元素**：HTML5引入了新的结构元素，如<header>, <nav>, <article>, <section>, <aside>和<footer>等，这些元素有助于提高网页的语义化，使得内容更易于理解和解析。 2. **多媒体支持**：HTML5支持内建的音频和视频元素(<audio>和<video>)，无需依赖Flash或其他插件，可以直接在浏览器中播放多媒体内容。同时，提供了API接口用于控制媒体播放，如播放、暂停、音量调整等。 3. **Canvas和SVG**：HTML5的Canvas提供了一个可编程的2D绘图环境，允许开发者动态绘制图形，而SVG则是一种矢量图形格式，支持复杂的图形渲染和动画效果。 4. **离线存储**：通过离线存储机制（如AppCache），HTML5允许网站在用户离线时也能访问部分数据，提高了Web应用的可用性和用户体验。 5. **表单控件**：HTML5对表单控件进行了改进，新增了如<date>, <time>, <range>, <color>等类型，增强了表单验证功能，使用户输入的数据更加规范。 6. **Web Workers和Web Storage**：Web Workers允许在后台运行脚本，提高了网页的计算性能；Web Storage（包括localStorage和sessionStorage）提供了比Cookie更大的存储空间，用于在本地存储用户数据。 7. **Geolocation API**：HTML5的地理定位API允许网站获取用户的地理位置信息，为开发基于位置的应用提供了可能。 8. **WebRTC**：虽然在原书中可能未详细讨论，但WebRTC是HTML5的重要补充，它提供了实时通信的能力，使得浏览器之间可以直接进行音视频通话和数据共享。 9. ** Accessibility**：HTML5对无障碍访问(Accessibility)做了改进，确保残障人士也能无障碍地浏览和使用网页。 10. **CSS3配合使用**：HTML5与CSS3的结合使用，可以实现更丰富、更具吸引力的网页设计，如多列布局、过渡和动画效果、响应式设计等。 Mark Pilgrim的这本书深入浅出地讲解了这些特性，通过实例演示和实战练习，帮助读者掌握HTML5的实际应用。无论是在面试中展现自己的技术功底，还是在项目开发中提升工作效率，这本书都是一个宝贵的参考资料。同时，O'Reilly Media的出版品质保证了内容的专业性和权威性。

stylesheets have their own MIME type. Everything has its own MIME type. The Web

runs on MIME types.

Of course, reality is more complicated than that. Very early web servers (I’m talking

web servers from 1993) didn’t send the Content-Type header, because it didn’t exist yet.

(It wasn’t invented until 1994.) For compatibility reasons that date all the way back to

1993, some popular web browsers will ignore the Content-Type header under certain

circumstances. (This is called “content sniffing.”) But as a general rule of thumb, ev-

erything you’ve ever looked at on the Web—HTML pages, images, scripts, videos,

PDFs, anything with a URL—has been served to you with a specific MIME type in the

Content-Type header.

Tuck that under your hat. We’ll come back to it.

A Long Digression into How Standards Are Made

Why do we have an <img> element? I don’t suppose that’s a question you ask yourself

very often. Obviously someone must have created it. These things don’t just appear out

of nowhere. Every element, every attribute, every feature of HTML that you’ve ever

used—someone created them, decided how they should work, and wrote it all down.

These people are not gods, nor are they flawless. They’re just people. Smart people, to

be sure. But just people.

One of the great things about standards that are developed “out in the open” is that

you can go back in time and answer these kinds of questions. Discussions occur on

mailing lists, which are usually archived and publicly searchable. So, I decided to do a

bit of “email archaeology” to try to answer the <img> element question. I had to go back

to before there was an organization called the World Wide Web Consortium (W3C).

I went back to the earliest days of the Web, when you could count the number of web

servers on the fingers of both hands, and maybe a couple of toes.

On February 25, 1993, Marc Andreessen wrote:

I’d like to propose a new, optional HTML tag:

IMG

Required argument is SRC="url".

This names a bitmap or pixmap file for the browser to attempt to pull over the network

and interpret as an image, to be embedded in the text at the point of the tag’s occurrence.

An example is:

(There is no closing tag; this is just a standalone tag.)

* http://1997.webhistory.org/www.lists/www-talk.1993q1/0182.html. The thread described over the next

several pages can be followed by clicking the “Next message” and “Previous message” links.

2 | Chapter 1: How Did We Get Here?

This tag can be embedded in an anchor like anything else; when that happens, it becomes

an icon that’s sensitive to activation just like a regular text anchor.

Browsers should be afforded flexibility as to which image formats they support. Xbm

and Xpm are good ones to support, for example. If a browser cannot interpret a given

format, it can do whatever it wants instead (X Mosaic will pop up a default bitmap as a

placeholder).

This is required functionality for X Mosaic; we have this working, and we’ll at least be

using it internally. I’m certainly open to suggestions as to how this should be handled

within HTML; if you have a better idea than what I’m presenting now, please let me

know. I know this is hazy with regard to image format, but I don’t see an alternative than

to just say “let the browser do what it can” and wait for the perfect solution to come

along (MIME, someday, maybe).

This quote requires some explanation. Xbm and Xpm were popular graphics formats

on Unix systems.

“Mosaic” was one of the earliest web browsers. (“X Mosaic” was the version that ran

on Unix systems.) When he wrote this message in early 1993, Marc had not yet founded

the company that made him famous, Mosaic Communications Corporation, nor had

he started work on that company’s flagship product, “Mosaic Netscape.” (You may

know them better by their later names, “Netscape Corporation” and “Netscape

Navigator.”)

“MIME, someday, maybe” is a reference to content negotiation, a feature of HTTP

where a client (like a web browser) tells the server (like a web server) what types of

resources it supports (like image/jpeg) so the server can return something in the client’s

preferred format. “The Original HTTP as defined in 1991” (the only version that was

implemented in February 1993) did not have a way for clients to tell servers what kinds

of images they supported, thus the design dilemma that Marc faced.

A few hours later, Tony Johnson replied:

I have something very similar in Midas 2.0 (in use here at SLAC, and due for public release

any week now), except that all the names are different, and it has an extra argument

NAME="name". It has almost exactly the same functionality as your proposed IMG tag. e.g.,

The idea of the name parameter was to allow the browser to have a set of “built in”

images. If the name matches a “built in” image it would use that instead of having to go

out and fetch the image. The name could also act as a hint for “line mode” browsers as

to what kind of a symbol to put in place of the image.

I don’t much care about the parameter or tag names, but it would be sensible if we used

the same things. I don’t much care for abbreviations, i.e., why not IMAGE= and SOURCE=. I

somewhat prefer ICON since it implies that the IMAGE should be smallish, but maybe

ICON is an overloaded word?

Midas was another early web browser, a contemporary of X Mosaic. It was cross-

platform; it ran on both Unix and VMS. “SLAC” refers to the Stanford Linear

Accelerator Center, now the SLAC National Accelerator Laboratory, which hosted the

A Long Digression into How Standards Are Made | 3

first web server in the United States (in fact, the first web server outside Europe). When

Tony wrote this message, SLAC was an old-timer on the WWW, having hosted five

pages on its web server for a whopping 441 days.

Tony continued:

While we are on the subject of new tags, I have another, somewhat similar tag, which I

would like to support in Midas 2.0. In principle it is:

The intention here would be that the second document is to be included into the first

document at the place where the tag occurred. In principle the referenced document

could be anything, but the main purpose was to allow images (in this case arbitrary sized)

to be embedded into documents. Again the intention would be that when HTTP2 comes

along the format of the included document would be up for separate negotiation.

“HTTP2” is a reference to Basic HTTP as defined in 1992. At this point, in early 1993,

it was still largely unimplemented. The draft known as “HTTP2” evolved and was

eventually standardized as “HTTP 1.0”. HTTP 1.0 did include request headers for

content negotiation, a.k.a. “MIME, someday, maybe.”

Tony went on:

An alternative I was considering was:

<A HREF="..." INCLUDE>See photo</A>

I don’t much like adding more functionality to the <A> tag, but the idea here is to maintain

compatibility with browsers that can not honour the INCLUDE parameter. The intention

is that browsers which do understand INCLUDE, replace the anchor text (in this case “See

photo”) with the included document (picture), while older or dumber browsers ignore

the INCLUDE tag completely.

This proposal was never implemented, although the idea of providing text if an image

is missing is an important accessibility technique that was missing from Marc’s initial

<IMG> proposal. Many years later, this feature was bolted on as the <img alt>

attribute, which Netscape promptly broke by erroneously treating it as a tooltip.

A few hours after Tony posted his message, Tim Berners-Lee responded:

I had imagined that figures would be represented as

<a name=fig1 href="fghjkdfghj" REL="EMBED, PRESENT">Figure </a>

where the relationship values mean

EMBED Embed this here when presenting it

PRESENT Present this whenever the source document is presented

Note that you can have various combinations of these, and if the browser doesn’t support

either one, it doesn’t break.

[I] see that using this as a method for selectable icons means nesting anchors. Hmmm.

But I hadn’t wanted a special tag.

4 | Chapter 1: How Did We Get Here?

This proposal was never implemented, but the rel attribute is still around (see “Friends

and (Link) Relations” on page 36).

Jim Davis added:

It would be nice if there was a way to specify the content type, e.g.

But I am completely willing to live with the requirement that I specify the content type

by file extension.

This proposal was never implemented, but Netscape did later add support for arbitrary

embedding of media objects with the <embed> element.

Jay C. Weber asked:

While images are at the top of my list of desired medium types in a WWW browser, I

don’t think we should add idiosyncratic hooks for media one at a time. Whatever hap-

pened to the enthusiasm for using the MIME typing mechanism?

Marc Andreessen replied:

This isn’t a substitute for the upcoming use of MIME as a standard document mecha-

nism; this provides a necessary and simple implementation of functionality that’s needed

independently from MIME.

Jay C. Weber responded:

Let’s temporarily forget about MIME, if it clouds the issue. My objection was to the

discussion of “how are we going to support embedded images” rather than “how are we

going to support embedded objections in various media.”

Otherwise, next week someone is going to suggest “let’s put in a new tag <AUD

SRC="file://foobar.com/foo/bar/blargh.snd">” for audio.

There shouldn’t be much cost in going with something that generalizes.

With the benefit of hindsight, it appears that Jay’s concerns were well founded. It took

a little more than a week, but HTML5 did finally add new <video> and <audio> elements.

Responding to Jay’s original message, Dave Raggett said:

True indeed! I want to consider a whole range of possible image/line art types, along with

the possibility of format negotiation. Tim’s note on supporting clickable areas within

images is also important.

Later in 1993, Dave proposed HTML+ as an evolution of the HTML standard. The

proposal was never implemented, and it was superseded by HTML 2.0. HTML 2.0 was

a “retro-spec,” which means it formalized features already in common use: “This

specification brings together, clarifies, and formalizes a set of features that roughly

corresponds to the capabilities of HTML in common use prior to June 1994.”

A Long Digression into How Standards Are Made | 5

Dave later wrote HTML 3.0, based on his earlier HTML+ draft. Outside of the W3C’s

own reference implementation, Arena, HTML 3.0 was never implemented. It was su-

perseded by HTML 3.2, which was also a “retro-spec”: “HTML 3.2 adds widely

deployed features such as tables, applets and text flow around images, while providing

full backward compatibility with the existing standard HTML 2.0.”

Dave later coauthored HTML 4.0, developed HTML Tidy, and went on to help with

XHTML, XForms, MathML, and other modern W3C specifications.

Getting back to 1993, Marc replied to Dave:

Actually, maybe we should think about a general-purpose procedural graphics language

within which we can embed arbitrary hyperlinks attached to icons, images, or text, or

anything. Has anyone else seen Intermedia’s capabilities with regard to this?

Intermedia was a hypertext project from Brown University. It was developed from 1985

to 1991 and ran on A/UX, a Unix-like operating system for early Macintosh computers.

The idea of a “general-purpose procedural graphics language” did eventually catch on.

Modern browsers support both SVG (declarative markup with embedded scripting)

and <canvas> (a procedural direct-mode graphics API), although the latter started as a

proprietary extension before being “retro-specced” by the WHAT Working Group.

Bill Janssen replied:

Other systems to look at which have this (fairly valuable) notion are Andrew and Slate.

Andrew is built with _insets_, each of which has some interesting type, such as text,

bitmap, drawing, animation, message, spreadsheet, etc. The notion of arbitrary recursive

embedding is present, so that an inset of any kind can be embedded in any other kind

which supports embedding. For example, an inset can be embedded at any point in the

text of the text widget, or in any rectangular area in the drawing widget, or in any cell of

the spreadsheet.

“Andrew” is a reference to the Andrew User Interface System, although at that time it

was simply known as the Andrew Project.

Meanwhile, Thomas Fine had a different idea:

Here’s my opinion. The best way to do images in WWW is by using MIME. I’m sure

postscript is already a supported subtype in MIME, and it deals very nicely with mixing

text and graphics.

But it isn’t clickable, you say? Yes, you’re right. I suspect there is already an answer to

this in display postscript. Even if there isn’t the addition to standard postscript is trivial.

Define an anchor command which specifies the URL and uses the current path as a closed

region for the button. Since postscript deals so well with paths, this makes arbitrary

button shapes trivial.

Display PostScript was an onscreen rendering technology codeveloped by Adobe and

NeXT.

This proposal was never implemented, but the idea that the best way to fix HTML is

to replace it with something else altogether still pops up from time to time.

6 | Chapter 1: How Did We Get Here?

剩余221页未读，继续阅读

midsummer1110

粉丝: 0
资源: 2

HTML5编程指南：马克·皮格里姆版

Python基于yolo的健身姿势检测与姿态矫正建议系统源代码+使用说明

使用谷歌地球引擎（GEE）和 Python 在孟加拉国西北部绘制基于机器学习算法的作物类型图.ipynb

【光伏预测】基于蛇群优化算法SO优化高斯过程回归GPR实现光伏多输入单输出预测附Matlab代码.rar

【光伏预测】基于鹈鹕优化算法POA优化高斯过程回归GPR实现光伏多输入单输出预测附Matlab代码.rar

深度学习图形识别点位知识

【创新未发表】Matlab实现引力搜索优化算法GSA-GRU实现风电数据预测算法研究.rar

【元胞自动机】基于matlab元胞自动机交通流仿真带有弯道的单车道（含时空图）【含Matlab源码 9047期】.mp4

编译原理实战-基于c语言实现表达式计算器+项目源码+文档说明

毕业设计&课设-用于 Spring Boot 的开源渗透框架及高危漏洞利用工具.zip

【创新未发表】Matlab实现人工蜂鸟优化算法AHA-GRU实现风电数据预测算法研究.rar

最新资源