(زبان نشانه گذاری ابر متن توسعه پذیر (ویرایش دوم :XHTML 1.0 (original) (raw)

چکیده

این مشخصات (فنی)، ویرایش دوم XHTML 1.0، فرمول بندی جدیدی از HTML 4 در قالب برنامه ای از XML 1.0 را مشخص می کند، و سه DTDمطابق با واحدهای تعریف شده توسط HTML 4 را تعیین می نماید. معناشناسی عناصر و ویژگی های آنها در توصیه نامه ی W3C برای HTML 4 تعیین شده اند. معناشناسی، چارچوبی برای توسعه پذیری XHTML در آینده را ارایه می نماید. سازگاری با مرورگرهای HTML موجود با پیروی از مجموعه رهنمودهای مختصری، امکانپذیر است.

شرح وضعیت این سند

در این بخش شرح وضعیت این سند در زمان انتشار آن بیان می شود. اسناد دیگری ممکن است جانشین این سند شوند. آخرین وضعیت این سری اسناد در W3Cنگهداری می شود.

این سند ویرایش دوم مشخصات (فنی) XHTML 1.0 به همراه تغییرات تصحیح نامه از تاریخ 1 اوت سال 2002 را شامل می شود. تغییرات میان این نسخه و توصیه نامه ی پیشین درنسخه ی نشانه گذاری شده ی متفاوتی تبیین شده است.

این ویرایش دوم نسخه جدیدی از XHTML 1.0 نیست (ویرایش نخست در 26 ژانویه ی سال 2000 منتشر شد). تغییرات این سند بازتاب تصحیحات اعمال شده ی مبتنی بر نظرات جامعه ی (کنسرسیوم وب) و نیز در نتیجه ی فعالیت مداوم در کارگروه HTML می باشد. در این سند هیچ تغییرات اساسی ای بجز گردآوری انواع اشتباهات تصحیح شده وجود ندارد.

لیست خطاهای شناخته شده در این مشخصات (فنی)(نسخه ی انگلیسی) در آدرس http://www.w3.org/2002/08/REC-xhtml1-20020801-errataقابل دسترس می باشد.

لطفا خطاهای موجود در این سند را در www-html-editor@w3.org (آرشیو) مطرح نموده و اطلاع دهید. بحث عمومی در رابطه با ویژگی های HTMLبر روی فهرست پستی www- html@w3.org (آرشیو) در جریان است.

این سند قبلا به عنوان بخشی از فعالیت HTML کنسرسیوم وب ارایه شده است. اهدافکارگروه HTML (ویژه ی اعضا) در منشور کارگروه HTMLمطرح شده است.

در زمان انتشار آن، کارگروه معتقد بود که حق امتیاز تبیین شده ای برای این مجموعه مشخصات (فنی) وجود ندارد. فهرست فعلی تبیین حق امتیاز مربوط به این مشخصات (فنی)، بر رویصفحه ی تبیین حق امتیازکارگروه یافت می شود.

لیستی از توصیه نامه های فعلی W3C و دیگر اسناد تخصصی در http://www.w3.org/TRموجود است.

فهرست مختصر مطالب

فهرست کامل مطالب

1. XHTML چیست؟

این قسمت حاوی اطلاعات مفید و آموزنده می باشد.

XHTML خانواده ای‌ از انواع اسناد و ماژول های موجود فعلی و آینده است که بازتولید، زیر مجموعه و توسعه‌ یافته ی HTML4]HTML 4] می باشد. انواع اسناد هم خانواده ی XHTML مبتنی بر XML هستند و در نهایت به منظور هماهنگی با مرورگرهای مبتنی بر XML طراحی شده اند. که جزئیات و مطالب تکمیلی آن به تفصیل در [XHTMLMOD] مورد بحث قرار گرفته است.

XHTML 1.0 (مشخصات فنی فعلی) اولین نوع سند از خانواده‌ی XHTML است که فرمول بندی جدیدی از سه نوع سند HTML 4 در قالب برنامه های کاربردی [XML 1.0 [XML می باشد. این بدین معنی است که زبانی برای محتوا است تا هم منطبق بر XML باشد و هم در صورتی که از برخیرهنمودهای ساده پیروی نماید، در HTML 4 مطابق با مرورگرها عمل نماید. توسعه دهنده هایی که محتوای (صفحات و وب سایت های) خویش را به XHTML 1.0 تغییر می دهند، از مزایای ذیل برخوردار می گردند:

خانواده‌ی XHTML گام بعدی در سیر تکاملی اینترنت می باشد. امروزه با استفاده از XHTML، توسعه دهندگان محتوا می توانند وارد دنیایXML شوند و در عین حال که هماهنگی و انطباق خود را با محتوای اسناد گذشته و آینده حفظ می نمایند می توانند از همه‌ی مزایای آن هم استفاده کنند.

1.1. HTML 4 چیست؟

HTML4] HTML4] یک زبان SGML (زبان نشانه گذاری عمومی شده‌ی استاندارد) کاربردی منطبق با استاندارد بین المللی ISO 8879است و به عنوان زبان استاندارد انتشار وب جهانی بسیار مورد توجه قرار گرفته است.

SGML زبانی برای توصیف زبانهای نشانه گذاری است، به ویژه زبانهایی که در تبادل سند الکترونیکی، مدیریت سند و انتشار سند استفاده شده اند. HTMLنمونه ای از یک زبان مبتنی بر SGML است.

SGML در نیمه ی دوم سال 1980 بوجود آمده و کاملا ثابت باقی مانده است. بخش اعظم این پایداری ناشی از این واقعیت است که از نظر محتوا غنی و انعطاف پذیر است. با این حال رسیدن به چنین سطحی از انعطاف پذیری کار چندان آسانی نیست و همین سختی گوشه ای از پیچیدگی های آن می باشد و همین امر مانع پذیرش آن در محیط های متنوع، از جمله در وب جهانی است.

HTML، همچنانکه که در ابتدا انتظار می رفت، قرار بر این بود زبانی جهت تبادل علمی و اسناد فنی دیگر و مناسب برای استفاده ی دیگر متخصصان هم باشد. HTML، مشکل پیچیدگی SGML را با تعیین مجموعه ی کوچکی از تگهای ساختاری و معنایی مناسب برای نوشتن اسناد نسبتا ساده رفع نموده است. علاوه بر ساده کردن ساختار سند، HTMLابر متن را هم مورد پشتیبانی قرار داد. سپس قابلیت های چند رسانه ای نیز به آن افزوده شد.

در مدت زمان بسیار کوتاهی، HTML محبوبیت بسیار زیادی یافت و چنان رشد و نموی پیدا کرد که با سرعت به هدف اصلی خود نائل آمد. پس از ظهور HTML، ابداع عناصر جدید جهت استفاده درون HTML(به عنوان استاندارد) و برای سازگاری HTML با بازارهای رو به رشد و بسیار تخصصی، سرعت گرفت. این ازدیاد عناصر جدید منجر به ایجاد مشکلاتی در تولید اسناد مناسب برای سیستم عامل های مختلف و محیط های متفاوت شده است.

1.2. XML چیست؟

™XML نام خلاصه شده‌ی زبان نشانه گذاری توسعه پذیر [XML] می‌باشد.

