#microformats 2011-07-14

2011-07-14 UTC
KevinMarks, mkaply, stereoket_, stereoket, krijnh, scor, tantek, nonge__, danbri, quiron, voxpelli, csarven, Amorphous, adactio, Askarii, aux, tlr, singpolyma, ericduran and adactio_ joined the channel
#
hober tantek & others: http://www.w3.org/Bugs/Public/show_bug.cgi?id=13240
#
hober n.b. henri's comment
#
singpolyma hober: I don't know how the community feels, but I've been using <time> in hAtom for some time now
#
tantek it's also been implemented in X2V and is running in the development version of H2VX: http://dev.h2vx.com/
#
tantek for those that want to try hCalendar+<time> for example
#
singpolyma cool
#
tantek singpolyma if you could try it with your hCalendar and let me know how it works for you that would be helpful
#
singpolyma ofc, with his proposal to go to <data> I think it makes more sense to add a new global attribute
#
singpolyma tantek: I don't publish a lot of hCal, but I'll keep it in mind.
#
hober well, i think generating some useful comments on that bug would be helpful
#
tantek hober I can't remember my pw for the W3C bug db and tried resetting it but didn't get any email so that seems broken
#
tantek could you add some of the above to the bug?
krijnh joined the channel
#
hober I'll add a comment linking to this IRC transcript
#
tantek edited /h2vx (+171) "noted that HTML5 time element support was added to dev.h2vx.com on 2010-09-02, follow-up to one comment" (view diff)
#
tantek This is the URL for H2VX support of HTML5: http://microformats.org/wiki/h2vx#HTML5_support
#
tantek so I think this is just a matter of mis or lack of communication
#
hober krijnh: krijnhoetmer.nl is down :(
#
tantek folks involved in microformats are absolutely interested in the <time> element, and are actively implementing / deploying support for it.
#
krijnh hober: I know, IP changed, will be back soon
#
singpolyma I love from the h2vx wiki there: "I'm a crazy XML person and my markup is 100% well formed XML, please don't tidy, please break and fail to process if it's not well formed"
#
hober krijnh: is it still logging? As in, when the DNS change propagates, will I be able to link to the discussion above?
#
tantek Brian Suda and I added the support for <time> (as well as other new HTML5 elements) to X2V and then deployed it in http://dev.h2vx.com/ last year (2010-09-02) for anyone to try testing out - we figured we would give it some time there before flipping the switch and deploying it to the primary use URL at http://h2vx.com/ cc: hsivonen hixie
#
tantek hober - for now feel free to quote and attribute directly
#
singpolyma we need an h2vx for hAtom
#
tantek singpolyma - do you have an XSLT for hAtom to Atom that "works" ?
#
singpolyma tantek: no :(
#
singpolyma is not an xslt wizard
#
singpolyma I should try writing something
#
Loqi agreed.
#
singpolyma adds that to giant heap of things I should do
#
tantek well if you have any kind of PHP-friendly code to convert hAtom to Atom, let me know (as in add it to http://microformats.org/wiki/h2vx#feedback ) and we can see about supporting a /atom path on h2vx.com
#
singpolyma hmm... php, eh? I could do it in PHP
#
krijnh hober: it disconnected a lot the last couple of days, hopefully it stays connected now
#
tantek right - I just said XSLT because that's what the rest of the converters on H2VX are written in
#
singpolyma right
#
krijnh hober: but if you send me your own log, I'll add it
#
tantek singpolyma - you could start with the XSLT hCalendar -> iCalendar and try converting it to handle hAtom -> Atom
ericduran joined the channel
#
hober krijnh: I don't keep logs [that's what your wonderful site is for! :)], but perhaps someone else here does...
#
krijnh Logs, or just a copy of what you've just said :)
#
hober yeah, i have all of this in my scroll buffer, so I can add something on that bug
#
singpolyma I only log when I'm away, and things with my nick in them :)
#
tantek krijnh - I thought you logged continuously, and then only published the channels that people requested?
#
krijnh tantek: not if my connection drops :)
#
krijnh We switched from adsl to fibre stuff, but had some problems with that
#
tantek singpolyma - I'm not sure about either <data> or a new global attribute because I think both would encourage lazy double-encoding of data which is a DRY violation.
#
singpolyma tantek: example?
#
tantek instead I think the <time> element approach is correct. prove the need for double-encoding on a case by case basis, and then create an element for each proven case.
#
tantek like I want a <number> element for example
#
singpolyma <time> seems very overly specific, like the img/video/audio debacle
#
tantek since it's clear from some of the examples where quantities or numbers are involved - e.g. hReview aggregate, that publishers use human or locale-specific numbers
#
tantek e.g. <number value="10000">10,000</number>
#
singpolyma right. already that's showing a tendency towards tag proliferation. which Is why I would support a global attr
#
singpolyma lest we end up with a billion tags
#
tantek <time> matches the use cases that have been demonstrated for dates and times, modulo the requested additions to it of course (which I still think are a good idea in general) http://wiki.whatwg.org/wiki/Time_element
#
tantek singpolyma - that's a false reductio absurdum
#
singpolyma fine, leave out the last statement then
#
tantek because no matter how you slice it there will be a very limited number of specific data types that require dual representation
#
tantek I would be surprised if more than 3-4 elements were added ever for this.
#
singpolyma possibly
#
singpolyma I just see this as similar to the img/audio/video vs object problem
#
tantek duration can be solved by extending the existing time element to handle ISO8601 duration syntax: https://secure.wikimedia.org/wikipedia/en/wiki/ISO_8601#Durations
#
singpolyma yes
#
tantek (which is needed for example for hMedia and hAudio)
#
singpolyma I certainly wouldn't oppose keeping <time>, because there's no precendent
#
singpolyma but I have no problem with generalising either
#
tantek though I'm not entirely convinced by the human/developer usability of the ISO8601 duration syntax - which is why I haven't proposed it as an addition to <time>
#
singpolyma well, time should support all of ISO8601 if that's the standard it's going to be based on, no?
#
tantek no - only the parts that have demonstrated use-cases
#
tantek like most "old" standards, ISO8601 is overdesigned
#
tantek and is best for picking and choosing from
#
tantek unless all features in a standard are based on documented/researched use-cases, it doesn't make sense to "support all of" that standard
#
singpolyma not even for compatability?
#
tantek no - subsetting is better for compatibility - less work
#
tantek eventually you iterate on the standard to document the subset that actually works interoperably
#
tantek btw
#
tantek this is not very human friendly: PnYnMnDTnHnMnS
#
tantek but could be with a slight modification - it suffers from the same problem as unhyphenated uncoloned dates and times
#
singpolyma yeah
#
tantek in fact I would use commas to make it readable
#
tantek e.g.
#
tantek PnY,nM,nD,nH,nM,nS
#
tantek as separators
#
tantek but only between components
#
tantek so you could still say P1M
#
tantek and I dislike the use of the "T" separator too - that's made ISO8601 datetimes less readable as well
#
singpolyma agree
#
tantek better than that for durations would be to simply require months to use Mo
#
tantek and minutes to use Min
#
tantek both accepted abbreviations
#
singpolyma ISO8601 wasn't really designed as a whole for standard humans
#
singpolyma though bits of it (YYYY-MM-DD) standard humans can use
#
tantek even machine formats should be made as human-friendly as possible
#
tantek because humans (developers) have to understand, implement, test, maintain them
#
tantek we've learned that lesson with markup vs binary formats
#
singpolyma somewhat
#
singpolyma currently works at google where everything is binary
#
tantek hah
#
tantek I'm talking specifically about formats for *human* content
#
tantek stuff humans author and generate
#
singpolyma sure
#
tantek machine to machine sure - go crazy with the bits
#
tantek also the time interval / repeating interval syntax is horrible: https://secure.wikimedia.org/wikipedia/en/wiki/ISO_8601#Time_intervals
#
singpolyma number of bytes also used to be a big deal. still is in contexts the valley doesn't care about :)
#
tantek ok, duration proposal added to WHATWG wiki:
#
tantek http://wiki.whatwg.org/wiki/Time_element#duration
#
tantek please feel free to add your +1 in support if you think it's a good idea to the discussion section: http://wiki.whatwg.org/wiki/Time_element#duration_discussion cc: hober, singpolyma, KevinMarks, manu`
lmorchard and krijnh joined the channel
#
tantek and posted to whatwg list
#
tantek edited /rel-enclosure (+32) "add brainstorming" (view diff)
#
tantek edited /rel-enclosure (+2) "/* See also */ *" (view diff)
#
Hixie tantek: microformats input on http://www.w3.org/Bugs/Public/show_bug.cgi?id=13240 would be helpful on that topic
#
tantek created /rel-enclosure-brainstorming (+731) "drafted with download attribute suggestion" (view diff)
tlr joined the channel
#
tantek Hixie - I can't give input on that bug because I forgot my W3C password to that bugzilla install and it is failing to send me a new one.
#
tantek I've asked others here to feel free to pass on my input.
#
singpolyma <@tantek> Brian Suda and I added the support for <time> (as well as other new HTML5 elements) to X2V and then deployed it in http://dev.h2vx.com/ last year (2010-09-02) for anyone to try testing out - we figured we would give it some time there before flipping the switch and deploying it to the primary use URL at http://h2vx.com/ cc: hsivonen hixie
#
singpolyma woah... clipboard fail
pnhChris and stereoket joined the channel
#
hober https://browserid.org/
abki_ joined the channel
#
singpolyma hober: saw that. Haven't looked into it enough yet to find out if it can be used without JS
tantek and Askarii joined the channel