On Oct 5, 2006, at 9:20 AM, Ciaran McNulty wrote:
I'd prefer to say that an hCard with missing elements *is* an hCard,
it's just invalid. It's like saying that a web page that's missing
its head is invalid, rather than saying it's not HTML.
Yeah, after thinking about it more, I don't really
Someone can mark up a form as an hCard anyway, regardless of whether
it's in the spec or not. I imagine at least one person has already
tried it after reading this thread, to see what it looks like. Thus,
parsers could be subjected to this construct regardless of whether
it's in the spec.
On 4 Oct 2006, at 19:37, Scott Reynen wrote:
What is the benefit of using the same root class name for forms
accepting a microformat as we use for the published microformat?
The first that comes to mind: If the form is pre-filled then you have
a valid vcard that could be parsed (with the
On 10/5/06, Ben Ward [EMAIL PROTECTED] wrote:
The first that comes to mind: If the form is pre-filled then you have
a valid vcard that could be parsed (with the addition of some form
parsing rules). Take for example an 'Edit Profile' page that contains
existing values.
That's a very good
On 05/10/06, Ciaran McNulty [EMAIL PROTECTED] wrote:
Elements like textarea/ that just wrap values could be parsed
normally but others like input type=text/ would need to be parsed
using the @value, and I'm not sure what we'd have to do to be able to
parse, for instance, radio buttons.
Quick
On 10/5/06, Tom Armitage [EMAIL PROTECTED] wrote:
Quick question (and this isn't mean as a troll or a leading one, it's
just because right now I can't think of any): what uF could be
valuably applied to a radio button? I guessed you might have two radio
buttons saying home address and work
On Oct 5, 2006, at 5:17 AM, Ciaran McNulty wrote:
I agree with this. I think indicating that a form contains an hCard
is semantically valid in and of itself, especially in the case of
presenting an hCard in a form for editing. There's also nothing
immediately wrong with saying that an empty
Scott,
Thanks for the in-depth reply, lots of good points! I've mulled it
over and here are a few thoughts.
On 10/5/06, Scott Reynen [EMAIL PROTECTED] wrote:
An empty hCard is not an hCard.
hCard requires at least a name, and
most other microformats have some basic requirements. So I think
Nice summary! I agree the issues are non-trivial, but I'm glad
somebody is hashing them out...
On Oct 5, 2006, at 7:20 AM, Ciaran McNulty wrote:
Scott,
Thanks for the in-depth reply, lots of good points! I've mulled it
over and here are a few thoughts.
On 10/5/06, Scott Reynen [EMAIL
On Oct 4, 2006, at 10:18 AM, Stephen Paul Weber wrote:
One thing about this would be that all current parsers would have
to be tweaked to ignore form as the root of a data-extraction
parseing.
Which may be a good idea anyway?
-ryan
___
On 28/09/06, Drew McLellan [EMAIL PROTECTED] wrote:
That's the ticket. But you'd need a mixture of name and class to
account for everything... e.g.
fieldset class=fn n
input type=text name=given-name /
input type=text name=family-name /
/fieldset
(obviously incomplete example)
drew.
One thing about this would be that all current parsers would have to
be tweaked to ignore form as the root of a data-extraction parseing.
On 10/4/06, Tom Armitage [EMAIL PROTECTED] wrote:
On 28/09/06, Drew McLellan [EMAIL PROTECTED] wrote:
That's the ticket. But you'd need a mixture of name
On Oct 4, 2006, at 12:18 PM, Stephen Paul Weber wrote:
One thing about this would be that all current parsers would have to
be tweaked to ignore form as the root of a data-extraction parseing.
I don't think it's quite that simple. What about cases where
microformats exist within forms, but
Ben Ward wrote:
What if I was to mark up the form (and fields) with hCard classes?
What a coincidence! Just last night, I spoke to a couple of people
about this exact concept at the WD06 after-party. Then I got home and
looked here and found this thread had just recently started! :-)
On Thursday, September 28, 2006 9:21 AM Drew McLellan Wrote
On 28/9/2006, Ryan Cannon [EMAIL PROTECTED] wrote:
What if I was to mark up the form (and fields) with hCard classes?
Good idea? Bad idea? I strikes me that it could be useful for auto-
complete applications, but not sure if
On 29/9/2006, Steve Ganz [EMAIL PROTECTED] wrote:
I've been thinking about this a lot lately too. I've had a note on
my fridge for about 2 months now that says simply Paste hCard. :)
I recently wrote a form and it just made sense to mark it up with
hCard semantics. To avoid
On 29/9/2006, Drew McLellan [EMAIL PROTECTED] wrote:
On 29/9/2006, Steve Ganz [EMAIL PROTECTED] wrote:
I've been thinking about this a lot lately too. I've had a note on
my fridge for about 2 months now that says simply Paste hCard. :)
I recently wrote a form and it just made sense
On 28 Sep 2006, at 13:33, Stephen Paul Weber wrote:
What about using the same markup as the appropriate uF, but a
different root class name (such as 'form')?
That's a possibility I guess, but thinking for a moment in the
context of the DOM, with the form fields filled in (and an
A cool implementation of this would be a form that optionally accepts
the URL for an hCard and auto-fills the data by making an AJAX request
to the entered page and transforming it with X2V.
Of course this wouldn't require hCard markup in the forms, but you
could build a slick library out of it.
On 9/28/06, Ben Ward [EMAIL PROTECTED] wrote:
Hello list, just a quick point for discussion:
Lets say you have a personal registration form in your web app, for
entering contact data which will later be output as an hCard in
various places.
What if I was to mark up the form (and fields) with
Lets say you have a personal registration form in your web app, for
entering contact data which will later be output as an hCard in
various places.
What if I was to mark up the form (and fields) with hCard classes?
I've long thought that a form should be marked up as if the data was
I think we are just about to independantly arrive at Live Clipboard.
The way LiveClipboard works is through the use of a js library that
parses the hCard/hCalendar and then inserts them into the form fields
that you define.
IF we standardised the form fields to match the same name as hCards
(or
Frances Berriman wrote:
Did
you see Drews demo of that with openID? It didn't require the forms
to use the microformat class names or anything.
Yeah, I've seen Drew's excellent auto-fill demo and had a couple of
conversations with him about combining that with OpenID. This isn't
so much
What about using the same markup as the appropriate uF, but a
different root class name (such as 'form')?
On 9/28/06, Ben Ward [EMAIL PROTECTED] wrote:
Frances Berriman wrote:
Did
you see Drews demo of that with openID? It didn't require the forms
to use the microformat class names or
On 28/9/2006, Ryan Cannon [EMAIL PROTECTED] wrote:
What if I was to mark up the form (and fields) with hCard classes?
Good idea? Bad idea? I strikes me that it could be useful for auto-
complete applications, but not sure if it would pollute the web
with effectively a useless/empty hCard
Hi all,
On Sep 28, 2006, at 4:12 AM, Drew McLellan wrote:
What if I was to mark up the form (and fields) with hCard classes?
Good idea? Bad idea? I strikes me that it could be useful for auto-
complete applications, but not sure if it would ‘pollute’ the web
with effectively a useless/empty
26 matches
Mail list logo