XML به عنوان روشی جهت بازیافت قدرت و انعطاف پذیریSGML فارغ از اکثر پیچیدگی های آن، شکل گرفت. اگرچه XML شکل ساده شده‌ی SGML است، لذا بیشتر قدرت و غنای SGML را محدود می نماید ولی در عین حال همچنان همه‌ی ویژگی های کاربردی معمول SGML را دارا می باشد.

در حین حفظ این ویژگی های مفید، XML از بیشتر ویژگی‌های پیچیده ی SGML که جهت برنامه نویسی و طراحی نرم افزارهای مناسب، مشکل و پر هزینه می باشند، صرف نظر می نماید.

1.3. چرا XHTML مورد نیاز است؟

مزایای تغییر جهت بسوی XHTML 1.0 در بالا توضیح داده شده است. برخی از مزایای تغییر جهت بسوی XHTML به طور کلی عبارتند از:

2. تعاریف

این بخش معمولی و استاندارد است.

2.1. اصطلاح شناسی

اصطلاحات ذیل در این مشخصات (فنی) بکار می روند. این اصطلاحات، تعاریف موجود در [RFC2119] را به شیوه های مبتنی بر تعاریف مشابه در [ISO/IEC 9945-1:1990 [POSIX.1بیان می کنند:

May

با توجه به کاربردهای آن، کلمه ی "may" به عنوان خصیصه ای اختیاری تفسیر می شود که وجود آن در این مشخصات (فنی) ضروری نیست اما می توان آنرا بکار گرفت. با توجه به همگونی سند، کلمه ی "may" بدین معنی است که خصیصه ی اختیاری نبایستی مورد استفاده قرار بگیرد. اصطلاح "optional" همان تعریف "may" را شامل می‌شود.

Must

در این مشخصات (فنی)، کلمه ی "must" واژه ای ضروری است که در بکارگیری یا انطباق اکید اسناد XHTML و بر اساس چارچوب آن تفسیر می شود. اصطلاح "shall" همان تعریف "must" را شامل می‌شود.

Optional

به توضیحات اصطلاح "May" رجوع کنید.

Reserved

مقدار یا رفتاری که نامشخص است، اما استفاده از آن توسط اسناد همگون و نیز برای پشتیبانی توسط مرورگرهای سازگار با آن غیر مجاز است.

Shall

به توضیحات اصطلاح "Must" رجوع کنید.

Should

با توجه به تشخیص دهنده های برنامه ی کاربردی، کلمه ی "should" به عنوان توصیه ی تشخیص دهنده ی برنامه ی کاربردی تفسیر می شود، اما ضروری نیست. با توجه به اسناد، کلمه ی "should" به عنوان یک تکنیک برنامه نویسی توصیه شده برای اسناد تفسیر می شود و به موردی ضروری جهت مطابقت اکید اسنادXHTML اشاره می نماید.

Supported

امکانات معین در این مشخصات (فنی) اختیاری هستند. اگر یکی از امکانات پشتیبانی شده باشد، به گونه ای که در این مشخصات (فنی) مشخص شده است، رفتار می نماید.

Unspecified

هنگامی که مقدار یا رفتاری نامشخص است، مشخصات (فنی) عدم نیاز به قابلیت حمل برای یک امکان، بر روی تشخیص دهنده ی برنامه ی کاربردی را تعیین می کند حتی هنگامی که با سندی مواجه می شود که آن امکان را مورد استفاده قرار می دهد. یک سند که نیازمند رفتار خاصی در چنین موردی است، به جای مقاومت در برابر هر رفتاری در موقع استفاده از این امکان، نمی تواند انطبافی با سند XHTML اکید داشته باشد.

2.2. اصطلاحات عمومی

ویژگی

یک ویژگی، پارامتری برای یک عنصر اعلان شده در DTDاست. دامنه ی مقدار و نوع ویژگی، از جمله یک مقدار پیش فرض موجود، درDTD تعیین می شوند.

DTD

یک DTD، یا تعریف نوع سند، مجموعه ای از اعلان های نشانه گذاری XML است، که بصورت یک مجموعه، ساختار قانونی، عناصر و ویژگی هایی که برای استفاده در سندی در دسترس هستند و با DTD منطبق می باشند را تعیین می نماید.

سند

یک سند مجموعه ای از داده هایی است که، پس از ترکیب با هر مجموعه ی دیگری که ارجاع داده می شود، طوری ساخته شده که اطلاعات سازمان یافته ی موجود در عناصر برمبنای DTD مربوطه را حفظ نماید. جهت کسب اطلاعات بیشتر به همگونی سند مراجعه نمایید.

عنصر

یک عنصر واحد ساختار بندی اعلان شده در DTD می باشد. مدل محتوای عنصر در DTD مشخص شده است و معانی و مفاهیم افزوده را می توان در تشریح اجزای عنصر تعیین کرد.

امکانات

امکانات، عناصر، ویژگی هاو معانی مرتبط با آن عناصر و ویژگی ها می باشد.

تشخیص دهنده ی برنامه ی کاربردی

به توضیحات اصطلاح "مرورگر" مراجعه نمایید.

تجزیه

تجزیه فرمانی است که به واسطه ی آن یک سند، بررسی شده و اطلاعات موجود در سند به چارچوبعناصر برای هر یک از اطلاعات تشکیل دهنده ی آن تفکیک می شود.

رندرینگ

رندرینگ عملی است که به موجب آن اطلاعات در یک سندارایه می شود. این ارایه به مناسب ترین شکل ممکن نسبت به محیط انجام می پذیرد ( به عنوان مثال:aurally، visually در پرینت).

مرورگر

مرورگر سیستمی است که اسناد XHTML را بنابر این مشخصات (فنی) پردازش می‌کند. جهت کسب اطلاعات بیشتر به سازگاری مرورگر مراجعه فرمایید.

اعتبارسنجی

اعتبارسنجی فرآیندی است که به موجب آن اسنادبا توجه به DTD مربوطه بررسی و تایید می‌شوند، که به منظور تضمین ساختار آن و نیز استفاده ازعناصر و ویژگی های سازگار با تعاریف موجود در DTDمی باشد.

ترکیب بندی صحیح

یک سند هنگامی بدرستی ترکیب بندی شده است که طبق قوانین تعیین شده در قسمت 2.1 از توصیه نامه ی [XML 1.0 [XMLساخته شده باشد.

3. تعریف معمولی و استاندارد XHTML 1.0

این بخش معمولی و استاندارد است.

3.1. همگونی سند

این نسخه از XHTML تعریفی از همنوایی اکید XHTML 1.0را تهیه نموده بطوری که محدود به عناصر و ویژگی هایی از فضاهای نامیXML و XHTML 1.0 است. جهت کسب اطلاعاتی راجع به بکارگیری XHTML با دیگر فضاهای نامی، به عنوان نمونه، شامل فراداده های بیان شده در RDF درون اسنادXHTML، قسمت 3.1.2 را ملاحظه فرمایید.

3.1.1. انطباق اکید اسناد

سند XHTML با همگونی اکید یک سند XML است که تنها نیازمند امکانات تشریح شده بصورت الزامی در این مشخصات (فنی) است. چنین سندی باید با همه ی معیارهای زیر هماهنگ باشد:

  1. باید با محدودیت های بیان شده در یکی از سه DTDموجود در DTD ها و در Appendix Bمطابق باشد.
  2. عنصر ریشه ای سند باید html باشد.
  3. عنصر ریشه ای سند باید محتوی یک اعلان xmlns برای فضای نامی XHTML باشد [XMLNS]. فضای نامی برای XHTML به صورتhttp://www.w3.org/1999/xhtml تعیین می شود. یک نمونه از عنصر ریشه ای می تواند بدین صورت باشد:
  4. در سند قبل از عنصر ریشه بایستی یک اعلان DOCTYPE وجود داشته باشد. شناسه عامه ی قرار گرفته در اعلان DOCTYPE بایستی به یکی از سه DTD موجود در DTD های مورد استفاده ی شناسه ی عمومی رسمی مربوطه ارجاع داده شود. شناسه ی سیستم ممکن است تغییر یافته باشد تا قراردادهای سیستم محلی منعکس شوند.
  5. زیر مجموعه ی DTD نبایستی به گونه ای استفاده شود که وجود هر پارامتر را در DTD باطل نماید.

وجود اعلان XML در همه‌ی اسناد XMLضروری نیست؛ هر چند نویسندگان سند XHTML به شدت تشویق می شوند تا از اعلان XML در تمامی اسنادشان استفاده نمایند. چنین اعلانی هنگامی لازم است که رمزگذاری کاراکتر سند غیر از UTF-16یاUTF-8 پیش فرض است و رمزگذاری توسط یک پروتکل سطح بالا تعیین نشده باشد. در اینجا مثالی از یک سندXHTML موجود است. در این مثال اعلان XML قرار داده شده است.

Virtual Library

Moved to example.org.

3.1.2. بکارگیری XHTML با فضاهای نامی دیگر

فضای نامی XHTML مطابق [XMLNS] ممکن است با دیگر فضاهای نامیXML بکار رود، گرچه چنین اسنادی دقیقا منطبق با اسناد XHTML 1.0 همانند آنچه در بالا تعریف شده، نیستند. کارW3C رسیدگی به شیوه های تبیین هماهنگی برای اسناد شامل فضاهای نامی چندگانه می باشد. به عنوان یک نمونه، [XHTML+MathML] را مشاهده فرمایید.

مثال ذیل شیوه ای که در آن XHTML 1.0 به همراه توصیه نامه ی MathML می تواند مورد استفاده قرار گرفته باشد را نشان می دهد:

A Math Example

The following is MathML markup:

      <cn> 3 </cn>
    </logbase>
    <ci> x </ci>
  </apply>

</math>

مثال زیر شیوه ای را که در آن نشانه گذاری XHTML 1.0 می تواند درون فضای نامی XML دیگری قرار گرفته باشد را نشان می دهد:

Cheaper by the Dozen isbn:number1568491379 

<!-- make HTML the default namespace for a hypertext commentary -->
<p xmlns='http://www.w3.org/1999/xhtml'>
    This is also available <a href="http://www.w3.org/">online</a>.
</p>

3.2. سازگاری مرورگر

مرورگر سازگار باید منطبق بر تمامی معیارهای زیر باشد:

  1. به منظور سازگاری با توصیه نامه ی [XML 1.0 [XML، مرورگر سند XHTML را بایستی از نظر ترکیب بندی صحیح، تجزیه و تحلیل نماید. اگر مرورگر معتبر باشد، بایستی اسناد را بر مبنای DTD هایشان و با توجه به [XML] معتبر نماید.
  2. هنگامی مرورگر، پشتیبان امکاناتتعیین شده در این مشخصات (فنی) یا مورد نیاز این مشخصات (فنی) از طریق مرجع معمولی و استاندارد است که در راستای سازگاری با امکانات تعریفی باشد.
  3. هنگامی که مرورگر سند XHTML را همچون XMLعمومی پردازش می کند باید تنها ویژگی های نوع ID را (مثل ویژگی idدر اکثر عناصر XHTML) به عنوان شناسه های گسسته تشخیص دهد.
  4. اگر مرورگر با یک عنصر مواجه شود که آنرا تشخیص ندهد، بایستی محتوای عنصر را پردازش نماید.
  5. اگر مرورگر با ویژگی ای روبرو شود که قادر به تشخیص آن نیست، باید از همه ی خصوصیات آن ویژگی (یعنی ویژگی و مقدارش) صرف نظر نماید.
  6. اگر مرورگر با یک مقدار ویژگی مواجه شود که نتواند آنرا تشخیص دهد، بایستی از مقدار ویژگی پیش فرض استفاده نماید.
  7. اگر با یک مرجع موجود مواجه شود (بجز یکی از موارد موجود تعیین شده در این توصیه نامه یا در توصیه نامه ی XML) که مرورگر برای آن اعلان پردازش شده ای ندارد (اگر اعلان در زیر مجموعه خارجی باشد و برای مرورگر قابل بازخوانی نباشد می تواند روی دهد)، مرجع موجود می بایستی همچون کاراکترها (که با امپرسند (&) شروع شده و با نقطه ویرگول (;) خاتمه می یابد) پردازش شده باشد که تشکیل دهنده ی مرجع موجود است.
  8. هنگام پردازش محتوا، مرورگرهایی را که با کاراکترها یا مراجع موجود کاراکتر به رسمیت شناخته شده مواجه می شوند که غیر قابل رندر هستند اما ممکن است جانشین رندر دیگری شوند، که همان معنی را می دهد، یا بایستی سند را برای کاربری که از رندر معمولی بی بهره است، به چنین شیوه ای که واضح است نشان دهد.
  9. فضای تهی با توجه به قوانین ذیل به کار گرفته شده است. کاراکترهای زیر در کاراکترهای فضای تهی [XML] تعیین می شوند:
    - SPACE ( )
    - HORIZONTAL TABULATION ( )
    - CARRIAGE RETURN ( )
    - LINE FEED ( )
    پردازنده ی XML کدهای انتهای خط سیستم های متفاوت را درون یک کاراکتر LINE FEED واحد تعدیل می کند، که مورد تایید برنامه ی کاربردی است.
    مرورگر باید تعریف تعیین شده از CSS را برای پردازش کاراکترهای فضای تهی استفاده نماید [CSS2]. توجه داشته باشید که توصیه نامه ی CSS2 با صراحت مسئله ی بکارگیری فضای تهی در مجموعه کاراکترهای غیر لاتین را مورد بررسی قرار نمی دهد. و در یکی از نسخه های آینده یCSS در زمانی که این مرجع به روز درآورده شده است، مورد بررسی قرار می گیرد.

توجه داشته باشید که به منظور تولید یک سند XHTMLاستاندارد، قوانین بالا و نیز قوانین موجود در [XMLC14N] بایستی در سند اعمال شوند.

4. تفاوت‌ آن با HTML 4

این بخش آموزنده است.

با توجه به این واقعیت که XHTML یک برنامه کاربردیXML است، شیوه های خاصی که در SGML-based HTML 4 کاملا مجاز بودند [HTML4] بایستی تغییر یابند.

4.1. اسناد بایستی ترکیب بندی صحیحی داشته باشند

ترکیب بندی صحیح یک مفهوم جدید معرفی شده توسط [XML] می باشد. در اصل بدین معنی است که همه عناصر یا بایستی تگهای بسته شونده داشته باشند یا در قالب خاصی نوشته شوند (بطوری که در زیر تشریح شده) آنهم همه عناصر بایستی بدرستی جای گرفته باشند.

اگرچه روی هم افتادگی در SGML غیر مجاز است، اما بطور گسترده ای از سوی مرورگرهای موجود پذیرفته می شود.

صحیح : عناصر تودرتو.

here is an emphasized paragraph.

نادرست : عناصر رویهم افتاده

here is an emphasized paragraph.

4.2. عناصر و نام‌های ویژگی بایستی در قالب حروف کوچک باشند

اسناد XHTML بایستی برای همه عناصرHTML و نام های ویژگی از حروف کوچک استفاده نمایند. این تفاوت ضروری است زیرا XML نسبت به بزرگ یا کوچک بودن حروف حساس است، به عنوان مثال

  • و
  • تگهای متفاوتی هستند.

    • 4.3. برای عناصر غیر تهی، تگهای پایانی ضروری است

    در SGML-based HTML 4 با عناصری که بطور ضمنی بسته می شوند، تعدادی ازعناصر مجاز به حذف تگ پایانی بودند. XML اجازه نمی دهد که تگهای پایانی حذف شوند. تمامی عناصر، غیر از آنهایی که در DTD بصورت EMPTY اعلام شده اند بایستی یک تگ پایانی داشته باشند. عناصری که در DTD بصورت EMPTYاعلام شده اند، می توانند یک تگ پایانی داشته باشند یا از عنصر تهی اختصاری استفاده نمایند (به عناصر تهی مراجعه کنید).

    صحیح: عناصر پایان داده شده

    here is a paragraph.

    here is another paragraph.

    نادرست : عناصر پایان داده نشده

    here is a paragraph.

    here is another paragraph.

    4.4. همواره بایستی مقادیر ویژگی با علامت نقل قول همراه باشند

    همه ی مقادیر ویژگی حتی آنهایی که بصورت عددی ظاهر می شوند، بایستی با علامت نقل قول همراه باشند.

    صحیح : مقادیر ویژگی دارای علامت نقل قول

    نادرست : مقادیر ویژگی فاقد علامت نقل قول

    4.5. حداقل سازی ویژگی

    XML از حداقل سازی ویژگی پشتیبانی نمی کند. جفت مقدار - ویژگی بایستی به طور کامل نوشته شده باشد. نام های ویژگی همچون compact و checkedدر عناصر، نمی توانند خارج از مقدار تعیین شده شان واقع شوند.

    صحیح : ویژگی های حداقل سازی نشده

    نادرست : ویژگی های حداقل سازی شده

    4.6. عناصر تهی

    عناصر تهی یا بایستی یک تگ پایانی داشته باشند یا تگ شروع باید با </ خاتمه یابد. برای مثال، </br> یا <hr></hr>. جهت کسب اطلاعات در مورد شیوه‌ های حصول اطمینان برای سازگاری مجدد با مرورگرهای HTML 4، رهنمودهای سازگاری HTML را مشاهده نمایید.

    صحیح: عناصر تهی پایان داده شده


    نادرست : عناصر تهی پایان داده نشده


    4.7. رفع مشکل فضای تهی مقادیر ویژگی

    هنگامی که مرورگرها، ویژگی ها را پردازش می نمایند، آنها مطابقبخش 3.3.3 از [XML] این کار را انجام می دهند:

    • فاصله ی محدوده ی خطوط و فضای تهی انتهایی.
    • توالی یک یا چند کاراکتر فضای تهی (شامل لینکهای شکسته) به یک فضای درون واژه ای واحد.

    4.8. اسکریپت و عناصر سبک بندی

    در XHTML، اسکریپت و عناصر سبک بندی با داشتن محتوای PCDATA# اعلان شده اند. در نتیجه، > و & بصورت شروع نشانه گذاری رفتار می نمایند و مواردی همچون ;lt& و ;amp& توسط پردازنده ی XML بترتیب به > و &به عنوان ارجاعات موجود به رسمیت شناخته خواهند شد. لفاف محتوای اسکریپت یا عنصر سبک بندی درون یک قسمت نشانه گذاری شده ی CDATA از گسترش این موارد جلوگیری می نماید.

    قسمت های CDATA توسط پردازشگر XML به رسمیت شناخته می شوند و بصورت گره هایی در مدل شیء سند ظاهر می شوند، بهقسمت 1.3 توصیه نامه ی DOM سطح 1 [DOM] مراجعه فرمایید.

    که جایگزینی برای استفاده از اسکریپت و اسناد سبک بندی خارجی می باشد.

    4.9. موارد منع شده ی SGML

    SGML به نویسنده یک DTD توانایی مستثنا کردن عناصر ویژه از محتوای موجود درون یک عنصر را اعطا می کند. چنین ممنوعیت هایی (به نام "استثناها") در XML مقدور نیست.

    برای مثال، HTML 4 Strict DTD تودرتویی یک عنصر 'a' درون عنصر دیگری از 'a' با هر عمق ولد (زیر مجموعه ای) را منع می کند. و امکان حذف چنین منعیاتی در XML وجود ندارد. حتی اگر این موارد منع شده در DTD تعیین نشده باشند، عناصر خاصی نبایستی تودرتو باشند. خلاصه ای از عناصر اینچنینی و عناصری که نبایستی بصورت تودرتو درون یکدیگر قرار بگیرند در موارد منع عنصرمعمولی و استاندارد موجود است.

    4.10. عناصری با ویژگی های "id" و "name"

    HTML 4 ویژگی name را برای عناصر a, applet, form, frame, iframe, imgو map تعیین نموده است. HTML 4 همچنین ویژگی id را معرفی نموده است. هر دوی این ویژگی ها طراحی شده اند تا به عنوان شناسه های گسسته مورد استفاده قرار گیرند.

    در XML، شناسه های گسسته از نوع IDهستند و تنها می توانند یک ویژگی واحد از نوع ID برای هر عنصر باشند. بنابراین در XHTML 1.0 ویژگی id تعریف شده تا از نوع IDباشد. به منظور حصول اطمینان از اینکه اسناد XHTML 1.0، اسنادXML بدرستی ساختاربندی شده ای هستند، اسناد XHTML 1.0 هنگام تعیین شناسه های گسسته راجع به عناصر فهرست شده ی بالا بایستی از ویژگی idاستفاده نمایند. جهت کسب اطلاعات راجع به حصول اطمینان از انچورهای اینچنینی که در هنگام ارایه ی اسناد XHTMLبصورت نوع رسانه text/html سازگار با موارد قبلی هستند، بهرهنمودهای سازگاری HTML مراجعه نمایید.

    توجه داشته باشید که در XHTML 1.0، ویژگی name این عناصر رسما نامناسب شناخته شده است و در نسخه ی بعدی XHTML حذف می شود.

    4.11.ویژگی هایی با مجموعه مقادیر از پیش تعریف شده

    HTML 4 و XHTML هر دو دارای ویژگی هایی هستند که شامل مجموعه مقادیر محدود و از پیش تعریف شده اند. (به عنوان مثال: ویژگی type عنصر input ). در SGML و XML، اینها ویژگی های پیش فرض نامیده می شوند. طبق HTML 4 برای تفسیر این مقادیر، حساسیتی نسبت به بزرگی و کوچکی حروف وجود نداشت، بنابراین مقدار TEXTبا text برابر بود. بر اساس XML، تفسیر این مقادیر نسبت به حروف کوچک و بزرگ حساس است و در XHTML 1همه ی این مقادیر بصورت حروف کوچک تعریف شده اند.

    4.12. مراجع موجود همچون مقادیر هگزا دسیمال

    SGML و XML هر دو اجازه ی ارجاع به کاراکترها با استفاده از مقادیر هگزادسیمال را می دهند. در SGML این مراجع می توانست با هر یک از ;Xnn#& یا ;xnn#& ساخته شود. در اسناد XML، بایستی از نسخه ی حروف کوچک استفاده نمایید. (یعنی: ;xnn#&)

    5. موارد مربوط به انطباق

    این قسمت معمولی و استاندارد است.

    اگرچه نیازی جهت سازگاری اسناد XHTML 1.0 با مرورگرهای موجود، وجود ندارد، ولی در عمل تحقق این امر آسان است. رهنمودهایی راجع به ایجاد اسناد سازگار را درضمیمه ی C می توانید بیابید.

    5.1. نوع رسانه ی اینترنت

    اسناد XHTML ای که از رهنمودهای مندرج در ضمیمه ی Cپیروی می کنند، "رهنمودهای سازگاری HTML" که می توانند با نوع رسانه ی "text/html "در [RFC2854] برچسب دار شوند، بطوری که با اکثریت مرورگرهایHTML سازگار باشند. آن اسناد و هر سند دیگر مطابق با این مشخصات (فنی) هم می توانند با نوع رسانه ی اینترنت "application/xhtml+xml" بصورتی که در [RFC3236] تعیین شده اند، برچسب دار شوند. جهت کسب اطلاعات بیشتر در مورد استفاده از انواع رسانه باXHTML، به مطلب توضیحی مربوطه ی [XHTMLMIME] مراجعه نمایید.

    DTD.A ها

    این ضمیمه ی معمولی و استاندارد است.

    این DTD ها و مجموعه های موجود، قسمت معمولی و استاندارد این مشخصات (فنی) را تشکیل می دهند. برای این مشخصات (فنی) مجموعه ی کامل فایل های DTDبه اضافه ی یک اعلان XML و کاتالوگ باز SGML در فایل zip وفایل gzip'd tar گنجانده شده اند. برای کاربرهایی که به دنبال کپی های محلی DTDهایی هستند تا آنها را مورد استفاده قرار دهند باید فایل های زیپ شده ی آنها را دانلود نموده و بجای DTDهای اشاره شده در ذیل، استفاده نمایند.

    A.1. تعاریف نوع سند

    این DTD ها شباهت زیادی به DTD های HTML 4 دارند.W3C توصیه می نماید که هنگام تایید اعتبار محتوا، از نسخه های معتبر اینDTD ها در شناسه های سیستم تعریف شده استفاده کنند. اگر در سند مورد استفاده، نیازمند استفاده از یکی از این DTD ها هستید، بایستی یکی از نسخه های دیگرهمین سند را دریافت نمایید. به طور کامل نسخه های معمولی و استاندارد DTD ها شامل این موارد می گردند:

    A.1.1. اکس اچ تی ام ال XHTML-1.0 - اکید

    فایل DTD/xhtml1-strict.dtd قسمت معمولی و استاندارد از این مشخصات (فنی) می باشد. محتوای مشروح این فایل به طور کامل در اینبخش مجزاموجود است.

    A.1.2.اکس اچ تی ام ال XHTML-1.0 - انتقالی

    فایل DTD/xhtml1-transitional.dtd قسمت معمولی و استاندارد از این مشخصات (فنی) می باشد. محتوای مشروح این فایل به طور کامل در اینبخش مجزاموجود است.

    A.1.3.اکس اچ تی ام ال XHTML-1.0 - مجموعه قاب

    فایل DTD/xhtml1-frameset.dtd قسمت معمولی و استاندارد از این مشخصات (فنی) می باشد. محتوای مشروح این فایل به طور کامل در اینبخش مجزاموجود است.

    A.2. مجموعه های موجود

    مجموعه های موجود XHTML همانند موارد مشابه در HTML 4هستند، اما به گونه ای تغییر یافته اند تا بصورت اعلان های موجود XML 1.0معتبر باشند. توجه داشته باشید که مجموعه های موجود برای علامت ارز یورو (;euro& یا ;8364#& یا ;x20AC#&) به عنوان بخشی از کاراکترهای ویژه تعریف شده اند.

    A.2.1.کاراکترهای لاتین - 1

    فایل DTD/xhtml-lat1.ent قسمت معمولی و استاندارد از این مشخصات (فنی) می باشد. محتوای مشروح این فایل به طور کامل در اینقسمت مجزاموجود است.

    A.2.2.کاراکترهای ویژه

    فایل DTD/xhtml-special.ent قسمت معمولی و استاندارد از این مشخصات (فنی) می باشد. محتوای مشروح این فایل به طور کامل در اینبخش مجزاموجود است.

    A.2.3. علائم

    فایل DTD/xhtml-symbol.ent قسمت معمولی و استاندارد از این مشخصات (فنی) می باشد. محتوای مشروح این فایل به طور کامل در اینبخش مجزاموجود است.

    B. موارد منع شده ی عناصر

    این ضمیمه معمولی و استاندارد است.

    عناصر زیر دارای ممنوعیت هایی در رابطه با عناصری که در بر می گیرند، هستند (به قسمت استثناهای SGMLمراجعه نمایید). این موارد منع شده، هر چقدر هم عناصر تو در تو باشند نیز صادق است، یعنی شامل تمامی عناصر زاده شده (زیر مجموعه) می گردند.

    a

    نبایستی عناصر a دیگری را در بر گیرد.

    pre

    نبایستی عناصر img, object, big, small, sub, یا sup را در بر بگیرد.

    button

    نبایستی عناصر input, select, textarea, label, button, form, fieldset, iframeیاisindex را در بر بگیرد.

    label

    نبایستی عناصر label دیگری را در بر گیرد.

    form

    نبایستی عناصر form دیگری را در بر گیرد.

    C. رهنمودهای سازگاری HTML

    این ضمیمه آموزنده است.

    این ضمیمه رهنمودهای طراحی برای برنامه نویسانی که می خواهند اسنادXHTML خود را بر روی مرورگرهای موجود ارایه نمایند، خلاصه می کند. توجه داشته باشید که در این توصیه نامه چگونگی انطباق HTML با مرورگرها و نحوه ی پردازش اسناد HTMLدر آنها مشخص نشده است و همچنین معنای نوع رسانه ی اینترنت text/html را هم تعیین نمی نماید. برای این تعاریف، به ترتیب به قسمت های [HTML4] و [RFC2854] مراجعه فرمایید.

    C.1. دستورالعمل های پردازش و اعلانXML

    بخاطر داشته باشید که دستورالعمل های پردازش در برخی از مرورگرها رندر می شوند. همچنین تعدادی از مرورگرها اعلان XML را به گونه ای تفسیر می کنند که گویای این مفهوم باشد که سند بجای HTML، سند XML به رسمیت شناخته نشده ای است، و لذا به صورتی که انتظار می رود ممکن است رندر نشود. برای سازگاری با انواعی از این مرورگرهای موروثی و قدیمی، ممکن است بخواهید که از بکارگیری دستورالعمل های پردازش و اعلان های XMLخودداری نمایید. بخاطر داشته باشید، اگر اعلان XMLدر یک سند نباشد، سند تنها می تواند از کاراکترهای رمزگذاری پیش فرض UTF-8 یا UTF-16 استفاده نماید.

    C.2. عناصر تهی

    یک فضا (فاصله) قبل از انتهای / و <از عناصر تهی قرار دهید، مثل: </ br /> ،<hr>و </ "img src="karen.jpg" alt="Karen>. همچنین از ترکیب تگ به حداقل رسانده شده برای عناصر تهی استفاده کنید، مثل: </ br>، به عنوان ترکیب جایگزین <br></br>مجاز توسط XML که نتایج متغیری را در بسیاری از مرورگرهای موجود ارایه می نماید.

    C.3. به حداقل رسانی عنصر و محتوای عنصر تهی

    با توجه به نمونه ی عنصر تهی که مدل محتوایش EMPTY نیست (برای نمونه، یک پاراگراف (P) یا عنوان (title) تهی) از شکل به حداقل رسانده شده استفاده نکنید (مثال: از <p> </p> استفاده کنید و نه از </ p>).

    C.4. اسکریپت ها و شیوه نامه های جاسازی شده

    در صورتی که شیوه نامه های شما از > یا & یا <[[ یا -- استفاده می نمایند، شیوه نامه های خارجی را مورد استفاده قرار دهید. اگر اسکریپت شما از > یا & یا <[[ یا -- استفاده می کنند، اسکریپت های خارجی را مورد استفاده قرار دهید. توجه داشته باشید که تجزیه کننده های XML مجاز هستند که بصورت نامحسوس محتوای توضیحات را پاک کنند. بنابراین، تکنیک گذشته که در آن از اسکریپت های "مخفی" و شیوه نامه های درون "توضیحات" که استفاده می شد تا منجر به هماهنگی اسناد شود، ممکن است به صورتی که در مرورگرهای مبتنی بر XML انتظار می رود، عمل ننماید.

    C.5. فواصل خط میان مقادیر ویژگی

    از فواصل خط و کاراکترهای فضای تهی چندگانه درون مقادیر ویژگی اجتناب نمایید. زیرا توسط مرورگرها بطور ناسازگاری بکار می روند.

    C.6. عنصر Isindex

    بیشتر از یک عنصر isindex را در head سند قرار ندهید. عنصر isindex در ارتباط با عنصر input نامناسب است.

    C.7. ویژگی های lang و xml:lang

    هنگام تعیین زبان یک عنصر از هر دو ویژگی lang و xml:lang، استفاده نمایید. مقدار ویژگی xml:lang اولویت دارد.

    C.8. شناسه های گسسته

    در XML، مراجع URI (یو آر آی) [RFC2396] که با شناسه های گسسته به شکل "foo#" پایان می یابند به عناصری با ویژگی "name="fooاشاره ندارند؛ بلکه به ویژگی تعیین شده از نوع IDاشاره دارد، مثل: ویژگی idدر HTML 4. بسیاری از سرویس گیرنده های موجود HTMLویژگی های نوع ID را بدین شیوه پشتیبانی نمی نمایند، بنابراین جهت به حداکثر رسانی تضمین سازگاری با (مرورگرهای) قبلی و پیش رو، مقدارهای یکسانی برای هر دوی این ویژگی ها می تواند ارایه شود ( مثال: <a id="foo" name="foo">...</a>).

    همچنین، از وقتی که مجموعه مقادیر مجاز برای ویژگی های نوع ID بسیار کوچکتر از ویژگی های نوع CDATA هستند، نوع ویژگی nameبه NMTOKEN تغییر یافته است. این ویژگی به گونه ای است که می تواند تنها مقادیر همانند نوع ID را داشته یا به صورت Nameکه در XML 1.0 قسمت 2.3، تولید 5 ساخته شده، باشد. متاسفانه این محدودیت نمی تواند در DTD های XHTML 1.0 بیان شود. بدلیل این تغییر، در هنگام تغییر اسناد موجود HTMLباید دقت شود. مقادیر این ویژگی ها بایستی درون سند منحصر به فرد و معتبر باشند، و هرگونه ارجاعی به این شناسه های گسسته (هر دوی داخلی و خارجی) می بایستی مقادیری را که باید در جریان تبدیل، تغییر یابند را به روز نماید.

    توجه داشته باشید که مجموعه ی مقادیر مجاز در XML 1.0 قسمت 2.3، تولید 5 بسیار بزرگتر از حد مجاز است تا در انواع ID و NAMEتعیین شده در HTML 4 مورد استفاده قرار گیرند. هنگام تعریف شناسه های گسسته جهت سازگاری با (مرورگرهای) قبلی، تنها رشته های مطابق با این الگو *[-._:A-Za-z][A-Za-z0-9] می بایستی استفاده شوند. جهت کسب اطلاعات بیشترقسمت 6.2 از [HTML4] را مشاهده نمایید.

    در نهایت، توجه داشته باشید که XHTML 1.0 ویژگی name عناصر a, applet, form, frame, iframe, img, و map را نامناسب می داند و در نسخه های بعدی XHTMLحذف خواهد شد.

    C.9. رمزگذاری کاراکتر

    از نظر تاریخی، رمز گذاری کاراکتر سند HTML یا توسط وب سرور از طریق پارامتر مجموعه کاراکتر هدر نوع محتوای HTTP یا توسط عنصر meta در خود سند تعیین می شود. در سندXML رمزگذاری کارکتر سند در اعلان XML تعیین می شود (مثال: <?"xml version="1.0" encoding="EUC-JP?>).به منظور قابلیت حمل اسناد موجود با رمزگذاری های کاراکتر ویژه، بهترین روش، حصول اطمینان از فراهم سازی هدرهای صحیح توسط وب سرور می باشد. اگر این امکانپذیر نیست، سندی که بخواهد به مجموعه اش رمزگذاری کاراکتر اضافه شود بایستی صریحا هر دوی اعلانXML یک اعلان رمزگذاری و یک دستور metahttp-equiv را داشته باشد. (مثال: </ "meta http-equiv="Content-type" content="text/html; charset=EUC-JP>). در مرورگرهای سازگار با XHTML، مقدار اعلان رمزگذاریِ اعلان XML اولویت دارد.

    توجه: بخاطر داشته باشید که اگر سند بایستی شامل اعلان رمزگذاری کاراکتر در دستور meta http-equiv باشد، آن سند همواره ممکن است توسط سرورهای HTTP و / یا مرورگرها بطوری که نوع رسانه ی اینترنت در آن دستور تعریف شده، تفسیر گردد. اگر سند به عنوان انواع رسانه ی چندگانه مورد استفاده قرار می گیرد، سرور HTTP بایستی جهت تنظیم رمزگذاری سند مورد استفاده قرار گیرد.

    C.10. ویژگی های بولی

    برخی از مرورگرهای HTML هنگامی که به شکل کامل (فول اسکرین و به حداقل نرسیده) ظاهر شوند، بطوری که توسط XML 1.0مورد نیاز است، قادر به تفسیر ویژگی های بولی نیستند. توجه داشته باشید که این مسئله بر روی مرورگرهای سازگار با HTML 4تاثیری ندارد. این ویژگیها در آن دخالت دارند: compact, nowrap, ismap, declare, noshade, checked, disabled, readonly, multiple, selected, noresize, defer.

    C.11. مدل شیء سند و XHTML

    توصیه نامه ی مدل شیء سند سطح 1 [DOM] واسط های مدل شیء سند را برای XML و HTML 4 تعریف می کند. مدل شیء سند HTML 4 مشخص می کند که عنصر HTML و نام های ویژگی به حروف بزرگ برگردانده شوند. مدل شیء سند XML مشخص می کند که عنصر و نام های ویژگی به گونه ای که تعیین شده اند، برگردانده شوند. در XHTML 1.0، عناصر و ویژگی ها بصورت حروف کوچک تعیین می شوند. این تفاوت ظاهری به دو صورت امکانپذیر است:

    1. مرورگرهایی که به اسناد XHTML سرویس داده شده به عنوان نوع رسانه اینترنت text/html دسترسی دارند که از طریق DOM می توانند از HTML DOMاستفاده نمایند و می توانند متکی به عنصر و نام های ویژگی برگردانده ی موجود به حروف بزرگ از واسط های آنها باشند.
    2. مرورگرهایی که به اسناد XHTML سرویس داده شده به عنوان نوع رسانه اینترنت text/xml, application/xml یا application/xhtml+xmlدسترسی دارند همچنین می توانند از XML DOM استفاده نمایند. عناصر و ویژگیها به حروف کوچک برخواهند گشت. همچنین برخی از اسنادXHTML می توانند یا نمی توانند در ساختار درختی (شجره نامه ی) شیء ظاهر شوند زیرا آنها در مدل محتوا اختیاری هستند (مثل: عنصر tbodyدرون table).و دلیل آن این است که برخی از عناصرHTML 4 مجاز بوده اند که به حداقل رسانده شوند بطوری که تگهای شروعی و پایانی هر دو از قلم انداخته شده اند (یک ویژگی SGML). این عمل در XML امکانپذیر نیست. بجای نیاز به نویسندگان سند برای وارد کردن عناصر خارجی، XHTML بصورت دلخواه عناصر را می سازد. مرورگرها باید بدین صورت وفق داده شوند. جهت کسب اطلاعات بیشتر در این مورد، لطفا [DOM2] را مشاهده نمایید.

    C.12. بکارگیری آمپرسندها در مقادیر ویژگی (و غیره)

    هم در SGML و هم در XML، کاراکتر آمپرسند ("&") شروع مرجع موجود را اعلام می نماید (مثل: ;reg& برای علامت تجاری ثبت شده "®"). متاسفانه، بسیاری از مرورگرهای HTML بدون سر و صدا کاربرد نادرست کاراکتر آمپرسند در اسناد HTML را نادیده می گیرند - رفتار آمپرسندهایی که همچون آمپرسندهای تحت الفظی به نظر نمی رسند. مرورگرهای مبتنی بر XML این استفاده ی نادرست را تحمل نمی نمایند و هر سندی که بصورت غلط از یک آمپرسند استفاده نماید "معتبر" نخواهد بود و در نتیجه مطابق با این مشخصات (فنی) نمی باشد. به منظور حصول اطمینان از سازگاری اسناد با مرورگرهای پیشین HTML و مرورگرهای مبتنی برXML، آمپرسندهای استفاده شده در سندی که بصورت کاراکترهای تحت الفظی رفتار می نمایند، باید خودشان را به عنوان یک مرجع موجود بیان کنند (مثل: ";amp&"). برای نمونه، هنگامی که ویژگی href عنصر a به اسکریپت CGI که پارامترهایی را بدنبال دارد، اشاره می نماید، بایستی بصورتhttp://my.site.dom/cgi-bin/myscript.pl?class=guest&amp;name=user بیان شود نه بدین گونه http://my.site.dom/cgi-bin/myscript.pl?class=guest&name=user.

    C.13. شیوه نامه های آبشاری (CSS) و XHTML

    توصیه نامه ی شیوه نامه آبشاری سطح 2 [CSS2] خصوصیات سبکی که برای ساختار درختی تجزیه اسناد HTML یا XML اعمال می شوند را تعیین می کند. تفاوتها در تجزیه نتایج بصری یا شنوایی متفاوتی را با توجه به گزینشگرهای مورد استفاده بدنبال خواهد داشت. نکات ذیل، این اثر را برای اسنادی که بدون تغییر به عنوان هر دو نوع رسانه مورد استفاده هستند، کاهش می دهد:

    1. شیوه نامه های CSS برای XHTMLمی بایستی از نام های ویژگی و عنصر با حروف کوچک استفاده نمایند.
    2. در جداول، عنصر tbody با تجزیه گر مرورگرHTML استنباط می گردد، و توسط تجزیه گر مرورگر XML مورد استنباط قرار نمی گیرد. بنابراین بایستی همواره به وضوح یک عنصرtbody را اضافه نمایید در صورتی که به درون یک گزینشگرCSS اشاره می نماید.
    3. درون فضای نامی XHTML، انتظار می رود که مرورگرها ویژگی "id" را همچون یک ویژگی نوع ID به رسمیت شناسند. بنابراین شیوه نامه ها بایستی بتوانند که استفاده از ترکیب گزینشگر خلاصه نویسی "#" را حتی اگر مرورگرها DTD را نخوانند، ادامه دهند.
    4. درون فضای نامی XHTML، انتظار می رود که مرورگرها ویژگی "class" را به رسمیت شناسند. بنابراین شیوه نامه ها بایستی بتوانند که استفاده از ترکیب گزینشگر خلاصه نویسی "." را ادامه دهند.
    5. CSS مطابق دستورات برای اسنادHTML و XML بطور متفاوت تعریف می شود؛ بخاطر داشته باشید که دستورات HTML برای اسنادXHTML ارایه شده به صورت HTML، اعمال می شوند و دستورات XML برای اسناد XHTMLارایه شده به صورت XML، اعمال می گردند.

    C.14. ارجاع به عناصر سبک بندی در قالب عملکردی مشابه با XML

    در HTML 4 و XHTML، عنصر style جهت تعیین دستورات سبک بندی داخلی سند مورد استفاده قرار می گیرد. در XML، اعلان شیوه نامه ی XML جهت تعیین دستورات سبک بندی استفاده می شود. به منظور سازگاری با این قرارداد، عناصر style بایستی مجموعه شناسه ی جزیی خود را با استفاده از ویژگی id داشته باشند و اعلان شیوه نامه ی XML بایستی مرجع این جزء باشد. برای نمونه:

    An internal stylesheet example

    This is text that uses our internal stylesheet.

    C.15. کاراکترهای فضای تهی HTML در مقابل XML

    تعدادی از کاراکترهایی که در اسناد HTML مجاز اند، در سندXML غیر مجاز می باشند. برای نمونه، در HTML، کاراکتر (Formfeed (U+000C بصورت فضای تهی مورد استفاده قرار می گیرد، در XHTML، بعلت تعریف کاراکترهای XML، استفاده از آن غیر مجاز است.

    C.16. مرجع کاراکتر نام برده ی ;apos&

    مرجع کاراکتر نام برده‌ی ;apos& (آپوستروف، U+0027) در XML 1.0 معرفی شد اما در HTML ظاهر نمی شود. لذا نویسندگان بایستی بجای;apos& از ;39#&استفاده نمایند تا همانگونه که انتظار می رود در مرورگرهای HTML 4 عمل نماید.

    D. تشکر و قدردانی

    این ضمیمه آموزنده است.

    این مشخصات (فنی) با مشارکت اعضای کار گروه W3C HTML نوشته شد.

    در انتشار ویرایش دوم، اعضای شرکت کننده بدین شرح بودند:

    Steven Pemberton, CWI/W3C (HTML Working Group Chair)
    Daniel Austin, Grainger
    Jonny Axelsson, Opera Software
    Tantek Çelik, Microsoft
    Doug Dominiak, Openwave Systems
    Herman Elenbaas, Philips Electronics
    Beth Epperson, Netscape/AOL
    Masayasu Ishikawa, W3C (HTML Activity Lead)
    Shin'ichi Matsui, Panasonic
    Shane McCarron, Applied Testing and Technology
    Ann Navarro, WebGeek, Inc.
    Subramanian Peruvemba, Oracle
    Rob Relyea, Microsoft
    Sebastian Schnitzenbaumer, SAP
    Peter Stark, Sony Ericsson

    در انتشار ویرایش نخست، اعضای شرکت کننده بدین شرح بودند:

    Steven Pemberton, CWI (HTML Working Group Chair)
    Murray Altheim, Sun Microsystems
    Daniel Austin, AskJeeves (CNET: The Computer Network through July 1999)
    Frank Boumphrey, HTML Writers Guild
    John Burger, Mitre
    Andrew W. Donoho, IBM
    Sam Dooley, IBM
    Klaus Hofrichter, GMD
    Philipp Hoschka, W3C
    Masayasu Ishikawa, W3C
    Warner ten Kate, Philips Electronics
    Peter King, Phone.com
    Paula Klante, JetForm
    Shin'ichi Matsui, Panasonic (W3C visiting engineer through September 1999)
    Shane McCarron, Applied Testing and Technology (The Open Group through August 1999)
    Ann Navarro, HTML Writers Guild
    Zach Nies, Quark
    Dave Raggett, W3C/HP (HTML Activity Lead)
    Patrick Schmitz, Microsoft
    Sebastian Schnitzenbaumer, Stack Overflow
    Peter Stark, Phone.com
    Chris Wilson, Microsoft
    Ted Wugofski, Gateway 2000
    Dan Zigmond, WebTV Networks

    E. منابع

    این ضمیمه آموزنده است.

    [CSS2]

    "Cascading Style Sheets, level 2 (CSS2) Specification", B. Bos, H. W. Lie, C. Lilley, I. Jacobs, 12 May 1998.
    Latest version available at: http://www.w3.org/TR/REC-CSS2

    [DOM]

    "Document Object Model (DOM) Level 1 Specification", Lauren Wood et al., 1 October 1998.
    Latest version available at: http://www.w3.org/TR/REC-DOM-Level-1

    [DOM2]

    "Document Object Model (DOM) Level 2 Core Specification", A. Le Hors, et al., 13 November 2000.
    Latest version available at: http://www.w3.org/TR/DOM-Level-2-Core

    [HTML]

    "HTML 4.01 Specification", D. Raggett, A. Le Hors, I. Jacobs, 24 December 1999.
    Latest version available at: http://www.w3.org/TR/html401

    [POSIX.1]

    "ISO/IEC 9945-1:1990 Information Technology - Portable Operating System Interface (POSIX) - Part 1: System Application Program Interface (API) [C Language]", Institute of Electrical and Electronics Engineers, Inc, 1990.

    [RFC2045]

    "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", N. Freed and N. Borenstein, November 1996. Note that this RFC obsoletes RFC1521, RFC1522, and RFC1590.

    [RFC2046]

    "RFC2046: Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", N. Freed and N. Borenstein, November 1996.
    Available at http://www.ietf.org/rfc/rfc2046.txt. Note that this RFC obsoletes RFC1521, RFC1522, and RFC1590.

    [RFC2119]

    "RFC2119: Key words for use in RFCs to Indicate Requirement Levels", S. Bradner, March 1997.
    Available at: http://www.ietf.org/rfc/rfc2119.txt

    [RFC2376]

    "RFC2376: XML Media Types", E. Whitehead, M. Murata, July 1998.
    This document is obsoleted by [RFC3023].
    Available at: http://www.ietf.org/rfc/rfc2376.txt

    [RFC2396]

    "RFC2396: Uniform Resource Identifiers (URI): Generic Syntax", T. Berners-Lee, R. Fielding, L. Masinter, August 1998.
    This document updates RFC1738 and RFC1808.
    Available at: http://www.ietf.org/rfc/rfc2396.txt

    [RFC2854]

    "RFC2854: The text/html Media Type", D. Conolly, L. Masinter, June 2000.
    Available at: http://www.ietf.org/rfc/rfc2854.txt

    [RFC3023]

    "RFC3023: XML Media Types", M. Murata, S. St.Laurent, D. Kohn, January 2001.
    This document obsoletes [RFC2376].
    Available at: http://www.ietf.org/rfc/rfc3023.txt

    [RFC3066]

    "Tags for the Identification of Languages", H. Alvestrand, January 2001.
    Available at: http://www.ietf.org/rfc/rfc3066.txt

    [RFC3236]

    "The 'application/xhtml+xml' Media Type", M. Baker, P. Stark, January 2002.
    Available at: http://www.ietf.org/rfc/rfc3236.txt

    [XHTML+MathML]

    "XHTML plus Math 1.1 DTD", "A.2 MathML as a DTD Module", Mathematical Markup Language (MathML) Version 2.0. Available at: http://www.w3.org/TR/MathML2/dtd/xhtml-math11-f.dtd

    [XHTMLMIME]

    "XHTML Media Types", Masayasu Ishikawa, 1 August 2002.
    Latest version available at: http://www.w3.org/TR/xhtml-media-types

    [XHTMLMOD]

    "Modularization of XHTML", M. Altheim et al., 10 April 2001.
    Latest version available at: http://www.w3.org/TR/xhtml-modularization

    [XML]

    "Extensible Markup Language (XML) 1.0 Specification (Second Edition)", T. Bray, J. Paoli, C. M. Sperberg-McQueen, E. Maler, 6 October 2000.
    Latest version available at: http://www.w3.org/TR/REC-xml

    [XMLNS]

    "Namespaces in XML", T. Bray, D. Hollander, A. Layman, 14 January 1999.
    XML namespaces provide a simple method for qualifying names used in XML documents by associating them with namespaces identified by URI.
    Latest version available at: http://www.w3.org/TR/REC-xml-names

    [XMLC14N]

    "Canonical XML Version 1.0", J. Boyer, 15 March 2001.
    This document describes a method for generating a physical representation, the canonical form, of an XML document.
    Latest version available at: http://www.w3.org/TR/xml-c14n

    Level Triple-A conformance icon, W3C-WAI Web Content Accessibility Guidelines 1.0

    Translators: Roauf Khalil Aqayi - Fayegh Daneshkhah
    مترجمین: رئوف خلیل آقایی - فایق دانشخواه

    This page translated into Persian/Farsi on October 16, 2011
    اين صفحه در 16 اکتبر 2011 به فارسی ترجمه شده است.

    :Please report errors in this translation to one of the following addresses
    لطفا خطاهای موجود در این ترجمه را با ارسال به یکی از آدرس های ذیل اطلاع دهید.

    http://lists.w3.org/Archives/Public/w3c-translators
    errors@farsiw3c.org
    errors@persianw3c.org