|
|
| Line 1: |
Line 1: |
| == Why Microformat support shouldn't become a core firefox feature ==
| | Moved to main page |
| | |
| The idea of Microformats(henceforth: MF) is great, but the implementation is awful. Awful in as much as the implementations tend to ignore the current struggle in the industry to push for correct usage of tags as having well-defined meanings. After years of 'Browser anarchy' and endless ignorance of standards, we are approaching a stage, with XHTML where everyone is playing ball.
| |
| | |
| MFs are supposed to be XHTML based formats, the X here stands for eXtensible (i.e. able to be expanded) yet the formats simply take existing HTML tags and attributes meant for other purposes and re-define them.
| |
| | |
| The correct implementation for XHTML compatible formats of this nature (i.e. like hCard or XOXO) would be as an XML namespace that can be loaded into an XHTML document (in the same way that MathML or SVG is) and styled by any proper XHTML browser*. Instead, these formats (ab)use current tags either, in the case of hCard, and hCalendar, by promoting the creation of SPAN soup, or, as with VoteLinks and XFN, by redefining existing attributes (such as rel and rev) which then can precipitate the changing of a tags behaviour from standard. Technically, the use of the 'class' attribute in many of the formats is not a violation of the standard. But by defining special behaviours/presentations to be attached to certain element classes that might have been defined for some other purpose, the potential for confusion amongst users and erronious behaviours/presentation of incidental data is much greater.
| |
| | |
| (*) Few current browsers are truly XHTML compatible, and therefore having a proper, well-defined XML namespace solution is not a currently viable option. Hence why these hack-like soultions have been formulated. As interim solutions, they are not all bad. They fulfill a need in the short term. However if these 'hacks' are accepted as qualified standards, there will be an inertial barrier to adoption of newer, better standards as new technologies (such as proper XHTML support) become mainstream. Web-designers and content producers will be slow in adopting more proper solutions, and the drive for adoption of XHTML in general will be reduced.
| |
| | |
| By keeping MF support as a plugin (or plugins), everyone will stay firmly aware that these formats are only a temporary work-around and that HTML4 dependance is something that should be avoided, not kept on purely for familiarity reasons. By keeping MF support out of the Firefox/Mozilla core, this will reduce the need for core developers to spend time on a feature that should be gotten rid of at the first technological opportunity, thus freeing them to spend more time on other areas of the Application.
| |