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
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 behaves
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
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
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. Like:
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
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 to
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
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
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),
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
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
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 different
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 is
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
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
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
___
18 matches
Mail list logo
