issues: Difference between revisions

From Microformats Wiki
Jump to navigation Jump to search
(text moved from main page)
m (cleaned up big time, got rid of false/theoretical/straw-man issues that are not even worth responding to, documented better issue requirements)
Line 1: Line 1:
Issues which apply to more than one microforamt.
<h1> Microformat Issues </h1>


This should be a brainstorming session trying to tackle such general problems as microformats implementation, microformats efficiency and other advanced concepts.
These are externally raised issues about microformats in general (these issues MUST apply to more than one microformat, which MUST be explicitly listed, otherwise the issue should be raised on the format specific issues page) with broadly varying degrees of merit.  Thus some issues are REJECTED for a number of obvious reasons (but still documented here in case they are re-raised), and others contain longer discussions. Some issues may be ACCEPTED and perhaps cause changes or improved explanations in the spec. Submitted issues may (and probably will) be edited and rewritten for better terseness, clarity, calmness, rationality, and as neutral a point of view as possible. Write your issues well. — [http://tantek.com/log/ Tantek]


==Bloated Format==
As this is a general microformats issues page, please only note ''concrete'' real world issues.  Theoretical issues will be deleted, as will any issues raised that do not contain documentation of specific real-world examples that use real-world microformats (not just brainstorms).


=== The Problem ===
__TOC__
Unfortunately, current microformats implementation consume a vast amount of space. The complexity will increase even more, when wanting to ''solve/add'' more complex issues. A direct consequence of this is a '''bloated format''':
* some of the markup is really bloated
** instead of a number, we end sometimes with a whole '''new paragraph''' of markup
** however, in order to be complete, the markup might need to be so
** nevertheless, having a page with 1000 data points will be a horror scenario


Therefore, I proposed to open this new brainstorming session/page on how to efficiently implement the microformats in web pages.
== Issues ==


=== Ideas/ Solutions ===
* ...


If we think a little bit back about '''css''', one of the main reasons of its development was:
== Template ==
* to separate content from style
** page code becomes more easy to '''understand'''
** and to '''maintain'''
** and often the '''size''' shrinks significantly


We must learn this lesson when dealing with microformats. Specifically, the following issues are important:
Please use this format (copy and paste this to the end of the list to add your issues):
* extensive microformat markup inside the page code will significantly reduce the readability of the code
* {{OpenIssue}} YYYY-MM-DD raised by [http://yourhomepage.example.com YOURNAME].
* repeating the markup will increase page size
*# ''Issue 1: Here is the first issue I have.''
* it will become more difficult to maintain/change the page
*# ''Issue 2: Here is the second issue I have.''
 
'''Solution'''
* '''define microformat classes'''
** e.g. in the page header, or
** in a separate file (see later)
* define '''abbreviations''' to those classes
** use actually only the abbrevioations inside the web page, instead of the '''whole paragraph''' of markup
 
* define the microformat classes inside a '''separate file''' (similarly to the css)
** this file needs NOT to be downloaded automatically
*** you do NOT need it for displaying the data
*** it is only needed when wanting to import the data somewhere
*** most viewers, however, only view the data
** let the browser automatically download this file, only IF:
*** there is enough bandwidth
*** the user wants to copy that data
*** the user wants to explicitly save the whole page
** when the user wants to copy an item
*** the web browser should acces that ''microformats'' additional page and
*** download only the relevant class (NO need to actually download the whole page)
*** '''EXTEND html protocol to be able to download ''web-file/class-defined-inside-file'' '''without beeing necessary to download the whole file
 
=== Requirements ===
 
New Tags:
* '''<struct> ... </struct>''': like the C/C++ struct, will define the microformats structure
* '''<v> ... </v>''': this will define the variable inside the ''struct'' that should be replaced
* '''<v ... />''': similarly to above, but this will NOT be displayed by the browser
** '''<v>''' is a shorthand for '''var''', to further reduce file size
 
=== Examples ===
 
Lets take this code:
<pre><nowiki>
<div class="hcite">
  <div class="book">
  <span class="fn">Book Title</span>
  <div class="chapter">
      <span class="fn">Chapter Title</span>
  </div>
  </div>
</div>
</nowiki></pre>
 
We would define this in the header like this:
<pre><nowiki>
<struct>
MyName{
  <div class="hcite">
  <div class="book">
    <span class="fn"><v /></span>
    <div class="chapter">
      <span class="fn"><v /></span>
    </div>
  </div>
  </div>
}
</struct>
</nowiki></pre>
 
or in a separate microformats file (NO struct needed):
<pre><nowiki>
MyName{
  <div class="hcite">
  <div class="book">
    <span class="fn"><v /></span>
    <div class="chapter">
      <span class="fn"><v /></span>
    </div>
  </div>
  </div>
}
</nowiki></pre>
 
Inside the web page we use:
<pre><nowiki>
<struct class="MyName">
  <v>1st variable</v>
  <v>2nd variable</v>
</struct>
</nowiki></pre>
 
 
IF, one variable should NOT be displayed by the browser, we would use <v val="..." /> instead (the ''val='' could be omitted), e.g.:
<pre><nowiki>
<div class="geo">
  <abbr class="latitude" title="37.408183">N 37° 24.491</abbr>
  <abbr class="longitude" title="-122.13855">W 122° 08.313</abbr>
</div>
</nowiki></pre>
 
Would become:
* inside the microformats definition page write:
<pre><nowiki>
MyGeoStructure{
  <div class="geo">
  <abbr class="latitude" title=v><v /></abbr>
  <abbr class="longitude" title=v><v /></abbr>
  </div>
}
</nowiki></pre>
 
* the code inside the web page:
<pre><nowiki>
<struct class="MyGeoStructure">
  <v "37.408183" /><v>N 37° 24.491</v>
  <v "-122.13855" /><v>W 122° 08.313</v>
</struct>
</nowiki></pre>
 
 
- discussion opened by [[discoleo|Leonard Mada]]

Revision as of 02:45, 4 December 2006

Microformat Issues

These are externally raised issues about microformats in general (these issues MUST apply to more than one microformat, which MUST be explicitly listed, otherwise the issue should be raised on the format specific issues page) with broadly varying degrees of merit. Thus some issues are REJECTED for a number of obvious reasons (but still documented here in case they are re-raised), and others contain longer discussions. Some issues may be ACCEPTED and perhaps cause changes or improved explanations in the spec. Submitted issues may (and probably will) be edited and rewritten for better terseness, clarity, calmness, rationality, and as neutral a point of view as possible. Write your issues well. — Tantek

As this is a general microformats issues page, please only note concrete real world issues. Theoretical issues will be deleted, as will any issues raised that do not contain documentation of specific real-world examples that use real-world microformats (not just brainstorms).

Issues

  • ...

Template

Please use this format (copy and paste this to the end of the list to add your issues):

  • open issue! YYYY-MM-DD raised by YOURNAME.
    1. Issue 1: Here is the first issue I have.
    2. Issue 2: Here is the second issue I have.
Retrieved from "http://microformats.org/wiki/index.php?title=issues&oldid=10936"