| 00:25 | <esprehn> | thanks! |
| 00:48 | <manu1> | Hixie: There has been some concern raised that the "datetime" attribute for the <time> element has been renamed to "dateTime". I'm trying to verify that this isn't true, and that the HTML <time> element has a content attribute called "datetime" (all lower-case). The HTMLTimeElement DOM interface has an IDL attribute called "dateTime". What's the likelihood of the content attribute being... |
| 00:48 | <manu1> | ...changed to "dateTime" (I'd hope the answer is almost no chance)? |
| 00:50 | <tantek> | manu1 - citation? |
| 00:51 | <Hixie> | manu1: no need to ask me, you can just check the spec. :-) |
| 00:51 | <Hixie> | manu1: if the spec is ambiguous about this though, please do let me know so I can clarify it |
| 00:51 | <manu1> | Hixie: Thanks, that's the answer I was hoping for... |
| 00:51 | <manu1> | tantek: http://lists.w3.org/Archives/Public/public-rdfa-wg/2013Mar/0013.html |
| 00:53 | <tantek> | manu1 - I don't see a reference to HTML5 / time in that email |
| 00:53 | <Hixie> | that is a very confused-looking e-mail |
| 00:53 | <tantek> | and the second reference, to XHTML Modularization - is fairly irrelevant as XHTML Modularization / XHTML 1.1 etc. is a dead-end and ignorable. |
| 00:54 | <Hixie> | and the first is to a 14+ year old spec... |
| 00:54 | <Hixie> | which doesn't have <time>... |
| 00:55 | <Hixie> | manu1: if that e-mail quotes the rdf spec correctly, though, it's very wrong |
| 00:55 | <Hixie> | manu1: the rdf spec, that is |
| 00:55 | <Hixie> | manu1: processing for <time> is defined in the HTML spec and it is not what that quote says |
| 00:56 | <manu1> | Hixie, tantek: There are a number rumors combined to make it seem like <time> in HTML5 is not stable... it's led to a couple of really strange readings of specs. I'm trying to dispel those rumors. |
| 00:57 | <manu1> | Hixie, tantek: We're just trying to nail down HTML+RDFa 1.1 and it's processing of the <time> element, specifically "datetime"... and some folks are claiming that <time datetime=""> isn't stable because of <insert rumor here>. |
| 00:58 | <manu1> | Hixie, tantek: I'm just trying to make the case that <time> is stable, as is "datetime"... |
| 00:58 | <manu1> | Hixie: It is somewhat strange that the IDL attribute is "dateTime" and the content attribute is "datetime" - but those haven't changed in years, right? |
| 00:59 | <manu1> | (as in, I don't really care if one is camel-case and the other is not... I can see the argument to camel-case the DOM interface IDL attribute") |
| 00:59 | <manu1> | in any case, I think I have my answer... thanks Hixie, tantek. :) |
| 01:00 | <Hixie> | well the <time> element we have now isn't the one we had a few years ago |
| 01:00 | <Hixie> | but that changed a while back |
| 01:00 | <Hixie> | i don't know if the IDL changed on <time> recently |
| 01:00 | <Hixie> | but that doesn't seem relevant to RDF :-) |
| 01:00 | <Hixie> | what _is_ relevant is how you parse the attribute |
| 01:01 | manu1 | nods, exactly. |
| 01:01 | <Hixie> | that should refer to "datetime value" |
| 01:01 | <Hixie> | and more specifically, to the "machine-readable equivalent of the element's contents" |
| 01:01 | <Hixie> | which defines precise steps to parse the attribute |
| 01:01 | <Hixie> | you should never refer to the <time> element's datetime="" attribute directly |
| 01:01 | <Hixie> | that's a layering violation |
| 01:02 | <manu1> | ahh, good point. Will update the spec with that language. |
| 01:03 | <Hixie> | ah, looks like the IDL for <time> did change recently |
| 01:03 | <Hixie> | to match the old <ins> and <del> IDLs |
| 01:04 | <Hixie> | which use dateTime |
| 01:04 | <manu1> | that must have been what folks got up in arms about... but I think they mis-read that as the content attribute changing... |
| 01:05 | <Hixie> | yeah i don't understand what confluence of misunderstandings could result in the e-mail you cited |
| 01:05 | <Hixie> | given that <time> is new, the IDL attribute on <ins> and <del> was always dateTime, that the IDL attribute and the content attribute are separate, given what the spec says, etc |
| 01:06 | <GPHemsley> | something datetime became dateTime recently |
| 01:06 | <GPHemsley> | not sure if it was the IDL, though |
| 01:06 | <GPHemsley> | but it was for <time> |
| 01:09 | <manu1> | GPHemsley: you're killing me. :) - was the W3C spec changed and not the HTML Living Standard? |
| 01:10 | <Hixie> | ignore GPHemsley, just look at the specs |
| 01:10 | <Hixie> | #whatwg is not normative |
| 01:12 | <manu1> | Hixie, GPHemsley: Yeah, just verified, it was the IDL attribute that changed... http://www.w3.org/TR/html5/text-level-semantics.html#the-time-element |
| 01:12 | <manu1> | that's all I needed, thanks again Hixie, tantek, GPHemsley :) |
| 01:12 | <Hixie> | good lord, don't quote the TR/ version |
| 01:12 | <Hixie> | that's months old |
| 01:13 | <GPHemsley> | Hixie recently made the change to the WHATWG version |
| 01:13 | <GPHemsley> | can't speak for anything else |
| 01:13 | <GPHemsley> | just acting as a memory jogger :) |
| 01:15 | <manu1> | Okay, well the latest W3C HTML 5.1 Nightly still has the IDL interface attribute as "datetime": http://www.w3.org/html/wg/drafts/html/master/text-level-semantics.html#the-time-element |
| 01:15 | <manu1> | I just need to point to something recent and show that the content attribute "datetime" hasn't changed... |
| 01:16 | <manu1> | scratch that, the W3C HTML 5.1 nightly has it as "dateTime" - had to refresh my browser cache to see it. :( |
| 01:16 | <manu1> | (has the IDL interface attribute as "dateTime" that is... nothing to see here, moving on) |
| 01:17 | <Hixie> | i highly recommend just using the whatwg spec. |
| 01:18 | manu1 | will. |
| 08:25 | <jgraham> | Agenda: caniusecaniuse? |
| 09:38 | <zcorpan_> | <input type=month> for credit card input? seriously? i'd hate a calendar when trying to enter my cc details |
| 09:39 | <zcorpan_> | i just want a text field so i can type the numbers |
| 10:01 | <Garbee> | zcorpan_, So use type=number |
| 10:02 | <zcorpan_> | Garbee: number is not appropriate |
| 10:04 | <Garbee> | Depends on how you're taking the input. |
| 10:04 | <Garbee> | If you want a month, you can set it to number and have min=1 and max=12. That would cover it. |
| 10:04 | <Garbee> | For just a month input. |
| 10:05 | <Ms2ger> | Not sure if you'd want up/down buttons for a month |
| 10:07 | <Garbee> | Then a simple select from options. |
| 10:07 | <Garbee> | Point is, type=month is not the only way to get a valid month value in a form. |
| 10:08 | <zcorpan_> | Garbee: indeed |
| 10:11 | <Garbee> | Although, I don't think type=month should be displaying a full calendar. |
| 10:12 | <Garbee> | I think it should show a list of month names (somehow) localized to the pages language. |
| 10:12 | <Garbee> | A full calendar to get a month is overkill imho. |
| 10:14 | <zcorpan_> | Garbee: <input type=month> takes year+month as input |
| 10:15 | <Garbee> | Why not have type=year secondary? That is tricky. |
| 10:17 | <Garbee> | still, a full calendar for month and year is still overkill. |
| 10:17 | <Garbee> | Days are completely irrelevant, just adding clutter to the interface (possibly also confusing people.) |
| 10:47 | <annevk> | Hmm, so cvs is installed on my laptop... Damn, I was gonna use that as an excuse |
| 10:48 | <odinho> | lolwut |
| 10:54 | <marcosc> | annevk: just delete the cvs executable. Problem solved. |
| 10:57 | <annevk> | zcorpan_: ideally <input type=month> has some set of bindings, one of which makes sense for credit card entry |
| 10:58 | <zcorpan_> | annevk: sounds like overengineering for a minor use case |
| 10:58 | <annevk> | zcorpan_: if bindings will be complicated, maybe, but hopefully they won't |
| 10:59 | <annevk> | also, credit card entry is pretty common |
| 10:59 | <zcorpan_> | yes |
| 10:59 | <annevk> | for each device sold it'll happen a couple of times typically, sounds like something you want to optimize for |
| 10:59 | <zcorpan_> | being common doesn't necessarily mean there's a problem to solve :-) |
| 11:00 | <annevk> | on phones I wouldn't want a full keyboard for those inputs for instance |
| 11:00 | <annevk> | selecting the month and year would be much quicker typically |
| 11:00 | <annevk> | or giving numeric input |
| 11:02 | <zcorpan_> | entering cc card info is something i'd optimize for, but the year/month part is just a small part of the whole thing. i'd start with thinking about what i want the optimal interface should be for entering everything |
| 11:02 | <zcorpan_> | i'd prefer if i didn't have to type it in at all |
| 11:03 | <zcorpan_> | anyway |
| 11:17 | <matjas> | zcorpan_: congrats! |
| 11:18 | <zcorpan_> | matjas: what for? |
| 11:40 | <annevk> | Hmm, being able to set referrer source to a Document has probably introduced a bug in XMLHttpRequest |
| 11:40 | <annevk> | So maybe Hixie's abstraction is not a good idea... |
| 11:43 | <annevk> | Of course, XHR's decoupling of fetch metadata and running the fetching steps is also not great, but that was already there... |
| 12:05 | <zcorpan_> | http://www.w3.org/mid/F9981AFB970564408FEB7DFCF62D44084711FD64⊙PTc seems interesting |
| 12:21 | <annevk> | People have been saying stuff like that for years |
| 12:31 | <karlcow> | about biblio db? |
| 12:35 | <annevk> | About the "common database" |
| 12:36 | <annevk> | Is anything other than CSP touching the fetch algorithm? |
| 12:36 | <annevk> | I should have reviewed CSP earlier on :-( |
| 12:37 | annevk | was kinda hoping it'd go away |
| 12:47 | <karlcow> | reliability, independence, distributed, interoperability, communities of interests, … blablablah :) |
| 13:08 | <annevk> | Reads like your average Twitter bio |
| 14:00 | <darobin> | zcorpan_: I have a prototype implementation for the shared ref db thing |
| 14:00 | <darobin> | I'm working on docs, tests, and deployment now |
| 14:03 | <zcorpan_> | darobin: cool |
| 14:07 | <darobin> | zcorpan_: the code's at https://github.com/w3c/the-library/ and https://github.com/darobin/couth in case you're interested |
| 14:07 | <darobin> | but it's not really ready for prime time just yet |
| 14:08 | <zcorpan_> | darobin: WHAT DO YOU MEAN IT'S NOT READY!? |
| 14:09 | <darobin> | zcorpan_: I mean there are no docs for wusses like you — other than that it works :) |
| 14:09 | <zcorpan_> | ah, excellent |
| 14:14 | <hsivonen> | Is there a public list of W3C Members with dates of joining? |
| 15:50 | <dglazkov> | good morning, Whatwg! |
| 15:57 | <annevk> | hsivonen: don't think so |
| 15:58 | <annevk> | dglazkov: whoa, early today |
| 16:14 | <annevk> | hsivonen: http://www.guardian.co.uk/technology/blog/2013/mar/12/tim-berners-lee-drm-cory-doctorow is relevant to your interests |
| 16:14 | <annevk> | maybe also manu-db ^^ |
| 16:21 | <SteveF> | annevk: clocks have gone back stateside... |
| 16:21 | <annevk> | SteveF: :-) |
| 16:52 | <dglazkov> | annevk: Daylight Zombie Time |
| 17:01 | <annevk> | MikeSmith: how would you feel about public-whatwg-bugs? |
| 17:01 | <annevk> | MikeSmith: my use case is getting a summary of newly filed bugs against WHATWG components on a page somewhere |
| 17:10 | manu-db | snickers at "A Web built on the urinary tract infection business model"... re: Doctorow / Berners-Lee blog post above from annevk |
| 17:13 | <manu-db> | annevk: Great article, thanks. I was a bit baffled to see Tim so supportive of the EME spec. I honestly think that the only way something "good" is going to come out of this is if an open DRM" scheme is proposed and implemented. |
| 17:14 | <manu-db> | (and even in that case, bleh...) |
| 17:17 | <annevk> | uhuh |
| 17:24 | <jgraham> | Guardian needs a "share on irc" button at the bottom of the article |
| 17:25 | <manu-db> | For those that haven't heard yet - the new SimCity game (which is pretty awesome, except for the "you must be online at all times DRM") has a /lot/ of JavaScript and is built on a custom version of WebKit: https://twitter.com/MaxisScott/status/310835756107177984 |
| 17:26 | <manu-db> | Electronic Arts is starting to do this with a ton of their games... might be a pre-cursor to jumping directly to HTML5+Canvas+WebGL (warning: wild speculation) |
| 17:26 | <gavinc> | Eh, I don't think it's DRM at that point so much as a network connected single player game of stupid. DRM doesn't break nearly as badly Sim City seems to be |
| 17:26 | <manu-db> | potato, potatoe |
| 17:26 | <manu-db> | :) |
| 18:40 | <annevk> | @tc39memes, finally |
| 18:41 | <marcosc> | :) |
| 18:41 | <wilhelm> | Hah. |
| 18:41 | <Ms2ger> | var let, eh |
| 18:52 | <slightlyoff> | annevk: I really wish people were honest about DRM: it's just a word for "crypto I don't like" |
| 18:52 | <annevk> | slightlyoff: if it was just crypto there wouldn't be a black box |
| 18:53 | <slightlyoff> | also, someone citing some evidence instead of conjecture about incentives would be hugely refreshing |
| 18:53 | <slightlyoff> | annevk: that's absolutely not true |
| 18:53 | <annevk> | slightlyoff: the web crypto stuff is not requiring a non-portable black box |
| 18:54 | <slightlyoff> | I don't love DRM, but I hate shit arguments for causes I like even more |
| 19:35 | <zewt> | that isn't at all what drm is |
| 19:36 | <zewt> | there are plenty of ways to define drm ("crypto designed to restrict the end user", "crypto designed to trigger laws against circumventing copy protection mechanisms"), but they're all much more specific than that |
| 20:15 | <karlcow> | drm = digital RIGHTS management |
| 20:16 | <karlcow> | but it became a suitcase word for many things. |
| 20:17 | <karlcow> | so only chaotic discussions can exist. |
| 20:17 | <karlcow> | acronym for a few other things too ☺ https://en.wikipedia.org/wiki/Drm |
| 20:18 | <karlcow> | hmm I like this one https://en.wikipedia.org/wiki/Digestive_rate_model |
| 20:18 | <karlcow> | Digestive Rate Model of the entertainment industry |
| 20:19 | <annevk> | Ms2ger: added Abstract/Goals to http://html5.org/temp/fetch.html |
| 20:19 | <Ms2ger> | Crap, now I guess I get to read it |
| 20:20 | Ms2ger | puts that at the end of his todo list |
| 20:20 | <annevk> | Ms2ger: not entirely done yet I guess, though I'm not sure how to classify unifying the error handling and redirecting model and such |
| 20:20 | <annevk> | Ms2ger: sure sure |
| 20:21 | annevk | is enjoying the E4H exchange |
| 20:22 | <marcosc> | yeah, that's been pretty good actually |
| 20:23 | marcosc | chews popcorn loudly ... imagines a world where there are no movies, but only dramas over on ES Discuss |
| 20:27 | <karlcow> | :) |
| 20:41 | <jgraham> | marcosc: Wait, what do you mean "imagines"? |
| 20:43 | <marcosc> | :) |
| 20:53 | <zewt> | karlcow: drm has nothing to do with "rights management"; don't be confused into thinking abbreviations invented for purposes of spin have anything to do with the words they're comprised of |
| 20:54 | <karlcow> | and here we come. :) |
| 20:54 | <karlcow> | QED |
| 20:54 | <zewt> | ... |
| 20:56 | <jsbell> | dang, wasn't subscribed to public-script-coord, I was missing out. I'd figured E4H was dead ages ago. This *is* good popcorn. |
| 21:00 | <zewt> | sadness: img.complete has no corresponding query for a failed load |
| 21:01 | <zewt> | so I can reliably tell if an image has successfully loaded, but detecting a failed load is much less reliable |
| 21:09 | <jgraham> | karlcow: To be fair the alternative expansion "digital restrictions management" is more accurate from the end user's point of view |
| 21:10 | <karlcow> | jgraham: agreed in the cultural context it has been used by the industry. |
| 21:12 | <karlcow> | And it's exactly my (own personal) issue with the system. |
| 21:13 | <internaut_jack> | Think I found a bug in Chrome with contenteditable attribute. Someone willing to validate for me? |
| 21:14 | <zewt> | (my issues with DRM are 1: that it often exists only to trigger anti-consumer laws, and 2: that it often involves embedding things into the user's own hardware, and having parts of my own property which are designed to act for somebody else's interest and explicitly against my own is exceptionally offensive) |
| 21:14 | <jgraham> | internaut_jack: Post a testcase and someone will look, I expect |
| 21:18 | <karlcow> | hmm… hesitating to reply to zewt. |
| 21:18 | karlcow | thinking |
| 21:20 | <karlcow> | Train of thoughts goes from cultural artifacts, embodiments of expression, copyright laws, economy of objects, etc. Before even touching the stinky bag of DRM. |
| 21:24 | <karlcow> | (dangerous) summary: For example, in the case of the book, you are never the owner of a text you have bought, you own the physical object which is the support of the text. (except if you have written it (: ) |
| 21:25 | <Hixie> | sweet, an in-the-wild sighting of <progress>! |
| 21:25 | Hixie | does a little dance |
| 21:25 | <zewt> | books don't come with a self-destruct mechanism that goes off if i do something the publisher doesn't like |
| 21:26 | <zewt> | Hixie: so there's been ... progress progress |
| 21:29 | <karlcow> | zewt: agreed but unrelated. :) |
| 21:29 | <internaut_jack> | jgraham, Here's the test case: http://jsfiddle.net/wtJVd/8/ |
| 21:29 | <zewt> | no less related than books, heh |
| 21:29 | <ashemedai> | Still not sure if this is Adobe messing up or Chrome: https://bugbase.adobe.com/index.cfm?event=bug&id=3517618 :\ |
| 21:29 | <internaut_jack> | Hixie, this is a working test case for events in chrome that label elements aren't firing properly: |
| 21:29 | <internaut_jack> | http://jsfiddle.net/wtJVd/8/ |
| 21:29 | <asmodai> | (So reported to both :P ) |
| 21:30 | <internaut_jack> | Hixie, from our conversation yesterday |
| 21:31 | <Hixie> | internaut_jack: looking |
| 21:31 | <Hixie> | internaut_jack: what am i looking for here? |
| 21:31 | <internaut_jack> | Hixie, There are two elements: a div and a label, both contenteditable. |
| 21:31 | <Hixie> | internaut_jack: oh you're saying keyboard events get redirected |
| 21:31 | <Hixie> | i see |
| 21:32 | <internaut_jack> | Hixie, The label element doesn't fire the events I've listed properly |
| 21:32 | <internaut_jack> | Hixie, EXCEPT for the 'input' event |
| 21:32 | <internaut_jack> | Hixie, Open your console, and you'll see the ones that get fired and where the label element doesn't report them. |
| 21:33 | <zewt> | except all the logs are "true", which is a bit hard to tell apart, heh |
| 21:33 | <internaut_jack> | zewt, Yes, but you can change 'em to whatever. |
| 21:33 | <internaut_jack> | Point is that they *don't* fire for the label element. |
| 21:36 | <internaut_jack> | Updated with more verbose logging: http://jsfiddle.net/wtJVd/10/ |
| 21:36 | <Hixie> | http://software.hixie.ch/utilities/js/live-dom-viewer/saved/2160 |
| 21:36 | <Hixie> | yeah |
| 21:36 | <Hixie> | weird |
| 21:38 | <internaut_jack> | Hixie, I'm getting some errors on that page you linked. |
| 21:40 | <Hixie> | what errors? |
| 21:41 | <Hixie> | (yeah, firefox is acting rationally. don't know what's up with chrome.) |
| 21:45 | <karlcow> | zewt: to be clearer, before DRM, I have an issue with copyright laws ;) |
| 21:46 | <karlcow> | And in a French context even more, not possible to put your own work in public domain. Legal silliness. :) |
| 21:53 | <internaut_jack> | Hixie, page doesn't load properly, get these in console: |
| 21:53 | <internaut_jack> | Uncaught RangeError: Maximum call stack size exceeded |
| 21:53 | <internaut_jack> | Could not send response: Cannot send a response more than once per chrome.extension.onRequest listener per document (message was sent by extension oiaejidbmkiecgbjeifoejpgmdaleoha). miscellaneous_bindings:124 |
| 21:53 | <internaut_jack> | Uncaught RangeError: Maximum call stack size exceeded |
| 21:53 | <internaut_jack> | In Chrome |
| 21:54 | <zewt> | looks like an extension problem, not to state the obvious |
| 21:57 | <internaut_jack> | zewt, Yes, but whatever that page depends on also breaks, putting this into the log: |
| 21:57 | <internaut_jack> | error: Uncaught RangeError: Maximum call stack size exceeded on line 90 |
| 21:57 | <internaut_jack> | rendering mode: BackCompat |
| 21:57 | <internaut_jack> | document has no title |
| 21:59 | <Hixie> | internaut_jack: o_O |
| 21:59 | <Hixie> | internaut_jack: sounds like you have some sort of broken extension that's messing with the page |
| 22:00 | <internaut_jack> | Hixie, still get these in the log using incognito, with no extensions: |
| 22:00 | <internaut_jack> | rendering mode: BackCompat |
| 22:00 | <internaut_jack> | document has no title |
| 22:02 | <zewt> | (i sure hope no browser is actually wasting people's time warning about a lack of title, heh) |
| 22:36 | <Hixie> | internaut_jack: yeah, you should get those, that's part of the info the live dom viewer reads out |
| 22:42 | <internaut_jack> | https://bugs.webkit.org/show_bug.cgi?id=112201 |
| 22:42 | <internaut_jack> | For those interested |
| 23:43 | <karlcow> | nooooooo "Polyglot: the final thread?" |
| 23:44 | <karlcow> | pushing slightlyoff on the edge of the final final final frontier of the universe ;) |