This is to address "SEO" and anchors () in documents.
Fortunately, good SEO is more complex then boiling down well-ranking
in SERPs into how the anchors are set in a document.
Regarding: http://microformats.org/wiki/anti-patterns#empty_hyperlinks
point A) if there is no href attribute and value
On Dec 16, 2007 1:39 PM, Martin McEvoy <[EMAIL PROTECTED]> wrote:
> my
> boss looks at my work and says "what are all these empty anchors
> about"... pause right there... any SEO worth his salt will know anchor
> text links that go nowhere, will A, reduce the quality of out going
> links from your
Hi Daniel,
I wanted to let you know that in implementing identity consolidation
using rel-me on people's public profiles, you killed the usefulness of
your work by adding rel-nofollow.
As you can see from the wiki, rel-me links MUST not be accompanied by
rel-nofollow attributes.
http://microform
On 12/15/07 4:39 PM, "Martin McEvoy" <[EMAIL PROTECTED]> wrote:
> OK Paul, lets try and put that in the real world, My client has a music
> store with around 500 pages of content and around 10 to 20 items of
> hAudio on each page, My client want's their pages to validate and be
> accessible.. no p
On Sun, 2007-12-16 at 12:28 +1300, Paul Wilkins wrote:
> On Dec 16, 2007 11:52 AM, Martin McEvoy <[EMAIL PROTECTED]> wrote:
> > The empty although valid, seems nasty to me and a little anti!,
> > microformats are supposed to represent the data they contain...are they?
>
>
> As I was saying, this
On Dec 16, 2007 11:52 AM, Martin McEvoy <[EMAIL PROTECTED]> wrote:
> The empty although valid, seems nasty to me and a little anti!,
> microformats are supposed to represent the data they contain...are they?
As I was saying, this is why there has been so much debate about this
and it's why compr
Hello Paul
On Sun, 2007-12-16 at 10:27 +1300, Paul Wilkins wrote:
> On Dec 16, 2007 8:00 AM, Manu Sporny <[EMAIL PROTECTED]> wrote:
> > What was the problem with the SPAN approach, again?
> >
> > 3:23
> >
> > - You can set most, if not all, screen readers to not verbalize @title
> > in SPAN.
> >
On Dec 16, 2007 8:00 AM, Manu Sporny <[EMAIL PROTECTED]> wrote:
> What was the problem with the SPAN approach, again?
>
> 3:23
>
> - You can set most, if not all, screen readers to not verbalize @title
> in SPAN.
> - We're not abusing ABBR.
I've been looking carefully through the HTML 4.01 specs
Paul Wilkins wrote:
> The hAudio time should be denoted in seconds. If 3:23 is given it's to
> be seen as three minutes and twenty two seconds. If hours are needed
> it should be 1:3:23 (0 prefix optional) to denote 1 hour three minutes
> and twenty two seconds.
>
> This way the hAudio standard ca
On Dec 15, 2007, at 3:08 AM, Ciaran McNulty wrote:
It seems to me "3:23" is already
machine-readable
Does 3:23 mean 3 mins 23 seconds, or 3 hours 23 mins, or 23 minutes
past three o'clock? ;-)
My point is it's not productive to ask such questions outside the
context of the actual problem,
Paul Wilkins wrote:
On Dec 15, 2007 8:21 AM, Ben Ward <[EMAIL PROTECTED]> wrote:
Agreed. I'll repost something I put into the GEO thread last week.
It's quoting directly from the HTML4 specification. This doesn't
actually need to have any concern with accessibility, or assistive
technology tools
On Dec 15, 2007 8:21 AM, Ben Ward <[EMAIL PROTECTED]> wrote:
> Agreed. I'll repost something I put into the GEO thread last week.
> It's quoting directly from the HTML4 specification. This doesn't
> actually need to have any concern with accessibility, or assistive
> technology tools. Frankly, the
On Fri, 2007-12-14 at 16:23 -0800, Tantek =?ISO-8859-1?B?xw==?=elik
wrote:
> On 12/14/07 3:55 PM, "Martin McEvoy" <[EMAIL PROTECTED]> wrote:
>
> > On Fri, 2007-12-14 at 23:18 +, Martin McEvoy wrote:
> >> I do NOT however believe that machine data should be displayed in a
> >> people area such
In message
<[EMAIL PROTECTED]>, Ciaran
McNulty <[EMAIL PROTECTED]> writes
On Dec 14, 2007 6:45 PM, Andy Mabbett <[EMAIL PROTECTED]>
wrote:
That's a reasonable argument. It's not reasonable, though, to argue
(which you're not, at least not here, but which others seem to be) that
16:03 is an ab
In message <[EMAIL PROTECTED]>, Scott
Reynen <[EMAIL PROTECTED]> writes
On Dec 14, 2007, at 12:21 PM, Ben Ward wrote:
I am going to ask that we better define the problem. That we follow
up the demand for a better pattern (regardless of whether your
personal motivation is following the spec o
On Sat, 2007-12-15 at 13:36 +1300, Paul Wilkins wrote:
> On Dec 15, 2007 1:21 PM, Martin McEvoy <[EMAIL PROTECTED]> wrote:
> > On Sat, 2007-12-15 at 12:33 +1300, Paul Wilkins wrote:
> > > On Dec 15, 2007 12:18 PM, Martin McEvoy <[EMAIL PROTECTED]> wrote:
> > > > you could perhaps do PT3:23 ? which
In message
<[EMAIL PROTECTED]>, Paul
Wilkins <[EMAIL PROTECTED]> writes
The least that could be got away with is 00:03:23, at which point it
would be a toss up between that or PT3M23S
Both of the above formats are valid and should be accepted by parsers
as a part of the ISO 8601 time/date f
On Dec 15, 2007 1:40 AM, Scott Reynen <[EMAIL PROTECTED]> wrote:
> It seems to me "3:23" is already
> machine-readable
Does 3:23 mean 3 mins 23 seconds, or 3 hours 23 mins, or 23 minutes
past three o'clock? ;-)
-Ciaran McNulty
___
microformats-discuss m
On Dec 14, 2007 6:45 PM, Andy Mabbett <[EMAIL PROTECTED]> wrote:
> That's a reasonable argument. It's not reasonable, though, to argue
> (which you're not, at least not here, but which others seem to be) that
> 16:03 is an abbreviation of what a human (geeks aside) would gather from
> the context a
19 matches
Mail list logo
