issues: Difference between revisions
AndyMabbett (talk | contribs) (moved from main page) |
(→Bloated Format: Examples added) |
||
Line 3: | Line 3: | ||
==Bloated Format== | ==Bloated Format== | ||
=== The Problem === | |||
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 | ** 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 | ** 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 | ** nevertheless, having a page with 1000 data points will be a horror scenario | ||
*** define | |||
*** define '''abbreviations''' to those classes | Therefore, I proposed to open this new brainstorming session/page on how to efficiently implement the microformats in web pages. | ||
=== Ideas/ Solutions === | |||
If we think a little bit back about '''css''', one of the main reasons of its development was: | |||
* 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: | |||
* extensive microformat markup inside the page code will significantly reduce the readability of the code | |||
* repeating the markup will increase page size | |||
* it will become more difficult to maintain/change the page | |||
'''Solution''' | |||
** discussion opened by [[discoleo|Leonard Mada]] | * '''define microformat classes''' | ||
** e.g. in the page header, or | |||
** in a separate file (see later) | |||
* define '''abbreviations (qasi tags)''' 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 | |||
* '''<var> ... </var>''': will define the part inside ''struct'' that should be replaced | |||
* '''<var ... />''': similarly to point above, but NOT displayed by browser | |||
** '''<var>''' could be shortend to '''<v>''', to further reduce file size | |||
=== Examples === | |||
Lets take this code: | |||
<div class="hcite"> | |||
<div class="book"> | |||
<span class="fn">Book Title</span> | |||
<div class="chapter"> | |||
<span class="fn">Chapter Title</span> | |||
</div> | |||
</div> | |||
</div> | |||
We would define this in the header like this: | |||
<struct> | |||
MyName{ | |||
<div class="hcite"> | |||
<div class="book"> | |||
<span class="fn"><var /></span> | |||
<div class="chapter"> | |||
<span class="fn"><var /></span> | |||
</div> | |||
</div> | |||
</div> | |||
} | |||
</struct> | |||
or in a separate microformats file (NO struct needed): | |||
MyName{ | |||
<div class="hcite"> | |||
<div class="book"> | |||
<span class="fn"><var /></span> | |||
<div class="chapter"> | |||
<span class="fn"><var /></span> | |||
</div> | |||
</div> | |||
</div> | |||
} | |||
Inside the web page we use: | |||
<struct class="MyName"> | |||
<var>This is the first variable</var> | |||
<var>This text is put in the 2nd variable</var> | |||
</struct> | |||
IF, one variable should NOT be displayed by the browser, we would use <var val="..." /> instead, e.g.: | |||
<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> | |||
Would become: | |||
* the microformats definition page | |||
MyGeoStructure{ | |||
<div class="geo"> | |||
<abbr class="latitude" title=var><var /></abbr> | |||
<abbr class="longitude" title=var><var /></abbr> | |||
</div> | |||
} | |||
* the web page | |||
<struct class="MyGeoStructure"> | |||
<var "37.408183" /><var>N 37° 24.491</var> | |||
<var "-122.13855" /><var>W 122° 08.313</var> | |||
</struct> | |||
- discussion opened by [[discoleo|Leonard Mada]] |
Revision as of 11:37, 23 November 2006
Issues which apply to more than one microforamt.
Bloated Format
The Problem
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.
Ideas/ Solutions
If we think a little bit back about css, one of the main reasons of its development was:
* 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:
- extensive microformat markup inside the page code will significantly reduce the readability of the code
- repeating the markup will increase page size
- it will become more difficult to maintain/change the page
Solution
- define microformat classes
- e.g. in the page header, or
- in a separate file (see later)
- define abbreviations (qasi tags) 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
- this file needs NOT to be downloaded automatically
Requirements
New Tags:
- <struct> ... </struct>: like the C/C++ struct, will define the microformats structure
- ... : will define the part inside struct that should be replaced
- : similarly to point above, but NOT displayed by browser
- could be shortend to <v>, to further reduce file size
Examples
Lets take this code:
Book Title
Chapter Title
We would define this in the header like this:
<struct> MyName{
} </struct>
or in a separate microformats file (NO struct needed):
MyName{
}
Inside the web page we use:
<struct class="MyName"> This is the first variable This text is put in the 2nd variable </struct>
IF, one variable should NOT be displayed by the browser, we would use instead, e.g.:
N 37° 24.491 W 122° 08.313
Would become:
- the microformats definition page
MyGeoStructure{
}
- the web page
<struct class="MyGeoStructure"> N 37° 24.491 W 122° 08.313 </struct>
- discussion opened by Leonard Mada