On 4 May 2007, at 22:19, Ted Drake wrote:
What’s the traction for something like this and “no-follow” to get
integrated into the microformat platform?
Well, robots-nocontent is not part of the the robots-exclusion draft,
which in itself has not been updated for over 18 months.
I contacted
Right,
I've set up a vote for this on the Wiki. As explained in my Wiki
commit comment, with the POSH page being something of a reference
rather than a page of active microformat development, I judge it to
be inappropriate to tack the vote on to the article itself and have
created a Talk:
On May 4, 2007, at 2:42 PM, Patrick H. Lauke wrote:
I'd invite you to document the list of every possible way to
represent each month in plain text, and then let us know if you
still think reading through such a list to figure out how to
publish dates is easier for publishers.
Maybe I've
On 05/05/2007, at 3:29 AM, Andy Mabbett wrote:
In message <[EMAIL PROTECTED]>,
Breton
Slivka <[EMAIL PROTECTED]> writes
It seems to me that in order to more effectively solve this problem,
this set of restrictions should be clarified- Here's what I've
got so
far, correct me if I'm wro
http://microformats.org/discuss/mail/microformats-discuss/2007-May/009504.html
On 5/4/07, Ted Drake <[EMAIL PROTECTED]> wrote:
This was a bit of a surprise on the yahoo search blog.
It's using the word "tag" incorrectly. It seems the search department is
adding a new microformat-like function th
This was a bit of a surprise on the yahoo search blog.
Its using the word tag incorrectly. It seems the search department is
adding a new microformat-like function that will allow us to tell spiders
what parts of the page are insignificant to SEO.
http://www.ysearchblog.com/archives/000444.html
Scott Reynen wrote:
I'd invite you to document the list of every possible way to represent
each month in plain text, and then let us know if you still think
reading through such a list to figure out how to publish dates is easier
for publishers.
Maybe I've lost track of the original issue he
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:
Fromage
Where's the visible data there? By your logic, tags should only
work on
the anchor element's content, not the tai
In message <[EMAIL PROTECTED]>, Breton
Slivka <[EMAIL PROTECTED]> writes
>It seems to me that in order to more effectively solve this problem,
>this set of restrictions should be clarified- Here's what I've got so
>far, correct me if I'm wrong.
>
>
>Date markup must:
>
>1> be capable of marking
In message <[EMAIL PROTECTED]>, Paul Wilkins
<[EMAIL PROTECTED]> writes
>The following from the proposal I suspect is errant.
>31 January 2007
>
>Were you after the following?
>31 January 2007
Yes; I note that you've already fixed that on the 'wiki'. Thank you.
--
Andy Mabbett
* Sa
In message <[EMAIL PROTECTED]>, Tantek Çelik
<[EMAIL PROTECTED]> writes
>Al's explanation provides good reasons *in general* why visible data
>works (and why invisible does not work),
Hmm.
Consider:
Fromage
Where's the visible data there? By your logic, tags should only work on
the anc
In message <[EMAIL PROTECTED]>, Tantek Çelik
<[EMAIL PROTECTED]> writes
>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
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 (in t
On 5/4/07 8:19 AM, "James Craig" <[EMAIL PROTECTED]> wrote:
> Copied the entire email below for context. Tantek, if you post this
> to the wiki, please note it as opinion and give a link to the thread.
> Marking this as fact would misrepresent the views of the Microformats
> group as a whole.
I d
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 (in their calendar
> program for example)
No the "i
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.
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
On May 3, 2007, at 5:57 PM, 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
Tantek Çelik wrote:
On 5/3/07 7:10 PM, "Patrick H. Lauke" <[EMAIL PROTECTED]> wrote:
But to bring it back to the original argument, the routine extraction
does not necessarily have to equate to data visible in, say, a
tooltip.
The routine extraction may well be mediated via some machine
in
(apologies for top posting but this is in response to Al's entire message,
not to any specific point in particular)
Al,
VERY well written. That's perhaps the clearest explanation I have seen of
why it is important to have visible information, even somewhat visible
rather than invisible.
May I q
On 5/3/07 7:10 PM, "Patrick H. Lauke" <[EMAIL PROTECTED]> wrote:
> But to bring it back to the original argument, the routine extraction
> does not necessarily have to equate to data visible in, say, a tooltip.
> The routine extraction may well be mediated via some machine interpretation.
"May" i
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 the
At 3:10 AM +0100 4 05 2007, Patrick H. Lauke wrote:
Al Gilman wrote:
If the machineable info is not routinely passing through the
consciousness of the communicating principals (that is, people),
Who may, without the machine-mediated interpretation, not actually
be able to make a qualitative
On May 4, 2007, at 3:29 AM, Breton Slivka wrote:
I don't think this will work, for the same reason tel-type and
adr- type don't work: l10n/i18n. They require displayed machine
values to be in English.
July
julio
7 月
июль
good point ...
parsing it might end up needing a database of day a
I agree that i18n is a stumbling block here. But, descriptions, titles
and names aren't translated as well, why would the date need be? Let's
put the smarts into the parsers and figure out which date we mean, and
have the user confirm it.
The place for such user confirmation is in authoring so
I've done more testing with the spanned/title solution to an abbreviated
date time pattern, and finally confirmed Jon Gibbins' report. It seems
JAWS has a few nuances I didn't know about.
I was planning to 'bake' a forum and comment system with microformats
(hAtom & hReview) and I'd prefer to get
And yet, to not do so means breaking another restriction. It's about
give and take. Is it better to make it easier for publishers, and
harder for parsers, or is it better to store the same date twice, and
let one go out of sync?
Another solution is to just store ISO dates free and clear, an
On 03/05/07, Andy Mabbett <[EMAIL PROTECTED]> wrote:
If it is intended to be separate form microformats, then having so much
about it on the microformat 'wiki' is somewhat misleading.
I must admit that I have some qualms about having it on the
microformats wiki also - if it's a term designed t
On 04/05/07, Tantek Çelik <[EMAIL PROTECTED]> wrote:
Human readable to one culture/language is not necessarily human readable to
other cultures/languages.
I agree that i18n is a stumbling block here. But, descriptions, titles
and names aren't translated as well, why would the date need be? Let
MM/DD is bad! What's 07/05 ? Today is 05/04 ... or is it 04/05 ?
Tomorrow is cool :)
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss
30 matches
Mail list logo