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

فرمول بندی جدیدی از HTML 4 در قالب XML 1.0

توصیه نامه ی W3C در 26 ژانویه سال 2000 و تصحیح شده در 1 اوت سال 2002

نسخه ی فعلی:

http://www.w3.org/TR/2002/REC-xhtml1-20020801

آخرین نسخه:

http://www.w3.org/TR/xhtml1

نسخه ی قبلی:

http://www.w3.org/TR/2000/REC-xhtml1-20000126

نسخه ی نشانه گذاری شده ی متفاوت:

http://www.w3.org/TR/2002/REC-xhtml1-20020801/xhtml1-diff.html

نویسندگان:

قسمت تشکر و قدردانی را مشاهده فرمایید.

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

در ضمن این سند در قالب  نسخه هایی غیر از نسخه ی اصلی هم در دسترس است که عبارتند از: فایل چند بخشی XHTML، نسخه ی پست اسکریپت، نسخه ی PDF، فایل ZIP، و فایل tgz.

كليه ‌ی حقوق چاپ و نشر 2002 W3C كه شامل تعهدات، نشان تجاری، استفاده از سند و قوانین صدور مجوز نرم افزار W3C می‌ باشد، برای (MIT, INRIA, Keio) محفوظ است.

Copyright © 2002 W3C^® (MIT, INRIA, Keio), All Rights Reserved. W3C liability, trademark, document use and software licensing rules apply.

---

چکیده

این مشخصات (فنی)، ویرایش دوم 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 منطبق بر XML هستند. به این ترتیب، آنها به آسانی قابل مشاهده و ویرایش هستند و با ابزارهای XML استاندارد تایید اعتبار می شوند.
• اسناد XHTML می توانند به گونه ای نوشته شوند که بخوبی و یا بهتر از آنچه که قبلا در مرورگرهای منطبق با HTML 4 امکانپذیر بوده است به شیوه ای نو در مرورگرهای هماهنگ با XHTML 1.0 عمل نمایند.
• اسناد XHTML می توانند برنامه های کاربردی (همچون: اسکریپت ها و اپلت ها) که هم بر مبنای مدل شیء سند HTML یا مدل شیء سند [DOM] اکس ام ال XML هستند را مورد استفاده قرار دهند.
• همچنان که خانواده‌ی XHTML تکامل می یابد، احتمال بیشتری وجود دارد که اسناد منطبق بر XHTML 1.0 سازگاری بیشتری با اسناد XHTML و دیگر اسناد مرتبط با آن داشته باشند.

خانواده‌ی 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 به طور کلی عبارتند از:

• توسعه دهندگان سند و طراحان مرورگر همیشه در پی کشف شیوه های نوین جهت بیان ایده هایشان با استفاده از (زبان) نشانه گذاری جدید هستند. در XML، معرفی عناصر جدید یا افزودن ویژگی های عنصر نسبتا آسان است. خانواده‌ی XHTML طوری طراحی شده است تا این عناصر و ویژگی های الحاقی را با استفاده از تکنیک ها و ماژول های XHTML جهت توسعه ی ماژول های جدید سازگار با XHTML منطبق نماید و برای توسعه‌ی واحدهای انطباق XHTML جدید (توضیح داده شده در مشخصات فنی پیمانه بندی XHTML) سازگار نماید. این ماژول ها امکان ترکیب مجموعه ویژگی های موجود و ویژگی های جدید را همزمان با توسعه‌ی محتوا و نیز همگام با طراحی مرورگرهای جدید فراهم می ‌نمایند.
• شیوه های جایگزین دسترسی به اینترنت همواره معرفی می‌شوند. خانواده‌ی XHTML بر مبنای تعامل پذیری مرورگر عمومی در ذهن طراحان آن طراحی شده است. از طریق مرورگری جدید و سازو کار پروفایل بندی سند، سرویس دهنده ها، پراکسی ها و مرورگرها می‌توانند به بهترین شیوه ی ممکن تغییر محتوا را به انجام رسانند. در نهایت توسعه‌ی محتوای سازگار با XHTML امکانپذیر می باشد تا توسط هر مرورگر منطبق بر 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 تعیین می شود. یک نمونه از عنصر ریشه ای می تواند بدین صورت باشد:

   <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
   

4. در سند قبل از عنصر ریشه بایستی یک اعلان DOCTYPE وجود داشته باشد. شناسه عامه ی قرار گرفته در اعلان DOCTYPE بایستی به یکی از سه DTD موجود در DTD های مورد استفاده ی شناسه ی عمومی رسمی مربوطه ارجاع داده شود. شناسه ی سیستم ممکن است تغییر یافته باشد تا قراردادهای سیستم محلی منعکس شوند.

   
   <!DOCTYPE html 
        PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
        "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
   
   <!DOCTYPE html 
        PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
        "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
   
   <!DOCTYPE html 
        PUBLIC "-//W3C//DTD XHTML 1.0 Frameset//EN"
        "http://www.w3.org/TR/xhtml1/DTD/xhtml1-frameset.dtd">
   

5. زیر مجموعه ی DTD نبایستی به گونه ای استفاده شود که وجود هر پارامتر را در DTD باطل نماید.

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

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE html 
     PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
    "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
  <head>
    <title>Virtual Library</title>

  </head>
  <body>
    <p>Moved to <a href="http://example.org/">example.org</a>.</p>
  </body>

</html>

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

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

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

<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
  <head>
    <title>A Math Example</title>
  </head>

  <body>
    <p>The following is MathML markup:</p>
    <math xmlns="http://www.w3.org/1998/Math/MathML">
      <apply> <log/>
        <logbase>

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

    </math>
  </body>
</html>

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

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

<!-- initially, the default namespace is "books" -->
<book xmlns='urn:loc.gov:books'
    xmlns:isbn='urn:ISBN:0-395-36341-6' xml:lang="en" lang="en">
  <title>Cheaper by the Dozen</title>
  <isbn:number>1568491379</isbn:number>
  <notes>

    <!-- 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>
  </notes>

</book>

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 غیر مجاز است، اما بطور گسترده ای از سوی مرورگرهای موجود پذیرفته می شود.

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

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

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

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

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

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

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

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

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 از گسترش این موارد جلوگیری می نماید.

<script type="text/javascript">
<![CDATA[
... unescaped script content ...
]]>
</script>

قسمت های 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 یک اعلان رمزگذاری و یک دستور meta http-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&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 بایستی مرجع این جزء باشد. برای نمونه:

<?xml-stylesheet href="http://www.w3.org/StyleSheets/TR/W3C-REC.css" type="text/css"?>
<?xml-stylesheet href="#internalStyle" type="text/css"?>
<!DOCTYPE html 
     PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
     "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
<title>An internal stylesheet example</title>

<style type="text/css" id="internalStyle">
  code {
    color: green;
    font-family: monospace;
    font-weight: bold;
  }
</style>
</head>
<body>
<p>
  This is text that uses our 
  <code>internal stylesheet</code>.

</p>
</body>
</html>

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. منابع

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