/abbr-design-pattern-alternatives
Test Cases: http://cookiecrook.com/test/uf/testcases/?printMarkup=true
Thanks,
James Craig
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats
Michael MD wrote:
http://microformats.org/wiki/dfn-design-pattern
* Feedback from the people building parsers (Mike Kaply, Brian Suda,
etc.) on whether this would be tricky or easy to implement.
quite easy I think...
my own scripts that parse hcalendar don't really care what tag is used
Apologies for not responding sooner. I've been working on a test case
script for all of the possibilities listed on the assistive-
technology-abbr-results pages, but side work always falls behind work
work. I'm getting close, I swear. Please add this format to the list
if you'd like us to
Paul Wilkins wrote:
From: Andy Mabbett [EMAIL PROTECTED]
I thought we'd decided that empty anchor tag-pairs were bad, from
an accessibility PoV?
Is the object tag to be used instead for the include pattern?
The object include pattern has some performance problems, it would
be best to
James Craig wrote:
Paul Wilkins wrote:
From: Andy Mabbett [EMAIL PROTECTED]
I thought we'd decided that empty anchor tag-pairs were bad, from
an accessibility PoV?
Is the object tag to be used instead for the include pattern?
The object include pattern has some performance problems
Hey Roger,
Looks interesting. Check out the Microformats process.
http://microformats.org/wiki/process
Then propose on the [microformats-new] list.
Cheers,
James
On May 20, 2007, at 2:37 PM, Costello, Roger L. wrote:
Hi Folks,
Michael Crichton says: The greatest challenge facing mankind
Just a thought:
Haven't thought too much about this, but are there any obvious
gotchas to using an anchor element with name attribute as a potential
replacement for the abbr-design-pattern? The only things I can
foresee are the plus sign (+) in pre-UTC time zones and the semicolon
(;) in
Ryan King wrote:
James Craig wrote:
Haven't thought too much about this, but are there any obvious
gotchas to using an anchor element with name attribute as a
potential replacement for the abbr-design-pattern?
I believe a[name] and @id need to be unique across an entire page
Ryan King wrote:
a[name has restrictions that input[name] does not have.
...snip...
1. http://www.w3.org/TR/html401/struct/links.html#h-12.2.1
Note and removed. Thanks!
http://microformats.org/wiki/assistive-technology-abbr-
results#Markup_Possibilities
James
Absalom Media wrote:
Obviously, if we're going to run with ISO8601, we need to include the
dashes as JAWS does read it better (which may require the usetitle
solution).
Any feedback on what would be an adequate common ground for this issue
as I want to start developing ?
While ISO 8601 is
I almost completely disagree with this. If people are actually
*using* Microformats as intended, there will be plenty of times when
the machine data will pass in front of the user (in their calendar
program for example) for verification. I do however, agree with the
following.
expressed
Scott Reynen wrote:
Tantek Çelik wrote:
To minimize the negative impact of that violation, the datetime
design
pattern does two things:
1. Keep both copies of the data on the same element (the further
apart two
copies of data, the greater the chance that that copies will
diverge).
2.
On May 4, 2007, at 8:24 AM, Tantek Çelik wrote:
On 5/4/07 8:19 AM, James Craig [EMAIL PROTECTED] wrote:
I almost completely disagree with this. If people are actually
*using* Microformats as intended, there will be plenty of times when
the machine data will pass in front of the user
Andy Mabbett wrote:
Tantek Çelik writes
Al's explanation provides good reasons *in general* why visible data
works (and why invisible does not work),
Consider:
a href=cheese lang=frFromagea
Where's the visible data there? By your logic, tags should only
work on
the anchor
victor jalencas wrote:
Since using ISO8601 is a w3c recommendation, I wondered where
specifically they were recommending its use. Looks like there is an
element (a couple of them, actually) with an attribute that can
legally contain an ISO datetime: INS and DEL.
Technically, that should only
Breton Slivka wrote:
span class=vmonthJuly/span span class=vday26/spanth,
span class=vyear2005/span
This solution is certainly more verbose, but note that it follows
all restrictions except for 7.
I don't think this will work, for the same reason tel-type and adr-
type don't work:
Tim Parkin wrote:
With all of the discussion about iso dates being unreadable and
that an
iso date isn't necessarily required when someone enters a date (i.e.
saying 24th June doesn't translate into a single date, neither does
'thursday'). Shouldn't the focus be on trying to standardise date
Tantek Çelik wrote:
If you want to carry on a theoretical discussion of namespaces,
please do so
elsewhere, for in practice, discussing them is a waste of time, and
off-topic for microformats lists.
Namespacing is not off-topic for Microformats. Note the hAudio proposal.
The main problem, as I understood it, is that object[data] expects
a URI, even if it doesn't know how to handle it, so the first
suggestion is actually requesting the relative path ./20050125
which causes extra junk 404s (Ex. 1; not necessarily a bug). Some UAs
even requested relative
Jon Gibbins wrote:
We can use rel on links, but could rel be used to permit something
like this on a span:
span class=dtstart rel=datetime:MMDDTHHMMSSZ+HHMMDD
Month/span
Hi John, I'm glad you mentioned this. It's been discussed before and
shot down given the reference, namespaces
Andy Mabbett wrote:
Tantek Çelik writes
the blog post on hAccessibility WaSP was seriously flawed
[...]
2. It recommended known unworkable solutions
Perhaps you missed this part:
We encourage the Microformats group to consider the problem,
whether or not they accept any
Jeremy Keith wrote:
James Craig wrote:
Due to opening up the pattern a bit more, there will also need to
be a flag to indicate when to use title attribute versus contents.
Something like this useTitle class:
No, this smells like a really bad idea. That class is now an
instruction
original abbr post, and include-pattern-feedback). In addition
I told
James Craig *in person* about this at SXSW, so I was a bit
surprised it
still made it to the blog post.
As Andy pointed out, the point of the article was not the proposed
solutions, but I want to point out that your reason
Tantek Çelik wrote:
Patrick H. Lauke wrote:
Forgive my newness to this, but: could you provide some examples of
where the generalised title-design-pattern would be problematic?
Here is a simple (theoretical) example (hReview fragment)
span class=rating title=Three means fair3/span
There
Absalom Media wrote:
Although in all my testing on this issue, the date-time-pattern still
announced the date correct (at least for hAtom, with dashes and
colons)
in terms of screenreader testing (JAWS 8 at advanced verbosity, Window
Eyes 6 and Firevox).
I'm still somewhat confused as to
Tantek Çelik wrote:
And though it may seem odd that I'm simultaneously arguing against the
proposed title-design-pattern and attempting to improve it, even if
I am
against a particular proposal, I would much rather attempt to
improve it in
good faith, for the benefit of having the best
Jeremy Keith wrote:
Microformats have always been a here-and-now technology rather than
a utopian idea for some future Semantic Web (see: RDF and other
noble but failed W3C technologies).
LOL. Poor RDF. There is an RDF thread about the article going on here:
Tantek Çelik wrote:
Generalizing this overloading of the title attribute to *any*
element seems
like a really bad idea from the perspective of minimal change.
Any element, but only on specific Microformat classes, each of which
has expected RegEx-matchable values. DTSTART, DTEND,
Brian Suda wrote:
the whole discussion begs the question about what people with
assistive technologies ACTUALLY think? A while ago there was a whole
report about who screen readers fail with AJAX apps, then someone
actually ASKED some blind folks if they could navigate the site...
they managed
Dr. Ernie Prabhakar wrote:
title=2007-03-12T17:00:00
Can you confirm that:
a) This will in fact solve the screen reader problem
It will not. Though I agree with Jeremy and Tantek that this solution
is slightly better than the current recommendation. It is still far
from accessible.
Dan Champion wrote:
Webadmin - Tenbus wrote:
Mike Kaply wrote:
Both upcoming and eventful do not have dashes in their dates.
They will need to be evangelized.
Wikevent.org's got it right http://wikevent.org/en/
Joan_Armatrading_2007_5_7 we don't need evangelising ;-)
Ditto for Revish -
Bringing, for discussion, a proposal from the WaSP ATF co-lead in
response to today's article.
http://www.webstandards.org/2007/04/27/haccessibility/#comment-57820
Patrick Lauke wrote:
so, looking at some “harmonisation” ideas then, what i would
suggest a way forward may be:
1) heavily
Paul Wilkins wrote:
This is a misuse of abbr at best.
See: open issue! 2007-01-26
http://microformats.org/wiki/hcard-issues
I also see that you are the author of that open issue, and that
it's been rejected.
Look again. The original rejection was for a different issue. The
real issue
On Mar 13, 2007, at 7:56 PM, James Craig wrote:
Look again. The original rejection was for a different issue. The
real issue is open and valid.
Sorry, I sent this two weeks ago but must've been offline until this
morning. I've been out of the country and am just now catching up
Paul Wilkins wrote:
With the abbr design pattern, you encode the machine-readable info
around the human-readable words.
p class=telabbr class=type title=faxTéléc/abbr: span
class=value(514) 123-4568/span/p
http://microformats.org/wiki/abbr-design-pattern has more details
on the abbre
Bob Jonkman wrote:
Hi all: Today I had the urge to mark up an arbitrary date, not one
that is part of
an hCalendar event, eg.
Use version 7.0.2 from abbr title=2007-03-055 March 2007/span
This is to provide some standarization in presenting dates, but
keep them human-
readable in
Paul Wilkins wrote:
While it specifies the time of insertion or deletion, the semantics
of that don't match up with what we're wanting to do here.
Unless you and Bob are working on that project together, the
semantics of the use can only be determined by Bob.
The INS and DEL elements are
Mike Kaply wrote:
Microformats that require specific settings on your web server, and
access by the user to configure that web server if necessary and a
very specific syntax that you might not be able to accomplish with
your configuration:
rel-tag
Don't forget it's also the only one that
to be documented. If it does not exist, it needs to be defined.
For example, the previously noted rejection statement seems
opinionated to me. If for no other reason, the frequency of this
request demands that it receive more consideration and deliberation.
Thanks for your consideration,
James
Nic James Ferrier wrote:
James Craig wrote:
i18n note: country-code may be missing. Usually a postal-code prefix,
such as FIN-00630 Helsinki or L-4750 Petange (Luxembourg), used
in addition to, or in lieu of, the country-name. Thoughts?
I do abbr class=country-name title=UKUnited Kingdom
Michael MD wrote:
It looks like what is really needed is a standard way to represent
standard country codes - so that machines can look up related
information for the country without the hit and miss problems of
freeform text names for places. (but keeping it simple for parsers
or
i18n note: country-code may be missing. Usually a postal-code prefix,
such as FIN-00630 Helsinki or L-4750 Petange (Luxembourg), used
in addition to, or in lieu of, the country-name. Thoughts?
http://microformats.org/wiki/adr#Property_List
___
Benjamin West wrote:
a href=javascript:ahah('Waldorf-Astoria-
Photo.html','Photo');photo/a
The best practice is to wire the event up, and to use a button
when
the element is not truly a link.
How is this not a link?
You can link to a template that takes the data as a parameter:
On Feb 12, 2007, at 7:37 AM, Mike Kaply wrote:
On 2/11/07, Kevin Marks [EMAIL PROTECTED] wrote:
Try making a fresh post, or republishing that one. This may be a
blogger issue with publishing via ftp?
When I debugged this problem, that is exactly what I discovered. It is
only broke when you
Scott Reynen wrote:
This may not solve 100% of issues, but I think Blogger could make
over 90% of plain-old web hosts work with the current rel-tag spec
by simply uploading tagname/index.html instead of tagname.html and
then point links to tagname/ (which resolves to index.html on most
Brian Suda wrote:
I would love to have my host have the latest, greatest version of PHP
technology. If they don't i don't go complain to PHP and ask them to
back-port functionality to an earlier version. I buck it up and either
move hosts, pay for the better service or co-locate my own box. It
Edward O'Connor wrote:
James Craig wrote:
Requiring a restful URL for rel-tag (though the ideal solution) is
expecting a lot more of a µf author than requiring authors to add a
bit of markup.
While properly implementing a tag space may be slightly more
difficult[1] than other methods
47 matches
Mail list logo
