include-pattern-brainstorming: Difference between revisions

From Microformats Wiki
Jump to navigation Jump to search
(noted request to name proposals by tech aspects rather than people (likely new guideline), removed simple contradiction to problem statement which simply wasted time/space, added longer explanation)
Line 1: Line 1:
=Include pattern Strawmen=
<h1>Include pattern Strawmen</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>):
Possible variations on the [[include-pattern|include pattern]], to resolve issues of accessibility (with empty anchors) and server load (with <code>object</code>):


== Toby Inkster's Minimally Verbose Solution ==
== Toby Inkster's Minimally Verbose Solution ==
'''Please name proposals by some technical aspect of the proposal rather than the author(s) in order to avoid overly "personalizing" an idea and having the idea be judged (positively or negatively) by the author associated with it rather than the merits of the idea, and to avoid having a specific person feel like they must defend attacks on the idea as if they were attacks on their person.'''


An alternative way of implementing the include pattern in a less verbose, and hopefully more accessible manner:
An alternative way of implementing the include pattern in a less verbose, and hopefully more accessible manner:
Line 49: Line 50:
2. inclusion of arbitrary data (#baz) in the class attribute is a [[anti-patterns#data_in_class_attributes|documented anti-pattern]].
2. inclusion of arbitrary data (#baz) in the class attribute is a [[anti-patterns#data_in_class_attributes|documented anti-pattern]].


(Unsigned comment by [[User:Tantek|Tantek]])
[[User:Tantek|Tantek]]


==Andy Mabbett==
==Andy Mabbett==
'''Please name proposals by some technical aspect of the proposal rather than the author(s) in order to avoid overly "personalizing" an idea and having the idea be judged (positively or negatively) by the author associated with it rather than the merits of the idea, and to avoid having a specific person feel like they must defend attacks on the idea as if they were attacks on their person.'''


:<code><foo id="birminghamid" class="locality">Birmingham</foo></code>
:<code><foo id="birminghamid" class="locality">Birmingham</foo></code>
Line 96: Line 98:


=== problems with arbitrary id values in class attributes ===
=== problems with arbitrary id values in class attributes ===
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 short: 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]].
*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)
 
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. "birminghamid") 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]].
 
[[User:Tantek|Tantek]]


==Martin McEvoy==
==Martin McEvoy==
'''Please name proposals by some technical aspect of the proposal rather than the author(s) in order to avoid overly "personalizing" an idea and having the idea be judged (positively or negatively) by the author associated with it rather than the merits of the idea, and to avoid having a specific person feel like they must defend attacks on the idea as if they were attacks on their person.'''


Don't <code>"include"</code> your data, you
Don't <code>"include"</code> your data, you

Revision as of 17:31, 4 February 2008

Include pattern Strawmen

Possible variations on the include pattern, to resolve issues of accessibility (with empty anchors) and server load (with object):

Toby Inkster's Minimally Verbose Solution

Please name proposals by some technical aspect of the proposal rather than the author(s) in order to avoid overly "personalizing" an idea and having the idea be judged (positively or negatively) by the author associated with it rather than the merits of the idea, and to avoid having a specific person feel like they must defend attacks on the idea as if they were attacks on their person.

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.

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

Tantek

Andy Mabbett

Please name proposals by some technical aspect of the proposal rather than the author(s) in order to avoid overly "personalizing" an idea and having the idea be judged (positively or negatively) by the author associated with it rather than the merits of the idea, and to avoid having a specific person feel like they must defend attacks on the idea as if they were attacks on their person.

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

then:

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

Some other possible variants are:

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

or

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

or

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

or

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

or

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

or

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

or

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

Note: "birminghamid" used for clarity; "birmingham" would be the semantically correct value.

(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, inclusion of arbitrary data (birminghamid) 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. "birminghamid") in a class attribute is an instance of including arbitrary data in the class attribute, which is a documented anti-pattern.

Tantek

Martin McEvoy

Please name proposals by some technical aspect of the proposal rather than the author(s) in order to avoid overly "personalizing" an idea and having the idea be judged (positively or negatively) by the author associated with it rather than the merits of the idea, and to avoid having a specific person feel like they must defend attacks on the idea as if they were attacks on their person.

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

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

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

Cons:

Related Pages