| 00:00 | <zewt> | i don't know in general, but i agree that having random people posting in GIGANTO HUGE TEXT (they're important people, folks!) is really annoying |
| 00:00 | <AryehGregor> | heycam, why does WebIDL seem to use TypeError for so many different things? AFAIK we have zero interop on what exception types to throw, so wouldn't it make the most sense to use different exception types for different types of errors? Like for passing too few arguments, at least -- that seems like it could benefit from a unique error type. |
| 00:00 | <zewt> | i think flowing email instead of forcing everything to 80-column (especially on mobile) is a major win, though, and basic formatting (italic, bold) |
| 00:01 | <TabAtkins> | zewt: Flowing is incompatible with using text-based quoting indicators. |
| 00:01 | <AryehGregor> | . . . maybe it's not so many places, actually. |
| 00:01 | <zewt> | (links, images) |
| 00:01 | <AryehGregor> | ES also uses TypeError a lot. |
| 00:01 | <zewt> | TabAtkins: no it's not; the renderer just needs to be a bit smarter--gmail does it fine |
| 00:01 | <AryehGregor> | But it doesn't seem to be the right type for too few arguments. |
| 00:02 | <TabAtkins> | zewt: Really? I occasionally see Gmail do dumb things with flowed text and >> quoting. |
| 00:02 | <zewt> | i'm not entirely sure what kind of magic gmail does |
| 00:03 | <TabAtkins> | I mean, it knows how to convert blockquotes into a proper plaintext. |
| 00:03 | <TabAtkins> | If everyone would just write in Markdown this would be easier. |
| 00:04 | <zewt> | i guess more specifically, flowed isn't enough for quotes; you need HTML's blockquote to supplement it |
| 00:04 | <TabAtkins> | Yeah. |
| 00:04 | <gavinc> | On decimals in durations... perhaps something along the lines of decimals can only be used in the final terminal? eg 1.5h makes sense 1.5h10m does not. Really any new field after a decimal doesn't make a whole lot of sense |
| 00:04 | <TabAtkins> | Or some other explicit indicator of start/stop quoting. |
| 00:05 | <zewt> | blockquote seems saner than > quoting in general, in particular because no matter how advanced human society gets, people will still feel the need to get "inventive" with quote markers |
| 00:05 | <zewt> | ("i don't like >, let's use # instead" STOP THAT) |
| 00:05 | <TabAtkins> | Or the person's initials as quote markers, urgh. |
| 00:06 | <zewt> | don't forget "You said:" |
| 00:06 | <zewt> | (... who?) |
| 00:07 | <Dashiva> | Don't forget forced line wrapping |
| 00:07 | <zewt> | talking about spec text is a whole lot easier with basic formatting, though |
| 00:07 | <TabAtkins> | Sure. |
| 00:07 | <zewt> | not being able to mimic spec rendering in email hurts |
| 00:07 | <TabAtkins> | All the formatting allowed in Markdown is useful without being obnoxious. |
| 00:08 | <zewt> | i wonder if there's a mystery firefox setting to disable pasting html |
| 00:14 | <AryehGregor> | Don't forget forced line wrapping that's then forced a second time so every line wraps to a second line that only has one word on it. |
| 00:15 | <AryehGregor> | Kind of like when the MTU decreases by a few bytes somewhere in the middle of transit. |
| 00:15 | <zewt> | (bleh, maybe i can disable it on gmail with some greasemonkey hackery; it's only gmail that it's a day-to-day headache with) |
| 00:20 | <AryehGregor> | "Due to a filter you created, this message was not sent to Spam." That needs a button saying "The filters were right, this isn't spam, try being smarter next time." |
| 00:21 | <Philip`> | Does Gmail actually learn from things you mark as spam/not-spam? |
| 00:21 | <AryehGregor> | I hope so. |
| 00:21 | Philip` | has never noticed an effect like that |
| 00:22 | <AryehGregor> | I'm guessing the effect isn't per-user. |
| 00:22 | <AryehGregor> | Or maybe it is. |
| 00:22 | <AryehGregor> | I don't know, I don't look at my spam folder much. |
| 00:23 | <AryehGregor> | But I'm sure it at least feeds back into whatever their global spam filter is. Like I bet if they add a new heuristic, they'll adjust the weight they give it based on what percentage of users change its results, or something. |
| 00:23 | <AryehGregor> | Isn't the classic way to do spam filtering a Bayesian filter that updates based on manual user corrections? |
| 00:23 | <TabAtkins> | Yup. |
| 00:23 | <AryehGregor> | If they did that or some variant but the weights were global instead of per-user, you wouldn't notice an individual effect from clicking Spam/Not Spam, but it would have an effect if enough users did it. |
| 00:24 | <AryehGregor> | Maybe an elaboration would have an extra per-user layer so your personal spam filter is more responsive to your changes. |
| 00:24 | <TabAtkins> | I wish/hope they do. |
| 00:24 | <AryehGregor> | I honestly have no idea, spam filtering is all voodoo magic. But surely you'd have no way of checking your filter's accuracy if not for the Spam/Not Spam buttons. |
| 00:25 | <TabAtkins> | I'm quite certain we use a Bayesian filter of some variety. |
| 00:25 | <zewt> | it's pretty annoying that gmail filters have no "mark as spam" option |
| 00:25 | <TabAtkins> | I'm hoping/wishing for a personalized filter layered atop the global one. |
| 00:25 | <AryehGregor> | zewt, . . . they don't? |
| 00:26 | <AryehGregor> | Oh, the filters. |
| 00:26 | <zewt> | nope; the closest is delete |
| 00:26 | <AryehGregor> | As in the things Gmail calls filters, not spam filters. |
| 00:26 | <AryehGregor> | Right. |
| 00:26 | <AryehGregor> | That would be nice. |
| 00:26 | AryehGregor | uses the "Don't mark as spam" feature for several filters |
| 00:26 | <zewt> | i havn't had too much trouble with false positives on gmail |
| 00:27 | <TabAtkins> | Other than the "mark everything from @google.com as spam" issue, me neither. |
| 00:27 | <AryehGregor> | I've had a few simple ones. |
| 00:27 | <TabAtkins> | And I have a fitler to prevent that now. |
| 00:27 | <AryehGregor> | Like yeah, @google.com gets marked as spam a lot. |
| 00:27 | <zewt> | i recently had "69% Discount! BUY VIGARA & CILAIS NOW!!! Next Day Delivery!" pass gmail's spam filter |
| 00:27 | <AryehGregor> | I wonder if it's due to bad SPF rules or something. I think I investigated that once. |
| 00:27 | <zewt> | how could they possibly identify *that* as spam? |
| 00:28 | <AryehGregor> | I've also had routine daily mailings from my servers (like logwatch) marked as spam sometimes. |
| 00:28 | <TabAtkins> | zewt: Too much spoofing, I suppose, and we *for some reason* don't use the existing verification systems. |
| 00:28 | <AryehGregor> | IIRC, once most of the logwatch mails I got were marked as spam, but I marked them all not spam a couple of times and they stopped being marked as spam, so maybe that's anecdotal evidence that it learns from mistakes like that. |
| 00:28 | <zewt> | gmail has more incentive to listen to you screaming "not spam" than "spam" |
| 00:29 | <zewt> | since false positives are much more dangerous than false negatives |
| 00:29 | <AryehGregor> | TabAtkins, what existing verification systems? SPF, which breaks forwarding? Or DKIM, which requires everyone sending mail from a domain to have that domain's private key? |
| 00:29 | <zewt> | i imagine that has to be pretty localized, though, or it'd be abusable (create accounts, send your spam to them, mark them not spam) |
| 00:30 | <AryehGregor> | Verification of the sender in SMTP is just completely broken, because of legacy constraints like mailing lists. |
| 00:30 | <TabAtkins> | I know nothing of email verification systems and their shortcomings. |
| 00:30 | <AryehGregor> | SPF and DKIM are great, if all your mail is being sent from servers you control. |
| 00:31 | <AryehGregor> | And not being forwarded or mangled. |
| 00:31 | <AryehGregor> | Otherwise, not so much. |
| 00:31 | <TabAtkins> | zewt: Makes sense. I suppose that using a personalize ham filter and a global spam filter works fine. |
| 00:31 | <TabAtkins> | Since you *always* want spam information to be globally contributed, I guess. |
| 00:31 | <zewt> | global spam filtering is also abusable, in the opposite way, so at least it probably has to be heavily diluted |
| 00:31 | <zewt> | ("hey guys, let's make gmail mark ebay as a spammer") |
| 00:31 | <TabAtkins> | Only with more difficulty, and hamminess is typically consulted before spamminess. |
| 00:32 | <zewt> | of course, there's subjectivity in there, too |
| 00:32 | <AryehGregor> | . . . why is Chrome so persistently bad at restoring tabs when you close multiple windows in succession? |
| 00:32 | <zewt> | for example, i consider mail from companies i've done business with that i didn't give them permission to use my email address for ("newsletters", "special offers") to be spam; some people don't |
| 00:32 | <AryehGregor> | Not only does it not restore any window other than the last you closed, it commonly forgets about the other window entirely. |
| 00:33 | AryehGregor | hopes he didn't have any important tabs that got eaten |
| 00:35 | <AryehGregor> | Would it be so hard for it to notice when I close two windows within three seconds of each other and restore both when I restart? |
| 00:35 | <AryehGregor> | Reliably? |
| 00:35 | AryehGregor | grumbles |
| 00:35 | <zewt> | firefox yells at you if you close a window with multiple tabs open |
| 00:35 | <AryehGregor> | The first time, until you uncheck the box. |
| 00:35 | <zewt> | there's sort of a disconnect in the way sessions work vs. the way chrome tries to look |
| 00:36 | <zewt> | eg. how chrome tries to look like a background system that's always present, and how people usually don't file->exit from chrome |
| 00:36 | <zewt> | where session restores tend to be tied to file->exit closing everything at once |
| 00:36 | <zewt> | it should probably at least have a "recently closed windows", which is restored with the session |
| 00:45 | AryehGregor | didn't realize you can use File->Exit to close everything at once |
| 00:45 | <AryehGregor> | That's a usable workaround, if it restores all windows automatically. |
| 00:45 | <paul_irish_> | AryehGregor: i use the Session Buddy extension which i set to autosave my windows |
| 00:45 | <heycam> | AryehGregor, JS itself tends to favour TypeError for those kinds of things (insufficient arguments, bad types, etc.) |
| 00:45 | <paul_irish_> | but also File ->Exit ya. |
| 00:46 | <heycam> | AryehGregor, which is why I went with it nearly everywhere |
| 00:52 | <jamesr_> | has anyone verified that Charles Pritchard isn't just a sophisticated n-gram email generation bot? |
| 00:58 | <Hixie> | ok for people following on at home i did a regen with some of the new text in the microsyntaxes section |
| 00:59 | <Hixie> | yearless dates (e.g. birthdays, 05-06): http://www.whatwg.org/specs/web-apps/current-work/#yearless-dates |
| 00:59 | <Hixie> | timezones as a separate concept: http://www.whatwg.org/specs/web-apps/current-work/#time-zones |
| 01:00 | <Hixie> | and durations: http://www.whatwg.org/specs/web-apps/current-work/#durations |
| 01:04 | <Hixie> | bbiab. |
| 01:05 | <mkanat> | Hixie: Hmm. I'm assuming Olsen timezones have already been discussed? |
| 01:07 | <kennyluck> | Hixie, "One or more digits followed by a U+004D LATIN CAPITAL LETTER M character, representing a number of hours." should read "number of minutes." |
| 01:23 | <zewt> | chrome doesn't implement the Worker interface inside workers? weird |
| 02:36 | <tantek> | mkanat Olsen style named timelines were previously rejected long ago from microformats' timezone microsyntaxes. |
| 02:37 | <mkanat> | tantek: Fair enough. I think they do make life easier for implementors who want perfect accuracy, but they're not going to be typed by most actual users. |
| 02:37 | <tantek> | The short version for why no Olsen named TZs is that people notoriously get them wrong especially with respect to DST |
| 02:37 | <mkanat> | As in, notoriously implement interpreting them improperly? |
| 02:38 | <tantek> | They dot actually make life easier for higher data quality - which is the right way to evaluate anything an author/coder might emit into HTML |
| 02:38 | <tantek> | s/dot/don't |
| 02:39 | <tantek> | Smart folks all the time write/say PDT when they mean PST and vice versa. |
| 02:40 | <mkanat> | Yes, but I was thinking the full Olsen zones, America/Los_Angeles and so on. |
| 02:40 | <mkanat> | I agree that the three-letter TZs are an abomination. |
| 02:40 | <tantek> | Better to address it with numerical precision upfront (with offset from Z) than provide the illusion of precision with named TZs |
| 02:41 | <tantek> | And it's yet another named registry dependency |
| 02:41 | <tantek> | Worse, one that's political and unpredictable |
| 02:42 | <tantek> | Never mind the DMCA takedown of the NIH FTP URL |
| 02:42 | <TabAtkins_> | Yeah, the city-based registry changes over time. |
| 02:43 | <mkanat> | I suppose numerical offsets do give you accuracy. |
| 02:43 | <tantek> | All those RFCs with references to Olsen now have broken links |
| 02:43 | <mkanat> | Even if the DST changeover goes to some other date in the future, your time is still accurate--it's just not in the TZ that that location would have, when you actually get to that date. |
| 02:44 | <mkanat> | I see the problems of trying to bake the Olsen DB into clients. |
| 02:45 | <zewt> | well, the biggest problem with named timezones is it's a moving target |
| 02:45 | <mkanat> | Right, that's the problem with baking it into clients. |
| 02:46 | <mkanat> | And people who want to use them on the server-side already have libraries for it that can emit times with numeric offsets if they want to send those to the client, so that does seem fine. |
| 02:50 | <tantek> | Mkanat, worse than baking into clients, with HTML/microformats it's a matter of baking into *documents* which must be much more reliable than clients. |
| 02:51 | <mkanat> | tantek: Yeah, that's a good point. |
| 02:59 | <tantek> | Also tried to send this earlier but I think I was already too far off the ground: |
| 02:59 | <tantek> | Hixie, fine with omitting fixed point numbers or now til examples documented on wiki, however we should be similarly conservative with out of order unit values etc until someone finds backward compat reasons/examples. |
| 03:00 | <TabAtkins_> | tantek: Don't quite agree. Allowing out-of-order unit values makes both parsing and generation somewhat easier. |
| 03:01 | <tantek> | Disagree because it makes simple transposition errors more difficult to detect |
| 03:02 | <TabAtkins_> | Hmm, transposition seems like a minor issue here. |
| 03:02 | <TabAtkins_> | Because the units are separate from each other by at least one digit. |
| 03:03 | <tantek> | Not that way |
| 03:03 | <tantek> | But like this |
| 03:03 | <tantek> | Writing 1m5h when 1h5m is intended |
| 03:03 | <tantek> | Also easy to miss that error web reviewing. |
| 03:04 | <TabAtkins_> | Hm, maybe. |
| 03:04 | <tantek> | Because people see the order of digits and assign relevance more to the order than to he unit suffixes |
| 03:06 | <tantek> | This is all about optimizing ease of authoring high quality data. |
| 03:07 | <tantek> | so i'd rather start with a more conservative syntax |
| 03:08 | <tantek> | Where errors are earlier / more easily detected and corrected |
| 03:09 | <tantek> | Speaking if errors - typing on an iPod sucks. I'm going to dinner and will resume later tonight in a laptop |
| 03:11 | tantek | didn't mean to have hat message be self-supporting. :/ |
| 03:11 | <TabAtkins_> | ^_^ |
| 03:49 | <erlehmann> | tantek, with “1h5m”, transposition errors can happen. so is the answer not something like “12:34”, where only order matters? |
| 04:11 | <tantek> | erlehmann: I'm considering exactly that for a potential separate duration attribute. |
| 04:12 | <erlehmann> | i see what you did there. |
| 05:56 | <Hixie> | ok. adding an element. |
| 05:56 | <Hixie> | step 1: adding a section for the element itself. |
| 05:59 | <Hixie> | step 2: updating the category lists to include the new element. |
| 05:59 | <Hixie> | pick an element with the same basic design (in this case <data>), and search the spec for mentions of that element in the category descriptions and copy what i did there. |
| 06:01 | <Hixie> | step 3: update images/content-venn.svg |
| 06:02 | <Hixie> | step 4: update the syntax section. not needed in this case as it's a "normal" element. |
| 06:02 | <Hixie> | step 5: update the phrasing element usage summary examples |
| 06:04 | <Hixie> | step 6: update the parser. unnecessary in this case as it's a "normal" element. |
| 06:04 | <Hixie> | step 7: add new examples and update existing ones that are affected by the new element. |
| 06:06 | <tantek__> | hey Hixie, I've been updating / tweaking the Time element wiki page regarding durations |
| 06:07 | <tantek__> | capturing a bunch of the things discussed in IRC |
| 06:13 | <Hixie> | step 8: update the rendering section. unnecessary in this case as there's no non-default rendering to speak of. |
| 06:14 | <Hixie> | step 9: update the obsolete section as appropriate. unnecessary in this case as I forgot to add <time> to that section when I dropped it. :-) |
| 06:14 | <Hixie> | step 10: update the indexes |
| 06:15 | <tantek__> | sounds like fun |
| 06:21 | <Hixie> | step 11: update the aria mappings. i believe there's nothing to map in this case. |
| 06:25 | <Hixie> | ok |
| 06:25 | <Hixie> | regen |
| 06:25 | <Hixie> | could do with more <data> examples now |
| 06:25 | <Hixie> | since i converted a lot of them back to <time> again |
| 07:00 | <rniwa> | Hixie: are you still there? |
| 07:00 | <Hixie> | yup |
| 07:01 | <rniwa> | Hixie: I have a question for you regarding accessKey content attribute |
| 07:01 | <rniwa> | Hixie: should accessKey content attribute simulate click upon key press? |
| 07:01 | <rniwa> | i.e. simulate mousedown, mouseup, & click |
| 07:01 | <rniwa> | or just click? |
| 07:01 | <Hixie> | it should do what the spec says :-) |
| 07:02 | <Hixie> | "When the user presses the key combination corresponding to the assigned access key for an element, if the element defines a command, the command's Hidden State facet is false (visible), the command's Disabled State facet is also false (enabled), and the element is in a Document, then the user agent must trigger the Action of the command." |
| 07:03 | <Hixie> | then see the subsections under http://www.whatwg.org/specs/web-apps/current-work/#commands for the specific definition of what the Action of an element is in any particular case |
| 07:03 | <Hixie> | (all elements with an assigned access key by definition have an Action) |
| 07:04 | <rniwa> | Hixie: ok, the spec appears to suggest we don't simulate mouedown/moseup |
| 07:05 | <rniwa> | just double-checking with you |
| 07:06 | <Hixie> | yeah nothing ever simulates mousedown/mouseup. The exact behaviour depends on what the element is. e.g. for <option> elements the event that eventually fires is 'change', for <div> elements the event that eventually fires is 'click', for <label> no event fires on the label but something might happen to the associated control, etc. |
| 07:07 | <erlehmann> | i want a novel by charles stross, where lawmakers of the future have the (?) embroidered on their clothing |
| 07:07 | <Hixie> | actually on <div> you'd see a 'focus' event also |
| 07:09 | <rniwa> | Hixie: right. |
| 07:09 | <rniwa> | Hixie: we might not be doing the right thing for focus at the moment |
| 07:09 | <rniwa> | but someone is working on accessKey content attribute |
| 07:09 | <rniwa> | so we might match the spec in near future :) |
| 07:09 | <rniwa> | Hixie: thanks for the help |
| 07:10 | <Hixie> | btw looking at the Action section it looks like the way it refers to the activation behaviour is a bit out of date |
| 07:11 | <Hixie> | so the exact text might change |
| 07:11 | <Hixie> | i think it won't affect the normative meaning |
| 07:12 | <Hixie> | hm. step 12: update the microdata algorithms to use <time> again. oops. |
| 07:12 | <Hixie> | tantek: if you're still around, check out the spec and let me know if the new text looks good to you |
| 07:14 | <Hixie> | http://www.whatwg.org/specs/web-apps/current-work/#the-time-element |
| 07:15 | <rniwa> | hm... |
| 07:16 | <Hixie> | hm? |
| 07:44 | <hsivonen> | I find it surprising that IE9 on Windows Phone doesn't have a JS JIT (according to http://www.sitepoint.com/mobile-ie9-differences/ ) |
| 07:45 | <hsivonen> | ooh. no Compatibility View, either |
| 07:45 | <annevk> | Hixie: no check-in yet? |
| 07:48 | <Hixie> | about to do it, unless you see a problem :-) |
| 07:49 | <annevk> | it doesn't say how to extract the datetime value |
| 07:49 | <Hixie> | "The datetime value of a time element is the value of the element's datetime content attribute, if it has one, or the element's textContent, if it does not." |
| 07:50 | <Hixie> | that not enough? |
| 07:51 | <annevk> | from a parser perspective there does not seem to be one algorithm for getting the value out |
| 07:51 | <Hixie> | "The time element represents its contents, with the added semantic that the the value given for the matching syntax in the list below, if any, is the meaning that corresponds to the element's contents." |
| 07:51 | <Hixie> | so you find which syntax it matches, if any, and that's what it represents |
| 07:53 | <Hixie> | admittedly, that makes the error handling parser for durations somewhat pointless |
| 07:54 | <annevk> | so you parse them as each of them and if one does not return an error you are okay? |
| 07:55 | <Hixie> | what the spec says now is that you check to see which syntax they conform to |
| 07:55 | <Hixie> | but i guess i can add a detector algorithm |
| 07:55 | <Hixie> | i'll do that tomorrow |
| 07:56 | <annevk> | ok, sounds good |
| 08:05 | <Hixie> | i wonder how to do this short of just having an algorithm that is all the algorithms together |
| 08:07 | <Hixie> | distinguishing a global date and time string from a local date and time string, for instance, without using some crude heuristic like "ends in a Z or has a + or - somewhere in it" |
| 08:12 | <annevk> | depends on the extensibility you want I suppose |
| 08:14 | <annevk> | http://xkcd.com/979/ I hate it when that happens :) |
| 08:33 | <annevk> | sweet http://blog.chromium.org/2011/11/lossless-and-transparency-encoding-in.html |
| 08:33 | <annevk> | hopefully Gecko will add it now |
| 08:50 | <hsivonen> | has Google explained why they aren't working with JPEG XR? |
| 08:51 | <hsivonen> | there might be good legal reasons |
| 08:51 | <hsivonen> | but without an explanation, it looks like it's Google doing its own thing instead of ISO standards |
| 08:56 | zcorpan | uncomments <time> in html-elements |
| 09:17 | <annevk> | hsivonen: prolly too hard, witness APNG |
| 09:59 | <erlehmann> | annevk, ENOCONTEXT what is too hard? |
| 10:53 | <hsivonen> | stuff I learned about URL parsing today: Three slashes after http: works in Firefox 8 but not in IE8. |
| 10:54 | <hsivonen> | works in Chrome, too |
| 10:59 | <smaug____> | annevk: we should kill also timeout for sync XHR |
| 11:01 | <annevk> | but timeout doesn't throw |
| 11:01 | <annevk> | at all |
| 11:01 | <annevk> | oh well, not really a great argument |
| 11:02 | <annevk> | smaug____: are you implementing the other exceptions? and changes to allow responseType to be set before open() etc. |
| 11:04 | <smaug____> | just reviewing a patch which throws when xhr is sync |
| 11:04 | annevk | hopes it's per spec |
| 11:04 | <hsivonen> | smaug____: should I prepare a patch to make HTML parsing unavailable in sync XHR? |
| 11:05 | <smaug____> | hsivonen: that would be good yes |
| 11:05 | <annevk> | hsivonen: it should still work in Workers though |
| 11:05 | <smaug____> | we really should try to kill sync XHR in Window context |
| 11:05 | <smaug____> | HTML Document in Workers? |
| 11:06 | <annevk> | oh right |
| 11:06 | <annevk> | though maybe, at some point |
| 11:08 | <hsivonen> | smaug____: OK. now that I've gotten some food, I'll try to track down the source of the error again... |
| 11:16 | <MikeSmith> | annevk: can you remind me please how I get http://html5.org/tools/web-apps-tracker to show all changes? |
| 11:16 | <MikeSmith> | nm |
| 11:16 | <MikeSmith> | http://html5.org/tools/web-apps-tracker?limit=-1 |
| 11:20 | <annevk> | sweet |
| 11:21 | <annevk> | now that's going to get hit often |
| 11:23 | <annevk> | someone tell me when html5.org goes down and I'll change the above URL to return "Damn it Mike™, you're awesome but did you have to expose this URL‽" |
| 11:23 | <zcorpan> | make it a rickroll redirect |
| 11:24 | <MikeSmith> | shit |
| 11:24 | <MikeSmith> | sorry man |
| 11:24 | <annevk> | heh |
| 11:24 | <MikeSmith> | change it to something else |
| 11:24 | <annevk> | I think we'll be fine |
| 11:24 | <annevk> | time will tell |
| 11:24 | <MikeSmith> | I'm managing to fuck up all kinds of things during the last two weeks |
| 11:24 | <MikeSmith> | I'm on a roll |
| 11:24 | <MikeSmith> | surprising even myself |
| 11:25 | <annevk> | more bad management if you ask me |
| 11:25 | <MikeSmith> | hard to know what lies ahead |
| 11:26 | <annevk> | maybe it's the cheese |
| 11:32 | <annevk> | zcorpan: http://lists.w3.org/Archives/Public/www-archive/2011Nov/0052.html |
| 11:34 | <annevk> | http://www.urbandictionary.com/define.php?term=blink182 "Was that blink 182 or blink 181? I lost count...fuck me gently with a chainsaw." |
| 11:35 | <annevk> | lol |
| 11:36 | <zcorpan> | annevk: great success |
| 12:01 | <zcorpan> | wonder if i should point out that a text/html; charset=windows-1252 resource can instantiate a worker with the url "#" which will interpret the same resource as a utf-8 script |
| 12:02 | <zcorpan> | (we even have a test case for this) |
| 12:26 | <ashaw> | I am wondering which IRC room works on developing the JS-API |
| 12:26 | <jgraham> | What js-api? |
| 12:27 | <annevk> | zcorpan: the point was more that it's not implemented apparently |
| 12:27 | <ashaw> | the Javascipt standard library |
| 12:29 | <zcorpan> | annevk: well it's implemented in opera |
| 12:30 | <annevk> | ashaw: are you talking about http://es5.github.com/ ? |
| 12:30 | <jgraham> | ashaw: Do you mean DOM? Or the "standard library" in ECMAScript? |
| 12:31 | <ashaw> | I do not know, in general I want to talk about window.crypto |
| 12:31 | <ashaw> | and other things arround it for the same sort of stuff |
| 12:32 | <annevk> | this would be okay for window.crypto I think |
| 12:32 | <jgraham> | ashaw: Here is as good a place as any I know, but I don't know how many of the relevant people hang out here |
| 12:32 | <annevk> | might not be anyone around to talk about it though |
| 12:33 | <ashaw> | I have implemented ECC crypto in javascript in order to try to make a start at an acceptable online voting system. |
| 12:33 | <ashaw> | however I have discovered a number of shortfalls that make this task, though possible, unpractical due to speed constraints. |
| 12:34 | <annevk> | you might be best of emailing to whatwg⊙wo |
| 12:34 | <annevk> | details here: http://www.whatwg.org/mailing-list |
| 12:34 | <annevk> | abarth can then reply whenever he's awake |
| 12:34 | <ashaw> | Ok, I'll email the mailing list. |
| 12:37 | <ashaw> | Basically, I need SHA, and a Bignum library over arrayBuffers and possibly support for loading a script into a web worker off a secure server so that data can be transfered only by a communication API |
| 12:37 | <ashaw> | Has any of this been brought up before? |
| 12:38 | <annevk> | Workers support a importScripts methods |
| 12:39 | <annevk> | method even |
| 12:40 | <ashaw> | is there any way that the main site can modify the web-workers context directly, and if so, can this be stopped. |
| 12:41 | <ashaw> | Also is there a way that window.crypto.random can be accessed from a web-worker |
| 12:41 | <zcorpan> | importScripts is same-origin-only though |
| 12:41 | <ashaw> | same-orogin-only is good |
| 12:41 | <zcorpan> | good :) |
| 12:42 | <zcorpan> | i thought "off a secure server" implied different-origin |
| 12:42 | <ashaw> | no-I ment an even stricter sense of same-origin |
| 12:43 | <ashaw> | i want a web worker that is locked up tight, and can-not be modified once started |
| 12:46 | annevk | isn't quite sure "One use case could be to replace everything in a document with new nodes:" is a use case zcorpan, but I'll allow it anyway |
| 12:47 | <annevk> | ashaw: I think only a Worker can modify a worker |
| 12:47 | <ashaw> | that same worker? or can one worker modify annother? |
| 12:48 | <annevk> | I'm going with "I don't think so" |
| 12:48 | <annevk> | you can only interact with a worker via postMessage() so I don't really see how |
| 12:49 | <ashaw> | Goooood. |
| 12:50 | <ashaw> | Now comes the question, as the cryptographically secure RNG has been put in window.crypto, there is no-way to access it from a web worker directly is there? |
| 12:50 | <ashaw> | Which is sad :( |
| 12:55 | <annevk> | well |
| 12:55 | <annevk> | it's on its own interface |
| 12:55 | <annevk> | I expect it to be exposed to workers as well |
| 12:55 | <annevk> | would make sense to me anyway |
| 12:55 | <annevk> | anyway, put that in your email |
| 12:56 | <annevk> | better to have it logged on list than here |
| 12:57 | <ashaw> | yeah |
| 12:58 | <ashaw> | I have been trying to figure our how to solve the problems mentioned here: http://rdist.root.org/2010/11/29/final-post-on-javascript-crypto/ |
| 13:01 | <annevk> | ok emailed improving the DOM rev 2 to www-dom |
| 13:01 | <annevk> | hopefully this one is a little better |
| 13:04 | <jgraham> | annevk: Why does remove take a ContentNode? |
| 13:06 | <annevk> | i'm a copy and paste man jgraham |
| 13:06 | <annevk> | better get used to it |
| 13:42 | <annevk> | smaug____: so timeout should throw on setting if the synchronous flag is set |
| 13:42 | <annevk> | smaug____: and open() should throw if timeout is set to something other than zero? |
| 13:42 | <annevk> | smaug____: see http://dev.w3.org/2006/webapi/XMLHttpRequest-2 for when withCredentials currently is supposed to throw |
| 13:42 | <annevk> | I will make that change now so I don't forget |
| 13:45 | <smaug____> | looking |
| 13:45 | <smaug____> | and yes, that timout handling sounds good |
| 13:48 | <Ms2ger> | http://lists.w3.org/Archives/Public/www-style/2011Nov/0389.html |
| 13:49 | <Ms2ger> | Björn seems even more snarky than usual, lately |
| 13:51 | <annevk> | I always wonder how he gets enough satisfaction about just being right and not having much of an effect on changing things around. |
| 13:52 | <annevk> | Assuming he's right most of the time, for now. |
| 13:54 | <Ms2ger> | Hmm, I wonder if Mozilla hackers are going to be confused by ContentNode |
| 13:55 | <smaug____> | Ms2ger: I'm sure we'll add ChromeNode :) |
| 13:55 | <Ms2ger> | nsIChrome? :) |
| 13:55 | <smaug____> | nsIDOMChromeNode |
| 13:55 | <smaug____> | nah, that would be visible to content |
| 13:55 | <smaug____> | nsIDOMContentNode |
| 13:56 | <smaug____> | oh, you meant nsIContent vs nsINode |
| 13:56 | <Ms2ger> | Yeah |
| 13:56 | <annevk> | Ms2ger: it's not an actual interface type though |
| 13:56 | <annevk> | Ms2ger: it's just IDL syntax |
| 13:56 | <Ms2ger> | Mm |
| 13:56 | <smaug____> | I wonder how many different meanings "content" has :) |
| 13:56 | <annevk> | at least, that's how I see it |
| 13:57 | <annevk> | so can name it FairyNode if that works better for everyone |
| 13:57 | <annevk> | because it won't make an iota of a difference |
| 13:57 | <annevk> | not sure I used "iota" right |
| 13:57 | <smaug____> | why *Node? |
| 13:57 | <smaug____> | DOMString isn't any kind of "Node" |
| 13:58 | <annevk> | in this context it becomes a Text node |
| 13:58 | <annevk> | but sure |
| 13:58 | <annevk> | we can call the thing FairyDust |
| 13:58 | <annevk> | as I said, does not matter |
| 13:58 | <smaug____> | DOMConstructionUnit or some such might describe it better |
| 13:59 | <smaug____> | well, not quite like that, something shorter and simpler |
| 13:59 | <annevk> | have fun bikeshedding |
| 13:59 | annevk | continues working on XHR |
| 13:59 | <smaug____> | thanks |
| 14:08 | <hsivonen> | annevk: I'm changing sync mode not to support HTML parsing |
| 14:08 | <hsivonen> | annevk: in order to avoid proliferating the sync evilness |
| 14:09 | <asmodai> | omg |
| 14:09 | <asmodai> | Opera 12 has decent MathML rendering :| |
| 14:09 | <annevk> | I'd sort of prefer to keep HTML/XML in feature parity |
| 14:09 | <annevk> | but okay |
| 14:09 | <annevk> | I mean technically it's a new feature, but making the bar to use HTML higher is very anti-platform |
| 14:10 | <annevk> | sync is also very anti-platform, but still |
| 14:10 | <jgraham> | asmodai: Hmm? Same as previous Operas afaik |
| 14:13 | <asmodai> | jgraham: Really? because last time around when I check on 11 it was not looking so decent? |
| 14:13 | <asmodai> | Unless my memory is deteriorating faster than I think it does. |
| 14:15 | <hsivonen> | hmm. turning off HTML parsing in sync mode make charset handling differ between sync and async... |
| 14:18 | <hsivonen> | discussions about spec organization so that normative references always point to more mature specs makes me sad |
| 14:18 | <hsivonen> | s/makes/make/ |
| 14:22 | <annevk> | hmm |
| 14:22 | <annevk> | smaug left |
| 14:22 | <annevk> | http://dev.w3.org/2006/webapi/XMLHttpRequest-2/#the-timeout-attribute |
| 14:22 | <annevk> | http://dev.w3.org/2006/webapi/XMLHttpRequest-2/#the-open-method |
| 14:40 | <annevk> | heh http://infrequently.org/2011/11/vendor-prefixes-are-a-rousing-success/ |
| 14:41 | <annevk> | now if Google/Apple sort out deprecating features in WebKit |
| 14:41 | <annevk> | I could buy into that |
| 14:41 | <annevk> | (and deprecating in a way that leads to actual removal) |
| 14:41 | <annevk> | if not, well... |
| 14:53 | <AryehGregor> | heycam|away, JS doesn't throw at all for insufficient arguments, does it? It just sets them to undefined? You're right that it seems to use TypeError for everything under the sun, though. |
| 14:56 | <AryehGregor> | It seems like it would be more desirable to throw distinct exceptions for too few arguments and wrong type, which is what Gecko currently seems to do. |
| 14:57 | <AryehGregor> | But I guess if browsers are willing to go with it, shrug. |
| 15:27 | <annevk> | AryehGregor: Opera throws WRONG_ARGUMENT_ERR or some such |
| 15:27 | <AryehGregor> | Yes. |
| 15:27 | <AryehGregor> | For both. |
| 15:27 | <AryehGregor> | It's a clearer error name than TypeError. |
| 15:27 | <annevk> | AryehGregor: oh okay :) |
| 15:28 | <annevk> | I think nobody has taken a critical look yet at that part of Web IDL |
| 15:28 | <annevk> | apart from maybe Microsoft but they don't give feedback until it is shipped typically |
| 15:32 | <jgraham> | I like TypeError |
| 15:32 | <jgraham> | I think aligining with javascript native APIs is a win |
| 15:33 | <jgraham> | Also, I notice that Alex doesn't really talk about the user or vendor point of view of prefixes, only the author point of view. It is pretty easy to say that prefixes are awesome when you work on webkit and are sure that everyone will include a -webkit- prefix always |
| 15:39 | <tantek> | Hixie: re: time element text update, minor tweak: |
| 15:40 | <tantek> | s/The datetime attribute must be present. Its value must be/The datetime attribute, if present, must be |
| 15:40 | <tantek> | since we explicitly allow <time>2011</time> etc. (even prefer) |
| 15:40 | <tantek> | to reduce DRY violations |
| 15:41 | <tantek> | also, example still to be fixed: |
| 15:41 | <tantek> | s/"2007-10-20">19/"2007-10-07">7 |
| 15:43 | <tantek> | regarding time zone offsets, experience has shown that *dropping* the ":" between the hours/minutes on timezone offsets helps better distinguish them from appearing like times |
| 15:44 | <tantek> | e.g. 07:00-0800 is more obviously 7am in PST than |
| 15:44 | <tantek> | 07:00-08:00 which looks like an interval of 7am to 8am. |
| 15:44 | <zewt> | whoever started with sub-hour timezone offsets needs to be shot into the sun |
| 15:44 | <tantek> | this is a human authorability/readability/verfiability concern |
| 15:45 | <tantek> | zewt I believe there is even a country that has a half-hour DST change. |
| 15:45 | <zewt> | tantek: -0800 is also just a common notation that people are familiar with |
| 15:45 | <tantek> | dbaron would know |
| 15:45 | <tantek> | yeah |
| 15:45 | <zewt> | i've heard of at least one place with a 15-minute offset :| |
| 15:46 | <tantek> | I'm fine with parsing with the colon as error recovery, however we should make timezone offsets valid only *without* the ":" between HH MM. |
| 15:46 | <annevk> | yeah, around India there's some fun stuff |
| 15:47 | <annevk> | India in fact has the half an hour |
| 15:48 | <annevk> | Bangladesh might be the one with three quarters? |
| 15:48 | <tantek> | Hixie, regarding year-less date parsing: |
| 15:48 | <tantek> | http://www.whatwg.org/specs/web-apps/current-work/#parse-a-yearless-date-string |
| 15:48 | <annevk> | oh, Nepal is |
| 15:48 | <annevk> | in Kathmandu it's 21:35 now |
| 15:48 | <tantek> | please explicitly allow the leading double-hyphen |
| 15:48 | <tantek> | making it optional is fine |
| 15:48 | <tantek> | e.g. |
| 15:48 | <tantek> | --11-18 |
| 15:49 | <tantek> | as that's the ISO8601 syntax for yearless dates |
| 15:49 | <annevk> | Chatham Islands in New Zealand have a similar weird offset |
| 15:49 | <annevk> | there it's 05:35 |
| 15:50 | <zewt> | into the sun. |
| 15:50 | <annevk> | if we have offsets at all it doesn't really matter how arbitrary they are |
| 15:57 | <smaug____> | "What front-ender in 2011 doesn’t test on at least two browsers?" I'm pretty sure in case of pages for mobile devices, it happens very often. |
| 16:01 | <jgraham> | Indeed. And even when they do it is probably stock iOS + stock android |
| 16:02 | <annevk> | apple.com/html5/ anyone? |
| 16:11 | <TabAtkins_> | Hixie: Somewhat confusingly, the <time> section says that @datetime is required, and then all of the examples don't use @datetime. |
| 16:12 | <annevk> | http://www.msnbc.msn.com/id/45306416/ns/health-diet_and_nutrition/ o_O |
| 16:12 | <annevk> | pizza a vegetable |
| 16:12 | <annevk> | wtf is wrong with that country |
| 16:12 | <zewt> | TabAtkins: fyi earlier <tantek> s/The datetime attribute must be present. Its value must be/The datetime attribute, if present, must be |
| 16:12 | <annevk> | I thought the EU had issues |
| 16:20 | <TabAtkins_> | zewt: Yeah. |
| 16:20 | <TabAtkins_> | annevk: It's called lobbying! Our government is basically run by corporations. |
| 16:20 | <divya> | TabAtkins: its just a better name for corruption |
| 16:21 | <divya> | and bribery |
| 16:21 | <TabAtkins_> | divya: Pretty much, yes. |
| 16:21 | <divya> | ?slap US politicians |
| 16:22 | <annevk> | lobbying makes some amount of sense (e.g. as wycats does on behalf of some set of developers), but this goes way beyond that |
| 16:22 | <divya> | this scares me SO MUCH http://jilliancyork.com/wp-content/uploads/2011/11/mubarak-and-us-presidents1.gif |
| 16:22 | <miketaylr> | the new national anthem: http://www.youtube.com/watch?v=wusGIl3v044 |
| 16:23 | <divya> | especially how Hosni looks unchanged over 40 yearss |
| 16:23 | <divya> | hahaha miketaylr |
| 16:23 | <timeless> | annevk: we tried to make ketchup a vegetable :) |
| 16:23 | <timeless> | divya: at least you can see it publicly :) |
| 16:24 | <divya> | timeless: whats the advantage? just despair? |
| 16:24 | <timeless> | you can openly see who is being corrupted |
| 16:24 | <timeless> | since it's in the public |
| 16:24 | <timeless> | whereas corruption in Finland occurs behind closed doors |
| 16:24 | <timeless> | you know it happened, but not how/to whom |
| 16:25 | <divya> | timeless: but both sucks anyway, we all end up getting screwed |
| 16:25 | <divya> | not like this public display of corruption makes any difference to the lives of ordinary people |
| 16:25 | <divya> | also i do not think corporations have altered the culture of a nation anywhere else as much as they have in the US |
| 16:26 | <timeless> | that's a function of time |
| 16:26 | <timeless> | and the fact that most other places already have preexisting corruption fighting to retain dominance :) |
| 16:26 | <timeless> | (hello Italy, Greece, Spain) |
| 16:27 | <divya> | i dunno timeless in india at least there are so many companies vying for favors that it ends up favouring nobody. |
| 16:27 | <divya> | which is great. except here in the US that is not the case. |
| 16:28 | <divya> | anywayysss sorry for ot convo :P |
| 16:28 | <tantek> | TabAtkins - see log for a bunch of <time> feedback/iteration |
| 16:29 | <timeless> | divya: what i've seen of india is that it has dangerous corruption at local levels |
| 16:29 | <timeless> | (see some illegal mining or something) |
| 16:29 | <timeless> | in the US, typically you can't get away w/ just corrupting local officials for that purpose |
| 16:29 | <divya> | timeless: totally, but it does not impact the whole nation like it does here. |
| 16:30 | <timeless> | it's all about Checks and Balances |
| 16:30 | <timeless> | our system requires bigger Checks :) |
| 16:30 | <divya> | hahahaha |
| 16:37 | <jgraham> | (in the particular case of school food, the US is hardly the only place with significant issues. There was an expose a few years back in Britain that showed schools spending 37p per pupil on food and not including anything that could remotely be descibed as healthy. I'm not sure the situation is much better in Sweden) |
| 16:38 | <Philip`> | (Fortunately we had Jamie Oliver to solve the nation's woes) |
| 16:41 | <jgraham> | (unfortunately he didn't. He did raise awareness of it as a problem though) |
| 16:44 | <tantek> | TabAtkins - also you may be interested in reviewing (and contributing to) the rationale for the data element: http://www.w3.org/wiki/User:Tantekelik/data_element |
| 16:44 | <tantek> | (per the emails you've been sending to public-html) |
| 17:31 | <JonathanNeal> | All right, lay it on me, if you must. Why are people hating on client-side LESS? |
| 17:34 | <jarek> | JonathanNeal: because it's over-complicated and there are no tools to debug it? |
| 17:34 | <JonathanNeal> | well, i appreciate hearing an answer, and i can understand the absense of debugging tools for the less itself. |
| 17:50 | <TabAtkins_> | tantek: Okay, I'll review when I get to the office and have the log to look at. |
| 17:52 | <tantek> | Thanks TabAtkins. Also feel free to join the data_element change proposal as a co-contributor assuming that's the approach you want to take. |
| 17:54 | <TabAtkins_> | Yeah, I'm about to edit the wiki page a bit. |
| 18:04 | <AryehGregor> | ES5 seems to leave typeof foo undefined if foo is a host object that doesn't implement [[Call]]. Are there real-world examples of such things that don't have a typeof "object"? |
| 18:05 | <AryehGregor> | Also: why is legacycaller legacy? |
| 18:05 | <AryehGregor> | Do we not want things implementing interfaces to be callable? |
| 18:09 | <annevk> | AryehGregor: correct |
| 18:09 | <AryehGregor> | Why not, out of curiosity? |
| 18:10 | <annevk> | getter is sufficient |
| 18:11 | <annevk> | caller is a legacy document.all thing |
| 18:11 | <annevk> | should rename constant to legacyconstant as well imo |
| 18:12 | <Hixie> | really? |
| 18:13 | <annevk> | whenever you want to use numeric constants, you want to use string enumeration instead |
| 18:14 | <AryehGregor> | Yeah, that would actually be a really good change. |
| 18:14 | <AryehGregor> | Hopefully it will scare spec writers away from using numeric constants in new interfaces. |
| 18:15 | <TabAtkins_> | Oh man, one can hope. |
| 18:16 | <annevk> | that doesn't mean btw that I think that whereever we have constants now we should introduce the equivalent with strings |
| 18:16 | <annevk> | just that we shouldn't propagate it further |
| 18:16 | <TabAtkins_> | Yes, many existing uses aren't worth bothering over. |
| 18:23 | <tantek> | Hixie, btw once that example fix is done, you can strike this paragraph: (The end date is encoded as one day after the last date of the event because in the iCalendar format, end dates are exclusive, not inclusive.) |
| 18:23 | <tantek> | since that's been fixed for a while in hCalendar :) http://microformats.org/wiki/dtend-issue |
| 18:29 | <AryehGregor> | WebIDL does not appear to define the [[Class]] of interface prototype objects. |
| 18:29 | <AryehGregor> | Is there something that implies it's implicitly "Object"? |
| 18:30 | <AryehGregor> | Oh: "If a value for the internal property [[Class]] is not given for a particular object, its value is implementation specific." |
| 18:30 | <AryehGregor> | Phooey. |
| 18:33 | <bga_> | hm |
| 18:55 | <Hixie> | tantek: you filed a bug about that right? at tpac? |
| 18:58 | <tantek> | yeah - the hCalendar example is a separate issue on the wiki page |
| 18:58 | <tantek> | I think you filed a bug about it at TPAC :) |
| 19:00 | <Hixie> | ok. so long as the issue is covered by a bug, i'll deal with it in a separate patch |
| 19:01 | <Hixie> | this patch is long enoug as it is |
| 19:02 | <Hixie> | annevk: i think the algorithm is just gonna be "try each of these algorithms in turn", because the alternative is either to make a really complicated hybrid algorithm for the whole thing (what UAs that care about performance will want to do), or a bunch of heuristics that will be a maintenance nightmare and that nobody will ever actually implement as written anyway |
| 19:06 | <AryehGregor> | Hixie, you use numeric constants in lots of new interfaces. You should really use strings instead. They're much nicer for authors. |
| 19:06 | <Hixie> | all those interfaces predate the change in prevailing opinion on the matter |
| 19:06 | <AryehGregor> | Are all of them implemented yet? |
| 19:06 | <Hixie> | file bugs if there are any not |
| 19:06 | <Hixie> | i'm happy to change htem |
| 19:09 | <AryehGregor> | http://www.w3.org/Bugs/Public/show_bug.cgi?id=14879 |
| 19:13 | <Hixie> | commented |
| 19:19 | <Hixie> | tantek: do you have a reference for the double hyphen thing for yearless dates? |
| 19:19 | <Hixie> | the wikipedia page says -- is used as an interval delimiter |
| 19:21 | <Hixie> | vcard seems to use wacked syntax without delimiters |
| 19:21 | <tantek> | really? that's odd. vCard4 certainly has it as an example for it http://tools.ietf.org/html/rfc6350#section-4.3 |
| 19:21 | <tantek> | yeah they leave out the delimiters between Y M D |
| 19:22 | <tantek> | (oddly) |
| 19:22 | <Hixie> | removing delimiters is a non-starter for <time> since it would lead to all kinds of ambiguities |
| 19:22 | <tantek> | well of course |
| 19:22 | <tantek> | it's worse than that |
| 19:22 | <Hixie> | so for now i'll punt on the -- thing |
| 19:22 | <tantek> | it hurts authorability |
| 19:22 | <Hixie> | for sure |
| 19:22 | <tantek> | hence the version I proposed with delimiters |
| 19:23 | <tantek> | --11-18 |
| 19:23 | <tantek> | instead of |
| 19:23 | <tantek> | --1118 |
| 19:23 | <tantek> | both are valid ISO8601 |
| 19:23 | <Hixie> | annevk: if you're still around, take a look and let me know if the rather naiive algorithm i put in is acceptable to you |
| 19:24 | <tantek> | which is why included --MM-DD in particular |
| 19:24 | <tantek> | in order to provide a microsyntax for month-day that was ISO8601 compatible |
| 19:25 | <Hixie> | ok screw it. i'm gonna find out if google actually has a copy of this damn standard and just read it. |
| 19:26 | <Hixie> | tired of reading second-hand accounts of it on the web :-) |
| 19:26 | <tantek> | Hixie, out of curiosity, why did you include the year-week microsyntax? (not that I oppose it, I just didn't find enough use-cases to really justify it_ |
| 19:26 | <tantek> | ) |
| 19:26 | <tantek> | I mean if you're going to include year-week, you might as well include year-ordinaldays |
| 19:26 | <tantek> | e.g. |
| 19:26 | <tantek> | 2011-322 |
| 19:26 | <Hixie> | you listed parity with <input type=foo> as a design policy, so i went with it |
| 19:27 | <Hixie> | (week dates are quite common in european business) |
| 19:27 | <tantek> | ah ok - wasn't sure if you considered that a strong enough reason - ok |
| 19:27 | <tantek> | interesting |
| 19:27 | <Hixie> | well i figured why not, it costs us virtually nothing at this point |
| 19:27 | <Hixie> | i mean, what's one more when there's half a dozen formats already |
| 19:27 | <tantek> | in that case, I'd say add ordinal dates also |
| 19:27 | <tantek> | as that would complete the wikipedia infobox examples |
| 19:28 | <tantek> | on the right here: http://en.wikipedia.org/wiki/ISO_8601 |
| 19:28 | <Hixie> | ordinal dates are too close to year-month imho. also, no <input type> equivalent, and not used as much as weeks as far as i'm aware. |
| 19:28 | <tantek> | http://en.wikipedia.org/wiki/ISO_8601#Ordinal_dates |
| 19:28 | <tantek> | and besides, everyone knows ordinal dates are the future, right TabAtkins? |
| 19:29 | <tantek> | there's no input type equivalent because ordinal dates are just another form of dates |
| 19:30 | <Hixie> | true. so there's not really a use case. |
| 19:30 | <Hixie> | and realistically, your bims ain't gonna take over any time soon :-P |
| 19:31 | <tantek> | my experience has been that bims have been useful for storage but not in publishing |
| 19:32 | <tantek> | the use cases for ordinals over normal dates are mostly just date-math related - easier to add / subtract # of days |
| 19:32 | <tantek> | or even weeks |
| 19:32 | <Hixie> | http://www.exit109.com/~ghealton/y2k/yrexamples.html#_International.ISO8601 is the first page i've found that supports your --month-day theory, but according to that page, -nn-nn is confusingly a _month_, not a yearless day... |
| 19:33 | <Hixie> | anyway, i'll add support for -- |
| 19:34 | <tantek> | it might make yearless dates less confusing for europeans |
| 19:34 | <tantek> | if a European sees 11-10 they erroneously interpret it as 11th of October |
| 19:34 | <Hixie> | as a european, i'd interpret it as november tenth |
| 19:35 | <tantek> | whereas if they saw --11-10 they may have a chance at noticing something is different than their locale-specific date-format and then see it correctly. |
| 19:35 | <Hixie> | yeah |
| 19:35 | <Hixie> | anyway, optional leading -- is now conforming and parsed |
| 19:35 | <Philip`> | If I saw --11-10 I wouldn't have a clue what it was and would have no idea where to look to find out |
| 19:35 | <Hixie> | ok unless anyone has anything else that needs changing, i'm gonna push it |
| 19:35 | <tantek> | again, this is about tweaking the syntax to increase data quality |
| 19:35 | <tantek> | Hixie - there were some complaints about using schema.org examples |
| 19:35 | <Hixie> | Philip`: what about if you saw "Birthday: <time>--11-10</time>" ? |
| 19:35 | <tantek> | I think it was on the bug on data |
| 19:36 | <Hixie> | tantek: if there's an open bug on something, i'll deal with that separately |
| 19:36 | <tantek> | Philip - as far as data quality is concerned, "wouldn't have a clue what it was" is better than silently misinterpreting it as a different value. |
| 19:36 | <Hixie> | none of the new examples are schema.org-related |
| 19:37 | <tantek> | Hixie, this one: itemtype="http://schema.org/BlogPosting"; |
| 19:37 | <tantek> | does anyone even use BlogPosting? |
| 19:37 | <tantek> | it's an unnecessary divergence from the Atom / hAtom vocabulary |
| 19:37 | <Philip`> | Hixie: I'm pretty sure I'd still have no idea |
| 19:37 | <tantek> | which btw, is in every copy of wordpress now |
| 19:37 | <tantek> | (hAtom that is) |
| 19:38 | <Philip`> | (I'd expect everyone to write birthdays as "10 Nov" or "10 November" anyway, not "11-10") |
| 19:39 | <tantek> | let me see if I get this right in microdata: |
| 19:39 | <tantek> | <article itemscope itemtype="http://microformats.org/profile/hatom">; |
| 19:39 | <tantek> | <h1 itemprop="entry-title">Small tasks</h1> |
| 19:39 | <tantek> | <footer>Published <time itemprop="published" datetime="2009-08-30">yesterday</time>.</footer> |
| 19:39 | <tantek> | <p itemprop="entry-content">I put a bike bell on his bike.</p> |
| 19:39 | <tantek> | </article> |
| 19:40 | <Hixie> | tantek: happy to add hAtom examples too, spec is trying to remain neutral on the question of vocabs. file bugs or send mails with suggested examples. |
| 19:40 | <tantek> | ah ok |
| 19:40 | <Hixie> | tantek: assuming there's a spec somewhere that defines the microdata vocabulary "http://microformats.org/profile/hatom"; and all its conformance rules, that looks right |
| 19:41 | <Hixie> | ok. i'm pushing the first draft of this new <time> element. |
| 19:41 | <tantek> | Hixie - the goal is to have the URL *be* the definition (or summary reference for) the spec |
| 19:42 | <tantek> | is there a distinction between name of vocabulary and root object in microdata? |
| 19:42 | <tantek> | or are they presume to be the same? |
| 19:42 | <Hixie> | tantek: that seems like a fine goal, though currently not an achieved one. |
| 19:42 | <Hixie> | "root object"? |
| 19:42 | <Hixie> | (not achieved for that to be a microdata vocabulary, i mean. looks like it defines a microformats one.) |
| 19:43 | <tantek> | right, the profiles need to be updated to be syntax independent |
| 19:43 | <tantek> | part of the goal of microformats-2, to separate vocabulary development so that they can be used independently of the microformats-2 syntax (and vice versa) |
| 19:44 | <tantek> | e.g. in microformats-2 it would look like this (URL not exist yet) |
| 19:44 | <tantek> | <article itemscope itemtype="http://microformats.org/profile/h-entry">; |
| 19:44 | <tantek> | <h1 itemprop="entry-title">Small tasks</h1> |
| 19:44 | <tantek> | <footer>Published <time itemprop="published" datetime="2009-08-30">yesterday</time>.</footer> |
| 19:44 | <tantek> | <p itemprop="entry-content">I put a bike bell on his bike.</p> |
| 19:44 | <tantek> | </article> |
| 19:45 | <Hixie> | tantek: for a vocabulary to be used for microdata, it needs to define conformance to the same level of detail as the vcard microdata vocabulary in the html spec |
| 19:45 | <Hixie> | tantek: which includes some microdata-specific concepts |
| 19:45 | <Hixie> | http://www.whatwg.org/specs/web-apps/current-work/#vcard |
| 19:46 | <tantek> | like "This vocabulary does not support global identifiers for items." ? |
| 19:47 | <Hixie> | pretty much every sentence in that section uses microdata-specific terminology |
| 19:47 | <Hixie> | ("item" is a special concept in microdata) |
| 19:47 | <tantek> | item/object same difference |
| 19:47 | <Hixie> | so long as somewhere you say that |
| 19:48 | <Hixie> | e.g. "when this vocabulary is used with microdata, conformance requirements corresponding to objects apply to items" or something |
| 19:48 | <tantek> | that's reasonable |
| 19:48 | <tantek> | btw if you're flattening vcard microdata in general (as you did with sex / gender-identity), you can drop all the "(inside n)" |
| 19:48 | <tantek> | ok |
| 19:49 | <tantek> | "n" is dropped in microformats-2 version of h-card and all its subproperties are flattened to just be properties of the "item" as you would say in microdata |
| 19:50 | <Hixie> | yeah |
| 19:50 | <Hixie> | i thought about changing that |
| 19:50 | <Hixie> | but i figured it'd be better to leave it so people could see how to spec that kind of structure |
| 19:50 | <Hixie> | since nobody uses this vocabulary anyway... :-) |
| 19:51 | <Hixie> | (if you want to define the "http://microformats.org/profile/hcard"; vocabulary such that people use it, i don't mind changing the URL in the HTML spec and adding a note saying that it's just an example vocab) |
| 19:51 | <tantek> | you could leave "org" as is if you want to leave the documentation of how to do that |
| 19:51 | <Hixie> | org has a different structure |
| 19:51 | <Hixie> | so they're both useful in their own way |
| 19:52 | <tantek> | aren't they just both list of subproperties? |
| 19:52 | <Hixie> | one is a fixed set, the other is more open-ended, iirc |
| 19:52 | <tantek> | they should both just be fixed sets |
| 19:53 | <Hixie> | org takes zero-or-more organization-unit properties |
| 19:53 | <Hixie> | ORG:name;unit;unit;unit |
| 19:53 | <Hixie> | or something |
| 19:53 | <tantek> | hmm, I thought commas delimited multivalues and ; delimited the subproperties |
| 19:54 | <tantek> | but I'd have to double-check vcard |
| 19:54 | <Hixie> | i dunno |
| 19:54 | <Hixie> | i'm just doing it from memory |
| 19:54 | <tantek> | would it be helpful for http://microformats.org/profile/hcard to provide the microdata-specific concepts you mention? |
| 19:55 | <Hixie> | hcard or hatom? |
| 19:55 | <tantek> | potentially both/all |
| 19:55 | <Hixie> | for hatom, sure, if it's to be used with microdata |
| 19:55 | <Hixie> | for hcard, also sure, if you want to take over speccing that vocab |
| 19:56 | <Hixie> | then i can change the html spec's vcard vocab to more obviously an example |
| 19:56 | <Hixie> | if you want to do that, send mail |
| 19:56 | <tantek> | why would you need to change the html spec's vocab? |
| 19:56 | <Hixie> | well we don't want two specs defining the same thing, especially if differently from each other :-) |
| 19:56 | <Hixie> | the vocabs in html are really only there to show how to define a vocab |
| 19:56 | <tantek> | I guess I'm not understanding - I was wondering if updating http://microformats.org/profile/hcard would help the example provided in the HTML spec. |
| 19:57 | <Hixie> | the urls are opaque per the spec |
| 19:57 | <Hixie> | you're not supposed to resolve them or anything |
| 19:58 | <tantek> | ah ok, so the example in the spec shows how to re-use a microformats profile/definition vocabulary to define a microdata vocabulary |
| 19:58 | <Hixie> | the url is the microformats url only because you asked it to be |
| 19:58 | <Hixie> | originally it was http://n.whatwg.org/something iirc |
| 19:59 | <tantek> | made sense to show basing on existing work |
| 19:59 | <Hixie> | yup |
| 19:59 | <tantek> | ok, I'll leave the current microformats profiles as-is then |
| 19:59 | <tantek> | because that better illustrates that process (of defining a new vocabulary based on an existing one) |
| 20:00 | <tantek> | the microformats-2 profile URLs will be different and contain microdata-specific language as needed |
| 20:00 | <tantek> | likely something like this (directly using their root class name / item) |
| 20:00 | <tantek> | http://microformats.org/profile/h-card |
| 20:00 | <Hixie> | 404 |
| 20:01 | <Hixie> | oh, you mean in the future |
| 20:01 | <Hixie> | got it |
| 20:01 | <Hixie> | sounds good |
| 20:15 | <annevk> | Hixie: you now have |
| 20:15 | <annevk> | + <li><p>If <span title="parse a month string">parsing a month |
| 20:15 | <annevk> | + string</span> from the element's <span>datetime value</span>, if |
| 20:15 | <annevk> | + The machine-readable equivalent is the <span |
| 20:16 | <annevk> | which seems wrong |
| 20:17 | <annevk> | otherwise it seems fine to me |
| 20:18 | <Hixie> | oops |
| 20:20 | <Hixie> | (i generated that section with some dubious regexps) |
| 20:20 | <Hixie> | (apparently got one wrong!) |
| 20:26 | <Hixie> | tantek: ok, i posted on the public-html thread proposing the <time> diff as the patch for your CP |
| 20:26 | <tantek> | Hixie, sounds good, I'll rereview. |
| 20:26 | <tantek> | so we're punting on a separate duration attribute then? |
| 20:27 | <Hixie> | *shrug*. imdb is already using datetime= for it. |
| 20:27 | <Hixie> | i don't have a strong view on the matter |
| 20:28 | <Hixie> | having mutually exclusive attributes has been kind of a pain in other contexts, fwiw (e.g. <meta) |
| 20:28 | <Hixie> | gotta go, lunch |
| 20:29 | <annevk> | hopefully the schema.org guys let not leak more ISO badness in there |
| 20:29 | <Hixie> | we can but hope |
| 20:34 | <tantek> | shall we pretend the "opening hours" problem isn't there? |
| 20:35 | <Hixie> | are they using <time> for that too? |
| 20:35 | <tantek> | yeah :( |
| 20:35 | <Hixie> | -_- |
| 20:35 | <tantek> | with a completely made-up syntax |
| 20:35 | Hixie | looks |
| 20:35 | <tantek> | basically, it looks like approach was, is it related to time? great, make something up and use the time element. |
| 20:36 | <Hixie> | well on the plus side it's distinguishable |
| 20:36 | <Hixie> | i say we ignore it for now, see how much uptake it gets |
| 20:36 | <Hixie> | and if it gets some, why not! |
| 20:36 | <tantek> | that's my preference for now too |
| 20:36 | <tantek> | and at least document alternatives to it |
| 20:36 | <tantek> | seems like opening hours should use multiple time elements |
| 20:37 | <tantek> | just as events do |
| 20:37 | <tantek> | etc. |
| 20:37 | <Hixie> | well we don't have any weekday things, and many elements is pretty verbose |
| 20:37 | <Hixie> | i don't see anything wrong with <data itemprop="openingHours" value="Tu,Th 16:00-20:00">...</data> though |
| 20:37 | <Hixie> | maybe i should add that example to the spec |
| 20:37 | <tantek> | lol - yeah |
| 20:38 | <tantek> | data is a good place to experiment with machine data extensions |
| 20:38 | <Hixie> | indeed |
| 20:38 | <tantek> | and then as you say we can better see if anything gets any uptake |
| 20:38 | <tantek> | without polluting existing elements |
| 20:39 | <TabAtkins> | tantek: Can you go respond to Sam that the current patch is fine? |
| 20:39 | tantek | will handle emails as they are queued. |
| 20:39 | <TabAtkins> | d'oh |
| 20:39 | <tantek> | I'll skip breakfast for IRC but not email :P |
| 20:40 | <TabAtkins> | What timezone are you in now? |
| 20:40 | <tantek> | -0800 ;) |
| 20:40 | <Hixie> | speaking of skipping breakfast, i need to go in to get mine. |
| 20:40 | <Hixie> | bbiab. |
| 20:40 | <TabAtkins> | tantek: Then it's not breakfast time, weirdo. |
| 20:40 | <TabAtkins> | You have already skipped it. |
| 20:40 | <tantek> | what Hixie said. bbiab. |
| 20:54 | <tantek> | Hixie, when you get back, finally reloaded the time element definition, just noticed the timezone examples still use the ':' syntax |
| 20:54 | <tantek> | <time>+00:00</time> |
| 20:54 | <tantek> | <time>-08:00</time> |
| 20:54 | <tantek> | without : is preferabl |
| 20:54 | <tantek> | <time>+0000</time> |
| 20:54 | <tantek> | <time>-0800</time> |
| 20:54 | <Hixie> | i'm running out the door as we speak but will look when i got back on |
| 20:54 | <Hixie> | afk |
| 20:55 | <tantek> | requires updating http://www.whatwg.org/specs/web-apps/current-work/#parse-a-time-zone-offset-component obv to allow 4 digits without the colon after the +/- is seen. |
| 20:55 | <tantek> | ok |
| 21:12 | <jgraham> | AryehGregor: +1 of FooPrototype if it is web compatible (which I assumed it was not but if IE and Opera both do it...) |
| 21:34 | <smaug____> | annevk: FYI, I'm adding telemetry probes to Gecko to check how often sync XHR is used. |
| 21:49 | <smaug____> | ojan: I was wondering about you performance concerns about DOM improvements since they don't apply to Gecko, but good that you corrected yourself :) |
| 21:49 | <ojan> | smaug____: yeah...it had been a while since i had last looked at the relevant webkit code |
| 21:49 | <smaug____> | the possible performance problem comes from Node vs DOMString as a parameter |
| 21:49 | <ojan> | smaug____: yea, but that's worth it IMO :) |
| 21:50 | <ojan> | smaug____: out of curiosity...what does gecko do to avoid appending a parent to it's child? do you walk up the ancestor chain? |
| 21:50 | <smaug____> | yeah, in general, I like the API |
| 21:51 | <ojan> | smaug____: webkit does...but having O(n) operations in append/etc sucks |
| 21:51 | <smaug____> | gecko does the same |
| 21:51 | <ojan> | smaug____: i'm wondering if there are clever ways we can optimize it out |
| 21:51 | <smaug____> | and yes, it suck |
| 21:51 | <ojan> | smaug____: rniwa had an idea that we could check if the new child had any children as a fast way out of a common case |
| 21:52 | <ojan> | i'm on the fence as to whether that's a good optimization or not though |
| 21:52 | <smaug____> | well, if one has extra memory to consume, you could store the "level" of DOM node in the nodes |
| 21:52 | <ojan> | smaug____: yeah...thought of that...memory aside, it means that when you move nodes you have to update the whole subtree |
| 21:52 | <smaug____> | but in gecko we don't want to increase the size of nodes |
| 21:53 | <smaug____> | though, I would need to check (or ask bz) how close we're size of cache lines |
| 21:53 | <TabAtkins> | Bloom filters solve everything. |
| 21:53 | <ojan> | i doubt we'd want to add to the size of node either |
| 21:53 | <smaug____> | ojan: well, for certain things you do need to update the whole subtree |
| 21:53 | <ojan> | TabAtkins: how would you use bloom filters here? |
| 21:53 | <smaug____> | like, whether the subtree is "in-document" |
| 21:54 | <ojan> | smaug____: that's true |
| 21:55 | <rniwa> | smaug____, ojan: we can "color" each tree with a unique value |
| 21:55 | <TabAtkins> | ojan: Fast-path for if the parent is in the subtree of its child. |
| 21:55 | <rniwa> | it won't solve the case where you're moving the node within the tree though... |
| 21:55 | <TabAtkins> | Or, rather, if the parent is in the ancestor chain of its child. |
| 21:56 | <rniwa> | smaug____, ojan: you could imagine that we can omit those O(n) checks if two nodes belong to a different fragment or document |
| 21:56 | <TabAtkins> | Or, arg, when doing B.appendChild(A), telling quickly if A is in the ancestor chain of B. |
| 21:56 | <TabAtkins> | And following up with an ancestor walk on positives. |
| 21:56 | <smaug____> | rniwa: well, you need to add some flags for colors, and that uses memory |
| 21:57 | <rniwa> | smaug____: I suppose. |
| 21:57 | <rniwa> | smaug____: but we already have a pointer for document fragment / document, right? |
| 21:57 | <TabAtkins> | Adding the filter would be additional memory, though. |
| 21:57 | <rniwa> | TabAtkins: how would you efficiently implement that filter? |
| 21:58 | <smaug____> | there is a pointer to parent, and to ownerdocument (not directly) |
| 21:58 | <TabAtkins> | rniwa: it's essentially identical to the descendant-combinator fast path we use now. |
| 21:58 | <TabAtkins> | And, hm, if we already have that, perhaps we can reuse it. |
| 21:58 | <rniwa> | TabAtkins: what's "descendant-combinator fast path"? |
| 21:59 | <TabAtkins> | rniwa: It's what I just described. ^_^ Every element has a bloom filter of its ancestors, so you can more quickly tell if a given element is in the ancestor chain. |
| 21:59 | <rniwa> | TabAtkins: WebKit implements this? |
| 22:00 | <TabAtkins> | rniwa: Yeah. |
| 22:00 | <rniwa> | TabAtkins: that's a big news to me |
| 22:00 | <rniwa> | TabAtkins: where is this implemented? |
| 22:00 | <Philip`> | TabAtkins: Doesn't that mean you still have an O(n) cost to update all the filters when reparenting a subtree? |
| 22:01 | <TabAtkins> | rniwa: http://peter.sh/2011/02/unspoofable-infobars-fast-descendant-selectors-and-the-web-inspector-api/ |
| 22:01 | <ojan> | TabAtkins: that fast path only applies during parsing i believe |
| 22:01 | <TabAtkins> | Philip`: Probably, yeah. |
| 22:01 | <ojan> | TabAtkins: we don't keep it around |
| 22:02 | <TabAtkins> | ojan: Ah, kk. |
| 22:02 | <ojan> | TabAtkins: we have a single bloom filter that we update as we add/remove elements during parsing, afaik |
| 22:02 | <ojan> | TabAtkins: ignoring memory, having a bloom filter per node has the problem of needing to update the entire subtree when you move nodes around |
| 22:03 | <rniwa> | TabAtkins: I don't think this is applicable for DOM operations |
| 22:03 | <ojan> | rniwa: yeah...we could check that the documents are the same...but i'm not sure how much that buys us for the common cases... |
| 22:03 | <rniwa> | TabAtkins: it's about selectors |
| 22:03 | <TabAtkins> | True that. |
| 22:04 | <rniwa> | ojan: right, for that reason (slow update), I don't think we can bloom filter for each node |
| 22:04 | <ojan> | rniwa: welll, it could serve the same purpose for DOM operations i think |
| 22:04 | <smaug____> | ah, antti implemented boom filters |
| 22:04 | <rniwa> | also, it'll consume SO MUCH memory |
| 22:04 | <jgraham> | I would have thought that the memory cost of storing the filters was reason enough not to use them |
| 22:04 | <ojan> | it is |
| 22:04 | <ojan> | bloom filters are not happening |
| 22:04 | <rniwa> | jgraham: yes |
| 22:05 | <ojan> | webkit's use of them is very limited |
| 22:05 | TabAtkins | wants to use bloom filters for everything. |
| 22:05 | <rniwa> | we're already getting complaints about how big Node object is |
| 22:05 | <rniwa> | so there's no way we can store bloom filter for each node |
| 22:05 | <rniwa> | on the other hand, in common case |
| 22:05 | <rniwa> | you end up adding a bunch of nodes to the same parent |
| 22:05 | <smaug____> | yeah, same with Gecko. It is hard to add new stuff to Node |
| 22:06 | <rniwa> | so maybe we can optimize that case |
| 22:06 | <jgraham> | Same hre, I think |
| 22:06 | <jgraham> | *here |
| 22:06 | <ojan> | rniwa: that's *a* common case |
| 22:06 | <smaug____> | although, traditionally Gecko's Node has been more light weight than webkit's |
| 22:06 | <ojan> | rniwa: i'm not sure it's the only one though |
| 22:06 | <smaug____> | but we've been adding new stuff to Node |
| 22:06 | <rniwa> | ojan: yeah, I think we need to cherry-pick those common cases and optimize for them |
| 22:06 | <rniwa> | ojan: I don't think we can solve this problem in general |
| 22:07 | <ojan> | rniwa: yeah...but if you get your common cases wrong, then you end up making things slower :) |
| 22:08 | <ojan> | rniwa: the hard part there if finding a representative subset of what real world dom usage is like == very hard |
| 22:08 | <rniwa> | ojan: don't think so. adding 4-5, or even 10, constant checks is much better than running O(n) algorithm |
| 22:09 | <ojan> | rniwa: not if you have to do the O(n) algorithm as well |
| 22:09 | <rniwa> | ojan: right, so we should add checks to determine cases where O(n) algorithm is not nded |
| 22:09 | <rniwa> | needed* |
| 22:09 | <rniwa> | of course, it'll be pointless if the algorithm to determine that itself is O(n) |
| 22:10 | <rniwa> | but I'm all for adding constant checks to avoid running O(n) algorithm |
| 22:11 | <jgraham> | The point is that unless the cases are common enough you have to do the checks and run the algorithm anyway. But it seems like there should be some common cases here |
| 22:11 | <rniwa> | jgraham: right. |
| 22:11 | <rniwa> | jgraham: I think in practice, we can measure the performance on gmail, facebook, etc... |
| 22:11 | <rniwa> | because they tend to do a lot of DOM operations |
| 22:12 | <ojan> | don't get me wrong...i support doing this...it will just need to be backed up buy good data on the effects on a number of top sites |
| 22:12 | <jgraham> | Right, one can certianly imagine seeing how often some easy cases are hit |
| 22:12 | <rniwa> | jgraham: yeah |
| 22:12 | <rniwa> | jgraham: we could add some logging mechanism and run it for one week while using gmail, facebook, etc... |
| 22:13 | <rniwa> | and see how common each case is |
| 22:13 | <Philip`> | Won't the common cases be that the DOM trees are very shallow, so the O(n) cost is negligible? |
| 22:13 | <rniwa> | Philip`: the problem is that we normally go up |
| 22:13 | <rniwa> | Philip`: i.e. parent -> parent's document |
| 22:14 | <rniwa> | Philip`: as supposed to looking through the inserted subtree |
| 22:14 | <Philip`> | Usually the documents would be very shallow too, I'd guess |
| 22:14 | <rniwa> | Philip`: and in practice, the inserted subtree tends to be shallow |
| 22:14 | <rniwa> | Philip`: don't think so |
| 22:14 | <jgraham> | Well it depends what you mean |
| 22:14 | <rniwa> | Philip`: I think we allow it to be at most 512 nodes deep |
| 22:15 | <jgraham> | Right, hundreds of nodes is atypical |
| 22:15 | <rniwa> | that's A LOT of nodes to check |
| 22:15 | <jgraham> | But a few tens of nodes might be common |
| 22:15 | <Philip`> | "at most" doesn't sound like the common case |
| 22:15 | <rniwa> | also the problem is cache locallity |
| 22:15 | <rniwa> | if we go up in the tree, then we'll be pulling those objects into registry in order to walk through the tree |
| 22:16 | <rniwa> | and that might reduce the cache locality |
| 22:16 | <smaug____> | TabAtkins: just curious, how does the webkit patch handle the false positive cases? |
| 22:16 | <smaug____> | or does it not need to |
| 22:16 | <rniwa> | in modern processors, this has a significant performance impact |
| 22:16 | <smaug____> | or does it just not care |
| 22:16 | <rniwa> | in fact... if one of elements up in the hierarchy, e.g. document ends up having a really big vtable |
| 22:16 | <rniwa> | you may end up invalidating a lot of cache |
| 22:17 | <rniwa> | though don't think webkit currently calls any virtual functions in appendChild, insertBefore, etc... |
| 22:17 | <rniwa> | virtual functions are evil LOL |
| 22:17 | <WeirdAl> | not as evil as eval |
| 22:18 | <rniwa> | WeirdAl: yeah, they're only 1 edit-distance away from each other |
| 22:18 | <smaug____> | virtual methods are indeed bad, really bad |
| 22:18 | Philip` | wonders if the parent/child pointers could be stored separately from the actual node data, so you can fit more of them into a cache line |
| 22:18 | <Philip`> | (if that's the problem) |
| 22:18 | <rniwa> | Philip`: I had that idea as well |
| 22:18 | <rniwa> | Philip`: but then looking through this table will be an issue |
| 22:18 | <ojan> | smaug____: the bloom filter is just used as a fast rejection |
| 22:18 | <smaug____> | ah |
| 22:18 | <rniwa> | Philip`: and in practice, you tend to access lots of data in one node object |
| 22:19 | <rniwa> | so not sure if that really improves the performance much |
| 22:19 | <rniwa> | it'll be really good to collect stats as ojan suggested |
| 22:20 | <rniwa> | some time in near future |
| 22:20 | smaug____ | is about to collect data about innerHTML usage |
| 22:20 | <ojan> | rniwa: you could just create a locally intrumented webkit and load a few top sites |
| 22:20 | <rniwa> | I might just do that myself :P |
| 22:20 | <rniwa> | ojan: yeah |
| 22:20 | <ojan> | smaug____: to what end? |
| 22:20 | <rniwa> | ojan: that's what I'm thinking |
| 22:20 | <smaug____> | ojan: basically to check what kind of data is set to innerHTML |
| 22:20 | <rniwa> | smaug____: yeah, that's also good thing to gather stats for |
| 22:21 | <smaug____> | whether it is short strings or markup or what |
| 22:21 | <rniwa> | smaug____: I think developers know that innerHTML is faster than inserting indivisual node |
| 22:21 | <smaug____> | (using telemetry) |
| 22:21 | <rniwa> | smaug____: so a lot of them use innerHTML instead of DOM methods |
| 22:21 | <rniwa> | smaug____: length? |
| 22:21 | <rniwa> | smaug____: or actual markup? |
| 22:21 | <smaug____> | well, in the old days DOM used to be a lot slower in all the browsers |
| 22:22 | <rniwa> | I'd be interested in knowing how many nodes are added per innerHTML |
| 22:22 | <rniwa> | and if people are calling innerHTML in consecutive manner without triggering layout |
| 22:22 | <rniwa> | e.g. |
| 22:22 | <rniwa> | for (...) innerHTML += ... |
| 22:22 | <smaug____> | rniwa: probably length, and whether short strings contain markup |
| 22:22 | <rniwa> | if consecutive concat to innerHTML is common |
| 22:22 | <rniwa> | we can probably lazily evaluate innerHTML |
| 22:23 | <rniwa> | though authors may cache things themselves if they are using innerHTML for speed |
| 22:23 | <smaug____> | that is quite hard |
| 22:23 | <rniwa> | may already* |
| 22:23 | <smaug____> | especially if you have mutation event listeners |
| 22:23 | <rniwa> | smaug____: yeah, on my second thought, lazily evaluating them might be tricky |
| 22:23 | <rniwa> | yeah :( |
| 22:23 | rniwa | hates mutation events |
| 22:24 | smaug____ | is still on progress to get MutationObserver done for Gecko |
| 22:24 | <rniwa> | smaug____: or if the inserted node pulled resources |
| 22:24 | <rniwa> | smaug____: or worse yet, script elements... |
| 22:24 | <smaug____> | (if I could focus only doing that...) |
| 22:25 | <annevk> | ojan: btw, you can implement it as a different method on Document and Element/DocumentFragment |
| 22:25 | <rniwa> | anyways, I'm planning to spend my Q1 improving webkit's dom code |
| 22:25 | <annevk> | ojan: we could even define some methods specially as such |
| 22:25 | rniwa | wants fast/slim DOM |
| 22:26 | <rniwa> | not slow/fat DOM |
| 22:26 | smaug____ | wants DOM implemented in JS :) |
| 22:27 | <rniwa> | smaug____: doesn't IE do that? |
| 22:27 | <Philip`> | Implementing DOM in JS and worrying about cache locality seem kind of completely opposing viewpoints :-) |
| 22:27 | <ojan> | annevk: yup |
| 22:28 | <ojan> | annevk: interestingly...webkit doesn't let you append a DocumentType if it's already in the DOM |
| 22:28 | <smaug____> | rniwa: really? I thought you need Proxies et al to implement DOM in JS, and IE doesn't, IIRC, have Proxy objects |
| 22:28 | <annevk> | ojan: oh, just saw your other email |
| 22:28 | <ojan> | annevk: i don't think the spec requires that though |
| 22:28 | <ojan> | annevk: so, i'm gonna see if i can remove that check |
| 22:28 | <annevk> | ojan: I think it does |
| 22:28 | <smaug____> | Philip`: JS JITs could optimize many things |
| 22:28 | <ojan> | annevk: oh...maybe i misread |
| 22:28 | <smaug____> | Philip`: also, JS is a lot safer language than C++ |
| 22:29 | <annevk> | ojan: http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html#concept-node-pre-insert see 4.4 |
| 22:29 | <ojan> | anoh isee...it's actually step 5, no? |
| 22:29 | <smaug____> | writing security bugs in C++ is way too easy |
| 22:30 | <ojan> | annevk: i see...it's actually step 5, no? |
| 22:30 | <annevk> | ojan: step 5 is for when you append to non-Document nodes |
| 22:30 | <ojan> | annevk: right...that's the case i'm talking about |
| 22:30 | <rniwa> | smaug____: yeah, dynamic optimization can do a whole lot |
| 22:31 | <annevk> | oh yeah that should fail in general |
| 22:31 | <annevk> | because you put in the wrong place |
| 22:31 | <ojan> | annevk: i believe webkit will let you append a DocumentType to an Element if it's not already in the DOM |
| 22:31 | <annevk> | ooh |
| 22:31 | ojan | goes to test |
| 22:31 | <rniwa> | smaug____: but we can't write layout code in javascript |
| 22:31 | <ojan> | sigh...now i have to remember how to make documenttype nodes |
| 22:32 | <annevk> | document.createDocumentType |
| 22:32 | <rniwa> | ! |
| 22:32 | <annevk> | euh sorry |
| 22:32 | <rniwa> | we have a method on document just to create doctype? |
| 22:32 | <annevk> | document.implementation.createDocumentType() |
| 22:32 | <annevk> | http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html#dom-domimplementation-createdocumenttype |
| 22:32 | <annevk> | rniwa: worse |
| 22:32 | <rniwa> | :( |
| 22:32 | <annevk> | rniwa: it's on document.implementation |
| 22:33 | <ojan> | annevk: nm...webkit seems to throw an error |
| 22:33 | <rniwa> | wtf |
| 22:33 | <ojan> | annevk: that was the check i was hoping we could get rid of |
| 22:33 | <ojan> | annevk: i don't really care if developers put/move documenttype nodes in their DOM |
| 22:33 | <ojan> | annevk: as long as we spec it that only the top-level node affects the actual compatMode |
| 22:34 | <annevk> | you could get rid of that check at that level, but you'd still need the check somewhere |
| 22:34 | <ojan> | annevk: it's something developers will basically never do...so it's worth getting rid of the check |
| 22:34 | <ojan> | annevk: why do you need the check at all? |
| 22:34 | <annevk> | oh |
| 22:35 | <annevk> | but you also need to check for Document and |
| 22:35 | <ojan> | annevk: in teh case of appending to a Document, there's a whole different set of rules and complications |
| 22:35 | <ojan> | annevk: but for the case of appending to an Element |
| 22:35 | <ojan> | annevk: i don't see why we don't just allow it |
| 22:35 | <annevk> | element.append(document) is what I meant |
| 22:35 | <annevk> | DocumentType is not the only node not allowed there |
| 22:36 | <ojan> | annevk: interesting...i forget how webkit handles that... |
| 22:36 | <annevk> | and there's Attr too |
| 22:36 | <annevk> | in your current impl |
| 22:37 | <annevk> | and prolly ShadowRoot? |
| 22:37 | <ojan> | annevk: interesting...i think this webkit code is just dumb actually |
| 22:38 | <rniwa> | ojan: I don't think those constant-time checks is a big of a deal |
| 22:38 | <ojan> | the "isChildTypeAllowed" call is what should deal with documenttype nodes...so we should be able to kill that if-check |
| 22:38 | <rniwa> | ojan: in fact, we could add a special node-flag to do this in constant time |
| 22:39 | <ojan> | rniwa: they're not as big a deal as the O(n) checks, but every branch we can get rid of adds up for such a performance-sensitive codepath |
| 22:39 | <rniwa> | ojan: but we can combine all those checks into one check |
| 22:39 | <rniwa> | ojan: because we can just do bitwise and |
| 22:39 | <rniwa> | ojan: in practice, function calls would cost us much more than those node-type checks |
| 22:40 | <rniwa> | ojan: checking a node-type is extremely efficient in webkit |
| 22:40 | <rniwa> | ojan: checking tagname is slower but none of the checks we're talking here involves checking a particular tag name |
| 22:40 | <rniwa> | so I don't think this would be an issue for us |
| 22:40 | <ojan> | rniwa: as i read the code right now...that if-check is actually completely rendudant with the existing isChildTypeAllowed call |
| 22:41 | <rniwa> | I see |
| 22:41 | <ojan> | i might be reading the code wrong though |
| 22:41 | <rniwa> | I actually bet that calling that function itself is much more expensive than any of the checks we do |
| 22:41 | <rniwa> | if it's not inlined |
| 22:42 | <rniwa> | I think any gains we get from optimizing those constant checks will be completely dwarfed by all function calls involved in binding code |
| 22:43 | <rniwa> | not that I'm opposed to make them faster |
| 22:43 | <rniwa> | but I don't think we should make the spec more permissive just to get rid of content-time node-type checks |
| 22:45 | <ojan> | i've given up on the spec changes... |
| 22:45 | <ojan> | which is to say, i don't think we'd gain much by changing the spec |
| 22:45 | <ojan> | if anything |
| 22:45 | <ojan> | but...there might be room for optimizing the webkit code |
| 22:46 | <rniwa> | ok. I guess I misunderstood you then |
| 22:46 | <rniwa> | ojan: definitely! |
| 22:46 | <ojan> | rniwa: no...you understood me right...i just changed my thinking on it :) |
| 22:46 | <rniwa> | k |
| 22:46 | <annevk> | the only potential room for improvement to the spec is that ele.append(DocumentType) would throw at the same point ele.append(Range) would throw |
| 22:47 | <annevk> | but at some point you got to check that the right object is actually passed |
| 22:47 | <ojan> | annevk: true |
| 22:58 | <ap> | Hixie: does HTML5 parser (still) disallow surrogates in numeric entities (such as ��)? |
| 23:04 | <Hixie> | yes |
| 23:04 | <Hixie> | ewll |
| 23:04 | <Hixie> | well |
| 23:04 | <ap> | Hixie: this used to work in Gecko and in WebKit, and I just got a bug |
| 23:04 | <Hixie> | the parser doesn't allow or disallow anything |
| 23:04 | <Hixie> | bu the syntax does |
| 23:05 | <ap> | Hixie: the parser converts these to U+FFFD |
| 23:05 | <Hixie> | that appears to be consistent with the spec (http://www.whatwg.org/specs/web-apps/current-work/#tokenizing-character-references) |
| 23:08 | <ap> | Hixie: so I sent that bug back for now, but I don't have a great explanation why we had to break this. It worked in at least two engines, and appeared useful |
| 23:08 | <Hixie> | why is it useful? |
| 23:08 | <Hixie> | just encode the actual character |
| 23:08 | <Hixie> | surrogates are a UTF-16 feature |
| 23:09 | <ap> | Hixie: in that some dumb perl script had more chance of encoding non-ASCII correctly. for some people, lots of people don't want to transfer non-ASCII |
| 23:09 | <ap> | for some reason |
| 23:09 | <TabAtkins> | ap: He meant use the escape for the actual character. |
| 23:09 | <roc> | oh dear, bz used the classic "with all due respect" -> "with absolutely no respect" |
| 23:09 | <Hixie> | ap: supporting surrogates would be like supporting é for é |
| 23:10 | <ap> | TabAtkins: like 😒 ? that's what I've been responding to. A dumb script won't do that |
| 23:10 | <Hixie> | ap: just use the actual unicode codepoint |
| 23:10 | <Hixie> | ap: why would a dumb perl script ever see utf-16? perl uses utf-8. |
| 23:10 | <Hixie> | tantek: i updated the spec to make : optional in time zones |
| 23:11 | <ap> | Hixie: practically, lots of software can handle UTF-16, but it's a tiny minority that works with non-BMP characters correctly |
| 23:11 | <ap> | Hixie: I entirely share your vision of what's right |
| 23:12 | <Hixie> | my recommendation is to get people to ignore UTF-16 entirely |
| 23:12 | <tantek> | Hixie - thanks re: tz |
| 23:12 | <Hixie> | honestly if we could drop utf-16 support the way we dropped utf-32 support, i'd be all over it |
| 23:12 | TabAtkins | still has a soft spot for utf-32. |
| 23:12 | <tantek> | The time-zone offset examples should show/prefer without : also |
| 23:13 | <Hixie> | TabAtkins: a pretty wide one i would assume :-P |
| 23:13 | <TabAtkins> | Hixie: Narrower than my ints, at least. |
| 23:13 | <ap> | Hixie: anyway, I'm not asking to revert the spec to previously interoperable behavior at this point. I'd love to have a better explanation of why we broke this, which I don't. |
| 23:14 | <Hixie> | tantek: i made them use a variety (though i think most still have the colon), but i'll bear that in mind when adding more examples |
| 23:14 | <tantek> | ideally the examples should be exemplary |
| 23:14 | <tantek> | to teach authors well |
| 23:14 | <Hixie> | ap: the real reason is probably that i didn't even think to test it, because i had a lapse of judgement in which i assumed browsers wouldn't do something so silly |
| 23:15 | <tantek> | especially the time-zone by itself examples |
| 23:15 | <Hixie> | tantek: when it comes to syntax, the examples are intentionally varied in their use of syntax to indicate that all valid syntaxes are equally valid |
| 23:15 | <Hixie> | tantek: (this applies to everything, not just date formats) |
| 23:17 | <tantek> | I realize the spec as-is isn't for authors, however I do think the varied use of syntax should be biased towards syntax that results in fewer authoring mistakes / data quality errors over time |
| 23:17 | <tantek> | sorry maybe i'm looking at an older snapshot |
| 23:17 | <tantek> | reloading |
| 23:18 | <Hixie> | a slight bias, agreed |
| 23:18 | <Hixie> | as i said, i'll make the examples lean more that way over time |
| 23:18 | <tantek> | yeah I was looking at an older version (multipage) |
| 23:18 | <Hixie> | i'm more concerned with getting the normative text of the w3c and whatwg specs converged again than worrying about example text :-) |
| 23:18 | <tantek> | looking at one-page version now |
| 23:18 | <Hixie> | multipage should be updated now, is it not? |
| 23:19 | <Hixie> | oh, i haven't uploaded it yet |
| 23:19 | <Hixie> | my bad |
| 23:19 | <tantek> | yeah one-page version looks better |
| 23:20 | <Hixie> | multipage should be updated in about 5 min |
| 23:21 | <tantek> | no problem - I'll stick with one page |
| 23:27 | <tantek> | Hixie, I think I need to raise a 4th separate issue and change proposal to get the ISO week formats in there, no problem doing so, I'll take care of that this weekend. |
| 23:27 | <tantek> | (regarding Sam's email) |
| 23:28 | <Hixie> | your devotion to their process is quite entertaining |
| 23:28 | <tantek> | just trying to help the wheels rotate |
| 23:28 | <Hixie> | sam did say though that if everyone thought the patch was ok we could short-circuit it, which may help them rotate faster :-) |
| 23:29 | <tantek> | I'll email you a suggested replacement for the schema.org example because I think that's the remaining outstanding issue that Sam (re)raised. |
| 23:29 | <tantek> | (regarding your patch) |
| 23:33 | <Hixie> | tantek: there's an issue with an example? |
| 23:33 | <Hixie> | i couldn't find any of these issues in the issue list so i wasn't sure what sam meant to be honest |
| 23:34 | <Hixie> | i don't recall even seeing a bug regarding a schema.org example, so by process it surely can't be an issue yet |
| 23:37 | <tantek> | it was raised as a comment in the bug on data |
| 23:37 | <tantek> | IIRC |
| 23:37 | <Hixie> | ah |
| 23:37 | <Hixie> | well the chairs told me not to touch that bug anymore so i haven't been reading it |
| 23:38 | <Hixie> | let me go have a look |
| 23:40 | <Hixie> | oh, i see, it's because they don't want microdata in the examples, not because they don't wnat schema.org in the examples |
| 23:40 | <tantek> | huh? not AFAICT |
| 23:40 | <tantek> | the opposite |
| 23:41 | <tantek> | nothing wrong with microdata in the examples |
| 23:41 | <tantek> | the specific comment about schema.org was objecting to that |
| 23:41 | <Hixie> | "In addtion to that, schema.org examples have no business in the W3C spec |
| 23:41 | <Hixie> | because microdata is not part of HTML5 ( just like RDFa isn't part of the spec |
| 23:41 | <Hixie> | )." |
| 23:41 | <Hixie> | all the comments that contain "schema.org" seem to support this train of thought |
| 23:42 | <Hixie> | anyway i don't mind stripping all the schema.org examples from the proposal and not adding them to the w3c spec |
| 23:42 | <Hixie> | that's fine |
| 23:42 | <Hixie> | it's the normative text that i care about |
| 23:43 | <Hixie> | (it baffles me that the w3c continues to consider microdata to not be part of html) |
| 23:44 | <tantek> | Hixie, here's an attempt at a replacement example for the blog post that's not microformats nor schema.org |
| 23:44 | <tantek> | <article itemscope itemtype="http://tools.ietf.org/html/rfc4287">; |
| 23:44 | <tantek> | <h1 itemprop="title">Small tasks</h1> |
| 23:44 | <tantek> | <footer>Published <time itemprop="published" datetime="2009-08-30">yesterday</time>.</footer> |
| 23:44 | <tantek> | <p itemprop="content">I put a bike bell on his bike.</p> |
| 23:44 | <tantek> | </article> |
| 23:44 | <Hixie> | that's still microdata though |
| 23:44 | <tantek> | sure, but it's not microdata that anyone is going to use in practice |
| 23:44 | <tantek> | I have a feeling that would resolve that particular objection |
| 23:44 | <Hixie> | which is fine by me and i'm happy to add the example to the whatwg spec, but my point is that the objection to those examples was over the use of microdata, not over the use of schema.org |
| 23:48 | <tantek> | Hixie, I will point that Sam's response to you seemed to agree with my proposed resolution to the issue |
| 23:48 | <tantek> | which says "Provide one or more examples that show use with microformats, microdata, and RDFa" |
| 23:48 | <Hixie> | examples of what? <time>? |
| 23:48 | <tantek> | and "Prefer use of openly developed vocabularies/URLs (e.g. microformats.org, whatwg.org, w3.org) rather than those developed by one company (or just a few companies) like schema.org." |
| 23:49 | <Hixie> | what are you quoting from? |
| 23:49 | <Hixie> | i see nothing in that bug that supports this line of reasoning |
| 23:49 | <tantek> | Sam's email |
| 23:49 | <Hixie> | (note that using rdfa with <time> is impossible wince RDFa doesn't support <time> yet as far as i can tell) |
| 23:49 | <tantek> | where he quotes me from |
| 23:49 | <Hixie> | which one |
| 23:49 | <Hixie> | url? |
| 23:50 | <tantek> | most recent - let me get the url |
| 23:50 | <Hixie> | oh i see |
| 23:50 | <Hixie> | got it |
| 23:50 | <Hixie> | he's quoting you |
| 23:50 | <Hixie> | ok |
| 23:50 | <tantek> | http://lists.w3.org/Archives/Public/public-html/2011Nov/0184.html |
| 23:50 | <tantek> | yeah |
| 23:50 | <Hixie> | i suggest a simpler solution then |
| 23:50 | <Hixie> | remove that part of your change proposal :-P |
| 23:50 | <Hixie> | and i'll add whatever examples you want :-) |
| 23:51 | <tantek> | it was added because Sam complained that my change proposal didn't address enough issues |
| 23:51 | <tantek> | sorry, "complained" is a bit harsh. pointed out. |
| 23:51 | <Hixie> | so he wants you to address more issues, but if you address them in a way that has no bearing on what was actually raised, he's ok with it? |
| 23:52 | <tantek> | ah this about *data* |
| 23:52 | <tantek> | sorry |
| 23:52 | <Hixie> | working with the w3c hurts my brain |
| 23:52 | <tantek> | he's quoting from |
| 23:52 | <tantek> | http://www.w3.org/wiki/User:Tantekelik/data_element |
| 23:52 | <tantek> | which is my attempt at a change proposal to add data |
| 23:52 | <Hixie> | it's not clear to me why we need any CPs here at all |
| 23:52 | <Hixie> | we have a patch |
| 23:53 | <Hixie> | unless someone has any objections, why can't the CP just be "apply the patch" |
| 23:53 | <tantek> | Hixie, I'm trying to interpret the issues in a way that will achieve consensus which is another way of saying minimizing friction so you can get on to more things |
| 23:53 | <tantek> | it started as one change proposal yes |
| 23:53 | <Hixie> | ok tell you what, i'll let you deal with the process as you wish, you tell me what to add to the spec |
| 23:53 | <tantek> | I've updated it / split it per feedback / guidance from Sam |
| 23:54 | <tantek> | in the interests of moving it through the HTML WG process |
| 23:54 | <tantek> | hoops etc. |
| 23:54 | <Hixie> | ok so what do you want me to add, and where |
| 23:55 | <tantek> | (reloading one-page version) |
| 23:58 | <tantek> | so the first change is to replace the schema.org example in the time section with the rfc4287 version I pasted above: http://krijnhoetmer.nl/irc-logs/whatwg/20111119#l-103 |
| 23:58 | <tantek> | and yes, RDFa use of <time> is currently undefined |
| 23:59 | <tantek> | I'll monitor the RDFa discussions and when they've figured it out I can suggest an example for RDFa+time as well, but we don't have to wait for that. |
| 23:59 | <Hixie> | do you mind if i tweak the example contents a bit? |
| 23:59 | <Hixie> | also, i'm not sure it makes sense to use an RFC url as an itemtype, is an example.org URL ok instead? |
| 23:59 | <tantek> | sure - I was just picking something that somehow made sense |
