www.sandeep.iocreated /SBCE (+1080) "Adding this to the wiki because every time I read the principles page and the point about diversity of approaches/implementations, I'm reminded of this." (view diff)
www.sandeep.ioedited /principles (+416) "(discussion section) There seems to be an unwritten principle of focusing on UX, should be make it explicit?" (view diff)
www.sandeep.ioedited /comments-presentation (+517) "(discussion section) Noted objection to accounting for long posts where only a part of it is in-reply-to another post." (view diff)
sandeepshettyI think they use the term final to mean something that can ship at the time (like indie-comments for example), no car design if of course final, you always have the next design and so on...
www.sandeep.ioedited /deleted (+505) "/* No Plans To Implement */ Simple workaround to avoid 410, 404 and tombstoning. leads me to believe that update might be enough and we could skip the concept of delete altogether." (view diff)
sandeepshettyI agree that "final" is a misnomer. Re UI converging: I think there are element that will converge like response counts, response details, etc.
sandeepshettyOne UI problem I'm facing at the moment.. is that as I follow comment threads (by following the in-reply-to) I have to reorient myself to each commenters site and "figure" out where the in-reply-to link is...
sandeepshettyhopefully our implementations will eventually have thread-readers which will follow the in-reply-tos and present a better view on our own sites.
www.sandeep.ioedited /deleted (+240) "/* Discussion */ Interestingly this (delete-workaround) also gives the commenter (content-owner) more control over explaining the intent of the delete." (view diff)
b0bg0d, musigny, tantek, tantek_, pfenwick, pfefferle and cweiske joined the channel
pfefferleis there any part in the mf2 spec that says the <div class="p-in-reply-to h-entry"> has to be inside the first h-entry or could it be also part of the p-content?
www.sandeep.ioedited /deleted (+590) "/* Discussion */ Added details of deleting non-comment responses using the workaround and converted to a list to facilitate discussion." (view diff)
Loqibarnabywalters: aaronpk left you a message 11 hours, 58 minutes ago: thx for the idea of only showing errors if you're logged in, just implemented that in like 3 minutes
tantekpfefferle - looks like barnabywalters answered your question about uf2 and h-entry vs. nested reply-context information etc. anything outstanding?
tommorrisit may not be perfect but I like the idea of having the viewer distributed with the data. makes it all the more time capsule compliant. because we're likely to have working browsers in twenty years time.
tantek#indiewebcamp is very much a move the web forward channel, but not just any random brainfart proposals for moving the web forward. rather, we filter web advancements by the simple question of how does it help my personal website right now?
tantekre: 1. assumption of error of proposals is reasonable given the incredibly bad track record of w3.org/TR drafts as a whole, and IETF RFCs as a whole
tantek2. random proposal similar is a reasonable conclusion as while not literally random, the aforementioned specs often pursue a *theoretical* need rather than an actual real-world documented use-cases based need, and thus "random" is a reasonable adjective (theory without data/research might as well be random)
tantekat lunch at the W3C Technical Plenary 1.5 years ago, in an discussion with TBL, we proposed a hypothetical .p TLD (to be purchased) that could be used for peer-to-peer DNS
aaronpkyes, it's an anti-pattern to start building things for others. but eventually software will need to be built for others because not everyone will build stuff for themselves
tantekthe "indieweb" is a tough enough problem space that right now the only people making conceptual progress in it are the people first building for themsevles
bretok! its just a simple way to send update notifications that was originally a work around for a different problem, but we figured we could add a parameter to delay incoming updates for a moment until github works out their issue