> 2. Microformats are in page, and there needs to be some way
> to indicate the microformats are available on the page that
> doesn't offend page authors. How can we accomplish this?
I second the opinion that this is a design issue and therefore should be
handled by css in some way. This would
Farndon, Tony skrev:
2. Microformats are in page, and there needs to be some way
to indicate the microformats are available on the page that
doesn't offend page authors. How can we accomplish this?
I second the opinion that this is a design issue and therefore should be
handled by css in s
> If something should add anything it should be added by a
> javascript...
CSS is frequently used to *add* and place onto a page, be it a
background image, a border, etc
What I am saying is rather than add say, a background image, you use CSS
to add/place a microformat icon. How this icon behave
Hello everyone.
Great work thus far.. just want to drop my 2cents.
1) I don't think Dimitri's text was very clear on this aspect in
particular, but I believe it would improve the UXP and still give
control to the publisher.
Why not mixing the suggestion of dimitry (which seems like a very
well-t
To try and give where I am coming from some context, this is how I see
it all working in my head:
FF3 has a set of (3?) methods for alerting/displaying/provding actions
for uF
1) An Operator style toolbar
2) An Operator Style status icon
3) Within the content of the page (+1 and then some for dim
On 9/5/07, André Luís <[EMAIL PROTECTED]> wrote:
> Hello everyone.
>
> - when the user hovers on the margin-mark, the user-agent should
> 'target' to the (root?) element (like what's done with the #anchor in
> urls) and that would allow the publishers to specify the
> looks/highlight accordingly. L
Thanks for the comments on the margin-marks concept. I sincerely
appreciate that.
I really like the idea of allowing additional control over
presentation via pseudo-classes, but I am worried that :target isn't
quite right, at least if we follow the spec to the letter
(http://www.w3.org/TR/css3-sel
> Thanks for the comments on the margin-marks concept. I
> sincerely appreciate that.
Credit where credit is due!
> I really like the idea of allowing additional control over
> presentation via pseudo-classes, but I am worried that
> :target isn't quite right, at least if we follow the spec t
Dimitri,
That was exactly why I suggested :target instead of :focus. I think
ufs shouldn't _require_ links or other focus-eable elements. And I'm
with you with the worries on pushing the meaning of the spec... is
there a more meaningful alternative I don't know about?
And I'm with Tony (and other
Dimitri Glazkov wrote:
> I really like the idea of allowing additional control over
> presentation via pseudo-classes, but I am worried that :target isn't
> quite right, at least if we follow the spec to the letter
> (http://www.w3.org/TR/css3-selectors/#target-pseudo), specifically
> since this ps
Manu Sporny wrote:
Dimitri Glazkov wrote:
I really like the idea of allowing additional control over
presentation via pseudo-classes, but I am worried that :target isn't
quite right, at least if we follow the spec to the letter
(http://www.w3.org/TR/css3-selectors/#target-pseudo), specificall
> And I'm with Tony (and others) on the protocol approach.
I should, however, add that I do have one concern about the protocol
approach; it does not degrade gracefully. Users of FF2, or IE7 or Safari
etc will just get a big old unknown protocol error.
This is easily countered by the designer ch
Farndon, Tony wrote:
And I'm with Tony (and others) on the protocol approach.
I should, however, add that I do have one concern about the protocol
approach; it does not degrade gracefully. Users of FF2, or IE7 or Safari
etc will just get a big old unknown protocol error.
This is easily cou
> Alex Faaborg wrote a clever mail about this earlier and
> presented a few issues and a few possibilites related to
> protocols. It was then discussed that perhaps there should be
> one protocl for each microformat?
> That would if so enable different programs to easily take
> care of differe
Tantek =?ISO-8859-1?B?xw==?=elik wrote:
> Syntactically the URI would still work, however, semantically it would have
> been broken, that is, it is bad to not only change URIs so that they 404 and
> just plain don't work, but it is also bad to change the *meaning* of that
> URI.
As long as there
On 5 Sep 2007, at 20:18, Toby A Inkster wrote:
Syntactically the URI would still work, however, semantically it
would have
been broken, that is, it is bad to not only change URIs so that
they 404 and
just plain don't work, but it is also bad to change the *meaning*
of that
URI.
As long as
In message <[EMAIL PROTECTED]>, Ben
Ward <[EMAIL PROTECTED]> writes
Whilst the ‘meaning’ in terms of microformats.org/wiki/hcard being
a page about hCard would still be valid, the context in which that URL
is used by publishers on the internet. Tutorials may link to the entire
page accompanie
On Sep 5, 2007, at 2:34 PM, Ben Ward wrote:
Syntactically the URI would still work, however, semantically it
would have
been broken, that is, it is bad to not only change URIs so that
they 404 and
just plain don't work, but it is also bad to change the *meaning*
of that
URI.
As long as t
In message <[EMAIL PROTECTED]>, Scott
Reynen <[EMAIL PROTECTED]> writes
or 2) leave the specs where they are and create new -intro pages.
>I've seen [...] no one object to #2.
Then you haven't been paying full attention.
--
Andy Mabbett
___
microf
19 matches
Mail list logo
