value-excerption-value-title-test: Difference between revisions
(→Response: Padded out the test response section with more examples and explanation.) |
m (→hAudio#1: An hAudio Song: Swapped to MicroformatsMailingList template) |
||
Line 40: | Line 40: | ||
===hAudio#1: An hAudio Song=== | ===hAudio#1: An hAudio Song=== | ||
''If you believe there is a publishing mark-up scenario that these tests do not cover, please post on the | ''If you believe there is a publishing mark-up scenario that these tests do not cover, please post on the {{MicroformatsMailingList}}.'' | ||
==Response== | ==Response== |
Revision as of 00:13, 9 January 2009
<entry-title>Value Excerption Pattern: Parsing from empty elements test</entry-title> This is a special page to introduce and gather results to widespread testing of a proposed extension to the value-excerption pattern. It looks like this:
<p class='dtstart'>
<span class='value' title='2009-01-06T22:54:00-0800'></span>
January 6th, in the evening
</p>
It allows you to include machine-form data alongside human form, without polluting visible formatted content with undesired machine form data.
This pattern is based on a rendering behavior whereby an empty element, that is one containing no inner text, is ignored by browsers rendering, but remains in the DOM tree. This allows an element to be included in the document with a title as above, but without the tooltip being exposed to users. Additionally, it is reliably reported that these empty elements are not passed to assistive technology either, so the machine data does not override presentation of content to users of screen readers.
Since this pattern attempts to resolve some long standing issues with including required machine-data in microformats, it's imperative we get this tested completely before adding it to a draft spec. So, following are a number of examples. Please try them out. Push them into publishing systems, editor apps and tools, and see that it comes the way you expect on the other side; render them in desktop browsers, mobile browers, screen readers, in braille… anything you can check, we wanted to know that it works, we need to see any quirks, oddities and so on.
Also, by all means provide thoughts on the publishing flow for this. An empty element is a little odd at first glance, but the reasoning is this: The ‘machine data’ is not meta-data, it is still content, so it's structurally appropriate to have it as a sibling to the human text.
Note that functioning with valid HTML is part of microformats, so inventing new attributes, using non-standard DOCTYPEs or XML extensions is not an applicable option for this syntax. We're trying to achieve something as gracefully as we can within the limits of HTML, without doing anything to harm user experience.
The proposed parsing rules
The main proposed parsing rules and restrictions for this pattern are as follows:
- Only one empty-value element may be included as a child of the property. No splitting or concatenation.
- The empty-value element must be the first-child of the property (not including any preceding whitespace)
- The machine-data value must represent the same data as the visible inner text; the property should not contain arbitrary data. Parsers and validator tools will be invited to test this where appropriate.
- The empty element can be any element, but as a generic,
span
is most appropriately. You could useu
if you wanted to save bytes, orinput type=hidden
if you think that makes sense. It won't matter to parsers. As per usual µf documentation,span
is the generic example.
The examples
Please test these examples of content, and report any problems as indicated below.
hAtom#1: An hAtom Article
hCal#1: An hCalendar Event
hCard#1: An hCard Profile
hAudio#1: An hAudio Song
If you believe there is a publishing mark-up scenario that these tests do not cover, please post on the mailing list.
Response
- Don't like the empty element? Don't like the use of the title attribute? Please file general issues concerning the proposed pattern on the main value excerption pattern issues page, or discuss them on the mailing list.
- Add the results of and responses to these tests themselves on this page.
Misplaced responses will be moved, and having to do so will make Ben growly, so, y'know, please be helpful.
Successful Tests
List successfully tested environments here. Add new environments as new list items, and expand existing list items with your name and platform variants to indicate verified successes.
Test | Environment | Type | Platforms | Verified By |
---|---|---|---|---|
hAtom#1 | Safari 3.1 | Rendering | Mac OSX 10.5 | User:BenWard |
hCal#1 | Safari 3.0 | Rendering | Mac OSX 10.5 | User:BenWard |
hCard#1 | Safari 3.0 | Rendering | Mac OSX 10.5 | User:BenWard |
Failed Tests
For failures, please provide as much information as you can. The precise impact of the error, whether the behavior could be regarded as a bug in the software you're testing, whether it works in future versions, whether you changed any settings in the software to produce the result, and if so, whether enabling/disabling that setting would be regarded a showstopper if this pattern were certified.
Since we want more detail, please expand failures into headed sections rather than cramming into a table.
For example, take this entirely plausible scenario as a template:
Example: Fake Publisher 3.1ß
- Platform
- Windows Vista
- Verified By
- User:BenWard
- Description
- When trying to enter an empty span in my editor, which I wrote myself whilst I was high, the application immediately crashes, performs
rm -rf /
on all UNIX boxes connected to my local network (which appears to cause Android phones within Bluetooth range to do the same…), and then causes all attached peripherals to combust. I was not able to reproduce, as my house was now on fire. I think using a self closing XHTML tag instead might work-around the problem because as we know, it's been proved by Real Scienticians that XML is always better than HTML. Alternatively, it may be a bug in the beta software. - Notes
- This is a beta release, and a bug has been filed.
- This product has a known history of flammability bugs.
- The user must explicitly enable the ‘Endanger My Life’ checkbox under the ‘Advanced Mislabelled Checkboxes’ tab of the ‘Complicated Preferences’ preferences pane.
- You get the idea.
General Test Feedback
- Any general feedback you have on this test is most welcome. However, if you have issues with the pattern or alternate suggestions, please file them on the main value-excerption-pattern-issues page. Also, please remember to sign your comments with —~~~~ —BenWard 00:12, 9 January 2009 (UTC)