#microformats 2015-05-08

2015-05-08 UTC
# 00:22 
tommorris edited /microformats2-parsing-brainstorming (+47) "adding MIME type" (view diff)
# 00:25 
tommorris edited /microformats2-parsing-brainstorming (+494) "use cases plz" (view diff)
# 00:29 
tantek tommorris: right at the top: "Use case: IndieWeb "deleted" indication inline in content for static file services that don't support HTTP return codes. "
# 00:30 
tommorris yeah, but why just the http-equivs. you'd need to have both to discern anything useful
# 00:30 
tommorris I'm just not sure why you'd want one but not the other
# 00:31 
tommorris meta http-equiv is there for when you can't set headers. but headers are still sent - the meta http-equiv just overrides them in the document
# 00:31 
tommorris getting the overrides without the values they are overriding is a bit weird
tantek joined the channel
# 00:38 
tantek tommorris: re: "when you can't set headers" - exactly: "static file services that don't support HTTP return codes"
# 00:39 
tantek re: "you'd need to have both to discern anything useful" - not true - and certainly not true in this specific use-case where you do check for a 410 status code first, and then go parse the file.
# 00:40 
tantek point is to *not* have to *separately* parse for http equiv status code 410, but be able to just always run the microformats parser on the HTML and do *zero* parsing in your own code
# 00:40 
tantek re: "why you'd want one but not the other" - because this use-case is in the context of already having gotten the headers via curl
# 00:41 
tommorris but in the context of building the library, if I have access to both why not merge the two and return a combined dictionary of both headers and meta http-equivs
# 00:42 
tommorris difference between...
# 00:42 
tommorris A: MUST return http-equiv only
# 00:42 
tommorris and
# 00:42 
tantek because it's extra work for the library
# 00:42 
tommorris B: MUST return http-equiv only and MAY return other headers parsed from the response and combine them together
# 00:42 
tantek and people already have header parsing / handling code
# 00:43 
tantek A is the minimum viable feature to satisfy the use-case - that's why
# 00:44 
tommorris should a microformats parser do anything with any of the other headers? behave like a proper HTTP user agent perhaps?
# 00:45 
tommorris if we're handling headers (and meta http-equiv are basically headers), we should probably follow what the headers tell us to do broadly in the same way browsers do
# 00:47 
tantek again - no need for the mvp for the use-case
# 00:47 
tantek less code = less chance of introducing bugs
# 00:48 
tantek a microformats parser may just get a URL (context) and a string of the curled data - e.g. that's how phpmf2 works now
elux_, fuzzyhorns, KartikPrabhu, tantek, KevinMarks_, eschnou, kez, gRegorLove, KevinMarks__, KevinMarks___, chiui and Left_Turn joined the channel
# 09:39 
justgerrardz edited /rel-author-fr (+8) (view diff)
# 09:41 
justgerrardz edited /process-fr (+232) "/* En rapport */" (view diff)
eschnou, adactio, kez, uf-wiki-visitor, elux, KevinMarks_, TallTed, KevinMarks__, KartikPrabhu, gRegorLove, bengo, chiui, KevinMarks___, fuzzyhorns and tantek joined the channel