include-pattern-strawman

(Difference between revisions)

Jump to: navigation, search
(Cons:)
Current revision (00:30, 12 February 2008) (view source)
(contributors)
 
(19 intermediate revisions not shown.)
Line 1: Line 1:
-
=Include pattern Strawmen=
+
<h1>include pattern brainstorming</h1>
 +
{{TOC-right}}
-
Possible variations on the [[include-pattern|include pattern]], to resolve issues of accessibility (with empty anchors) and server load (with <code>object</code>):
+
brainstorming to improve or extend the [[include-pattern]].
-
== Toby Inkster's Minimally Verbose Solution ==
+
== alternatives to using a or object ==
 +
Here are possible variations on the [[include-pattern|include pattern]], attempting to resolve issues of accessibility (with empty anchors) and server load (with <code>object</code>).
-
An alternative way of implementing the include pattern in a less verbose, and hopefully more accessible manner:
+
=== Non-Verbose Class-Based Solution ===
 +
(Originally suggested by Toby Inkster, based on an earlier proposal by Andy Mabbett)
 +
 
 +
An alternative way of implementing the include pattern in a less verbose, and hopefully more accessible manner.
<pre>
<pre>
Line 29: Line 34:
If people can find real-life uses of the hash character in existing sites that would conflict with this proposed usage pattern, then perhaps another character could be used. I rather like '@foo', or maybe even a combination such as '@#foo'.
If people can find real-life uses of the hash character in existing sites that would conflict with this proposed usage pattern, then perhaps another character could be used. I rather like '@foo', or maybe even a combination such as '@#foo'.
-
=== Including data in the middle of an element ===
+
==== Including data in the middle of an element ====
Above, the examples show how an element can be logically included as the first or last child of another element. For including data into the middle of an element, we need to be a tiny bit more verbose and insert a dummy element (in this case a &lt;span> element) where the included content should go:
Above, the examples show how an element can be logically included as the first or last child of another element. For including data into the middle of an element, we need to be a tiny bit more verbose and insert a dummy element (in this case a &lt;span> element) where the included content should go:
Line 42: Line 47:
</pre>
</pre>
-
=== problems with ordered ids in class ===
+
==== problems with ordered ids in class ====
Two problems:
Two problems:
1. class is an unordered set of values per HTML4.  introducing ordering is a non-starter both from a violation of HTML4 spec perspective and likely requiring of rewriting HTML4 parsers to maintain an ordering where they currently don't.
1. class is an unordered set of values per HTML4.  introducing ordering is a non-starter both from a violation of HTML4 spec perspective and likely requiring of rewriting HTML4 parsers to maintain an ordering where they currently don't.
-
2. inclusion of arbitrary data (#baz) in the class attribute is a [[anti-patterns#data_in_class_attributes|documented anti-pattern]].
+
<div style="margin-left:2em;border-left:thick solid #ccc;padding-left:1em;">
 +
A reading of HTML 4.01, section 7.5.2 doesn't seem to claim that the class list is unordered.  
-
(Unsigned comment by [[User:Tantek|Tantek]])
+
It does claim that it's a "set" of class names, and in mathematical parlance sets are unordered by definition, and must not contain duplicates, but it's unlikely that the framers of the HTML 4.01 spec intended the world "set" to be interpreted in that way -- far more likely they were referring to the layman's definition of the word.
-
==Andy Mabbett==
+
As far as parsers are concerned, DOM Level 2 HTML provides as "className" property as part of the HTMLElement interface, which is either directly used or is inherited by all DOM element nodes. The className is a string exactly reflecting the contents of the HTML class attribute, so should reflect their original order.
-
:<code><foo id="birminghamid" class="locality">Birmingham</foo></code>
+
And any non-DOM, naive SGML or XML parser that encounters a class attribute will just parse it as a plain old string anyway, so the order should be retained.
 +
 
 +
[[User:TobyInk|TobyInk]] 08:34, 5 Feb 2008 (PST)
 +
</div>
 +
 
 +
2. inclusion of arbitrary data (#baz) in the class attribute is a [[anti-patterns#data_in_class_attributes|documented anti-pattern]]. [[User:Tantek|Tantek]]
 +
 
 +
<div style="margin-left:2em;border-left:thick solid #ccc;padding-left:1em;">
 +
This anti-pattern is only mentioned as a subheading to the more general anti-pattern of invisble metadata. My suggested pattern for inclusions does not hide metadata -- it merely references metadata elsewhere on the page. It is no more guilty of hiding metadata than any other suggested include pattern, so I fail to see how this is relevant.
 +
 
 +
[[User:TobyInk|TobyInk]] 08:36, 5 Feb 2008 (PST)
 +
</div>
 +
 
 +
===Simple class name===
 +
 
 +
:<code><foo id="birmingham" class="locality">Birmingham</foo></code>
then:
then:
-
:<code><foo class="adr includes-birminghamid">[...]</foo></code>
+
:<code><foo class="adr includes-birmingham">[...]</foo></code>
Some other possible variants are:
Some other possible variants are:
-
:<code><foo class="adr birminghamid">[...]</foo></code>
+
:<code><foo class="adr birmingham">[...]</foo></code>
or
or
-
:<code><foo class="adr part-microformat birminghamid">[...]</foo></code>
+
:<code><foo class="adr part-microformat birmingham">[...]</foo></code>
or
or
-
:<code><foo class="adr use-birminghamid">[...]</foo></code>
+
:<code><foo class="adr use-birmingham">[...]</foo></code>
or
or
-
:<code><foo class="adr uses-birminghamid">[...]</foo></code>
+
:<code><foo class="adr uses-birmingham">[...]</foo></code>
or
or
-
:<code><foo class="adr include-birminghamid">[...]</foo></code>
+
:<code><foo class="adr include-birmingham">[...]</foo></code>
or
or
-
:<code><foo class="adr locality-birminghamid">[...]</foo></code>
+
:<code><foo class="adr locality-birmingham">[...]</foo></code>
or
or
-
:<code><foo id="birminghamid">Birmingham</foo></code>
+
:<code><foo id="birmingham">Birmingham</foo></code>
:[...]
:[...]
-
:<code><foo class="adr locality-birminghamid">[...]</foo></code>
+
:<code><foo class="adr locality-birmingham">[...]</foo></code>
-
Note: "birminghamid" used for clarity; "birmingham" would be the semantically correct value.  
+
(originally suggested by [[User:AndyMabbett|Andy Mabbett]] in <http://microformats.org/discuss/mail/microformats-discuss/2008-January/011422.html et seq.)
-
(originally suggested in <http://microformats.org/discuss/mail/microformats-discuss/2008-January/011422.html et seq.)
+
==== problems with arbitrary id values in class attributes ====
 +
In short: similar to [[#problems_with_ordered_ids_in_class|problems with ordered ids in class]], inclusion of arbitrary data (birmingham) in the class attribute is a [[anti-patterns#data_in_class_attributes|documented anti-pattern]].
-
=== problems with arbitrary id values in class attributes ===
+
Longer: The value of an <code>id</code> attribute on an element is essentially an arbitrary string used to uniquely identify that element in the context of the document. Thus the re-use of such an arbitrary string (e.g. "birmingham") in a class attribute is an instance of including arbitrary data in the class attribute, which is a [[anti-patterns#data_in_class_attributes|documented anti-pattern]].
-
Similar to [[#problems_with_ordered_ids_in_class|problems with ordered ids in class]], inclusion of arbitrary data (birminghamid) in the class attribute is a [[anti-patterns#data_in_class_attributes|documented anti-pattern]]. (Unsigned comment by [[User:Tantek|Tantek]])
+
-
*In this proposal, the class name is not "arbitrary data". In the cited page the use of data in class names is deprecated as "another form of invisible metadata". This proposal involves no more "invisible metadata" than do the existing include patterns; and is semantically logical.  [[User:AndyMabbett|Andy Mabbett]] 00:52, 4 Feb 2008 (PST)
+
-
==Martin McEvoy==
+
[[User:Tantek|Tantek]]
-
Don't <code>"include"</code> your data, you
+
* In this proposal, the class name is not "arbitrary data", since it uses a semantically valid IDs; and is semantically logical. In the cited page the use of data in class names is deprecated as "another form of invisible metadata". This proposal involves no more "invisible metadata" than do the existing include patterns. [[User:AndyMabbett|Andy Mabbett]] 00:52, 4 Feb 2008 (PST)
-
could perhaps just reference them eg:
+
** existing include patterns use <code>href</code> and <code>data</code> (not <code>class</code>) attributes which are both of type URI to point to a fragment identifier.  arbitrary links are proper semantic use of URI attributes per HTML4. however in a class attribute, arbitrary links are no more than arbitrary data, and are thus an example of [[anti-patterns#data_in_class_attributes|the documented anti-pattern]]. (Unsigned comment by [[User:Tantek|Tantek]])
 +
*** The fragment identifier is not data. Well, OK, it is data in the sense that virtually everything is data, but, in the example above, the link itself is not address data -- it's a pointer to data... information about where the real data might be found... it's ''metadata''. [[User:TobyInk|TobyInk]] 07:42, 6 Feb 2008 (PST)
-
<pre><foo id="me" class="fn">Martin McEvoy</foo></pre>
+
===Use <code>@</code> to Reference IDs===
 +
 
 +
Don't <code>"include"</code> your data, you could perhaps just reference them.
 +
 
 +
<pre><foo id="me" class="fn">Fred</foo></pre>
<pre><bar class="me@url">http://wherever.com/</bar></pre>
<pre><bar class="me@url">http://wherever.com/</bar></pre>
Line 110: Line 135:
parsers instead of replacing data can then just append their data?
parsers instead of replacing data can then just append their data?
-
Suggested on Microformats Discuss: http://microformats.org/discuss/mail/microformats-discuss/2008-February/011470.html
+
Suggested in: [http://microformats.org/discuss/mail/microformats-discuss/2008-February/011470.html microformats-discuss/2008-February/011470.html]
-
===Cons:===
+
==== problems with using at ref to id ====
* Too verbose http://microformats.org/discuss/mail/microformats-discuss/2008-February/011473.html
* Too verbose http://microformats.org/discuss/mail/microformats-discuss/2008-February/011473.html
-
* Inclusion of arbitrary data <code>@</code>, "anti-pattern" as pointed out on microformats discuss http://microformats.org/discuss/mail/microformats-discuss/2008-February/011479.html
+
* Inclusion of arbitrary data <code>@</code>, "[[anti-patterns#data_in_class_attributes|documented anti-pattern]]" as pointed out on microformats discuss http://microformats.org/discuss/mail/microformats-discuss/2008-February/011479.html
-
== Related Pages ==
+
===Use a Class Create method===
-
{{include-pattern-related-pages}}
+
 
 +
Create a class such as <code>"data"</code> in the following example, or any unique class name much the same as we do already with <code>id=""</code>.
 +
 
 +
Examples could be <code>"reviewer"</code> or <code>"me"</code>.
 +
 
 +
example,
 +
<pre><span class="vcard">   
 +
        <span class="data">
 +
                <span class="fn">Foo</span>
 +
        </span>
 +
        <a class="email" href="mailto:foo@bar.com">email foo@bar.com</a>
 +
</span></pre>
 +
 
 +
Use an empty span to reference your unique class name with class <code>"include *"</code> anywhere you would
 +
like the created class to be included.
 +
 
 +
example,
 +
<pre><span class="vcard">
 +
        <span class="include data"></span>
 +
        <a class="email" href="mailto:foo@baz.com">email foo@baz.com</a>
 +
</span></pre>
 +
 
 +
The result "could" turn out much like this:
 +
 
 +
example,
 +
<pre><span class="vcard">
 +
        <span class="fn">Foo</span>
 +
        <a class="email" href="mailto:foo@baz.com">email foo@baz.com</a>
 +
</span></pre>
 +
 
 +
====Problems====
 +
 
 +
* If class="include data" is taken to mean "include all elements with a class name of 'data'", then the element will include itself and potentially introduce problems with recursion. [[User:TobyInk|TobyInk]] 02:23, 11 Feb 2008 (PST)
 +
** Not Necessarily so, It would depend on Parsing rules. [[User:WebOrganics|Martin McEvoy]] 17:19, 11 Feb 2008 (GMT)
 +
 
 +
=== Use property inheritance from groups, implicit member/group relations (by containment) and explicit property/object relations (by reference) ===
 +
 
 +
This proposal is only presented for the record. The main reason it has been discarded is because "the use of [[rev]], and any new microformats values for rev, has been deprecated for several reasons.  See [[rev#Should_rev_even_be_used|Should rev even be used]].".
 +
 
 +
It is really two proposals in one:
 +
* property inheritance from group elements: if an object is part of a group, it inherits the properties associated with this group.
 +
* explicit property referencing. This technique provides an alternative to the current technique of associating by containment a property with an object, or sub-property with parent property. With the suggested new technique, the property or sub-property does not have to be contained (resp.) by the object or parent property: the association is made explicitly via a rev link.
 +
 
 +
Example:
 +
 
 +
<pre>
 +
Our company has office locations in <a href="#adrlist1" rev="locality">San Francisco</a>:
 +
<ul id="adrlist1">
 +
<li id="adr1" class="adr"><span class="street-address">665 3rd Street</span>, and</li>
 +
<li id="adr2" class="adr"><span class="street-address">123 Folsom</span></li>
 +
</ul>
 +
</pre>
 +
 
 +
This example would be interpreted as:
 +
* adr1 and adr2 belong to the group adrlist1 by containment.
 +
* "San Francisco" is the locality property of the adrlist1 group.
 +
* hence, adr1 and adr2 inherit the locality property from adrlist1 since they are not overriding it.
 +
 
 +
=== Use property inheritance from groups, explicit group/member referencing and implicit property relations (by containment) ===
 +
 
 +
<pre>
 +
Our company has <span id="#adrlist1>office locations in <span class="locality">San Francisco</span></span>:
 +
<a id="adr1" href="#adrlist1" rel="group" class="adr"><span class="street-address">665 3rd Street</span><span>,
 +
and <a id="adr2" href="#adrlist1" rel="group" class="adr"><span class="street-address">123 Folsom</span></span>
 +
</pre>
 +
 
 +
This technique use: property inheritance from group and explicit relationships between groups and members. The HTML code actual reflects the meaning of the sentence: the items following the columns belong to a group from which they inherit a property (locality).
 +
 
 +
This example would be interpreted as:
 +
* adr1 and adr2 belong to the #adrlist1 group (by reference).
 +
* locality is associated with #adrlist1 by containment
 +
* adr1 and adr2 inherit the locality property "San Francisco" from the group they belong to, since they are not overriding it.
 +
 
 +
== contributors ==
* [[User:TobyInk|Toby Inkster]]
* [[User:TobyInk|Toby Inkster]]
 +
* [[User:AndyMabbett|Andy Mabbett]]
* [[User:WebOrganics|Martin McEvoy]]
* [[User:WebOrganics|Martin McEvoy]]
 +
* [[User:Guillaume Lebleu|Guillaume Lebleu]]
 +
 +
== Related Pages ==
 +
{{include-pattern-related-pages}}

Current revision

include pattern brainstorming

Contents


brainstorming to improve or extend the include-pattern.

alternatives to using a or object

Here are possible variations on the include pattern, attempting to resolve issues of accessibility (with empty anchors) and server load (with object).

Non-Verbose Class-Based Solution

(Originally suggested by Toby Inkster, based on an earlier proposal by Andy Mabbett)

An alternative way of implementing the include pattern in a less verbose, and hopefully more accessible manner.

 <p>We have three branches in <span class="locality" id="ldn">London</span>,
 including our head office in <span class="locality" id="ken">Kensington</span>:</p>
 <ul>
   <li class="adr #ldn">
     <span class="street-address">123 Oxford Street</span>
   </li>
   <li class="adr #ken #ldn">
     <span class="street-address">5 Kensington High Street</span>
   </li>
   <li class="adr #ldn">
     <span class="street-address">1 Pall Mall</span>
   </li>
 </ul>

The order of the space-delimited class attributes should be considered significant -- that is, in <foo class="bar #baz"> the content referred to by #baz is logically included as the last child of the <foo> element, but in <foo class="#baz bar">, it is logically included as the first child. (See below for an example where the included element should occur in the middle of the element content.)

Yes, the hash mark is valid in the class attribute, though rarely used because it won't work with CSS 1 selectors.

If people can find real-life uses of the hash character in existing sites that would conflict with this proposed usage pattern, then perhaps another character could be used. I rather like '@foo', or maybe even a combination such as '@#foo'.

Including data in the middle of an element

Above, the examples show how an element can be logically included as the first or last child of another element. For including data into the middle of an element, we need to be a tiny bit more verbose and insert a dummy element (in this case a <span> element) where the included content should go:

 <p>Our head office is in <span id="ldn" class="locality">London</span> at:
 <p class="adr">
   <span class="street-address">5 Kensington High Street</span><br>
   <span class="#ldn"></span>
   <span class="postal-code">SW7 1AA</span>
 </p>

problems with ordered ids in class

Two problems:

1. class is an unordered set of values per HTML4. introducing ordering is a non-starter both from a violation of HTML4 spec perspective and likely requiring of rewriting HTML4 parsers to maintain an ordering where they currently don't.

A reading of HTML 4.01, section 7.5.2 doesn't seem to claim that the class list is unordered.

It does claim that it's a "set" of class names, and in mathematical parlance sets are unordered by definition, and must not contain duplicates, but it's unlikely that the framers of the HTML 4.01 spec intended the world "set" to be interpreted in that way -- far more likely they were referring to the layman's definition of the word.

As far as parsers are concerned, DOM Level 2 HTML provides as "className" property as part of the HTMLElement interface, which is either directly used or is inherited by all DOM element nodes. The className is a string exactly reflecting the contents of the HTML class attribute, so should reflect their original order.

And any non-DOM, naive SGML or XML parser that encounters a class attribute will just parse it as a plain old string anyway, so the order should be retained.

TobyInk 08:34, 5 Feb 2008 (PST)

2. inclusion of arbitrary data (#baz) in the class attribute is a documented anti-pattern. Tantek

This anti-pattern is only mentioned as a subheading to the more general anti-pattern of invisble metadata. My suggested pattern for inclusions does not hide metadata -- it merely references metadata elsewhere on the page. It is no more guilty of hiding metadata than any other suggested include pattern, so I fail to see how this is relevant.

TobyInk 08:36, 5 Feb 2008 (PST)

Simple class name

<foo id="birmingham" class="locality">Birmingham</foo>

then:

<foo class="adr includes-birmingham">[...]</foo>

Some other possible variants are:

<foo class="adr birmingham">[...]</foo>

or

<foo class="adr part-microformat birmingham">[...]</foo>

or

<foo class="adr use-birmingham">[...]</foo>

or

<foo class="adr uses-birmingham">[...]</foo>

or

<foo class="adr include-birmingham">[...]</foo>

or

<foo class="adr locality-birmingham">[...]</foo>

or

<foo id="birmingham">Birmingham</foo>
[...]
<foo class="adr locality-birmingham">[...]</foo>

(originally suggested by Andy Mabbett in <http://microformats.org/discuss/mail/microformats-discuss/2008-January/011422.html et seq.)

problems with arbitrary id values in class attributes

In short: similar to problems with ordered ids in class, inclusion of arbitrary data (birmingham) in the class attribute is a documented anti-pattern.

Longer: The value of an id attribute on an element is essentially an arbitrary string used to uniquely identify that element in the context of the document. Thus the re-use of such an arbitrary string (e.g. "birmingham") in a class attribute is an instance of including arbitrary data in the class attribute, which is a documented anti-pattern.

Tantek

Use @ to Reference IDs

Don't "include" your data, you could perhaps just reference them.

<foo id="me" class="fn">Fred</foo>
<bar class="me@url">http://wherever.com/</bar>

parsers instead of replacing data can then just append their data?

Suggested in: microformats-discuss/2008-February/011470.html

problems with using at ref to id

Use a Class Create method

Create a class such as "data" in the following example, or any unique class name much the same as we do already with id="".

Examples could be "reviewer" or "me".

example,

<span class="vcard">    
        <span class="data">
                <span class="fn">Foo</span>
        </span>
        <a class="email" href="mailto:foo@bar.com">email foo@bar.com</a>
</span>

Use an empty span to reference your unique class name with class "include *" anywhere you would like the created class to be included.

example,

<span class="vcard">
        <span class="include data"></span>
        <a class="email" href="mailto:foo@baz.com">email foo@baz.com</a>
</span>

The result "could" turn out much like this:

example,

<span class="vcard">
        <span class="fn">Foo</span>
        <a class="email" href="mailto:foo@baz.com">email foo@baz.com</a>
</span>

Problems

Use property inheritance from groups, implicit member/group relations (by containment) and explicit property/object relations (by reference)

This proposal is only presented for the record. The main reason it has been discarded is because "the use of rev, and any new microformats values for rev, has been deprecated for several reasons. See Should rev even be used.".

It is really two proposals in one:

Example:

Our company has office locations in <a href="#adrlist1" rev="locality">San Francisco</a>: 
<ul id="adrlist1">
<li id="adr1" class="adr"><span class="street-address">665 3rd Street</span>, and</li>
<li id="adr2" class="adr"><span class="street-address">123 Folsom</span></li>
</ul>

This example would be interpreted as:

Use property inheritance from groups, explicit group/member referencing and implicit property relations (by containment)

Our company has <span id="#adrlist1>office locations in <span class="locality">San Francisco</span></span>: 
<a id="adr1" href="#adrlist1" rel="group" class="adr"><span class="street-address">665 3rd Street</span><span>,
 and <a id="adr2" href="#adrlist1" rel="group" class="adr"><span class="street-address">123 Folsom</span></span>

This technique use: property inheritance from group and explicit relationships between groups and members. The HTML code actual reflects the meaning of the sentence: the items following the columns belong to a group from which they inherit a property (locality).

This example would be interpreted as:

contributors

Related Pages

include-pattern-strawman was last modified: Tuesday, February 12th, 2008

Views