| 00:14 | <Hixie> | heycam: so the problem is onerror has a different type on HTMLElement and HMTLBodyElement/Window |
| 00:15 | <heycam> | Hixie, hmm ok |
| 00:16 | <heycam> | wonder if it makes sense just to lose a bit of type information and make the HTMLElement one a bit more general, or to actually have the two onerror properties |
| 00:16 | <heycam> | for the other cases like HTMLPropertiesCollection I think it's ok though |
| 00:17 | <Hixie> | the whole thing of applying methods from oene object to another is so wacked |
| 00:17 | <heycam> | that's why it throws if the target is not a subtype :) |
| 00:17 | <heycam> | (of the original interface it was declared on) |
| 00:18 | <Hixie> | right but it doesn't make sense to apply the method of the original interface on a subtype if it has a different implementation of that method |
| 00:18 | <heycam> | so sometimes it makes perfect sense to apply to it a subtype, and in a few cases you want different behaviour |
| 00:18 | <Hixie> | e.g. namedItem from HTMLCollection instances on an HTMLProperiesCollection instance, or the onerror setter of HTMLElement on HTMLBodyElement |
| 00:19 | <Hixie> | are there times where it makes sense where the subtype has an explicit definition of its own? |
| 00:19 | <heycam> | I guess mostly not |
| 00:19 | <heycam> | unless you're are just by chance shadowing the name |
| 00:19 | <heycam> | for whatever reason |
| 00:20 | <Hixie> | that would be dumb |
| 00:20 | <heycam> | well it would yes :) |
| 00:20 | <heycam> | what I don't like is embedding knowledge of what subtypes exist in the ancestor interface |
| 00:20 | <heycam> | but maybe it's unavoidable |
| 00:21 | <Hixie> | well i don't see how else you do this case |
| 00:21 | <Hixie> | whatever solution we use |
| 00:21 | <heycam> | yeah |
| 00:21 | <Hixie> | the real problem is we're doing subclassing in a language without a classical OOP model |
| 00:22 | <Hixie> | but that ship has sailed |
| 00:22 | <heycam> | I think I prefer the ancestor method to throw if it has an unacceptable sutyped object, than for it to automatically delegate to the overridden method |
| 00:22 | <Hixie> | agreed |
| 00:22 | <heycam> | should this just be the default? |
| 00:22 | <Hixie> | probably the only behaviour |
| 00:23 | <heycam> | yeah |
| 00:23 | <heycam> | ok |
| 00:23 | <heycam> | let's do that |
| 00:23 | <Hixie> | if a method/setter/getter from a prototype of interface A is applied to an object that is of an interface B that is a subclass of A, and B defines its own method/getter/setter with the same name, then throw. |
| 00:24 | <heycam> | yes |
| 00:24 | <heycam> | including if it's something that inherits from B |
| 00:24 | <heycam> | (but maybe that's what you meant) |
| 00:24 | <Hixie> | right |
| 00:25 | heycam | is in the middle of migrating to a new computer but notes it down to do |
| 00:25 | <heycam> | actually I'll comment in the bug |
| 00:25 | <Hixie> | i'll add this in an e-mail to you |
| 00:26 | <heycam> | ok |
| 00:28 | <heycam> | probably no need to mention setters/getters |
| 00:28 | <heycam> | since they can't be explicitly got |
| 00:28 | <heycam> | and are otherwise captured by methods |
| 00:28 | <Hixie> | k |
| 00:28 | <heycam> | but attributes too? |
| 00:28 | <Hixie> | by setters/getters i meant attributes |
| 00:28 | <heycam> | ah right |
| 00:29 | <heycam> | isn't there some stupid thing like SVGDocument.title, or have we fixed that |
| 00:29 | <Hixie> | HTML defines Document.title |
| 00:29 | <Hixie> | it defers to SVGDocument.title in certain cases |
| 00:29 | <Hixie> | SVGDocument and Document are the same interface these days |
| 00:29 | <heycam> | yeah |
| 00:29 | <heycam> | OK. I guess it should just have the "looking for SVG <title>" built in to it |
| 00:29 | <heycam> | and we shouldn't have title at all |
| 00:29 | <heycam> | (we = SVG) |
| 00:29 | <Hixie> | (and "For historical reasons, Window objects must also have a writable, configurable, non-enumerable property named HTMLDocument whose value is the Document interface object.") |
| 00:30 | <Hixie> | that's be fine too, right now i just defer to the SVG spec: http://www.whatwg.org/specs/web-apps/current-work/#document.title |
| 00:30 | <heycam> | aha :) |
| 00:31 | <heycam> | https://svgwg.org/svg2-draft/struct.html#InterfaceSVGDocument |
| 00:31 | <heycam> | (though it's now a partial interface Document) |
| 00:31 | <heycam> | those three attributes will disappear at some point |
| 00:31 | <Hixie> | hah, "For historical reasons, Window objects must also have a writable, configurable, non-enumerable property named SVGDocument whose value is the Document interface object." |
| 00:31 | <Hixie> | wonder where that came from! |
| 00:32 | <Hixie> | where's the normative prose that defines SVG's Document.title? |
| 00:32 | <Hixie> | the IDL only links to the information text below the IDL |
| 00:32 | <Hixie> | (e-mail sent) |
| 00:33 | <heycam> | much of SVG is still written in that style you don't like :) |
| 00:33 | <heycam> | although the bulletted list under the IDL is probably still counted as normative due to a sentence somewhere in the spec |
| 00:34 | <heycam> | saying that UAs must follow these statements or something |
| 00:34 | <Hixie> | oh that really is meant to be the definition? |
| 00:34 | <Hixie> | that definition is worse than worthless :-P |
| 00:34 | <heycam> | it looks a bit crappy |
| 00:34 | <heycam> | yeah what if there are two <title>s |
| 00:34 | <Hixie> | or if you set it and there are two text nodes |
| 00:34 | <Hixie> | oh it's readonly |
| 00:34 | <heycam> | is Document's writable? |
| 00:35 | <Hixie> | yeah |
| 00:35 | <Hixie> | this is more like what this should look like to actually capture what needs to happen: http://www.whatwg.org/specs/web-apps/current-work/#document.title |
| 00:35 | <Hixie> | that's like a screen's worth of text for what SVG has in one line :-P |
| 00:35 | <Hixie> | anyway |
| 00:35 | <heycam> | ok. well I'm sure it's fine if it just does the same here. |
| 00:35 | <heycam> | oh great, you've already written it :) |
| 00:35 | <Hixie> | didn't mean this to become an svg bitchfest, i was actually expecting there to be a definition elsewhere :-) |
| 00:36 | <heycam> | lol |
| 00:36 | <heycam> | I think there is nothing preventing those three IDL attributes from being removed then |
| 00:36 | heycam | will get to it at some point |
| 00:36 | <Hixie> | if you do please file a bug to have the HTML spec define the SVG side of things too |
| 00:36 | <Hixie> | or provide a hook or something |
| 00:36 | <zewt> | grr, how is it 2012 and almost no HTTP libraries support pipelining |
| 00:37 | <heycam> | Hixie, is anything else needed? |
| 00:37 | <heycam> | oh yes |
| 00:37 | <heycam> | because you just defer to our one |
| 00:53 | <heycam> | MikeSmith, user Nasserbufahad⊙gc on the W3C bugzilla seems to be causing some havoc |
| 00:54 | <zewt> | heh just saw that |
| 01:09 | <Hixie> | MikeSmith: yt? |
| 01:10 | <Hixie> | MikeSmith: Nasserbufahad⊙gc just corrupted a huge number of bugs |
| 01:10 | <MikeSmith> | heycam: Hixie working on it |
| 01:10 | <Hixie> | MikeSmith: if you could kill that account and undo all the changes it made, that'd be awesome (might need direct DB access) |
| 01:10 | <Hixie> | k |
| 01:11 | <Hixie> | oh hey, heycam is ahead of me |
| 01:11 | <heycam> | a rare thing |
| 01:11 | <Hixie> | dunno about that! |
| 01:13 | <Hixie> | heycam: i don't really have enough knowledge to response to bz's concern about the performance implications about what we discussed earlier |
| 01:14 | <heycam> | Hixie, I don't know what the reason for that is either |
| 01:17 | <Hixie> | heh, i like your reply |
| 01:20 | <MikeSmith> | so I shut down Nasserbufahad⊙gc bugzilla access |
| 01:21 | <MikeSmith> | looking through changes he made, so far I only see that he changed the OS value |
| 01:21 | <zewt> | he reassigned a bunch to himself |
| 01:21 | <MikeSmith> | ah OK |
| 01:21 | <MikeSmith> | that I'll revert then |
| 01:21 | <zewt> | https://www.w3.org/Bugs/Public/show_bug.cgi?id=15023 https://www.w3.org/Bugs/Public/show_bug.cgi?id=19554 |
| 01:21 | <MikeSmith> | thanks |
| 01:22 | <zewt> | (just ones I happened to get a cc for, so there are probably tons) |
| 01:22 | <MikeSmith> | stepping through all of them now |
| 01:22 | <MikeSmith> | yeah |
| 01:22 | <zewt> | did someone write a "fuck with bugzilla" script or was it slow enough that he was just being an idiot by hand |
| 01:23 | <MikeSmith> | heh he re-assigned some to Hixie as well |
| 01:23 | <MikeSmith> | zewt: no idea |
| 01:23 | <MikeSmith> | I wasn't seeing them come through in real time |
| 01:23 | <TabAtkins> | That means it's probably by hand. |
| 01:24 | <zewt> | in other words, a 12-year-old went "haha they let me do this i'll show them" |
| 01:25 | <MikeSmith> | the OS value he changed them to is Windows 3.1 |
| 01:27 | <MikeSmith> | this had to be a script |
| 01:27 | <MikeSmith> | some of the changes have a timestamp only 1 second apart |
| 01:27 | <MikeSmith> | or actually some even the same time |
| 01:28 | <zewt> | does bugzilla have a history system robust enough to pick a batch of changes and undo? |
| 01:36 | <dbaron> | MikeSmith, I suspect he did "reassign to default assignee/qa" |
| 01:36 | <MikeSmith> | ok |
| 01:36 | <dbaron> | Also, folks, bugzilla has a UI for changing multiple bugs at once |
| 01:36 | <dbaron> | it's reasonably powerful |
| 01:36 | <MikeSmith> | true that |
| 01:37 | <dbaron> | (I think he changed every bug in "CSS Level 2" to Windows 3.1.) |
| 01:37 | <MikeSmith> | strangely though, he changed the assignee on some and then also changed it back |
| 01:38 | <MikeSmith> | I don't know how to tell what all he changed |
| 01:39 | <MikeSmith> | right now I'm just looking at the ones I'm Cced on, but that's a ton because I'm on the default Cc for tons of components |
| 01:39 | <gavin__> | if you were using a new bugzilla, you could use page.cgi?id=user_activity.html |
| 01:39 | <MikeSmith> | but not for the CSS componts |
| 01:39 | <MikeSmith> | gavin: ah OK |
| 01:40 | <MikeSmith> | we're running 4.2.3 I think |
| 01:40 | <gavin> | that may be new enough? |
| 01:40 | <gavin> | ah, no |
| 01:40 | <gavin> | that may also be a b.m.o-specific thing, not sure |
| 01:41 | <MikeSmith> | yeah https://www.w3.org/Bugs/Public/page.cgi?id=user_activity.html just shows me an error |
| 01:41 | <MikeSmith> | "The requested format does not exist with a content type of html." |
| 01:41 | <dbaron> | w3c bugzilla is generally an antique model bugzilla |
| 01:42 | <dbaron> | possibly fossilized |
| 01:42 | <gavin> | hrm, https://www.w3.org/Bugs/Public/ says 4.2.4 |
| 01:42 | <gavin> | b.m.o is running 4.0.9+, according to https://bugzilla.mozilla.org/ |
| 01:43 | <dbaron> | maybe it's just not turning any of the new features on? |
| 01:43 | <dbaron> | or all the good stuff is b.m.o-specific? |
| 01:44 | <gavin> | (b.m.o bug 764897 confirms that it's on pre-4.2) |
| 01:44 | <MikeSmith> | dbaron: W3C was running a really old version until fairly recently, but upgraded |
| 01:45 | MikeSmith | looks to see if there's an admin option for turning on the user-activity thing |
| 01:48 | <gavin> | I think it's a custom b.m.o extension |
| 01:48 | <MikeSmith> | http://w3.org/brief/MzA0 is the list of remaining bugs where he reassigned to himself |
| 01:52 | <MikeSmith> | gavin: yeah I don't see any parameter for it at https://www.w3.org/Bugs/Public/editparams.cgi?section=index |
| 02:15 | <MikeSmith> | rniwa: that guy changed the OS value on dozens and dozens of bugs |
| 02:15 | <rniwa> | MikeSmith: yeah. |
| 02:15 | <rniwa> | MikeSmith: it was super annoying :/ |
| 02:15 | <MikeSmith> | I'm planning to just leave them as-is |
| 02:15 | <MikeSmith> | yeah |
| 02:16 | <MikeSmith> | I was thinking of changing them back en masse, but I guess that might be equally annoying |
| 02:16 | <MikeSmith> | I wish we really could just eliminate that field |
| 02:51 | <Hixie> | MikeSmith: there should be a way at the db level to just revert all his changes |
| 02:51 | <MikeSmith> | yeah |
| 02:51 | <MikeSmith> | I sent mail to the systems team about it |
| 02:51 | <MikeSmith> | I don't have direct access to the DB myself |
| 02:52 | <MikeSmith> | anyway the only destructive changes I can see that he made were the re-assignments, and I've now reverted all of those |
| 03:01 | <Hixie> | MikeSmith: thanks man |
| 03:02 | <MikeSmith> | thanks for the heads-up |
| 03:02 | <MikeSmith> | was away from e-mail at the time |
| 08:07 | <kennyluck> | Back to Windows 3.1!! |
| 08:12 | <hsivonen> | kennyluck: ? |
| 08:15 | <kennyluck> | hsivonen, I am getting thousands of Bugzilla mails because a bot (<Nasserbufahad⊙gc>) changes the OS filed of all bugs in the CSS 2.1 component to Windows 3.1… like this one → https://www.w3.org/Bugs/Public/show_activity.cgi?id=15892 |
| 08:17 | <jordanbtucker> | hi guys |
| 08:17 | <jordanbtucker> | looking at parsing.html#the-stack-of-open-elements, it defines a "current table", but i don't see any other references to the current table in the rest of the spec |
| 08:18 | <jordanbtucker> | what is the point of the current table? |
| 08:19 | <MikeSmith> | kennyluck: yeah I shut down that account several hours ago |
| 08:19 | <kennyluck> | MikeSmith, great thanks! |
| 08:20 | <MikeSmith> | unfortunately not before it managed to send all the spam |
| 08:20 | <MikeSmith> | I think I already repaired any of the actual destructive changes it made |
| 08:20 | <MikeSmith> | e.g., changed the assignee on some bugs |
| 08:23 | <MikeSmith> | jordanbtucker: I have not clue either what the point of defining "current table" is or was |
| 08:23 | <MikeSmith> | hsivonen might know |
| 08:24 | <MikeSmith> | but it's probably worth filing a bug on |
| 08:24 | <jordanbtucker> | perhaps it was used for something in a previous version of the parser, but, yeah, i'll file a bug |
| 08:33 | <annevk> | heh nice find |
| 08:35 | <jordanbtucker> | i'm writing a parser |
| 08:36 | <annevk> | language? |
| 08:36 | <jordanbtucker> | C# |
| 08:36 | <annevk> | I did some archaeology and http://www.w3.org/TR/2009/WD-html5-20090212/tree-construction.html seems to still use the concept |
| 08:40 | <MikeSmith> | hmm I thought IE8 is supposed to have document.querySelectorAll support |
| 08:40 | <jordanbtucker> | interesting |
| 08:41 | <MikeSmith> | wonder why the "current table" stuff was removed |
| 08:41 | <MikeSmith> | I don't find any mention of it the subversion logs |
| 08:42 | <MikeSmith> | maybe 3382? |
| 08:43 | <MikeSmith> | yeah |
| 08:43 | <MikeSmith> | http://html5.org/tools/web-apps-tracker?from=3381&to=3382 |
| 08:43 | <annevk> | MikeSmith: it's now defined in terms of a "foster parent element" which also uses a table |
| 08:43 | <MikeSmith> | ok |
| 08:45 | <MikeSmith> | annevk: actually it seems like maybe it already was defined in those terms before Hixie removed the current-table bits |
| 08:45 | <MikeSmith> | seems like what he changed is, he added the "in table text" insertion mode |
| 08:46 | <hsivonen> | Whoa. http://mozilla.github.com/pdf.js/features/ says IE10 doesn’t have XMLHttpRequest.prototype.overrideMimeType() |
| 08:49 | <annevk> | Is there a way to verify whether an object instance in JavaScript is "JSON-safe" without causing that object to execute script? |
| 08:52 | <Ms2ger> | Probably not |
| 08:53 | <hsivonen> | hmm. Google keeps having interesting ways of abusing the platform. And then asking for native features. |
| 08:53 | <hsivonen> | like loading scripts as multiple <script>s in an iframe |
| 08:57 | <MikeSmith> | so I guess IE8 only supports querySelectorAll in standards mode. and I'm guessing that http://netrenderer.com/ doesn't do its IE8 rendering in standards mode |
| 08:58 | <hsivonen> | huh? doesn’t it defeat the point of netrenderer if it doesn’t let IE8 choose its mode like a normal installation would? |
| 09:03 | <MikeSmith> | hsivonen: would think so. But I'm using a simple "if (!document.querySelectorAll) return" and it seems to be returning on that |
| 09:03 | <MikeSmith> | otherwise I'm pretty sure I'd be seeing something rendered from the code after that |
| 09:04 | <hsivonen> | MikeSmith: would you like me to run your test case in real IE8? |
| 09:05 | <karlcow> | darobin: not sure if it's a known issue but… |
| 09:05 | <MikeSmith> | yeah if you have a minute |
| 09:05 | <karlcow> | for example on http://www.w3.org/TR/html5/common-dom-interfaces.html#domstringmap-0 |
| 09:05 | <karlcow> | click on Table of contents |
| 09:05 | <karlcow> | it goes to http://www.w3.org/TR/html5/index.html#contents which is a file not found |
| 09:05 | <MikeSmith> | hsivonen: http://qa-dev.w3.org:8888/?doc=http%3A%2F%2Fwikipedia.com Or actually, any document would do |
| 09:05 | <MikeSmith> | hsivonen: you should see a "Message filtering" button |
| 09:06 | <annevk> | Ms2ger: was afraid of that |
| 09:06 | <MikeSmith> | karlcow: hmm yeah |
| 09:06 | <hsivonen> | MikeSmith: I see that button in Firefox. I don’t see the button in IE8 on Windows XP. |
| 09:07 | <hsivonen> | MikeSmith: Browser Mode: IE8; Document Mode: IE8 Standards |
| 09:08 | <MikeSmith> | hsivonen: OK, thanks. If you have one more minute, lemme remove the "if (!document.querySelectorAll)" check |
| 09:08 | <hsivonen> | MikeSmith: Object doesn’t support this property or method, line 8 in / |
| 09:08 | <MikeSmith> | oh |
| 09:08 | <MikeSmith> | line 8.. |
| 09:08 | <hsivonen> | MikeSmith: ‘null’ is null or not an object script.js line 488, char 4 |
| 09:09 | <hsivonen> | line 8 of HTML—not scriptjs |
| 09:09 | <MikeSmith> | OK |
| 09:10 | <hsivonen> | “‘null’ is null or not an object” is a lovely error message |
| 09:10 | <MikeSmith> | heh |
| 09:11 | <MikeSmith> | hsivonen: this makes me wonder whether the JavaScript for http://html5.validator.nu/ or http://validator.nu/ works in IE8 |
| 09:11 | <hsivonen> | MikeSmith: didn’t work last I checked |
| 09:11 | <MikeSmith> | ah |
| 09:11 | <MikeSmith> | OK |
| 09:11 | <hsivonen> | let’s see |
| 09:12 | <hsivonen> | “‘null’ is null or not an object” happens on validator.nu, too |
| 09:12 | <MikeSmith> | ah OK |
| 09:12 | <MikeSmith> | man I was worrying about trying to stick to JS feature s that work IE8. For the validator code, I mean. I guess I don't need to worry about it, huh? |
| 09:13 | <hsivonen> | I suppose not unless you also want to fix the old code |
| 09:13 | <darobin> | karlcow: yeah, there was a last minute renaming of index.html to Overview.html by the webmaster... |
| 09:13 | <MikeSmith> | hsivonen: no thanks :) |
| 09:15 | <MikeSmith> | hsivonen: if no IE8 users are currently unhappy enough about not having the parts of the UI that rely on JavaScript to file a bug, they won't miss anything new we add to the UI that needs JavaScript |
| 09:16 | <MikeSmith> | darobin: yeah I wish now he really hadn't done that. I can't remember at this point what his rationale was |
| 09:16 | <hsivonen> | MikeSmith: makes sense |
| 09:16 | <darobin> | MikeSmith: it's okay, I'm fixing the tools to just use Overview.html everywhere next time |
| 09:17 | <MikeSmith> | darobin: ok |
| 09:23 | <Smylers> | “[20:09] <Hixie> GPHemsley: our shared list...” You have a private list for WHATWG business? |
| 09:23 | <Smylers> | I had a look, but it doesn't seem to be publicly archived anywhere. |
| 09:23 | <Smylers> | Shocking! |
| 09:58 | <annevk> | o_O |
| 09:58 | <Ms2ger> | Hmm? |
| 09:59 | <annevk> | Ms2ger: there's a list for "I want a wiki account" so we don't need to list individual email addresses on the wiki |
| 09:59 | <Ms2ger> | Ah, I see |
| 10:09 | <zcorpan> | MikeSmith: iirc, the js code in v.nu is deliberately throwing an exception in ie8 because otherwise ie would crash. |
| 10:09 | <MikeSmith> | oh |
| 10:09 | <MikeSmith> | ah yeah |
| 10:10 | <MikeSmith> | I know the part you mean |
| 10:10 | <MikeSmith> | but that's only in the code that handles the message grouping I think |
| 10:10 | <zcorpan> | ah, ok |
| 10:11 | <zcorpan> | what else is throwing? |
| 10:11 | <MikeSmith> | no, I mean that's the only place where we're throwing |
| 10:11 | <zcorpan> | ok |
| 10:12 | <MikeSmith> | and if/when we add the message-filtering feature, it will replace the current message-grouping feature |
| 10:12 | <MikeSmith> | so we should probably move that throw to somewhere else, if we want to keep |
| 10:12 | <MikeSmith> | *keep it |
| 10:15 | <zcorpan> | Smylers1: it's archived, but only the Hixie Team have access |
| 10:15 | <zcorpan> | (i.e. Hixie and his cats) |
| 10:16 | <Ms2ger> | Probably still a bigger group than the team-html-* lists |
| 10:49 | darobin | wonders if he should sign his cat up to team-html-* too |
| 10:57 | <annevk> | ffs |
| 10:58 | <odinho> | bffs? |
| 10:58 | <annevk> | relList does not have uniqueness right? |
| 10:59 | <annevk> | or is the rel="up up up" thing gone? |
| 11:01 | <annevk> | and why is class="" not defined as unordered set of unique space-separated tokens? |
| 11:01 | <annevk> | Hixie!! |
| 11:02 | <annevk> | this probably unlikely to be an effective way of reaching him |
| 11:02 | <jgraham> | It is 3am in SF |
| 11:02 | <annevk> | I know |
| 11:02 | <jgraham> | I imagine that the most successful way to reach him would be to break into his bedroom |
| 11:02 | <jgraham> | and tickle his feet |
| 11:03 | <jgraham> | And try and shout your complaint in the time between him waking up and calling the police |
| 11:03 | <annevk> | by the time I get there I might as well have waited eight hours |
| 11:03 | <jgraham> | You could get someone else to do it for you, I guess |
| 11:04 | <jgraham> | There's probably a startup with that as their business model |
| 11:06 | <SimonSapin> | http://xkcd.com/163/ |
| 11:06 | <annevk> | anyway, I guess DOMTokenList already guarantees uniqueness so Hixie should just update rel/class to point that out |
| 11:07 | <annevk> | which would make rel="up up up up" as jreschke pointed out long ago, a kinda flawed solution |
| 11:07 | <annevk> | which means I can rewrite DOMTokenList to represent an ordered Set |
| 11:07 | <annevk> | and then whenever DOMTokenList updates the corresponding attribute is updated |
| 11:08 | <annevk> | SimonSapin: apt |
| 11:31 | <annevk> | DOMTokenList represents an ordered set; DOMTokenList update steps update the associated string; DOMTokenList parser takes a string and initializes the DOMTokenList |
| 11:32 | <hsivonen> | so someone mentioned yesterday that the CSS WG has a process for dealing with Level 2.1 tests that don’t pass in a compliant Level 3 implementation |
| 11:32 | <hsivonen> | is that process documented somewhere? |
| 11:32 | <hsivonen> | was sending http://lists.w3.org/Archives/Public/public-css-testsuite/2012Dec/0000.html the right thing to do per that process? |
| 11:33 | <jgraham> | Pretty sure referencing W3C Memes for Process is never right per Process |
| 11:34 | <annevk> | hsivonen: http://wiki.csswg.org/test has a bunch of pages |
| 11:34 | <hsivonen> | jgraham: at least I refrained from referencing http://w3cmemes.tumblr.com/post/35332222321/css-2-1-syndata-is-awesome |
| 11:38 | <hsivonen> | It still troubles me that writing and reviewing http://test.csswg.org/suites/css2.1/20110323/html4/at-charset-046.htm didn’t lead to a spec change |
| 11:40 | <hsivonen> | annevk: I don’t find a policy for this topic there |
| 11:41 | <annevk> | me neither :/ |
| 11:41 | <hsivonen> | oh well. I’ll wait and see what happens |
| 11:44 | <hsivonen> | actually, the test case that matches the meme is http://test.csswg.org/suites/css2.1/20110323/html4/at-charset-045.htm |
| 11:46 | <annevk> | thanks a lot for following through hsivonen |
| 11:46 | <annevk> | still doing your best to get that angel badge ;-) |
| 11:58 | <darobin> | annevk: I hope you'll make good on your TAG promises now that the election is open! |
| 11:59 | <darobin> | slightlyoff: that's for you too |
| 11:59 | <darobin> | and marcosc |
| 11:59 | <darobin> | and wycats_ :) |
| 11:59 | <annevk> | darobin: by that I take it you mean to post to www-tag? |
| 11:59 | <marcosc> | annevk made promises? |
| 11:59 | <darobin> | annevk: yup |
| 11:59 | <darobin> | he promised to campaign properly |
| 12:00 | <darobin> | four seats for four horsemen |
| 12:00 | <hsivonen> | how many votes per Member? |
| 12:00 | <darobin> | hsivonen: up to four, to be cast on distinct individuals |
| 12:00 | <hsivonen> | darobin: ok |
| 12:01 | marcosc | looks at www-tag for the first time ever. |
| 12:01 | <darobin> | some members have already voted so I reckon you ought to get your campaign going |
| 12:01 | <marcosc> | at least they don't send a lot of email |
| 12:02 | <AryehGregor> | Wait, annevk wants to be on the TAG? Won't that just result in giant flamewars? |
| 12:02 | <zcorpan> | is https://bugzilla.mozilla.org/show_bug.cgi?id=816045#c8 a spec bug? |
| 12:02 | <annevk> | darobin: thanks for the heads up, will try to get to it before the end of the week |
| 12:03 | <darobin> | coolness |
| 12:03 | <darobin> | AryehGregor: depends on who gets elected |
| 12:03 | <darobin> | amongst the candidates, there are annevk, slightlyoff, marcosc, and wycats_ — if they all get elected it could lead to interesting changes :) |
| 12:03 | <AryehGregor> | darobin, that sounds like "yes, but you can't prove it". |
| 12:04 | <darobin> | nah, actually I think if the results turn out right it could prove constructive |
| 12:04 | <AryehGregor> | Also, I thought the TAG theoretically has no power per Process and is really just a way for the Director to claim he's not acting unilaterally. |
| 12:09 | <AryehGregor> | Anyway, even if you take over the TAG, that will just put it at loggerheads with the AC. |
| 12:09 | <jgraham> | AryehGregor: What the process *says* isn't important. It's about what people percieve. |
| 12:09 | <AryehGregor> | Oh well, I gave up on W3C process ages ago. |
| 12:12 | <annevk> | AryehGregor: Is your point that we should not try? |
| 12:13 | <AryehGregor> | Yes, I think the W3C is fundamentally a lost cause, because it's ultimately controlled (financially) by the Members, who mostly are not qualified to have opinions on anything. |
| 12:14 | <marcosc> | ouch |
| 12:15 | <AryehGregor> | A standards body that's controlled by a vote of organizations with only minor or tangential stakes in the web cannot be expected to produce useful policies. |
| 12:15 | <darobin> | that's all a rather broad mischaracterisation :) |
| 12:15 | <annevk> | AryehGregor: Irrespective of whether that's true, there's no other suitable body that offers patent protection and participation from Microsoft. So trying to somehow reform the body seems like it's worth a shot. |
| 12:15 | <AryehGregor> | The correct structure needs to be de facto control by implementers. |
| 12:15 | <AryehGregor> | Well, good luck. |
| 12:15 | <darobin> | the Director has power, and in my experience doesn't need anyone's blessing to act |
| 12:16 | <darobin> | being "at loggerheads with the AC" is something that I don't even understand in the TAG context |
| 12:16 | <darobin> | (having been both an AC rep and a TAG member) |
| 12:16 | <AryehGregor> | I suppose the AC isn't involved directly in much that's important, so you could work around it. |
| 12:16 | <AryehGregor> | I'm mostly thinking of the licensing issue. |
| 12:17 | <darobin> | the licensing issue is not a TAG decision |
| 12:17 | <AryehGregor> | I know, it's an AC decision, right? |
| 12:17 | <darobin> | yup |
| 12:17 | <AryehGregor> | That's my point about the AC. |
| 12:17 | <AryehGregor> | If the AC gets to make those decisions, they'll be wrong. |
| 12:17 | <darobin> | sometimes, not always |
| 12:17 | <AryehGregor> | Wasn't the AC also what decided to not allow Web Apps 1.0 to be hosted at the W3C to start with? |
| 12:17 | <darobin> | though you won't get disagreement from me on the licensing issue |
| 12:18 | <darobin> | AryehGregor: note that it's the AC that brought us RF in the first place |
| 12:18 | <darobin> | AryehGregor: hmmm, no |
| 12:18 | <hsivonen> | RF is the W3C’s greatest achievement |
| 12:19 | <hsivonen> | RF is still the main value W3C provides |
| 12:19 | <darobin> | thank the AC, then ;-) |
| 12:19 | <hsivonen> | makes the silliness of copying and pasting WHATWG specs in the W3C worthwhile |
| 12:19 | <AryehGregor> | I should probably just stay quiet here, because I tend to lose interest as soon as anyone tries to tell implementers what to do. |
| 12:19 | <AryehGregor> | The AC "brought us" RF, or just were willing to approve it? |
| 12:20 | darobin | tries to remember last time someone "told implementers what to do" |
| 12:20 | <odinho_> | Who is Nasserbufahad, and why does he think all spec bugs are related to Windows 3.1? |
| 12:20 | <darobin> | AryehGregor: it's from a long time ago, but if the RF policy had been decided by implementers alone, we probably wouldn't have it |
| 12:21 | <marcosc> | odinho_: yeah, that guy needs a banning. |
| 12:21 | <odinho> | odinho_: WTF. /me slaps odinho_ |
| 12:21 | <darobin> | just suggesting that the industry and the way(s) in which it congregates can be complex and fluctuating |
| 12:21 | <darobin> | anyway, I need to skedaddle |
| 12:22 | <annevk> | MikeSmith: maybe by default new users should not have editbugs on w3.org? |
| 12:22 | <annevk> | MikeSmith: at least if this happens again I'd be for that, because this was crazy |
| 12:22 | <marcosc> | agreed |
| 12:22 | <AryehGregor> | Or have flood protection for editbugs, if Bugzilla supports it. |
| 12:23 | <MikeSmith> | it used to be that way but then we had to manually give people editbugs, which is also a PITA and makes me the bottleneck |
| 12:23 | <AryehGregor> | Random users shouldn't need to modify more than three bugs in any 24-hour period. |
| 12:23 | <MikeSmith> | AryehGregor: yeah, some kind of flood protection sure would make a lot more sense |
| 12:23 | <AryehGregor> | Soft security! |
| 12:24 | <MikeSmith> | but the thing is, there are some times when we need to mass-change hundreds of bugs at once |
| 12:24 | <MikeSmith> | e.g., we did that to clone all the HTML spec bugs a while back |
| 12:25 | <MikeSmith> | anyway, question: without using querySelectorAll, if I have some elements that are class="foo bar" and some that are class="foo", is there any good way (other than manually walking the tree) that I can select just the class="foo" elements only? |
| 12:25 | <AryehGregor> | MikeSmith, why without qSA? |
| 12:25 | <odinho> | MikeSmith: Y U invent arbitrary restrictions? :| |
| 12:25 | <AryehGregor> | How about getElementsByClassName() and then filter? |
| 12:25 | <MikeSmith> | heh |
| 12:26 | <MikeSmith> | AryehGregor: filter by iterating through the resulting nodelist? |
| 12:26 | <odinho> | I'd like to do this querySelectorAll thing, but it's too long to type, so how can I do it in some other way? :P |
| 12:26 | <AryehGregor> | MikeSmith, yes. |
| 12:26 | <AryehGregor> | Either with a loop, or .filter(). |
| 12:27 | <MikeSmith> | not using qSA because I don't need it for anything else in this script. Just using getElementsByClassName for everything else |
| 12:27 | <MikeSmith> | AryehGregor: OK |
| 12:27 | <AryehGregor> | That seems like an arbitrary restriction. |
| 12:28 | <odinho> | Presumably to support older browsers, though you didn't hear that from me! |
| 12:28 | <odinho> | I like my bubble where I just code for the new stuff. :D |
| 12:29 | <MikeSmith> | I could switch everything to using qSA but I think the performance of that is worse, right? |
| 12:29 | <AryehGregor> | Is this script so performance-sensitive that it would make a difference? |
| 12:29 | <AryehGregor> | Are you talking about trees with many thousands of nodes with a function being run many times per second? |
| 12:30 | <AryehGregor> | CSS selectors are extremely fast. I doubt it would be a problem unless you're doing something exciting. |
| 12:30 | <MikeSmith> | ok |
| 12:31 | <MikeSmith> | this is definitely not exciting |
| 12:31 | <AryehGregor> | (also, you *can* use qSA only in the places you need it, y'know -- you don't get extra points for minimizing the number of distinct functions used) |
| 12:31 | <AryehGregor> | I personally use qS(A) for everything and don't bother with the older-style functions unless I have a very specific reason. |
| 12:31 | <odinho> | Shouldn't be slower for the common cases. Implementation should have a fast path for those. That's my opinion, now I pay everyone 2c (?) |
| 12:31 | <MikeSmith> | heh |
| 12:31 | <MikeSmith> | AryehGregor: OK |
| 12:32 | <AryehGregor> | The selector here would probably be something like "[class=foo]" or ".foo:not(.bar)", which is unlikely to hit fast paths AFAIK. |
| 12:32 | <MikeSmith> | yeah, just "[class=foo]" |
| 12:33 | <jgraham> | If you don't get points for minimising the number of functions used, what the hell was jQuery doing? |
| 12:36 | <MikeSmith> | hey btw is there a way to make Opera correctly display a button as a button if it doesn't have any form ancestor? |
| 12:36 | <MikeSmith> | I mean without writing all the button styling |
| 12:37 | <MikeSmith> | which I've already done now so perhaps my question is moot |
| 12:37 | <MikeSmith> | still, I'm curious |
| 12:42 | <gsnedders> | MikeSmith: What doesn't work? <html><button>foo</button> WFM |
| 12:43 | <MikeSmith> | gsnedders: hmm yeah |
| 12:44 | <MikeSmith> | so now I'm wondering why it wasn't working when I tried it |
| 12:46 | <MikeSmith> | hmm yeah but I tried it again and it's definitely not in this case |
| 12:46 | MikeSmith | tries to make a reduced test |
| 12:47 | <gsnedders> | No foreignObject around? |
| 12:49 | <annevk> | MikeSmith: [class=foo] won't match class="foo " |
| 12:49 | <MikeSmith> | annevk: yeah, that's OK |
| 12:49 | <MikeSmith> | I'm generating that "foo" values so I know they don't have spaces |
| 12:53 | <annevk> | hackydyhack |
| 13:00 | <annevk> | MikeSmith: any update yet on just having WHATWG/URL in Bugzilla? |
| 13:01 | <annevk> | Is there any specification outside of HTML that uses DOMTokenList and/or DOMSettableTokenList? |
| 13:02 | <annevk> | jgraham: did you or someone else create classList testcases? |
| 13:02 | <annevk> | jgraham: some of them might need to be updated after I have rewritten this |
| 13:02 | <annevk> | (and implementations too) |
| 13:03 | <MikeSmith> | annevk: I thought I added it already |
| 13:08 | <jgraham> | annevk: Yes, I or someone else created them |
| 13:08 | <jgraham> | But I don't remember which |
| 13:08 | <jgraham> | Which does sort of suggest someone else |
| 13:28 | <MikeSmith> | annevk: ah OK yeah I haven't talked to Art yet |
| 13:28 | <MikeSmith> | will ask him now |
| 13:58 | <MikeSmith> | annevk: talked with Art and has I expected he's not going amenable to dropping the component |
| 13:59 | <annevk> | so he favors two components? |
| 13:59 | <annevk> | I guess he can keep his useless component then and confuse people all over :/ |
| 14:00 | <MikeSmith> | yeah I don't think I am going to convince him |
| 14:01 | <MikeSmith> | so anyway, given that, I will make sure to move over myself any bugs filed there |
| 14:01 | <MikeSmith> | maybe I can write a script to do it automatically |
| 14:06 | <annevk> | the component in WebAppsWG is empty |
| 14:06 | <annevk> | it's just that people might stumble upon it |
| 14:06 | <annevk> | and Art's copy of the URL draft doesn't even refer to it |
| 14:07 | <annevk> | does he even know what he's doing? |
| 14:08 | <MikeSmith> | he knows what he's doing |
| 14:09 | <MikeSmith> | he's stuck with the consequences of trying to chair a WG under W3C policies that he has no control over and doesn't necessarily agree with |
| 14:09 | <MikeSmith> | he's one of the best chairs we have |
| 14:09 | <annevk> | there's no policy on bug components though |
| 14:10 | <MikeSmith> | and he's working in good faith |
| 14:10 | <MikeSmith> | yeah I know |
| 14:10 | <annevk> | e.g. the i18n WG does not care about it |
| 14:10 | <annevk> | sorry, I18N WG |
| 14:11 | <MikeSmith> | that may be just because they're not actually paying attention |
| 14:11 | <MikeSmith> | most people aren't paying attention |
| 14:11 | <MikeSmith> | Art pays attention |
| 14:11 | <MikeSmith> | and stays on top of things |
| 14:11 | <annevk> | I discussed it with the chairs |
| 14:11 | <MikeSmith> | ah OK |
| 14:13 | <annevk> | arv: in a normal timezone by any chance? |
| 14:25 | <arv> | annevk: Normal by my standard at least |
| 14:25 | <annevk> | arv: so for all arity methods, do we want to support the empty sequence? |
| 14:26 | <annevk> | arv: or do we want to make a distinction, perhaps at IDL level too, between 0 or more and 1 or more |
| 14:27 | <arv> | annevk: yes. or let me clarify, ...foo means foo can be an empty array. If we want at least one of it we need to have one required param and on rest param (foo, ...fooRest) |
| 14:27 | <arv> | annevk: for the DOM mutation methods I don't see a reason to restrict to 1+ |
| 14:28 | <annevk> | from an IDL perspective having "foo..." and "optional foo..." makes more sense to me |
| 14:29 | <annevk> | I guess I'm fine with the DOM mutation methods supporting 0 |
| 14:29 | <annevk> | it seems weird to have optional and not use it for arity given this use case |
| 14:30 | <arv> | Why do we want to diverge from JS, Python, Java, C# here and make ...foo mean 1+ arguments? |
| 14:31 | <annevk> | I guess we don't, it just seems illogical |
| 14:32 | <arv> | you don't need to include optional in the type spec either. ... means optional |
| 14:33 | <annevk> | sure |
| 14:33 | <annevk> | I guess my perspective is that when I right the spec I don't want to talk about foo and fooRest as if they're separate |
| 14:33 | <annevk> | I only care about a collection of foo objects and that there's at least one of them |
| 14:34 | <annevk> | s/right/write/ o_O |
| 14:34 | <annevk> | I would imagine I'd like the same in type-constrained code :-) |
| 14:36 | <arv> | Fair enough. It does make spec prose more verbose but on the other hand idl and prose often drift apart |
| 14:36 | <arv> | There are two options. One is to only write this requirement in prose. The other one is to be more verbose. Your call ;-) |
| 14:37 | <zewt> | well, the other option is to add syntax to webidl, so the verbosity is encapsulated in the dispatch |
| 14:38 | <zewt> | (don't know all the context, but FWIW i agree that things like DOM "append these items" methods should definitely accept 0) |
| 14:38 | <annevk> | Yeah, the moment we give people a "your call" our APIs will start to diverge, but that is happening anyway :/ |
| 14:39 | <annevk> | I thought requiring optional DOMString... was kinda neat (for 0 or more), but if ... is expected to mean optional in so many places I guess that's not gonna fly |
| 14:40 | <zewt> | what it means in the IDL doesn't need to correspond to what a similar-looking token means in JS, though |
| 14:41 | <zewt> | (i'm assuming this is a new JS feature, from context--don't know where to look for a description, and "..." is 100% ungooglable) |
| 14:41 | <zcorpan> | MikeSmith: document.querySelectorAll('[class=foo]') |
| 14:42 | <annevk> | zewt: arv seems to disagree and in general people are already uncomfortable with IDL being so "alien" |
| 14:43 | <MikeSmith> | zcorpan: yeah, thanks |
| 14:43 | <zcorpan> | oh i see you reached that conclusion later |
| 14:44 | <arv> | zewt: http://wiki.ecmascript.org/doku.php?id=harmony:specification_drafts It has been in the ES6 drafts for a year maybe and it is available in Firefox since a few months back |
| 14:44 | <zewt> | annevk: it's defining typed interfaces and inheritance trees, it's inherently not at all javascript |
| 14:45 | <zewt> | no sense pretending it is, IMO |
| 14:45 | <arv> | zewt: WebIDL only describes JS. There are no other bindings defined. |
| 14:45 | <zewt> | also if it's "...foo" in JS and the more common "foo..." in the idl, that makes them pretty clearly different |
| 14:45 | <zewt> | arv: doesn't matter, the webidl language is not javascript |
| 14:45 | <arv> | zewt: Who are we pretending we are not serving JS only? |
| 14:46 | <zewt> | uh, I didn't say it's not only used for javascript |
| 14:46 | <zewt> | i said it isn't javascript |
| 14:46 | <arv> | zewt: But we are only serving JS so we might as well stop pretending we are trying to define APIs that can be used from any language |
| 14:47 | <zewt> | ... i didn't say anything about that |
| 14:47 | <arv> | zewt: so aligning the semantics has high value |
| 14:47 | <arv> | as well as syntax where possible |
| 14:47 | <zewt> | the webidl language and the javascript language basically have nothing in common, so that makes no sense |
| 14:48 | <arv> | zewt: I'm not ok with that. I think that is an issue by itself |
| 14:49 | <zewt> | unless you're planning on redefining webidl from scratch, i think "oh well" :) |
| 14:49 | <arv> | these are living standards |
| 14:49 | <arv> | when we add new features we should align them when possible |
| 14:49 | <zewt> | you're free to try to convince everyone to make a new idl language, but today what we have is webidl |
| 14:49 | <zcorpan> | MikeSmith: the "show all" and "hide all" links have the visited style, which looks annoying |
| 14:52 | <zewt> | annevk: fwiw, another idea off the top of my head is eg. "DOMString{1,}...", though I suppose that's overcomplicated if all you'll ever want is 0+ and 1+ |
| 14:53 | <MikeSmith> | zcorpan: what should I change them to? no color? blue? |
| 14:53 | <zcorpan> | blue |
| 14:53 | <annevk> | maybe DOMString...+ |
| 14:53 | <MikeSmith> | ok |
| 14:53 | <MikeSmith> | will do |
| 14:53 | <annevk> | but it seems so inconssitent with the rest of IDL |
| 14:53 | <zewt> | hmm |
| 14:54 | <zcorpan> | which APIs want 0+? |
| 14:54 | <zewt> | i'd expect 0+ to be the majority and 1+ to be rare |
| 14:54 | <annevk> | zcorpan: append/prepend in DOM |
| 14:54 | <annevk> | 1+ is URLQuery.set I guess |
| 14:54 | <zewt> | typically you wouldn't want foo.apply(foo, list_of_stuff) to fail if list_of_stuff happens to be empty |
| 14:55 | <zewt> | (unless it has to) |
| 14:55 | <annevk> | although URLQuery.set could be 0+ too, it would just mean the same as URLQuery.delete when passed with 0 |
| 14:55 | <zcorpan> | annevk: why do append/prepend want 0+? |
| 14:55 | <zewt> | could say "DOMString+", and not have a syntax for 1+ at all (do that in prose if it comes up) |
| 14:56 | <annevk> | zcorpan: convenience |
| 14:56 | <annevk> | zewt: arity is already DOMString... |
| 14:56 | <annevk> | don't need a syntax for that :) |
| 14:56 | <zcorpan> | annevk: convenience for "Run the mutation method macro."? |
| 14:57 | <annevk> | zcorpan: no |
| 14:57 | <annevk> | zcorpan: for people using the methods |
| 14:57 | <zewt> | zcorpan: the question is the opposite--why would you want to cause an error if it's <1 |
| 14:57 | <zewt> | if what the caller wants is obvious, then you're just introducing unneeded errors and making people sprinkle extra conditionals around |
| 14:58 | <zewt> | eg. python's list.extend method doesn't throw if the parameter is empty |
| 14:59 | <zcorpan> | ok |
| 15:00 | <gsnedders> | Zero is the base-case, fairly intuitively. It is the case where you do no mutation, otherwise you process each list member. |
| 15:00 | <gsnedders> | Till the list is empty, recursively. |
| 15:01 | <zcorpan> | but calling it with no arguments would run the mutation method macro. i'm not familiar enough with that area of the spec to tell if it's no-op or not |
| 15:02 | <annevk> | oh there might be bugs there |
| 15:02 | <annevk> | I didn't know arity could be 0 at the time |
| 15:13 | <zcorpan> | hsivonen: article:first-of-type { ... } also wouldn't work, since it selects multiple articles if they aren't sibilngs |
| 15:17 | <hsivonen> | zcorpan: OK. please take my failure to write a proper selector as amplifying my point. |
| 15:20 | <zcorpan> | i can't think of a selector that does what you want |
| 15:21 | <SimonSapin> | hsivonen: what selector do you want? |
| 15:21 | <zcorpan> | "first <article>" |
| 15:22 | <SimonSapin> | first … of the whole document? |
| 15:22 | <zcorpan> | yep |
| 15:22 | <SimonSapin> | I don’t think selectors can do that |
| 15:22 | <SimonSapin> | not without post-filtering |
| 15:23 | <zcorpan> | what do you mean with post-filtering? |
| 15:24 | <SimonSapin> | getting results from a selector, and then doing something else |
| 15:24 | <SimonSapin> | in JS maybe |
| 15:25 | <SimonSapin> | or in this particular case, just using querySelector() |
| 15:42 | <annevk> | SimonSapin: it's not the speculative parser, it's just how <img> works |
| 15:42 | <SimonSapin> | is it? |
| 15:43 | <SimonSapin> | I have a pages with dozens of SVGs in <object> with a PNG <img> fallback each, only the first few PNGs are loaded |
| 15:46 | <annevk> | afaik there's nothing in <img> loading that looks at the parent |
| 15:46 | <annevk> | might that the spec and/or browsers have a bug |
| 15:48 | <gsnedders> | I thought object fallback only loaded when needed? |
| 15:48 | <SimonSapin> | annevk: I don’t know. I see this is both Firefox and Chromium |
| 15:55 | <marcosc> | is it normal that when onload of an image fires in Chrome it does not have a target set? |
| 16:03 | <annevk> | you mean .target is null? |
| 16:04 | <annevk> | that sounds kinda unlikely |
| 16:04 | <annevk> | arv: so I think implementations of DOMTokenList can be optimized a little bit |
| 16:05 | <annevk> | arv: e.g. class="test test foo "; classList.remove("test") -> class="foo" |
| 16:06 | <arv> | annevk: I just started writing a bug for that |
| 16:06 | <arv> | annevk: We should just split the string into an ordered set, then remove the token and the serialize back to a string |
| 16:06 | <annevk> | right |
| 16:07 | <annevk> | that's what the spec will end up saying, it just doesn't propagate setAttribute("class", ...) modifications yet |
| 16:07 | <zcorpan> | SimonSapin: the context here was in a CSS stylesheet |
| 16:08 | <annevk> | arv: one question about that |
| 16:08 | <annevk> | arv: when do browsers check which attribute was changed versus when they queue the mutation record? |
| 16:09 | <SimonSapin> | zcorpan: then no, not possible with a single selector, without any assumption about the structure of a document |
| 16:09 | <annevk> | arv: I set "class"; "class" attribute is changed; do "class" specific steps; queue record |
| 16:09 | <annevk> | arv: or maybe queue record; do "class" specific steps |
| 16:09 | <arv> | annevk: I'm not sure... let me check |
| 16:09 | <annevk> | I guess it doesn't matter since mutation observers run afterwards regardless, but it might matter when debugging I guess |
| 16:14 | <arv> | annevk: we set the attribute data before we do the attribute specific handling... The queuing happens after both of those. |
| 16:16 | <annevk> | thanks |
| 16:16 | <annevk> | I guess it's about time we make the specs more specific about that |
| 16:30 | <Masklinn> | How would one go about sending feedback on a whatwg spec, a use case concerning a spec not for instance? Through the mailing lists, through mailing the editor directly, something else? |
| 16:31 | <Masklinn> | s/not/note/ |
| 16:31 | <annevk> | Masklinn: IRC/bug reports/mailing list |
| 16:31 | <annevk> | Masklinn: preferably feedback is publicly tracked, but if it's a small thing you can decide to contact the editor directly |
| 16:32 | <annevk> | Masklinn: see also "Participate" in the spec |
| 16:33 | <Masklinn> | annevk: bug report? ah yes, I was looking at the whatwg home page (which does not mention the bug tracker) |
| 16:34 | <Masklinn> | annevk: and I managed to completely miss the fixed "submit review comment" control, shame |
| 16:34 | <Masklinn> | annevk: sorry for the bother, and thanks for the answer |
| 16:37 | <Hixie> | whatwg.org/newbug also |
| 16:37 | <Hixie> | if you want a detailed reply, e-mail is better |
| 16:37 | <Hixie> | if you want a place you can go to track progress in dealing with the issue, bug report is better |
| 16:40 | <Hixie> | btw, the admin⊙wwo address is just an alias to GPHemsley, me, and annevk, not technically a list. There's no discussion there. |
| 16:40 | <Hixie> | There is a private WHATWG list (has the charter members on it, for things like coordinating the copyright stuff), but it gets basically zero traffic and i send updates about any traffic that it does get to the main whatwg list each time. |
| 16:50 | <annevk> | I'm not on admin@, but I've no desire to be either :) |
| 16:50 | <Hixie> | just me and GPHemsley? |
| 16:51 | <dglazkov> | good morning, Whatwg! |
| 16:51 | <annevk> | Hixie: I think so, but maybe you subscribed annevk⊙oc or so? :-) |
| 17:02 | <GPHemsley> | jreschke++ |
| 17:03 | <jgraham> | Don't see that on here much |
| 17:04 | gsnedders | wonders why |
| 17:07 | <jgraham> | Why we don't see it much or why GPHemsley is incrementing him? |
| 17:10 | <gsnedders> | The latter. |
| 17:14 | <GPHemsley> | gsnedders: If I wait long enough, jreschke responds to mailing list messages for me. |
| 17:15 | <wycats_> | AryehGregor: have some faith |
| 17:15 | <GPHemsley> | Hixie: You cannot let annevk get away with not getting user registration requests! |
| 18:48 | <Hixie> | jonlee: yt? |
| 18:48 | <Hixie> | jgraham: yt? |
| 18:49 | <Hixie> | hober: yt? |
| 18:50 | <annevk> | What's the hashtag for TAG elections? #tagelections? |
| 18:50 | <Ms2ger> | The TAG on twitter? Hehehehe |
| 18:50 | <annevk> | I thought I'd tweet that Polyglot Markup is syntax, not architecture. |
| 18:51 | <annevk> | Hixie: http://wiki.whatwg.org/index.php?title=New_Features_Awaiting_Implementation_Interest&curid=2569&diff=8867&oldid=8864 seems like an incorrect edit |
| 18:52 | <annevk> | Hixie: the thread has nothing to do with progress events for <img> |
| 18:52 | <Hixie> | hashtags are only useful for things people want to read about :-P |
| 18:52 | <Hixie> | oops, wrong row |
| 18:52 | <Hixie> | heh |
| 18:59 | <annevk> | Hixie: oh you |
| 19:00 | <marcosc> | Hixie: given "large 2x, small 1x" and a pixel density of 1.1, is "large 2x" chosen? |
| 19:00 | <Hixie> | i don't recall; follow the algorithm and see :-) |
| 19:01 | <marcosc> | I did, and got large 2x |
| 19:01 | <marcosc> | but that seems kinda bad |
| 19:01 | <Hixie> | then large 2x is probably the right answer |
| 19:02 | <Hixie> | you generally want the image that's higher density than your display, if you don't have an exact match |
| 19:02 | <Hixie> | since scaling down is prettier than scaling up |
| 19:02 | <Hixie> | (you can lose bits, but can't invent them) |
| 19:02 | <marcosc> | understood |
| 19:02 | <Hixie> | if it's close, though, iirc the algorithm does let the UA decide exactly what the cut-off should be |
| 19:03 | <Hixie> | and if the user zooms, the old images don't disappear until the new ones are ready |
| 19:05 | <marcosc> | Hixie, unless I missed something, there doesn't seem to be any error events fired if a source can't be gotten. Is that right? |
| 19:06 | <Hixie> | you mean for the automatic updates that happen on zoom? |
| 19:06 | <Hixie> | or for the initial load? |
| 19:06 | <marcosc> | I think for both, but certainly for automatic updates |
| 19:07 | <Hixie> | for automatic updates, if the image can't be fetched, then the browser just pretends it didn't update, yeah |
| 19:07 | <Hixie> | for the initial load, the 'error' event is fired two lines below the 'load' event. |
| 19:08 | <marcosc> | ok, I was really wondering about the automatic update one |
| 19:08 | <marcosc> | I guess that can be checked in the network tab of developer tools |
| 19:08 | <marcosc> | a dev could see a 404 there |
| 19:08 | <marcosc> | or whatever |
| 19:08 | <Hixie> | my theory was that onerror means that the <img> is broken, and the image isn't broken in this case, it just keeps its previous image |
| 19:10 | <marcosc> | Hixie, that seems ok to me... I guess as long as the browser spits something out on the console, then it should be fine |
| 19:11 | <Hixie> | k |
| 19:11 | <marcosc> | thanks! |
| 19:12 | <Hixie> | if the spec is unclear, please don't hesitate to file bugs |
| 19:12 | <Hixie> | either with the tool in the spec or whatwg.org/newbug or e-mailing the list |
| 19:12 | <marcosc> | no, it's pretty clear. The problem is that I've been implementing in JS and it's not really possible to implement this part of the spec. |
| 19:13 | <marcosc> | There is just not enough information to do a 1 to 1 |
| 19:13 | <marcosc> | available in the HTMLImageElement interface, that is |
| 19:13 | <marcosc> | like, there is no readyState for images |
| 19:13 | <marcosc> | and there is no way to check the mimetype directly |
| 19:14 | <marcosc> | etc., or there is no way to check if an error already occured |
| 19:14 | <marcosc> | The parsing was fairly straight forward |
| 19:14 | <Hixie> | yeah. it's intended for browsers to implement :-) |
| 19:15 | <marcosc> | Browsers, pfff! :) |
| 19:15 | <Hixie> | if something is entirely implementable in JS, there's really not much point putting it in teh spec |
| 19:15 | <Hixie> | it could just be done in JS :_) |
| 19:16 | <marcosc> | Yeah, absolutely. Prollyfillin has been good though, because it helps people understand the problem space |
| 19:16 | <marcosc> | Like the 1.1 thing above ... and there are some other things that are confusing |
| 19:16 | <marcosc> | and some that are just ergonomic issues like I keep typing x1 instead of 1x |
| 19:17 | <Hixie> | shims are fine, but i do think there's been a kind of obsession with them recently |
| 19:17 | <Hixie> | amongst the web author community |
| 19:17 | <Hixie> | anyway, it's not bad |
| 19:17 | <marcosc> | you mean like, prollyfill.org ? :) |
| 19:17 | <Hixie> | i'm just not used to it |
| 19:18 | <Hixie> | i know not this prollyfill.org thingy |
| 19:19 | <Hixie> | btw, the premise at the top of http://briankardell.wordpress.com/2012/11/17/w3c-extensible-web-community-group/ is wrong |
| 19:19 | <Hixie> | the bottleneck in standards development right now is not the standards |
| 19:19 | <Hixie> | it's the browser vendors |
| 19:19 | <Hixie> | we're writing specs so fast the vendors can't implement them fast enough |
| 19:19 | <marcosc> | yeah, I agree |
| 19:19 | <Hixie> | (not a criticism of anything, just an observation) |
| 19:20 | <marcosc> | I personally don't care where the bottleneck is. It's nice to have a way to try out ideas |
| 19:20 | <othermaciej> | some have the impression that even if a spec is written and widely implemented but not officially finalized, that proves standards are too slow |
| 19:20 | <othermaciej> | even though such cases have little effect on ability of web content authors to use the technology |
| 19:21 | <marcosc> | what that group wants to do is really find where the pain points are ... probably once we have Web Components at lot of those pain points go away |
| 19:22 | <marcosc> | well, some do... but limitations like I pointed out in HTMLImageElement's interface will remain for a while (if not forever) |
| 19:23 | <Hixie> | othermaciej: indeed. or vice versa, when a spec is "finalised" but has no implementations, that it mans standardisation is slow (when really it means either implementation priorities are the bottleneck, or that the spec is not actually finished at all, despite the editors' wishes) |
| 19:24 | <othermaciej> | I guess CSS is a special case here because they ask implementors to expose "not officially finalized" in syntax |
| 19:29 | <jgraham> | Hixie: I'm here |
| 19:29 | <Hixie> | jgraham: has opera any input on <menu>? |
| 19:31 | <jgraham> | Hixie: Subject to the usual provisos that we don't discuss roadmap, etc. etc. I am not aware of any specific plans. Although I believe the context menu support in our extensions API might be something like the spec? |
| 19:32 | <Hixie> | jgraham: mainly i'm looking for thumbs-up or thumbs-down on either what's in the spec now or one of the proposals to vary it that were sent to the list recently |
| 19:33 | <jgraham> | Yeah, so I read the email |
| 19:33 | <jgraham> | But I'm not sure that I have thought hard enough to have a useful opinion |
| 19:34 | <jgraham> | Certainly it seems that what's in the spec isn't being implemented :| |
| 19:34 | <Hixie> | well, yeah, so that's my question... what will you implement :-) |
| 19:34 | <Hixie> | if anything :-) |
| 19:48 | <annevk> | marcosc: pain points that go away will be replaced by others |
| 19:48 | <annevk> | marcosc: and when that stops there's a new platform on the rise |
| 19:49 | <marcosc> | annevk: ok, so lets just stop all this web platform nonsense now :) |
| 19:50 | <annevk> | marcosc: I dropped "web" years ago :p |
| 19:51 | <marcosc> | heh, be cool to rename this hatwg :) |
| 19:51 | <Hixie> | annevk: dom core doesn't seem to support Window being at the top of the tree for event dispatch, btw |
| 19:51 | <Hixie> | annevk: anyway i'm looking at how to do event redispatch, and i don't think the way we're doing it is going to work |
| 19:52 | <Hixie> | annevk: because right now it requires every single spec that fires an event to go define redispatching steps |
| 19:52 | <annevk> | Window you make work by saying that for the purposes of event dispatch, it's the furthest ancestor of that tree |
| 19:53 | <Hixie> | annevk: what we need instead is a way for the HTML spec to define the tree, which includes Window and what the global object should be (since different Event objects need different prototype objects), and for the events to be dispatched like now and for the dispatching to automatically apply that tree, cloning the event object accordingly |
| 19:54 | <Hixie> | annevk: some events will need some specific rules, e.g. we need a way to figure out how to handle the different targets of focus events |
| 19:55 | <Hixie> | annevk: when focus goes from one iframe to another, and those iframes are in an iframe that is in another iframe, then the event should only be targetted up one level, not bot |
| 19:55 | <Hixie> | h |
| 19:55 | <Hixie> | the current thing for Window is a hack |
| 19:55 | <Hixie> | it contradicts what DOM core says |
| 19:55 | <annevk> | I'm pretty sure I explained somewhere in a bug how it should be written |
| 19:56 | <Hixie> | you require the dispatching steps to be invoked with redispatching steps |
| 19:56 | <Hixie> | but that doesn't work |
| 19:56 | <Hixie> | the dispatching steps are all over many specs |
| 19:56 | <Hixie> | we can't go and update a dozen specs to do this |
| 19:56 | <Hixie> | this has to happen for all events |
| 19:57 | <Hixie> | not just the ones that want it |
| 19:57 | <Hixie> | e.g. it needs to happen for dispatchEvent() |
| 19:57 | <annevk> | I was talking about Window |
| 19:58 | <Hixie> | re Window, right now the spec says to dispatch on "ancestors", and defines "ancestors" indirectly via your definitions of tree, but Window doesn't have "an ordered list of zero or more child objects" |
| 19:58 | <annevk> | in this context it does have one child object, Document |
| 19:58 | <annevk> | in the "event tree" |
| 19:59 | <Hixie> | that's a hack |
| 19:59 | <annevk> | how is it a hack? |
| 19:59 | <Hixie> | the spec says "An object that participates in a tree has [...] an ordered list of zero or more child objects" |
| 19:59 | <Hixie> | this is false for Window |
| 19:59 | <annevk> | in the context of events it participates in a tree |
| 20:00 | <Hixie> | right, the spec pretends that it's the DOM tree, but only for events, not for appendChild() |
| 20:00 | <Hixie> | that's just weird and hacky |
| 20:00 | <annevk> | no there's all kinds of trees |
| 20:00 | <annevk> | I specifically defined trees separately from node trees exactly because of this |
| 20:00 | <Hixie> | right but the only tree that is relevant to event dispatch is the DOM tree |
| 20:01 | <Hixie> | anyway my point is that we can fix this all at once when we fix redispatching |
| 20:01 | <annevk> | given Window that seems false |
| 20:01 | <Hixie> | because you can just have the host spec define the tree |
| 20:01 | <Hixie> | and it can include Window |
| 20:01 | <Hixie> | instead of saying "it's part of the tree in this case but not that one" |
| 20:01 | <annevk> | we're getting close to the point where I'd rather have HTML define all this |
| 20:02 | <annevk> | but I guess we can try to pretend there's a separation for a little longer |
| 20:03 | <Hixie> | well i don't really understand why y'all want dom core to not rely on html, but that's your problem :-) |
| 20:04 | <Hixie> | i don't mind how we define it |
| 20:04 | <Hixie> | so long as it's defined |
| 20:04 | <Hixie> | ideally without having to jump through hoops and contortions |
| 20:04 | <annevk> | I think that's mostly Ms2ger at this point |
| 20:05 | <annevk> | So when spec A says "dispatch E" it somehow needs to obtain a contextual tree from HTML if it's dispatched on either a node or Window? |
| 20:06 | <annevk> | I don't really see how to write this down in a way that remains comprehensible. |
| 20:07 | <annevk> | On top of that, how does DOM know when there's a boundary crossed in the tree it is provided and it needs to invoke the event cloning steps? |
| 20:07 | <Hixie> | the boundary is always above the Window |
| 20:08 | <annevk> | (As an aside, does it use the same object for capture and bubble? So does it need to keep track of the subtrees somehow?) |
| 20:08 | <Hixie> | how to define it... this only happens for DOM nodes, so I guess the HTML spec could define it for Document objects |
| 20:08 | <Hixie> | so: |
| 20:08 | <Hixie> | at the lowest level (the "real" target) it works like now |
| 20:08 | <Hixie> | at the higher levels, the target is always an iframe |
| 20:08 | <annevk> | oooh there's still a target? |
| 20:09 | <Hixie> | and it is as if the event was dispatched on the iframe, except you don't get a target phase |
| 20:09 | <Hixie> | it just bubbles and captures through it |
| 20:09 | <annevk> | oh |
| 20:09 | <Hixie> | or we could have a target phase i guess |
| 20:09 | <Hixie> | i don't really mind |
| 20:09 | <Hixie> | dglazkov might |
| 20:09 | <Hixie> | i guess it has to have a target |
| 20:09 | <Hixie> | otherwise you could tell it was retargetted |
| 20:09 | <annevk> | you don't want to expose that? |
| 20:10 | <Hixie> | well consider the web components / xbl case |
| 20:10 | <Hixie> | if you have a click on a button |
| 20:10 | <Hixie> | you don't care that the button has a dozen <div>s |
| 20:10 | <Hixie> | you just think it's a button |
| 20:10 | <Hixie> | should work just like today |
| 20:10 | <Hixie> | it's less important form seamless events |
| 20:10 | <Hixie> | for |
| 20:10 | <annevk> | makes sense |
| 20:11 | <annevk> | but what is the order? capture phase all the way down, target bubble target bubble target bubble ... |
| 20:11 | <Hixie> | (for xbl/web comp, the higher levels, the target is the web component, not an iframe) |
| 20:11 | <annevk> | or capture target bubble capture target bubble ... |
| 20:12 | <Hixie> | it's definitely capture (target) capture (target) capture target bubble (target) bubble (target) bubble |
| 20:12 | <Hixie> | i dunno which of the (target)s are where targetting should go |
| 20:12 | <Hixie> | each scope has to have a clone of the event |
| 20:13 | <Hixie> | but e.g. if the inner level cancels the event, the outer level should have its event updated accordingly too |
| 20:14 | <annevk> | maybe there should be a shared event object that's exposed as a separate JS object in each tree? |
| 20:14 | <annevk> | that's gonna require some pretty invasive changes though :-( |
| 20:15 | <annevk> | Hixie: target / bubble should probably go together |
| 20:16 | <Hixie> | i've been saying it's gonna require invasive changes for some time :-) |
| 20:18 | <annevk> | so I guess that's what http://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/shadow/index.html#events is about... |
| 20:20 | <annevk> | but http://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/shadow/index.html#event-dispatch seems broken |
| 20:20 | <annevk> | Hixie: Window is not always the furthest ancestor for shadow trees |
| 20:21 | <annevk> | Hixie: in any event, I won't have time to work on this I think until Feb at least |
| 20:27 | <Hixie> | annevk: k |
| 20:27 | <Hixie> | annevk: (what's the highest ancestor of a shadow tree?) |
| 20:27 | <annevk> | Hixie: I think it's ShadowRoot |
| 20:28 | <annevk> | Hixie: I would expect shadow trees to also want private events though |
| 20:29 | <Hixie> | yeah |
| 20:29 | <Hixie> | i don't really know that side as well |
| 20:29 | <annevk> | so you can't really say this is the tree, these are the JS event object scopes within the tree, make it happen |
| 20:30 | <Hixie> | maybe we just need to hook something to the root of the tree (Document, ShadowRoot) |
| 20:30 | <Hixie> | that says what to do |
| 20:30 | <Hixie> | and DOM Events hooks into that |
| 20:31 | <Hixie> | I expect I'll write a draft of a section that does this for HTML later today for seamless, and just add a note saying that you expect to get to this in DOM Core in feb |
| 20:33 | <annevk> | if you keep calling it DOM Core it might become August :p |
| 20:34 | <Hixie> | what's it called? |
| 20:34 | <annevk> | just DOM |
| 20:34 | <Hixie> | well that's confusing :-P |
| 20:34 | <Hixie> | that's as bad as the HTML spec being called HTML |
| 20:34 | <Hixie> | possibly worse :-P |
| 20:34 | <annevk> | you see, I didn't think that was bad :) |
| 20:38 | <annevk> | Hixie: so it would be useful to know the details for the various MouseEvent objects and such |
| 20:38 | <annevk> | Hixie: based on that we can then figure out if we need cloning or something more sophisticated |
| 20:39 | <Hixie> | yes |
| 20:39 | <Hixie> | a user interaction spec would be a good start :-) |
| 20:40 | <annevk> | but this is some massive suckage |
| 20:40 | <annevk> | e.g. you invoke preventDefault() |
| 20:40 | <annevk> | tada, problems with definitions everywhere |
| 20:40 | <Hixie> | yup |
| 20:40 | <Hixie> | the web evolves |
| 20:40 | <Hixie> | :-) |
| 20:41 | <annevk> | so you can introduce an abstract event concept which is dispatched and is exposed via a duplicated Event object that acts as an interface for the abstract event |
| 20:42 | <annevk> | but then all events everywhere need to acknowledge that somehow I suppose |
| 20:42 | <annevk> | and define how their respective attributes would interface in various event scopes |
| 20:43 | <annevk> | and this fails for cross-origin |
| 20:44 | <Hixie> | events usually have readonly attributes |
| 20:45 | <Hixie> | so that's not as hard as it looks, i expect |
| 20:45 | <Hixie> | btw if you can convince people to not do event retargetting, that works for me |
| 20:45 | <Hixie> | might be easier, dunno :-) |
| 20:45 | <annevk> | I guess where it's hard is UI events |
| 20:45 | <Hixie> | focus, mouse movements |
| 20:46 | <Hixie> | that might be it, dunno |
| 20:46 | <annevk> | although even there you might be able to define mouse movements as a function rather than as predefined values |
| 20:46 | <annevk> | dunno about focus |
| 20:46 | <Hixie> | mutation events, but i suggest we just don't propogate those, if we even admit that they exist |
| 20:47 | <annevk> | yeah, we don't acknowledge them and we're not going to make those more complex either I hope |
| 20:49 | <annevk> | so yeah, I guess DOM would have "event tree" which for nodes is the "node tree" unless redefined in other contexts (HTML) |
| 20:49 | <annevk> | and then it would have "event scopes" which are magic and cannot be explained without features from HTML and prolly shadow DOM |
| 20:51 | <annevk> | and it would define "abstract event" which is dispatched throughout the "event tree" is exposed per "event scope" as Event, which basically is an interface for everything "abstract event", but shields that from the scripting environment |
| 20:51 | <annevk> | Hixie: does that sound about right? |
| 20:56 | <annevk> | Hixie: reopened https://www.w3.org/Bugs/Public/show_bug.cgi?id=18780 |
| 20:56 | <Hixie> | actually i think maybe it should be more concrete than that |
| 20:57 | <Hixie> | maybe the dom spec can actually construct the tree itself by just walking the dom and when it gets to an object that defines a scope it uses the data from that object |
| 20:57 | <Hixie> | and then the other specs just have to hook into that |
| 21:34 | <Yuhong> | My hope for the TAG is to get them to finish this: http://www.w3.org/2001/tag/2011/12/evolution/ |
| 21:38 | <Yuhong> | Hixie: IE10RP Win7 |
| 21:39 | <Yuhong> | log: onsubmit start |
| 21:39 | <Yuhong> | log: action set in onsubmit before submit() |
| 21:39 | <Yuhong> | log: onsubmit end |
| 21:39 | <Yuhong> | http://software.hixie.ch/utilities/js/live-dom-viewer/saved/1974 |
| 21:39 | <Yuhong> | For http://software.hixie.ch/utilities/js/live-dom-viewer/saved/1979: |
| 21:40 | <Yuhong> | ""with submit(), return false": goes to /. |
| 21:40 | <Yuhong> | ""without submit(), return false" does nothing. |
| 21:40 | <Yuhong> | "with submit(), return true": "Document" |
| 21:41 | <Yuhong> | "without submit(), return true": "Document" |
| 21:41 | <Yuhong> | All in IE10 mode. |
| 21:42 | <Hixie> | cool, thanks |
| 21:43 | <hober> | Hixie: what's up? |
| 21:49 | <annevk> | Hixie: hmm interesting, and then Document outside a browsing context would not define a scope, etc? |
| 21:50 | <annevk> | Hixie: I guess you could then do some kind of loop for all the collected trees to do the dispatch thingie |
| 21:50 | <annevk> | Hixie: you'd still have the whole abstract event -> Event mapping mess though |
| 21:51 | <Hixie> | hober: looking for apple's input on <menu> stuff |
| 21:51 | <Hixie> | annevk: yeah, there's no getting away from it being complicated if we do this, i think |
| 21:52 | <hober> | Hixie: i'll try to drum some up |
| 21:52 | <annevk> | o_O |
| 21:52 | <annevk> | Ms2ger got a formal warning |
| 21:56 | <annevk> | I wonder why non-WHATWG people always misspell WHATWG (I've seen WHAT-WG, WHAT WG, WhatWG, ... Is it some kind of lame attempt at showing disrespect? If you're gonna talk about it as if it were an entity, at least get the name right.) |
| 22:04 | <tantek> | annevk http://en.wikipedia.org/wiki/Hanlon%27s_razor |
| 22:08 | <annevk> | tantek: fair |
| 22:08 | <annevk> | tantek: for some reason spelling mistakes in names upset me the most |
| 22:09 | <tantek> | annevk, I think you'd be used to it by now, although it's certainly taken me years ;) |
| 22:09 | <annevk> | (which is why adactio refers to me as "Anne Van Kesteren") |
| 22:10 | <tantek> | with the miscapitalization of "Van" [sic] ? |
| 22:11 | <annevk> | tantek: I wish I was, I'm over HTML5 WG now, or XForms WG (actually Forms WG), or HTML WG when they meant XHTML2 WG, but WHATWG still irks me |
| 22:11 | <annevk> | tantek: yeah, although the rules for that are kinda brutal. If you omit the first name you have to capitalize it. |
| 22:11 | <tantek> | oh interesting |
| 22:12 | <annevk> | and it sorts under K, whereas in Sweden a similar name would sort under v, so it's better to sort on full name :-) |
| 22:15 | <tantek> | so: <span class="h-card"><span class="p-name">Anne van Kesteren</span> - if you omit his given name, you have to capitalize <span class="p-family-name">Van <span class="p-sort-string">Kesteren</span></span></span> |
| 22:16 | <tantek> | :) |
| 22:16 | <annevk> | what do you know, tantek's got markup for that :-) |
| 22:20 | <tantek> | annevk - perhaps if you added it to your web page more folks might notice |
| 22:20 | <tantek> | e.g. |
| 22:20 | <tantek> | change this: <footer>Copyright © 2003-2012 Anne van Kesteren</footer> |
| 22:20 | <tantek> | to: |
| 22:21 | <tantek> | <footer>Copyright © 2003-2012 <span class="h-card"><a class="p-name p-url p-uid" href="http://annevankesteren.nl/">Anne van Kesteren</span>. If and only if you omit his given name, please capitalize "<span class="p-family-name">Van <span class="p-sort-string">Kesteren</span></span>"</span>.</footer> |
| 22:21 | <tantek> | sorry, correction: |
| 22:21 | <tantek> | <footer>Copyright © 2003-2012 <span class="h-card"><a class="p-name u-url u-uid" href="http://annevankesteren.nl/">Anne van Kesteren</span>. If and only if you omit his given name, please capitalize "<span class="p-family-name">Van <span class="p-sort-string">Kesteren</span></span>"</span>.</footer> |
| 22:21 | <tantek> | :) |
| 22:21 | <tantek> | certainly adactio would have to respect that ;) |
| 22:23 | <tantek> | one more correction (darn closing tags) |
| 22:23 | <tantek> | <footer>Copyright © 2003-2012 <span class="h-card"><a class="p-name u-url u-uid" href="http://annevankesteren.nl/">Anne van Kesteren</a>. If and only if you omit his given name, please capitalize "<span class="p-family-name">Van <span class="p-sort-string">Kesteren</span></span>"</span>.</footer> |
| 22:23 | <tantek> | apparently my markup (or cognitive in general) skills are reduced post-torn-calf-muscle :/ |
| 22:24 | <annevk> | that seems a bit excessive; is there some kind of compact thingie yet? Would be nice if this filled in all the expected classes without having to specify them: <h1 class=h-card><a href="/">Anne van Kesteren</a></h1> |
| 22:24 | <annevk> | it's beyond me why you'd want class=u-url on an <a> for instance |
| 22:25 | <annevk> | <a> means URL :-) |
| 22:25 | <tantek> | <h1 class=h-card><a href="/">Anne van Kesteren</a></h1> works |
| 22:26 | <tantek> | once you start adding the extra stuff like family-name and sort-string, you have to make the other parts explicit too |
| 22:26 | <annevk> | oh sweet |
| 22:26 | <tantek> | actually, let me try something in the php-mf2 parser |
| 22:27 | <tantek> | oh sweet, the implied property rules I specified for the URL property work just fine when there's only one URL |
| 22:28 | <tantek> | thus slightly shorter: |
| 22:29 | <tantek> | <footer>Copyright © 2003-2012 <span class="h-card"><a class="p-name" href="http://annevankesteren.nl/">Anne van Kesteren</a>. If and only if you omit his given name, please capitalize "<span class="p-family-name">Van <span class="p-sort-string">Kesteren</span></span>"</span>.</footer> |
| 22:30 | <tantek> | you can try it for yourself here: http://waterpigs.co.uk/php-mf2/ |
| 22:31 | <Hixie> | how is "DOM" still a WebApps product component |
| 22:33 | <annevk> | Hixie: I didn't change any of that |
| 22:33 | <Hixie> | i don't care, except i can never find "WebAppsWG" in the list |
| 22:33 | <Hixie> | since it sorts below "Web " |
| 22:38 | <annevk> | there's a link at the top of the spec if you're lost; I'll count this towards changing if it ever comes up |
| 22:39 | <Hixie> | i was searching for the events bug |
| 22:40 | <annevk> | Hixie: https://www.w3.org/Bugs/Public/show_bug.cgi?id=18780 |
| 22:40 | <Hixie> | yeah i found it |
| 22:40 | <annevk> | oh, was, doh :) |
| 22:40 | <Hixie> | before i complained here :-) |
| 22:42 | <Hixie> | annevk: so i guess for event redispatching actually the only thing that actually needs to be defined is the link from the Window to the <iframe> |
| 22:42 | <Hixie> | annevk: well, that plus the event-specific stuff |
| 22:42 | <Hixie> | but I mean as a general rule for disepatching |
| 22:45 | <annevk> | I think what I want is that dispatching acquires a collection of trees |
| 22:45 | <annevk> | it starts by doing the capture phase on the outermost tree, inwards; then does the target + bubbling phase, outwards |
| 22:46 | <annevk> | for each tree it creates an associated event object which proxies a shared abstract event object |
| 22:47 | <annevk> | what I haven't quite mentally figured out is how exactly the acquiring of trees is gonna work |
| 22:48 | <annevk> | in a DocumentFragment it's pretty clear it's just that, in a standalone Document it's just that too, but when there's browsing contexts it gets icky |
| 22:49 | <Hixie> | sounds about right |
| 22:50 | <Hixie> | can't you just walk the tree and when you get to the root, say "if the object has a defined <dfn>scope object for event dispatch</dfn>" (so I can give you the Window) and "if the node has a defined <dfn>surrogate event redispatch parent</dfn>" and start walking up from that again? |
| 22:51 | <Hixie> | and I just have to tell the Document that it has those objects |
| 22:51 | <Hixie> | and then we're done |
| 22:51 | <Hixie> | well except for the event cloning |
| 22:51 | <Hixie> | and magic with focus and mouse stuff |
| 22:52 | <dglazkov> | Hixie, annevk: I am back now, do I need to read the whole scrollback? |
| 22:52 | <Hixie> | we're talking about how to spec event redispatch |
| 22:53 | <dglazkov> | I feel a headache coming on |
| 22:53 | <Hixie> | hah |
| 23:01 | <annevk> | Hixie: maybe have "event parent" (defined on Document to be Window) and "event parent tree" (defined on Window to be container node) |
| 23:02 | <Hixie> | that works too |
| 23:02 | <Hixie> | what terminology should i use? |
| 23:03 | <Hixie> | well |
| 23:03 | <Hixie> | "event parent tree" doesn't work because i want to just point to the iframe |
| 23:03 | <Hixie> | and have the tree be implied |
| 23:03 | <annevk> | right the DOM spec would do the looping and building |
| 23:03 | <annevk> | maybe |
| 23:03 | <Hixie> | and it's a different relationship, "event parent" and "event parent tree" sound like they're the same thing |
| 23:03 | <annevk> | event cross-boundary parent |
| 23:03 | <Hixie> | k |
| 23:04 | <annevk> | and then whenever there's a cross-boundary parent I start building up a new tree |
| 23:04 | <annevk> | dglazkov: at some point you need to define your stuff in terms of this |
| 23:04 | <Hixie> | so for seamless i just have to say: |
| 23:04 | <Hixie> | <p>The <span>nested browsing context</span>'s <code>Window</code> object's <span>event |
| 23:04 | <Hixie> | cross-boundary parent</span> is the <span>browsing context container</span>.</p> |
| 23:05 | <Hixie> | (guaranteed to be same-origin for now) |
| 23:05 | <Hixie> | (i'll make sure not to do this if it's ever cross-origin) |
| 23:05 | <annevk> | yeah, cross-origin could only work if they share the event loop, which is nasty |
| 23:06 | <Hixie> | well iframes and their parents have to share an event loop |
| 23:06 | <Hixie> | but events leaking out of cross-origin stuff is all manner of scary |
| 23:07 | <Hixie> | hm the logs don't seem to have the above yet |
| 23:07 | <annevk> | (I suggested this terminology btw because this also works if we want to do events on completely different trees, or non-trees) |
| 23:07 | <Hixie> | oh, it crossed a day boundary |
| 23:07 | <Hixie> | nevermind |
| 23:08 | <Hixie> | ok for Window i've left the old text for now, but commented out i have: |
| 23:08 | <Hixie> | <p>If a <code>Document</code> object is associated with a <code>Window</code> object, its |
| 23:08 | <Hixie> | <span>event parent</span> is that <code>Window</code> object.</p> |
| 23:08 | <annevk> | if you want I can fix that pretty quickly |
| 23:08 | <Hixie> | i'm in no rush |
| 23:08 | <annevk> | k |
| 23:08 | <Hixie> | that last bit is just editorial |
| 23:09 | <annevk> | the abstract event object thing is what requires a bit more thinking |
| 23:09 | <Hixie> | and the hard part of the event redispatching stuff is how to clone the events |
| 23:09 | <annevk> | right |
| 23:09 | <annevk> | my funding is primarily for URL work, with other things as I get to them, so I try to stick to that for now |
| 23:09 | <Hixie> | k |
| 23:16 | <annevk> | Hixie: btw, make it cross-boundary event parent, sound a lot better |
| 23:17 | <annevk> | sounds* |
| 23:17 | <Hixie> | k |
| 23:32 | <Hixie> | AryehGregor: yt? |
| 23:33 | <Hixie> | nm |
| 23:34 | <zewt> | wow, charles-whoever trying to censor complaints of plagiarism makes me pretty much lose any vestige of whatever opinion i might still have had for the w3c |
| 23:35 | <hober> | that reminds me, time to catch up on public-webapps |
| 23:46 | <zewt> | cool, paypal broke password autocomplete in firefox, welcome back to the dark ages |
| 23:46 | <zewt> | nothing is quite as insecure as making people actually type in passwords |
| 23:53 | <smaug____> | dglazkov: http://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/custom/index.html#extensions-to-document-interface |
| 23:53 | <smaug____> | is dictionary LifecycleCallbacks really right? |
| 23:53 | <smaug____> | is that even valid webidl? |
| 23:54 | <smaug____> | I would have expected callback interface LifecycleCallbacks { created() }; or something like that |
| 23:55 | <zewt> | "we will focus our efforts on SMPTE-TT." |
| 23:56 | <zewt> | random viacom employee sure takes his ball and goes home fast at the first sign of disagreement |
| 23:56 | <Hixie> | i don't know if SMPTE-TT does pixel-perfect positioning, but if so, that is the appropriate thing to do for their use case |
| 23:56 | <Hixie> | i don't understand why they weren't trying to do that in the first placre |
| 23:56 | <Hixie> | place, even |
| 23:57 | <zewt> | but it wasn't in response to "you should do this in SMPTE-TT", it was in resposne to "what you're saying is incorrect" |
| 23:57 | <Hixie> | i'll take it either way... |
| 23:57 | <Hixie> | (i also don't understand why they're trying to do what they're trying to do) |
| 23:58 | <zewt> | i'm also a bit tired of the "we need to add *feature* because it exists in *random other spec*", as if that shortcuts the requirement to actually justify a feature |
| 23:59 | <Hixie> | especially given that there have been studies cited, including one actually available to read, that show that eye tracking experiments show that this feature is bad |