value-class-pattern-brainstorming: Difference between revisions
(→to do: Added browser testing results.) |
(→disadvantages: verbosity) |
||
Line 46: | Line 46: | ||
*# require "value" attribute be the last attribute specified on the param element | *# require "value" attribute be the last attribute specified on the param element | ||
*# require equivalent human visible text be placed immediately (allowing for whitespace) following the param | *# require equivalent human visible text be placed immediately (allowing for whitespace) following the param | ||
* '''Verbose:''' not very hand-authoring friendly, compared to other suggestions such as: | |||
** [[datetime-design-pattern#Machine-data_in_class|Machine data in class]]: <code><span class="type data-cell">Mobile:</span></code> | |||
** [http://microformats.org/discuss/mail/microformats-discuss/2008-February/011583.html data prefix in titles]: <code><span class="type" title="data:cell">Mobile</span></code> | |||
=== to do === | === to do === | ||
* Browser testing. This code sample must be tested in various browsers to determine how they process and handle pages with such code | * Browser testing. This code sample must be tested in various browsers to determine how they process and handle pages with such code |
Revision as of 08:57, 27 August 2008
value excerption pattern brainstorming
The value-excerption-pattern is derived from value-excerpting in hCard. The precise parsing behavior is not yet finalized, so the pattern should be used only with extreme caution.
This brainstorming page is for exploring ideas related to specifying the value-excerption-pattern in more detail and ideas for special case handling of the value-excerption-pattern in combination with specific semantic HTML elements per those elements' particular semantics.
These are merely explorations for now, and should NOT be used in actual content publishing, nor implemented in any production code.
- Editor
- Tantek Çelik
object param handling
2008-08-23 Ben Ward and Tantek Çelik brainstormed the following possible special case markup handling for the use of the value-excerption-pattern with the <object> element. Modified 2008-08-26.
The following markup example documents one way the hCard tel
property's type
subproperty could be specified with the enumerated value of "cell" while providing the UK English "mobile" as the human visible object text contents:
<object class="type" lang="en-GB"> <param name="value" value="cell" /> mobile </object>
summary
- object element special case handling of value excerption. When a microformat (sub)property class name is specified on an object element, then value excerption handling is modified as follows:
- first param with name attribute value. if the first child of the object is a param element, and that param element has name attribute value of "value", then use the value attribute value for the value for the microformat (sub)property class name specified on the object.
- continue. if not, continue with existing value excerption handling, and microformat (sub)property parsing rules as currently best specified by hcard-parsing.
notes
Note that the param element does not have a 'class' attribute and thus its 'name' attribute (which has a compatible semantic) is used instead to invoke the value excerption pattern.
advantages
- Greater semantic re-use. The use of the param element to specify a value for its object is in line with the param element's semantics. The semantic association between the object and the param element is defined in the HTML4 specification.
- Less invention. This use of object param is superior to the use of a nested empty span element. The association of an empty span with its parent is a new semantic not previously defined in the HTML4 specification. Thus this use of object param markup better follows the principle of minimum invention as compared to nested empty span markup.
neutral
- Similar violation of DRY to nested empty span.
disadvantages
- Less human visible than abbr DRY violation. The contents/values of param elements are not exposed to the user of a browser, unlike the title attribute of abbr which, since it is commonly available as a hover tooltip, is more human visible, thus verifiable, than param.
- DRY violation content divergence risk greater than abbr. With abbr, one element is used to express both a human visible string and the property value, thus tying these values closer together (thus reducing risk of divergence). With object param, two elements are used, and thus risk of divergence may be greater than the use of abbr. Possible mitigating techniques that would help keep the property value and the equivalent human visible string closer to each other, perhaps as close in the code as they are when using abbr:
- require param be first child of object
- require use of only one param child (allow other child elements)
- require exclusive use of object for value excerption i.e. no using the same object for an actual replaced object and a value excerption
- require "value" attribute be the last attribute specified on the param element
- require equivalent human visible text be placed immediately (allowing for whitespace) following the param
- Verbose: not very hand-authoring friendly, compared to other suggestions such as:
- Machine data in class:
<span class="type data-cell">Mobile:</span>
- data prefix in titles:
<span class="type" title="data:cell">Mobile</span>
- Machine data in class:
to do
- Browser testing. This code sample must be tested in various browsers to determine how they process and handle pages with such code
- determine which browsers to test (based on popularity, deployment, etc.)
- write a full sample test case using the above object param markup pattern and a complete hCard
- write a more complex sample test case with multiple uses of the object param markup pattern
- test do browsers properly display the UK English text "mobile"?
- test do browsers generate multiple browser (e.g. Webkit, Trident etc.) controls as they would for embedded frames (nested HTML objects)?
- determine any other tests
- Parser implementability. Determine approximately how much work it would be to implement this special case object param support.
- I've just added support for this. It took 19 bytes of code. TobyInk 01:24, 25 Aug 2008 (PDT)
- Document in more detail. Assuming browser tests of a simple example pass (proper visible text displayed, page efficiency not compromised by additional control creation), document how to handle/parse this pattern in more detail. Iterate.
Browser Testing
Using the following simple, HTML4 hcard:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd"> <title><object> value excerption pattern: hCard Telephone Type Test Case</title> <body class="vcard"> <h1 class="fn"><a class="url" href="http://ben-ward.co.uk">Ben Ward</a></h1> <p class="tel"> <object class="type"> <param name="value" value="cell"> Mobile: </object> <span class="value">415-123-567</span> </p> </body>
Results
A pass is to display a heading level one ‘Ben Ward’ with hyperlink, followed by a paragraph displaying the text ‘Mobile: 415-123-567’ Browsers selected based on YUI Graded Browser Support (August 2008), plus some others.
- Opera 9.5 - Pass
- Firefox 2, 3 - Pass
- Microsoft Internet Explorer 5.2 (Mac) - Pass
- Microsoft Internet Explorer 6 - Partial Pass†
- Microsoft Internet Explorer 7 - Partial Pass†
- Microsoft Internet Explorer 8 (beta) - Partial Pass†
- Safari 3 - Pass
- Safari 2 - *Fail* ††
† Internet Explorer 6–8 on Windows XP renders the correct text, but triggers an ActiveX security warning bar on the page load. †† Safari 2 renders a default-sized white box (as if embedding an external control). It breaks layout and does not display the desired content.
Safari 2 Tweak
The example is tweaked as follows to affect Safari 2 rendering:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd"> <title><object> value excerption pattern: hCard Telephone Type Test Case</title> <body class="vcard"> <h1 class="fn"><a class="url" href="http://ben-ward.co.uk">Ben Ward</a></h1> <p class="tel"> <object data="data://" class="type"> <param name="value" value="cell"> Mobile: </object> <span class="value">415-123-567</span> </p> </body>
A data="data://"
URL attribute is added to the object
element.
Safari 2 Result
- Safari 2 - Partial Pass†
† Safari 2 renders the object correctly on first page load, *however*, upon using the browser ‘Refresh’ function, the object
element reverts to the broken rendering described in the original test.
Current Conclusion
- Safari 2 does not pass the test acceptably for this to be adopted as the only solution.
- Internet Explorer's security warnings are irritating, but justifiably unacceptable.
--BenWard 20:17, 26 Aug 2008 (PDT)
previous iterations
20080823
<object class="type" lang="en-GB"> <param class="value" name="value" value="cell" /> mobile </object>
disadvantages
- Invalid (X)HTML - although this pattern does make sense, it is worth noting that
<param>
is one of just a handful of HTML elements for which theclass
attribute is not defined. Use of this pattern will break validation unless a custom DTD is employed.