faq-th: Difference between revisions

From Microformats Wiki
Jump to navigation Jump to search
No edit summary
 
(14 intermediate revisions by the same user not shown)
Line 96: Line 96:
Any required [[governance]] of the microformats IRC channel, wiki, and mailing lists (and very little ''has been'' required) is discussed by a group of volunteer administrators, who are listed on that page.
Any required [[governance]] of the microformats IRC channel, wiki, and mailing lists (and very little ''has been'' required) is discussed by a group of volunteer administrators, who are listed on that page.


===Q: ''Who is the registrar for microformats?''===
===ถาม: ''ใครเป็นนายทะเบียนของไมโครฟอร์แมต?''===


A: There is no central registry. Microformats are registered in a distributed manner using profiles. For more information on profiles see http://microformats.org/wiki/profile-uris and http://gmpg.org/xmdp/
ตอบ: ไม่มีนายทะเบียนกลางสำหรับไมโครฟอร์แมต  การลงทะเบียนของไมโครฟอร์แมตนั้นเป็นแค่การแจกจ่ายกันโดยใช้โปรไฟล์  สำหรับข้อมูลเพิ่มเติมเกี่ยวกับโปรไฟล์ ลองดู http://microformats.org/wiki/profile-uris และ http://gmpg.org/xmdp/


Conflicts and interoperability are managed through social processes rather than a formal registry. Current microformat profiles can be found at http://gmpg.org,  http://w3.org, and http://microformats.org.
ความขัดแย้งและความเข้ากันได้ในการใช้งานถูกจัดการผ่านการพูดคุยแลกเปลี่ยนความคิดเห็นมากกว่าระบบการลงทะเบียนแบบเป็นทางการ  โปรไฟล์ของไมโครฟอร์แมตปัจจุบันอยู่ที่ http://gmpg.org,  http://w3.org, และ http://microformats.org.


===Q: ''So multiple microformats with the same name can be valid?''===
===ถาม: ''ถ้าอย่างนั้นไมโครฟอร์แมตหลายๆอันที่มีชื่อเดียวกันก็ได้หรือ?''===


A: Yes. The community at microformats.org can hopefully play a role in determining which is preferred by bringing interested folks together in one place and helping them resolve that question. As long as each microformat maintains a valid profile, each can be used effectively.
ตอบ: ใช่แล้ว  แต่เราหวังว่าชุมชนที่ microformats.org จะสามารถทำหน้าที่นำคนจากหลากหลายที่ๆสนใจในไมโครฟอร์แมตมาร่วมในการออกความเห็นและตอบคำถามข้อนี้ร่วมกัน ตราบใดที่แต่ละไมโครฟอร์แมตมีโปรไฟล์ที่ถูกต้อง ไมโครฟอร์แมตนั้นๆก็สามารถถูกนำไปใช้ได้


===Q: ''How do I validate my microformated content?''===
===ถาม: ''ผมจะรู้ได้ยังไงว่าไมโครฟอร์แมตในเนื้อหาของผมถูกต้องหรือเปล่า?''===


A: Currently there is no automatic general-purpose validator for microformats (See [[to-do#for_all_microformats|To Do - for all microformats]]). There are however some microformat-specific tools listed on the [[implementations]] page which can help with validation. [https://addons.mozilla.org/firefox/4106/ Operator] does a good job of compliant parsing for microformats in general. For [[hcard|hCard]], try the [http://feeds.technorati.com/contacts/ Technorati Contacts Feed service]. For [[hcalendar|hCalendar]], try the [http://feeds.technorati.com/events/ Technorati Events Feed service]. Also, posting your examples to the [http://microformats.org/discuss microformats-discuss mailing list], and adding them to the respective examples/implementations sections/pages will very often get folks from the community to review and validate them for you.
ตอบ: ณ​ ปัจจุบัน ยังไม่มีเครื่องมือตรวจสอบความถูกต้องทั่วไปสำหรับทุกไมโครฟอร์แมต (ลองดู [[to-do#for_all_microformats|สิ่งที่ต้องทำ - สำหรับทุกไมโครฟอร์แมต]]) อย่างไรก็ตาม มีเครื่องมือสำหรับตรวจสอบบางไมโครฟอร์แมตอยู่ที่หน้า [[implementations]] ที่จะสามารถช่วยให้คุณตรวจสอบความถูกต้องได้ [https://addons.mozilla.org/firefox/4106/ โอเปอร์เรเตอร์] ก็เป็นอีกเครื่องมือนึงที่สามารถ parse ไมโครฟอร์แมตโดยทั่วๆไปได้ค่อนข้างดี  สำหรับ [[hcard|hCard]] ลองดู  [http://feeds.technorati.com/contacts/ บริการ Technorati Contacts Feed] สำหรับ [[hcalendar|hCalendar]] ลองดู [http://feeds.technorati.com/events/ บริการ Technorati Events Feed] นอกจากนั้นการส่งตัวอย่างของคุณไปที่ [http://microformats.org/discuss กลุ่มข่าว microformats-discuss] และเพิ่มตัวอย่างไปไว้ในส่วน ตัวอย่าง/การใช้งาน ของแต่ละหน้ายังทำให้ชุมชมมีส่วนร่วมในการให้ความเห็นและตรวจความถูกต้องให้กับคุณได้เหมือนกัน


===Q: ''How do microformats breach language barriers?''===
===ถาม: ''ไมโครฟอร์แมตจะช่วยแก้ปัญหาเรื่องความเข้าใจทางภาษาได้ยังไง?''===
'''Would we have to "force" non-English speaking web page developers to use something like class="name" (as opposed to "namen" or "nom") for their productions to be properly indexed by agents?'''
'''เราจำเป็นที่จะต้อง "บังคับ" นักพัฒนาเว็บที่ไม่ได้พูดภาษาอังกฤษเป็นพื้นฐานให้ใช้อะไรเช่น class="name" (แทนที่จะเป็น "namen" หรือ "nom") เพื่อให้เนื้อหาของเค้าสามารถถูกทำดัชนีโดย search agents ด้วยหรือ?'''


A: Yes, but that's no different to using English words like "class", "span" or "head". This was briefly discussed on the microformats-discuss list most recently as "Language Maps" but has been raised before that. Some folks have raised the issue that microformats use English names for properties, and they would like alternate (non-English) names in other (natural) languages, and perhaps try to establish a mapping between them. As microformats property names are based on existing standards (see [[process]], and [[naming-principles]]), this is another problem that is far outside the scope of microformats. As Ryan King put it, this is a pre-existing (unsolved) "problem" with English-based HTML, the English-based CSS, the English-based HTTP and so on. Note that this is NOT about the internationalization of the content and data itself - which is of course an excellent goal, advocated and promoted by microformats and the standards they are based on (e.g. W3C, IETF). This is purely about the names of the properties (and enumerated values) in the formats. See also [[internationalization]].
ตอบ: ใช่แล้ว แต่มันก็ไม่ต่างอะไรกับการใช้คำภาษาอังกฤษอย่าง "class", "span" หรือ "head" ปัญหานี้ได้มีการถกเถียงกันในกลุ่มข่าว microformats-discuss ในเรื่อง "Language Maps" แต่ก่อนหน้านี้ก็มีการถกเรื่องนี้เหมือนกัน  บางคนก็ได้บอกมาว่าไมโครฟอร์แมตใช้ชื่อภาษาอังกฤษสำหรับ properties และพวกเค้าต้องการให้ใช้ชื่อเป็นภาษาอื่นๆ (ที่ไม่ใช่ภาษาอังกฤษ) ได้ด้วย และก็จะสร้าง mapping ระหว่างภาษาเหล่านั้น


===Q: ''How come microformats sometimes to linger as Drafts even though they seem usable?'' ===
เนื่องจากว่าไมโครฟอร์แมตมีพื้นฐานบนมาตรฐานที่มีอยู่แล้ว (ลองดู [[process]] และ [[naming-principles]]) นี่เลยกลายเป็นปัญหาที่อยู่นอกเหนือไมโครฟอร์แมต  อย่างที่ไรอัน คิงได้ว่าไว้ ปัญหานี้เป็น "ปัญหา" ที่มีอยู่แล้วและยังไม่ได้ถูกแก้ไขจาก HTML, CSS, HTTP และมาตรฐานอื่นๆที่อิงกับภาษาอังกฤษเป็นหลัก  กรุณาทำความเข้าใจว่านี่ไม่เกี่ยวกับการแปลข้อมูลให้เป็นภาษาต่างๆ - ซึ่งก็เป็นเป้าหมายที่ดีซึ่งองค์กรที่สร้างมาตรฐานต่างๆ (เช่น W3C, IETF) ต่างก็สนับสนุนเป้าหมายนี้  ปัญหานี้เป็นปัญหาที่เกี่ยวชื่อของ property และค่าที่อนุญาติสำหรับ property ในไมโครฟอร์แมต  ลองดู [[internationalization]] ด้วย


A: [http://microformats.org/wiki/faq#Q:_Who_controls_microformats.3F Tantek] went over this at the recent [http://2007.sxsw.com/interactive/programming/panels/?action=show&id=IAP060234 The Growth and Evolution of Microformats] panel at [http://en.wikipedia.org/wiki/South_by_Southwest SXSW]. He conveyed that it was important to have a basic software implementation -- even an experimental one -- before moving a format from Draft to Specification. It can sometimes be hard to recognize subtle inconsistencies within a format by eye; however, in the process of implementing a format-reader in code, inconsistencies (if any) can become much more noticeable (due to [[dry | DRY / Don't Repeat Yourself]], among other programming best practices). Then, once such a tool has been created (in effect, confirming the programmability of the format), it can be transitioned to a Specification (so as to encourage other machine-based implementations).
===ถาม: ''ทำไมบางครั้งไมโครฟอร์แมตที่ดูเหมือนใช้งานได้แล้วกลับยังอยู่ในสถานะเป็นเอกสารฉบับร่างอยู่?'' ===


== Creating and Suggesting New Microformats ==
ตอบ: [http://microformats.org/wiki/faq#Q:_Who_controls_microformats.3F คุณแทนเทค]ได้พูดถึงเรื่องนี้ในการอภิปรายหัวข้อ[http://2007.sxsw.com/interactive/programming/panels/?action=show&id=IAP060234 The Growth and Evolution of Microformats] ที่ผ่านมาเมื่อเร็วๆนี้ในงานสัมนา [http://en.wikipedia.org/wiki/South_by_Southwest SXSW]  โดยเขาได้อธิบายว่าก่อนที่จะเปลี่ยนสถานะของไมโครฟอร์แมตจากเอกสารฉบับร่างเป็นมาตรฐานนั้น มีความจำเป็นอย่างยิ่งที่จะต้องมีโปรแกรมที่นำฟอร์แมตนั้นไปใช้จริงๆก่อน ถึงแม้ว่าโปรแกรมนั้นจะยังเป็นตัวทดลองอยู่ก็ตาม  เหตุผลก็คือมันค่อนข้างยากที่จะเห็นช่องโหว่ในไมโครฟอร์แมตจากการอ่านและตรวจด้วยตาเปล่า แต่เมื่อได้ทดลองเขียนโปรแกรมเพื่ออ่านไมโครฟอร์แมตนั้นจริงๆ จะสามารถเห็นช่องโหว่และข้อผิดพลาดของฉบับร่างได้อย่างชัดเจนยิ่งขึ้น (สืบเนื่องจากหลักการ [[dry | DRY / Don't Repeat Yourself]])  หลังจากที่เครื่องมือสำหรับไมโครฟอร์แมตนั้นได้ถูกสร้าง (ซึ่งหมายความว่าฟอร์แมตนั้นเหมาะสมพอที่จะนำมาเขียนโปรแกรมต่างๆได้) ไมโครฟอร์แมตจึงจะเปลี่ยนสถานะจากเอกสารฉบับร่างเป็นมาตรฐาน (หรือ Specification) เพื่อนำไปสู่การเขียนโปรแกรมอื่นๆเพิ่มเติมต่อไป


===Q. ''I would like to author a new microformats open standards specification for my site/business.  How do I get started?''===
== การสร้างและเสนอไมโครฟอร์แมตใหม่ ==


A. The first thing to do before attempting a new microformat open standard is to make as much use of [[POSH]] and existing [[microformats]] open standards as possible in whatever site you are looking to mark up with your new microformat, as a way of learning what is left to be done. That is, at a minimum first:
===ถาม. ''ผมอยากจะสร้างไมโครฟอร์แมตใหม่สำหรับเว็บไซต์/ธุรกิจของผม จะเริ่มอย่างไรดี?''===
* Mark up all people and organizations as [[hcard|hCards]].
* Mark up all events and time based things as [[hcalendar|hCalendar]] events.
* Mark up all reviews as [[hreview|hReviews]].
* etc.
Then join the microformats [http://microformats.org/discuss discuss list], and ask folks what they think of your use of the microformats and if it can be improved.


From that experience you will then be able to figure out what is left to be specified.  Otherwise it is too hard to approach the "whole problem".
ตอบ. สิ่งแรกที่คุณต้องทำก่อนที่จะสร้างไมโครฟอร์แมตใหม่คือพยายามใช้งาน [[POSH]] และ[[microformats|ไมโครฟอร์แมต]]ต่างๆที่มีอยู่ให้มากที่สุดเท่าที่จะทำได้ในเว็บไซต์ของคุณ เพื่อที่จะเรียนรู้ว่ายังเหลืออะไรที่จะต้องเพิ่มเติมในฟอร์แมตใหม่ของคุณ ก่อนอื่นเลยคุณจะต้อง:
* Mark up บุคคุลหรือองค์กรด้วย [[hcard|hCards]]
* Mark up เหตุการณ์ต่างๆและสิ่งที่อ้างอิงเรื่องวันและเวลาด้วย [[hcalendar|hCalendar]]
* Mark up บทวิจารณ์ด้วย [[hreview|hReviews]].
* ฯลฯ
จากนั้นก็เข้าร่วมใน[http://microformats.org/discuss กลุ่มสนทนา]เกี่ยวกับไมโครฟอร์แมตและขอความคิดเห็นจากสมาชิกในกลุ่มว่าพวกเขาคิดอย่างไรกับการใช้งานไมโครฟอร์แมตของคุณ และจะมีวิธีพัฒนาวิธีการใช้งานของคุณหรือไม่


Once you have completed that, take a look at the microformats [[process]] for how to walk through the steps of creating a new microformat, and note the specific problem you are trying to solve to the microformats-discuss list.  This will help you find more people to help you solve the problems you are trying to solve.
จากประสบการณ์นี้คุณจะสามารถพบว่ามีอะไรที่ยังขาดไปและต้องเพิ่มเข้าไปในไมโครฟอร์แมตใหม่ของคุณบ้าง ถ้าไม่ใช้วิธีนี้คุณจะพบว่ามันยากเกินไปที่จะมองเห็น "ภาพรวมของปัญหา" ทั้งหมด


===''Q How do I know if an idea for a Microformat has already been suggested in the past?''===
หลังจากคุณได้ทำสิ่งที่กล่าวมาทั้งหมดข้างต้น ลองดู[[process|แนวทางปฏิบัติ]]เพื่อเรียนรู้ขั้นตอนต่างๆในการสร้างไมโครฟอร์แมตใหม่ และแจงรายละเอียดปัญหาที่คุณต้องการแก้ไขให้กับกลุ่มสนทนาเกี่ยวไมโครฟอร์แมตได้รับทราบ  วิธีนี้จะช่วยให้คุณหาคนที่สามารถช่วยคุณแก้ปัญหาได้อีกด้วย


A. Check the list of proposed and rejected microformats.
===''ถาม ผมจะรู้ได้ยังไงว่าไอเดียสำหรับไมโครฟอร์แมตถูกเสนอมาแล้วหรือยัง?''===
* [[rejected-formats]]


===Q. ''What if I can't find real-world examples of a standard I'd like to propose?''===
ตอบ. ลองเช็ครายชื่อไมโครฟอร์แมตที่ถูกเสนอและตอบปฏิเสธที่
* [[rejected-formats|ฟอร์แมตที่ถูกปฏิเสธ]]


A. If we can't find real-world examples of the '''types of data''' a proposal would address, it's probably not suitable for a microformat. If we only can't find real-world examples of the '''specific markup''' a proposal would use for that data, however, that's not really a problem. It's actually the lack of such standard markup in real-world publishing around a specific problem that suggests the need for increased consensus.
===ถาม. ''จะทำยังไงถ้าผมหาตัวอย่างการใช้งานจริงสำหรับมาตรฐานที่ผมอยากนำเสนอไม่ได้?''===


== Specific Microformat Questions ==
ตอบ. ถ้าเราไม่สามารถหาตัวอย่างการใช้งานจริงสำหรับ '''ชนิดของข้อมูล''' ที่คุณต้องการการนำเสนอ มันคงไม่เหมาะที่จะเป็นไมโครฟอร์แมต  แต่ถ้าเราแค่ไม่สามารถหาตัวอย่างการใช้งานจริงสำหรับ '''markup บางตัว''' เราอาจใช้การนำเสนอนั้นได้  โดยทั่วไปแล้วกรณีเกี่ยวกับ markup มักไม่ใช่ปัญหาจริงๆ เพราะปัญหาเหล่านี้ส่วนใหญ่เกิดจากการขาดมาตรฐานในการ markup เวลาใช้งานจริง ซึ่งหมายความว่าจะต้องมีการถามความคิดเห็นของคนส่วนใหญ่ว่าควรใช้ markup แบบไหนมากกว่า
If you have a question regarding a specific microformat, you may want to check the FAQ specific to that microformat.
 
* [[hatom-faq]]
== คำถามเจาะจงเกี่ยวกับไมโครฟอร์แมต ==
* [[hcalendar-faq]]
ถ้าคุณมีคำถามเกี่ยวกับไมโครฟอร์แมตอันใดอันหนึ่ง ลองเช็คที่คำถามที่ถูกถามบ่อยๆสำหรับไมโครฟอร์แมตนั้นๆดูสิ
* [[hcard-faq]]
* [[hatom-faq | คำถามที่ถูกถามบ่อยๆเกี่ยวกับ hatom]]
* [[hreview-faq]]
* [[hcalendar-faq | คำถามที่ถูกถามบ่อยๆเกี่ยวกับ hcalendar]]
* [[rel-faq]]
* [[hcard-faq | คำถามที่ถูกถามบ่อยๆเกี่ยวกับ hcard]]
* [[rel-tag-faq]]
* [[hreview-faq | คำถามที่ถูกถามบ่อยๆเกี่ยวกับ hreview]]
* [http://gmpg.org/xfn/faq xfn-faq]
* [[rel-faq | คำถามที่ถูกถามบ่อยๆเกี่ยวกับ rel]]
* [[xfolk-faq]]
* [[rel-tag-faq | คำถามที่ถูกถามบ่อยๆเกี่ยวกับ rel-tag]]
* [[xmdp-faq]]
* [http://gmpg.org/xfn/faq คำถามที่ถูกถามบ่อยๆเกี่ยวกับ xfn]
* [[xoxo-faq]]
* [[xfolk-faq | คำถามที่ถูกถามบ่อยๆเกี่ยวกับ xfolk]]
* [[xmdp-faq | คำถามที่ถูกถามบ่อยๆเกี่ยวกับ xmdp]]
* [[xoxo-faq | คำถามที่ถูกถามบ่อยๆเกี่ยวกับ xoxo]]


== Class interactions ==
== Class interactions ==
Line 174: Line 176:




== <code>&lt;div&gt;</code> and <code>&lt;span&gt;</code> semantics ==
== การใช้ <code>&lt;div&gt;</code> และ <code>&lt;span&gt;</code> ==


=== Q. ''Is it semantically meaningless to use divs?'' ===
=== ถาม. ''การใช้ div นั้นไม่มีความหมายเลยหรือ?'' ===


A. Yes, both <code>&lt;div&gt;</code> and <code>&lt;span&gt;</code> have nearly no semantics. <code>&lt;div&gt;</code> can be used to represent a "division" of the page content. Similarly <code>&lt;span&gt;</code> can be used to reperesent that that "span" of text has some meaning, but the specifics of what that meaning is undefined by the <code>&lt;span&gt;</code>.
ตอบ. ใช่แล้ว ทั้ง <code>&lt;div&gt;</code> และ <code>&lt;span&gt;</code> เรียกได้ว่าแทบจะไม่มีความหมายเท่าไร <code>&lt;div&gt;</code> สามารถแทนที่ "ส่วนใดส่วนหนึ่ง" ของเนื้อหา ส่วน <code>&lt;span&gt;</code> สามารถใช้เพื่อแทนที่ "ช่วงใดช่วงหนึ่ง" ของประโยคที่มีความหมายพิเศษ แต่ไม่ได้ระบุอย่างเจาะจงว่าช่วงนั้นของประโยคหมายถึงอะไร




=== Q. ''Does the use of <code>&lt;div&gt;</code> and <code>&lt;span&gt;</code> elements add any semantics to web pages?''===
=== ถาม. ''การใช้ <code>&lt;div&gt;</code> และ <code>&lt;span&gt;</code> จะเพิ่มคุณค่าความหมายให้กับหน้าเว็บหรือเปล่า?''===


A. According to the [http://www.w3.org/TR/REC-html40/struct/global.html#h-7.5.4 HTML 4 spec], <code>&lt;div&gt;</code> and <code>&lt;span&gt;</code> "offer a generic mechanism for adding structure to documents." Their only meaning is in dividing documents into sections, and as such, their presence implies that the content within has a specific, but undefined by the element markup, semantic. Thus they are nearly semantic-free.
ตอบ. ตามที่ได้ระบุไว้ใน [http://www.w3.org/TR/REC-html40/struct/global.html#h-7.5.4 สเป็ก HTML 4] <code>&lt;div&gt;</code> และ <code>&lt;span&gt;</code> "เป็นกลไกคร่าวๆเพื่อเพิ่มโครงสร้างให้กับเนื้อหา" ความหมายเดียวของอีลีเม้นต์เหล่านี้คือเพื่อแบ่งเอกสารเป็นส่วนๆ ซึ่งหมายความได้ว่าส่วนนั้นอาจจะมีความหมายบางอย่างพิเศษ แต่ไม่สามารถบอกได้จาก markup ได้ว่าความหมายนั้นคืออะไร


=== Q. ''Why do the examples on the wiki use <code class="element">&lt;span&gt;</code> and <code class="element">&lt;div&gt;</code> for nearly everything?''===
=== ถาม. ''ทำไมตัวอย่างในวิกินี้ถึงใช้ <code class="element">&lt;span&gt;</code> และ <code class="element">&lt;div&gt;</code> เพื่อแทนความหมายเกือบจะทุกอย่างเลยล่ะ?''===


A. <code class="element">&lt;span&gt;</code> and <code class="element">&lt;div&gt;</code> are generic elements in HTML. When you use microformats, you should pick the most specific semantic element available for the semantics you are trying to express. You might, for example, apply <code>class="vevent"</code> to a <code><nowiki><tr></nowiki></code>, or <code>class="vcard"</code> to a <code><nowiki><p></nowiki></code>.
ตอบ. <code class="element">&lt;span&gt;</code> และ <code class="element">&lt;div&gt;</code> เป็นอีลีเม้นต์ที่ไม่ได้มีความหมายเฉพาะใน HTML เมื่อคุณใช้ไมโครฟอร์แมตคุณควรเลือกอีลีเม้นต์ที่ตรงกับความหมายที่สุดเท่าที่จะทำได้เป็นอันดับแรกและก็ให้ความหมายไมโครฟอร์แมตผ่าน class เช่นคุณสามารถใช้ <code>class="vevent"</code> กับ <code><nowiki><tr></nowiki></code> หรือ <code>class="vcard"</code> กับ <code><nowiki><p></nowiki></code> ก็ได้


== Class semantics ==
== Class semantics ==


===Q. ''How will microformat class names impact page size?''===
===ถาม. ''ชื่อของ class ในไมโครฟอร์แมตจะมีผลกับขนาดของหน้าเว็บยังไงบ้าง?''===


A. You probably won't notice any impact on page size when authoring with microformats.  Our experience is that people use comparably sized class names, and [[semantic-class-names|semantic class names]] are now considered an industry best practice. Some sites are successfully publishing millions of microformats, and we haven't heard any complaints yet. You are more likely to gain space savings by more fully adopting [[microformats#the_microformats_principles|the principles of microformats]], and eliminating tables for layout.
ตอบ. คุณจะไม่ค่อยเห็นผลกระทบกับขนาดของหน้าเว็บที่ใช้ไมโครฟอร์แมตซักเท่าไร จากประสบการณ์ของเราคนก็ใช้ชื่อ class ที่ยาวพอๆกับชื่อ class ในไมโครฟอร์แมต และ [[semantic-class-names|semantic class names]] เองก็ถือเป็น best practice ในแวดวงเว็บในตอนนี้เหมือนกัน บางเว็บไซต์ส่งหน้าเว็บที่ใช้ไมโครฟอร์แมตเป็นล้านๆหน้าแต่ก็ไม่บ่นอะไรกับเรื่องขนาดของหน้าเว็บที่เพิ่มขึ้นเลยแม้แต่น้อย เราคิดว่าคุณน่าจะประหยัดเนื้อที่ได้มากกว่าด้วยซ้ำถ้าคุณลองทำตาม [[microformats#the_microformats_principles|หลักการของไมโครฟอร์แมต]] และเลิกใช้ table เพื่อจัด layout ของหน้าเว็บคุณ
<span class="todo">''TODO: Consider creating a new section for web authoring tips?  Or at least linking to another site that advocates good authorship.''</span>
<span class="todo">''TODO: Consider creating a new section for web authoring tips?  Or at least linking to another site that advocates good authorship.''</span>


===Q. ''Can an element have more than one class''===
===ถาม. ''หนึ่ง element สามารถมีได้หลาย class หรือเปล่า''===


A. Yes, the class attribute can contain a space delimited list of classes. For example:
ตอบ. element สามารถมีได้หลายๆ class โดยใช้เว้นวรรคเป็นตัวคั่นแต่ละ class ใน attribute  เช่น:
   &lt;p class=&quot;todo idea&quot;&gt;Write high quality and simple mark-up.&lt;/p&gt;
   &lt;p class=&quot;todo idea&quot;&gt;เขียน mark-up ที่มีคุณภาพ&lt;/p&gt;


See W3C HTML 4.01 Specification: [http://www.w3.org/TR/html401/struct/global.html#adef-class 7.5.2 Element identifiers: the id and class attributes]
ลองดูสเป็กของ HTML 4.01 จาก W3C ที่: [http://www.w3.org/TR/html401/struct/global.html#adef-class 7.5.2 Element identifiers: the id and class attributes]


===Q. ''Do (X)HTML class names have semantics?''===
===ถาม. ''ชื่อของ class ใน (X)HTML มีความหมายหรือเปล่า?''===


A. The HTML4 specification does not define any particular class values [http://www.w3.org/TR/REC-html40/struct/global.html#h-7.5.2 REF], nor does it define any particular semantic for class values [http://www.w3.org/TR/REC-html40/struct/global.html#h-7.5.2 REF], except that they "may be used for general user agent processing" [http://www.w3.org/TR/REC-html40/struct/global.html#h-7.5.2 REF]. However, the [http://www.w3.org/TR/WD-htmllink-970328#profile" draft of "Hypertext Links in HTML"], allows for a "profile" to define meanings for those classes. [http://gmpg.org/xmdp/ XMDP] is a format for defining meta data profiles for (X)HTML, and thus an XMDP profile can be used to define the meanings of class names.
ตอบ. สเป็ก HTML4 ไม่ได้ระบุค่าที่ class จะเป็นได้เอาไว้ [http://www.w3.org/TR/REC-html40/struct/global.html#h-7.5.2 REF] และก็ไม่ได้บอกด้วยว่าค่าของ class จะต้องมีความหมายแบบใดแบบหนึ่ง [http://www.w3.org/TR/REC-html40/struct/global.html#h-7.5.2 REF] เพียงแค่บอกว่าค่าของ class "สามารถถูกนำไปใช้เพื่อประมวลผลโดย user agent ทั่วไป" [http://www.w3.org/TR/REC-html40/struct/global.html#h-7.5.2 REF] อย่างไรก็ตาม [http://www.w3.org/TR/WD-htmllink-970328#profile" เอกสารฉบับร่างชื่อ "Hypertext Links in HTML"] อนุญาติให้  "profile" ระบุความหมายพิเศษสำหรับค่าของ class ได้  [http://gmpg.org/xmdp/ XMDP] เป็นฟอร์แมตหนึ่งที่ระบุ profiles สำหรับ (X)HTML ซึ่งคุณสามารถนำมาใช้เพื่อให้ความหมายของชื่อ class ได้


See also:
ลองดู:
* [http://tantek.com/log/2002/12.html#L20021216 A Touch Of Class]
* [http://tantek.com/log/2002/12.html#L20021216 A Touch Of Class]
* [http://www.w3.org/TR/WD-htmllink-970328 Hypertext Links in HTML]
* [http://www.w3.org/TR/WD-htmllink-970328 Hypertext Links in HTML]
Line 223: Line 225:
* [http://tantek.com/log/2004/07.html#d20t2359 More about the class attribute, Tantek Çelik]
* [http://tantek.com/log/2004/07.html#d20t2359 More about the class attribute, Tantek Çelik]


===Q. ''Should human readable data go into class names?'' ===
===ถาม. ''เราควรใส่ข้อมูลที่ต้องการให้ผู้อ่านได้อ่านไว้ในชื่อ class หรือเปล่า?'' ===


A. No. We should not put human readable data into the <code>class</code> attribute, because it puts human-readable data in a spot that's no longer visible. See the [[principles]].
ตอบ. เราไม่ควรใส่ข้อมูลที่เขียนเพื่อให้ผู้อ่านได้อ่านไว้ใน <code>class</code> attribute เพราะว่าการทำแบบนั้นจะทำให้ข้อมูลไปอยู่ในจุดที่ผู้อ่านไม่สามารถเห็นได้ ดู [[principles|หลักการ]].


Q. Follow-up. How is that different from putting human readable data into the <code>title</code> attribute?
ถาม. ถามต่อ  แล้วการใส่ข้อมูลไว้ในชื่อ class มันต่่างอะไรกับการใส่ไว้ใน <code>title</code> attribute ล่ะ?


A. The title attribute is displayed in tool-tips in the overwhelming majority of browsers in use and thus is quite semi-visible, and thus human verifiable by casual users. The class attribute is not displayed in a tool-tip or any other user interface (not withstanding developer interfaces like view source).
ตอบ. <code>title</code> attribute นั้นถูกแสดงในทูลทิปในหลายๆเบราว์เซอร์ และก็ถือว่าเกือบๆจะมองเห็นได้โดยผู้ใช้ทั่วไป แต่ class attribute นั้นจะไม่ถูกแสดงเลย ไม่ว่าจะเป็นในทูลทิปหรือในส่วนอื่นๆของ user interface (ไม่นับรวม user interface ที่ใช้โดยนักพัฒนา เช่นตอนดูซอร์สโค้ด).


== Microformats and Spam ==
== Microformats and Spam ==
Line 251: Line 253:
In addition, microformats encourage the content to be visible and thus prefer the text of an element rather than using the 'title' attribute or any other less visible alternative.  The exception is made for datetimes and abbr due to the fact that microformats are for humans first, machines second.  Thus the content of the abbr element is used to provide human visible content and the machine equivalent is placed in the less visible (but still easily verifiable) 'title' attribute.
In addition, microformats encourage the content to be visible and thus prefer the text of an element rather than using the 'title' attribute or any other less visible alternative.  The exception is made for datetimes and abbr due to the fact that microformats are for humans first, machines second.  Thus the content of the abbr element is used to provide human visible content and the machine equivalent is placed in the less visible (but still easily verifiable) 'title' attribute.


== Nesting of elements ==
== การใช้ element ซ้อนกัน ==
=== Q. ''It seems that <code>&lt;span class=&quot;vcard fn org&quot; id=&quot;club&quot;&gt;...&lt;/span&gt;</code> should work. Is this correct?''===
=== ถาม. ''ดูเหมือนว่า <code>&lt;span class=&quot;vcard fn org&quot; id=&quot;club&quot;&gt;...&lt;/span&gt;</code> น่าจะใช้งานได้นี่นา ถูกหรือเปล่า?''===


A. No. See [[hcard-faq#nesting-properties]].
ตอบ. คำตอบคือผิด ลองดู [[hcard-faq#nesting-properties]].


== See Also ==
== See Also ==
* [[misconceptions]]
* [[misconceptions]]

Latest revision as of 15:50, 30 July 2008

คำถามที่ถูกถามบ่อยๆเกี่ยวกับไมโครฟอร์แมต

คุณสามารถดูคำถามที่ถูกถามบ่อยๆเกี่ยวกับไมโครฟอร์แมตได้ในหน้านี้ สำหรับคำถามจาก press กรุณาดู press-faq

ถ้าคุณกำลังหาไมโครฟอร์แมตสำหรับ mark up คำถามที่ถูกถามบ่อยๆ (FAQs) ลองอ่าน question-answer

คำถามเกี่ยวกับวิกิ

ถาม: ผมจะสร้างชื่อผู้ใช้ได้อย่างไร? ทำไมวิกิถึงไม่ให้ผมใช้ชื่อที่ผมระบุ?

ตอบ: ก่อนอื่นกรุณาอ่าน: http://en.wikipedia.org/wiki/Wikipedia:Username เราแนะนำให้คุณใช้ชื่อจริงมากกว่าชื่อเล่นหรือนามปากกา เนื่องจากการใช้ชื่อจริงส่งเสริมให้เกิดความโปร่งใสและความรับผิดชอบมากกว่า

ปัญหาที่ผู้ใช้ส่วนใหญ่พบบ่อยที่สุดเวลาสร้างชื่อผู้ใช้คือลืมใช้ตัวอักษรตัวใหญ่สำหรับตัวอักษรแรกของชื่อผู้ใช้ ลองใช้ชื่อจริงของคุณในรูปแบบ WikiCase เป็นชื่อผู้ใช้, เช่น RyanKing

กลุ่มข่าว

ถาม: ผมได้เป็นสมาชิกกลุ่มข่าว แต่ทำไมผมไม่เห็นคำตอบของผมในกลุ่มข่าวเลย?

ตอบ: เราไม่ได้มีการควบคุมข้อความในกลุ่มข่าว microformats-discuss กลุ่มข่าวนี้จะรับข้อความจากสมาชิกเท่านั้น เพราะฉะนั้นคุณจะต้องส่งข้อความหากลุ่มข่าว microformats-discuss ผ่านอีเมล์ที่คุณใช้สมัครเป็นสมาชิกเท่านั้น

ถาม: "The message's content type was not explicitly allowed" หมายความว่าอะไร?

ตอบ: กรุณาอ่าน กฏระเบียบการใช้กลุ่มข่าว โดยเฉพาะอย่างยิ่ง:

ห้ามใช้อีเมล์แบบ HTML หรือ RTF โปรแกรมเมล์ของคุณควรจะให้คุณสามาถเลือกที่จะส่งเมล์แบบ plain text ได้ ให้ส่งเมล์ในรูปแบบของ plain text เท่านั้น มิเช่นนั้นอาจไม่มีใครสามารถอ่านเมล์คุณได้

กลุ่มข่าวถูกเซ็ตค่าให้ตีกลับเมล์ที่ถูกส่งในรูปแบบของ text/html โดยอัตโนมัติ เพราะฉะนั้นกรุณาตั้งค่าโปรแกรมเมล์คุณให้ส่งอีเมล์ในรูปแบบของ plain text

คำถามเบื้องต้นเกี่ยวกับไมโครฟอร์แมต

ถาม: xxx หมายความว่าอะไร?

ตอบ: ลองดู อภิธานศัพท์.

ถาม: ใครใช้ไมโครฟอร์แมตบ้าง?

ตอบ: ลองดู รายชื่อผู้ใช้ดังๆ; ผู้ใช้ไมโครฟอร์แมตอื่นๆ และ เครื่องมือสำหรับไมโครฟอร์แมต

ถาม: ไมโครฟอร์แมตมีไว้เพื่ออะไร? และผมควรจะใช้ไมันเมื่อไร?

ตอบ: คุณกำลังเขียน HTML เพื่อแสดงข้อมูลที่มีความหมายเช่นที่อยู่ คุณถามตัวเองว่า: ผมต้องการจะ mark up ข้อมูลนี้ด้วย class เพื่อจัดรูปแบบด้วย CSS แล้วผมควรจะใช้อะไรเป็นชื่อ class เหล่านี้ดีล่ะ? คำตอบก็คือลองดูมาตรฐานไมโครฟอร์แมตที่เกี่ยวข้องดูสิ แล้วก็ใช้ชื่อ class ที่อยู่ในมาตรฐานนั้น เพียงเท่านี้คุณก็ไม่ต้องสร้าง class ของคุณเองขึ้นมา นอกจากนั้นหน้าเว็บของคุณยังมีความหมายสำหรับโปรแกรมคอมพิวเตอร์ที่เข้าใจ mark up ของคุณอีกด้วย

ไมโครฟอร์แมตถูกออกแบบมาเพื่อให้ข้อมูลทีคุณเผยแพร่ออกไปมีความหมายสำหรับโปรแกรมคอมพิวเตอร์ที่อ่านหน้าเว็บของคุณ มันเอื้อประโยชน์ให้โปรแกรมต่างๆ เช่น search engine สามารถใช้ข้อมูลที่คุณเผยแพร่ได้ดีขึ้น

ถาม: ไมโครฟอร์แมตขึ้นอยู่กับ (X)HTML หรือเปล่า?

ตอบ: ไมโครฟอร์แมตถูกสร้างมาให้ถูก embed ในรูปแบบต่างๆได้ ไม่ว่าจะเป็น (X)HTML, RSS, Atom หรือที่ไหนก็ตามที่ใช้ (X)HTML ได้


ถาม: ผมจะช่วยสนับสนุนไมโครฟอร์แมตได้อย่างไร?

ตอบ: ลองดูที่ get-started ถ้าคุณอยากจะใช้งานไมโครฟอร์แมตด้วยตัวเอง และ งานที่ยังค้างอยู่ ถ้าคุณต้องการช่วยในการพัฒนาไมโครฟอร์แมต นอกจากนั้นลองดู http://microformats.org/discuss เพื่อร่วมพูดคุยเกี่ยวกับไมโครฟอร์แมต


ถาม: ผมอยากจะบริจาคเงินเพื่อช่วยเหลือโครงการไมโครฟอร์แมต ผมต้องทำอย่างไร?

ตอบ: ขอบคุณสำหรับความเต็มใจของคุณที่จะช่วยเหลือไมโครฟอร์แมต เราเพิ่งเริ่มก่อตั้งเว็บไซต์นี้มาไม่นาน และก็ได้ตัดสินใจว่าในระหว่างที่เรายังตัดสินใจไม่ได้ว่าจะรับเงินบริจากยังไง เราขอให้คุณบริจาคเงินให้กับมูลนิธิและโครงการอื่นๆก่อน (เช่น สภากาชาด)


ถาม: ไมโครฟอร์แมตไหนที่ถูกนำไปใช้งานแล้วบ้าง?

ตอบ: ลองดูหน้า implementations


ถาม: ผมควรจะใช้ไมโครฟอร์แมตอันไหน?

ตอบ: มีความเป็นไปได้ว่าเว็บไซต์ของคุณมีข้อมูลที่คล้ายคลึงกับไมโครฟอร์แมตหลายๆแบบอยู่แล้ว ยกตัวอย่างเช่น คุณคงมีข้อมูลเกี่ยวกับบุคคล และ/หรือ ที่อยู่ติดต่อของเค้าที่ไหนซักที่ คุณสามารถ mark up ข้อมูลเหล่านี้ด้วย hCard (ลองดูหน้า hCard authoring สำหรับวิธีใช้งานอยางละเอียด หรือถ้าคุณกำลังจะประกาศข่าว (press release) ลองใช้ hAtom ดูสิ


ถาม: คุณมีตราไมโครฟอร์แมตที่ผมสามารถลิงก์มาจากหน้าเว็บหรือบล๊อกของผมหรือไม่?

ตอบ: เรามีตราอยู่ที่ buttons แต่เราเปิดรับตราใหม่ๆเสมอ! ส่งตราที่คุณทำมาให้เราได้เลย!


ถาม. มีเครื่องมืออะไรที่สนับสนุนการใช้งานไมโครฟอร์แมตบ้าง?

ตอบ. มีมากมายเลย...ลองดูที่ implementations

ถาม. มีวิธีไหนที่จะระบุได้บ้างว่าหน้าเว็บมี markup ที่สนับสนุนไมโครฟอร์แมต?

ตอบ. แอททริบิวท์ 'profile' ของ HTML HEAD สามารถบอกโปรแกรมต่างๆได้ว่าอาจจะมีไมโครฟอร์แมตอยู่ในหน้าเว็บ มาตรฐาน HTML ของ W3C ได้อธิบายเกี่ยวกับแอททริบิวท์ profile มากกว่านี้ และ คำอธิบายเกี่ยวกับ XMDP ก็เขียนเกี่ยวกับวิธีการใช้มัน

ถาม. จะดีกว่ามั๊ยถ้าผมจะใช้ URI เพื่อแทนข้อมูลเกี่ยวกับภูมิศาสตร์แทนที่จะใช้ชื่อ class แบบไมโครฟอร์แมต?

ตอบ. โดยทั่วไปแล้วเราคิดว่ามันยุ่งยากกว่า และก็ไม่ค่อยเป็นมิตรกับคนที่ตีพิมพ์ข้อมูลที่จะต้องใช้ URI แทนที่ class

คนที่ตีพิมพ์ข้อมูลภูมิศาสตร์ไม่ได้ตีพิมพ์ลิงก์ไปหาข้อมูลเหล่านั้น พวกเค้าตีพิมพ์ *เนื้อหา* ที่เกียวกับข้อมูล ภูมิศาสตร์ ต่างหาก

เพราะฉะนั้นสิ่งที่ง่ายที่สุดสำหรับผู้แต่งคือทิ้งข้อมูลที่ตีพิมพ์ในเนื้อหาและ mark up เนื้อหาภูมิศาสตร์นั้นด้วย class ที่มีความหมายแทนที่จะย้าย (หรือคัดลอก) เนื้อหาไปไว้ใน URI

แต่ทั้งนี้ทั้งนั้นก็ต้องดูว่าคุณต้องการจะสร้างลิงก์เพื่อเปิดแผนที่ไปที่จุดภูมิศาสตร์นั้นๆหรือเปล่า ในกรณีนี้การใช้งานลิงก์เป็นสิ่งที่เหมาะสมที่เดียว เพราถ้าคุณบังคับผู้ใช้ให้ต้องใช้ โปรโตคอล "geo:" แทน "http:" คุณคงทำให้ผู้ใช้งานรำคาญตายแน่ๆ

ถาม: ใครเป็นคนควบคุมไมโครฟอร์แมต?

ตอบ: An open community. Microformats are open standards licensed under Creative Commons Attribution. Much of the work here was begun on Technorati's Developer Wiki, but Technorati has since divested control of these microformat standards to the open community here. The microformats.org domain is registered to Rohit Khare (see Whois microformats.org), CommerceNet is graciously hosting the servers, but claims no control over microformat standards. Anyone may follow the established process and contribute towards the development of microformat standards.

Any required governance of the microformats IRC channel, wiki, and mailing lists (and very little has been required) is discussed by a group of volunteer administrators, who are listed on that page.

ถาม: ใครเป็นนายทะเบียนของไมโครฟอร์แมต?

ตอบ: ไม่มีนายทะเบียนกลางสำหรับไมโครฟอร์แมต การลงทะเบียนของไมโครฟอร์แมตนั้นเป็นแค่การแจกจ่ายกันโดยใช้โปรไฟล์ สำหรับข้อมูลเพิ่มเติมเกี่ยวกับโปรไฟล์ ลองดู http://microformats.org/wiki/profile-uris และ http://gmpg.org/xmdp/

ความขัดแย้งและความเข้ากันได้ในการใช้งานถูกจัดการผ่านการพูดคุยแลกเปลี่ยนความคิดเห็นมากกว่าระบบการลงทะเบียนแบบเป็นทางการ โปรไฟล์ของไมโครฟอร์แมตปัจจุบันอยู่ที่ http://gmpg.org, http://w3.org, และ http://microformats.org.

ถาม: ถ้าอย่างนั้นไมโครฟอร์แมตหลายๆอันที่มีชื่อเดียวกันก็ได้หรือ?

ตอบ: ใช่แล้ว แต่เราหวังว่าชุมชนที่ microformats.org จะสามารถทำหน้าที่นำคนจากหลากหลายที่ๆสนใจในไมโครฟอร์แมตมาร่วมในการออกความเห็นและตอบคำถามข้อนี้ร่วมกัน ตราบใดที่แต่ละไมโครฟอร์แมตมีโปรไฟล์ที่ถูกต้อง ไมโครฟอร์แมตนั้นๆก็สามารถถูกนำไปใช้ได้

ถาม: ผมจะรู้ได้ยังไงว่าไมโครฟอร์แมตในเนื้อหาของผมถูกต้องหรือเปล่า?

ตอบ: ณ​ ปัจจุบัน ยังไม่มีเครื่องมือตรวจสอบความถูกต้องทั่วไปสำหรับทุกไมโครฟอร์แมต (ลองดู สิ่งที่ต้องทำ - สำหรับทุกไมโครฟอร์แมต) อย่างไรก็ตาม มีเครื่องมือสำหรับตรวจสอบบางไมโครฟอร์แมตอยู่ที่หน้า implementations ที่จะสามารถช่วยให้คุณตรวจสอบความถูกต้องได้ โอเปอร์เรเตอร์ ก็เป็นอีกเครื่องมือนึงที่สามารถ parse ไมโครฟอร์แมตโดยทั่วๆไปได้ค่อนข้างดี สำหรับ hCard ลองดู บริการ Technorati Contacts Feed สำหรับ hCalendar ลองดู บริการ Technorati Events Feed นอกจากนั้นการส่งตัวอย่างของคุณไปที่ กลุ่มข่าว microformats-discuss และเพิ่มตัวอย่างไปไว้ในส่วน ตัวอย่าง/การใช้งาน ของแต่ละหน้ายังทำให้ชุมชมมีส่วนร่วมในการให้ความเห็นและตรวจความถูกต้องให้กับคุณได้เหมือนกัน

ถาม: ไมโครฟอร์แมตจะช่วยแก้ปัญหาเรื่องความเข้าใจทางภาษาได้ยังไง?

เราจำเป็นที่จะต้อง "บังคับ" นักพัฒนาเว็บที่ไม่ได้พูดภาษาอังกฤษเป็นพื้นฐานให้ใช้อะไรเช่น class="name" (แทนที่จะเป็น "namen" หรือ "nom") เพื่อให้เนื้อหาของเค้าสามารถถูกทำดัชนีโดย search agents ด้วยหรือ?

ตอบ: ใช่แล้ว แต่มันก็ไม่ต่างอะไรกับการใช้คำภาษาอังกฤษอย่าง "class", "span" หรือ "head" ปัญหานี้ได้มีการถกเถียงกันในกลุ่มข่าว microformats-discuss ในเรื่อง "Language Maps" แต่ก่อนหน้านี้ก็มีการถกเรื่องนี้เหมือนกัน บางคนก็ได้บอกมาว่าไมโครฟอร์แมตใช้ชื่อภาษาอังกฤษสำหรับ properties และพวกเค้าต้องการให้ใช้ชื่อเป็นภาษาอื่นๆ (ที่ไม่ใช่ภาษาอังกฤษ) ได้ด้วย และก็จะสร้าง mapping ระหว่างภาษาเหล่านั้น

เนื่องจากว่าไมโครฟอร์แมตมีพื้นฐานบนมาตรฐานที่มีอยู่แล้ว (ลองดู process และ naming-principles) นี่เลยกลายเป็นปัญหาที่อยู่นอกเหนือไมโครฟอร์แมต อย่างที่ไรอัน คิงได้ว่าไว้ ปัญหานี้เป็น "ปัญหา" ที่มีอยู่แล้วและยังไม่ได้ถูกแก้ไขจาก HTML, CSS, HTTP และมาตรฐานอื่นๆที่อิงกับภาษาอังกฤษเป็นหลัก กรุณาทำความเข้าใจว่านี่ไม่เกี่ยวกับการแปลข้อมูลให้เป็นภาษาต่างๆ - ซึ่งก็เป็นเป้าหมายที่ดีซึ่งองค์กรที่สร้างมาตรฐานต่างๆ (เช่น W3C, IETF) ต่างก็สนับสนุนเป้าหมายนี้ ปัญหานี้เป็นปัญหาที่เกี่ยวชื่อของ property และค่าที่อนุญาติสำหรับ property ในไมโครฟอร์แมต ลองดู internationalization ด้วย

ถาม: ทำไมบางครั้งไมโครฟอร์แมตที่ดูเหมือนใช้งานได้แล้วกลับยังอยู่ในสถานะเป็นเอกสารฉบับร่างอยู่?

ตอบ: คุณแทนเทคได้พูดถึงเรื่องนี้ในการอภิปรายหัวข้อThe Growth and Evolution of Microformats ที่ผ่านมาเมื่อเร็วๆนี้ในงานสัมนา SXSW โดยเขาได้อธิบายว่าก่อนที่จะเปลี่ยนสถานะของไมโครฟอร์แมตจากเอกสารฉบับร่างเป็นมาตรฐานนั้น มีความจำเป็นอย่างยิ่งที่จะต้องมีโปรแกรมที่นำฟอร์แมตนั้นไปใช้จริงๆก่อน ถึงแม้ว่าโปรแกรมนั้นจะยังเป็นตัวทดลองอยู่ก็ตาม เหตุผลก็คือมันค่อนข้างยากที่จะเห็นช่องโหว่ในไมโครฟอร์แมตจากการอ่านและตรวจด้วยตาเปล่า แต่เมื่อได้ทดลองเขียนโปรแกรมเพื่ออ่านไมโครฟอร์แมตนั้นจริงๆ จะสามารถเห็นช่องโหว่และข้อผิดพลาดของฉบับร่างได้อย่างชัดเจนยิ่งขึ้น (สืบเนื่องจากหลักการ DRY / Don't Repeat Yourself) หลังจากที่เครื่องมือสำหรับไมโครฟอร์แมตนั้นได้ถูกสร้าง (ซึ่งหมายความว่าฟอร์แมตนั้นเหมาะสมพอที่จะนำมาเขียนโปรแกรมต่างๆได้) ไมโครฟอร์แมตจึงจะเปลี่ยนสถานะจากเอกสารฉบับร่างเป็นมาตรฐาน (หรือ Specification) เพื่อนำไปสู่การเขียนโปรแกรมอื่นๆเพิ่มเติมต่อไป

การสร้างและเสนอไมโครฟอร์แมตใหม่

ถาม. ผมอยากจะสร้างไมโครฟอร์แมตใหม่สำหรับเว็บไซต์/ธุรกิจของผม จะเริ่มอย่างไรดี?

ตอบ. สิ่งแรกที่คุณต้องทำก่อนที่จะสร้างไมโครฟอร์แมตใหม่คือพยายามใช้งาน POSH และไมโครฟอร์แมตต่างๆที่มีอยู่ให้มากที่สุดเท่าที่จะทำได้ในเว็บไซต์ของคุณ เพื่อที่จะเรียนรู้ว่ายังเหลืออะไรที่จะต้องเพิ่มเติมในฟอร์แมตใหม่ของคุณ ก่อนอื่นเลยคุณจะต้อง:

  • Mark up บุคคุลหรือองค์กรด้วย hCards
  • Mark up เหตุการณ์ต่างๆและสิ่งที่อ้างอิงเรื่องวันและเวลาด้วย hCalendar
  • Mark up บทวิจารณ์ด้วย hReviews.
  • ฯลฯ

จากนั้นก็เข้าร่วมในกลุ่มสนทนาเกี่ยวกับไมโครฟอร์แมตและขอความคิดเห็นจากสมาชิกในกลุ่มว่าพวกเขาคิดอย่างไรกับการใช้งานไมโครฟอร์แมตของคุณ และจะมีวิธีพัฒนาวิธีการใช้งานของคุณหรือไม่

จากประสบการณ์นี้คุณจะสามารถพบว่ามีอะไรที่ยังขาดไปและต้องเพิ่มเข้าไปในไมโครฟอร์แมตใหม่ของคุณบ้าง ถ้าไม่ใช้วิธีนี้คุณจะพบว่ามันยากเกินไปที่จะมองเห็น "ภาพรวมของปัญหา" ทั้งหมด

หลังจากคุณได้ทำสิ่งที่กล่าวมาทั้งหมดข้างต้น ลองดูแนวทางปฏิบัติเพื่อเรียนรู้ขั้นตอนต่างๆในการสร้างไมโครฟอร์แมตใหม่ และแจงรายละเอียดปัญหาที่คุณต้องการแก้ไขให้กับกลุ่มสนทนาเกี่ยวไมโครฟอร์แมตได้รับทราบ วิธีนี้จะช่วยให้คุณหาคนที่สามารถช่วยคุณแก้ปัญหาได้อีกด้วย

ถาม ผมจะรู้ได้ยังไงว่าไอเดียสำหรับไมโครฟอร์แมตถูกเสนอมาแล้วหรือยัง?

ตอบ. ลองเช็ครายชื่อไมโครฟอร์แมตที่ถูกเสนอและตอบปฏิเสธที่

ถาม. จะทำยังไงถ้าผมหาตัวอย่างการใช้งานจริงสำหรับมาตรฐานที่ผมอยากนำเสนอไม่ได้?

ตอบ. ถ้าเราไม่สามารถหาตัวอย่างการใช้งานจริงสำหรับ ชนิดของข้อมูล ที่คุณต้องการการนำเสนอ มันคงไม่เหมาะที่จะเป็นไมโครฟอร์แมต แต่ถ้าเราแค่ไม่สามารถหาตัวอย่างการใช้งานจริงสำหรับ markup บางตัว เราอาจใช้การนำเสนอนั้นได้ โดยทั่วไปแล้วกรณีเกี่ยวกับ markup มักไม่ใช่ปัญหาจริงๆ เพราะปัญหาเหล่านี้ส่วนใหญ่เกิดจากการขาดมาตรฐานในการ markup เวลาใช้งานจริง ซึ่งหมายความว่าจะต้องมีการถามความคิดเห็นของคนส่วนใหญ่ว่าควรใช้ markup แบบไหนมากกว่า

คำถามเจาะจงเกี่ยวกับไมโครฟอร์แมต

ถ้าคุณมีคำถามเกี่ยวกับไมโครฟอร์แมตอันใดอันหนึ่ง ลองเช็คที่คำถามที่ถูกถามบ่อยๆสำหรับไมโครฟอร์แมตนั้นๆดูสิ

Class interactions

Q. Are there issues with page styling when specific class values are used?

A. There might be. However, any such issues can be easily (trivially) worked around by using contextual selectors.


Q. How does the use of class values for semantics interact with the use of class values for attaching CSS styles?

A. The class attribute takes a space separated set of class names HTML4 reference. Thus both author and microformat defined class names may be used in the same class attribute. In addition, microformat class names provide the author with a consistent set of class names to use for styling. If the author is already using using specific class names, they can continue to do so, and include microformat class names. If the author is already using a class name that happens to also be a microformat class name, then the author may want to consider using contextual CSS class selectors to make sure that avoid any unintentional styling effects.

See also:


การใช้ <div> และ <span>

ถาม. การใช้ div นั้นไม่มีความหมายเลยหรือ?

ตอบ. ใช่แล้ว ทั้ง <div> และ <span> เรียกได้ว่าแทบจะไม่มีความหมายเท่าไร <div> สามารถแทนที่ "ส่วนใดส่วนหนึ่ง" ของเนื้อหา ส่วน <span> สามารถใช้เพื่อแทนที่ "ช่วงใดช่วงหนึ่ง" ของประโยคที่มีความหมายพิเศษ แต่ไม่ได้ระบุอย่างเจาะจงว่าช่วงนั้นของประโยคหมายถึงอะไร


ถาม. การใช้ <div> และ <span> จะเพิ่มคุณค่าความหมายให้กับหน้าเว็บหรือเปล่า?

ตอบ. ตามที่ได้ระบุไว้ใน สเป็ก HTML 4 <div> และ <span> "เป็นกลไกคร่าวๆเพื่อเพิ่มโครงสร้างให้กับเนื้อหา" ความหมายเดียวของอีลีเม้นต์เหล่านี้คือเพื่อแบ่งเอกสารเป็นส่วนๆ ซึ่งหมายความได้ว่าส่วนนั้นอาจจะมีความหมายบางอย่างพิเศษ แต่ไม่สามารถบอกได้จาก markup ได้ว่าความหมายนั้นคืออะไร

ถาม. ทำไมตัวอย่างในวิกินี้ถึงใช้ <span> และ <div> เพื่อแทนความหมายเกือบจะทุกอย่างเลยล่ะ?

ตอบ. <span> และ <div> เป็นอีลีเม้นต์ที่ไม่ได้มีความหมายเฉพาะใน HTML เมื่อคุณใช้ไมโครฟอร์แมตคุณควรเลือกอีลีเม้นต์ที่ตรงกับความหมายที่สุดเท่าที่จะทำได้เป็นอันดับแรกและก็ให้ความหมายไมโครฟอร์แมตผ่าน class เช่นคุณสามารถใช้ class="vevent" กับ <tr> หรือ class="vcard" กับ <p> ก็ได้

Class semantics

ถาม. ชื่อของ class ในไมโครฟอร์แมตจะมีผลกับขนาดของหน้าเว็บยังไงบ้าง?

ตอบ. คุณจะไม่ค่อยเห็นผลกระทบกับขนาดของหน้าเว็บที่ใช้ไมโครฟอร์แมตซักเท่าไร จากประสบการณ์ของเราคนก็ใช้ชื่อ class ที่ยาวพอๆกับชื่อ class ในไมโครฟอร์แมต และ semantic class names เองก็ถือเป็น best practice ในแวดวงเว็บในตอนนี้เหมือนกัน บางเว็บไซต์ส่งหน้าเว็บที่ใช้ไมโครฟอร์แมตเป็นล้านๆหน้าแต่ก็ไม่บ่นอะไรกับเรื่องขนาดของหน้าเว็บที่เพิ่มขึ้นเลยแม้แต่น้อย เราคิดว่าคุณน่าจะประหยัดเนื้อที่ได้มากกว่าด้วยซ้ำถ้าคุณลองทำตาม หลักการของไมโครฟอร์แมต และเลิกใช้ table เพื่อจัด layout ของหน้าเว็บคุณ TODO: Consider creating a new section for web authoring tips? Or at least linking to another site that advocates good authorship.

ถาม. หนึ่ง element สามารถมีได้หลาย class หรือเปล่า

ตอบ. element สามารถมีได้หลายๆ class โดยใช้เว้นวรรคเป็นตัวคั่นแต่ละ class ใน attribute เช่น: 

  <p class="todo idea">เขียน mark-up ที่มีคุณภาพ</p>

ลองดูสเป็กของ HTML 4.01 จาก W3C ที่: 7.5.2 Element identifiers: the id and class attributes

ถาม. ชื่อของ class ใน (X)HTML มีความหมายหรือเปล่า?

ตอบ. สเป็ก HTML4 ไม่ได้ระบุค่าที่ class จะเป็นได้เอาไว้ REF และก็ไม่ได้บอกด้วยว่าค่าของ class จะต้องมีความหมายแบบใดแบบหนึ่ง REF เพียงแค่บอกว่าค่าของ class "สามารถถูกนำไปใช้เพื่อประมวลผลโดย user agent ทั่วไป" REF อย่างไรก็ตาม " เอกสารฉบับร่างชื่อ "Hypertext Links in HTML" อนุญาติให้ "profile" ระบุความหมายพิเศษสำหรับค่าของ class ได้ XMDP เป็นฟอร์แมตหนึ่งที่ระบุ profiles สำหรับ (X)HTML ซึ่งคุณสามารถนำมาใช้เพื่อให้ความหมายของชื่อ class ได้

ลองดู:

Q. I thought one of the main goals of CSS was to separate data from presentation. Isn’t this sneaking presentation back into data?

A. This is a quite commonly expressed objection to the way microformats uses class, but it's based on a misunderstanding of the way the class attribute in HTML was designed. Yes, class is very commonly,and appropriately used by web designers in conjunction with CSS to style pages, and in truth, it is often overused for that, but despite this, class, according to the HTML specification "has several roles in HTML", including "for general purpose processing by user agents".

Microformats utilize this second aspect of the class (and id) attribute, and do so legitimately. It is not an abuse of the class or id attribute to use it to add semantic context to a document. Nor is the use of class in and of itself presentational - in fact, it is an important mechanism for separating presentation from structured content.

For some more on using class semantically, here are some articles

ถาม. เราควรใส่ข้อมูลที่ต้องการให้ผู้อ่านได้อ่านไว้ในชื่อ class หรือเปล่า?

ตอบ. เราไม่ควรใส่ข้อมูลที่เขียนเพื่อให้ผู้อ่านได้อ่านไว้ใน class attribute เพราะว่าการทำแบบนั้นจะทำให้ข้อมูลไปอยู่ในจุดที่ผู้อ่านไม่สามารถเห็นได้ ดู หลักการ.

ถาม. ถามต่อ แล้วการใส่ข้อมูลไว้ในชื่อ class มันต่่างอะไรกับการใส่ไว้ใน title attribute ล่ะ?

ตอบ. title attribute นั้นถูกแสดงในทูลทิปในหลายๆเบราว์เซอร์ และก็ถือว่าเกือบๆจะมองเห็นได้โดยผู้ใช้ทั่วไป แต่ class attribute นั้นจะไม่ถูกแสดงเลย ไม่ว่าจะเป็นในทูลทิปหรือในส่วนอื่นๆของ user interface (ไม่นับรวม user interface ที่ใช้โดยนักพัฒนา เช่นตอนดูซอร์สโค้ด).

Microformats and Spam

Q. Given that Google now looks at hidden content as potential spam, will invisible microformats be considered spam?

A. It is advisable not to hide information in your site, regardless of whether it is microformatted or not. Microformats provide a mechanism for marking up visible content. Any mechanism for embedding invisible or hidden content risks being considered spam due to the fact that invisible (meta)data inevitably ends up being abused. Avoid invisible (meta)data. Publish visible data.

Design Patterns with Abbr & Title

Q. Why is ABBR being used when the title attribute is available on all HTML elements?

In the datetime design pattern the title attribute is used for the value of the property and the node value is used as the display value. <abbr title="value-here">Display-Here</abbr>.

A. The short answer is that <abbr> has the correct semantics.

The longer answer is that the value is often an abbreviated version of the formal value. Of course, if you don't want to use an <abbr>, you can use another element like this:

<abbr title="2006-12-31T12:59:59Z" class="dtstamp">New Year</abbr>

<span class="dtstamp">2006-12-31T12:59:59Z</span>

In addition, microformats encourage the content to be visible and thus prefer the text of an element rather than using the 'title' attribute or any other less visible alternative. The exception is made for datetimes and abbr due to the fact that microformats are for humans first, machines second. Thus the content of the abbr element is used to provide human visible content and the machine equivalent is placed in the less visible (but still easily verifiable) 'title' attribute.

การใช้ element ซ้อนกัน

ถาม. ดูเหมือนว่า <span class="vcard fn org" id="club">...</span> น่าจะใช้งานได้นี่นา ถูกหรือเปล่า?

ตอบ. คำตอบคือผิด ลองดู hcard-faq#nesting-properties.

See Also

Retrieved from "http://microformats.org/wiki/index.php?title=faq-th&oldid=34157"