| 05:11 | <annevk> | zcorpan, yeah that's what I use too |
| 05:39 | <annevk> | thanks for filing that bug Ms2ger |
| 05:39 | <annevk> | I forgot about it :( |
| 05:39 | <annevk> | I think I reached the point where people have to file bugs or otherwise it's unlikely to happen |
| 05:52 | <annevk> | Hixie: if an API needs to be scoped to a certain origin, what terminology should be used? |
| 05:53 | <annevk> | I guess that's an overly broad question... |
| 05:55 | <annevk> | Hixie: there's one API to that enables a particular origin to make use of the API; the other API is dependent on that |
| 05:55 | <annevk> | Hixie: Notification.requestPermission(callback) -> new Notification() |
| 05:56 | <annevk> | I guess if I talk about the "origin" with that referencing HTML I should probably be okay |
| 06:00 | <annevk> | so does roc's blog post mean https://twitter.com/rocallahan is fake? |
| 06:00 | <annevk> | or is twitter not a social network? |
| 06:04 | <MikeSmith> | I thought I remember roc saying long ago that he didn't use twitter |
| 06:05 | <MikeSmith> | maybe he set up the account but never used it |
| 06:08 | <Hixie> | annevk: i'd have to see more context to answer that |
| 06:11 | <annevk> | Hixie: k, I checked it in http://dvcs.w3.org/hg/notifications/raw-file/tip/Overview.html |
| 06:12 | <annevk> | Hixie: search for "origin" and "If notifications are not allowed" (that needs to do the origin/permission check somehow) |
| 06:12 | <Hixie> | "The conceptual "default", but meaning "granted" does not exist." is grammatically bogus, btw. try "There is no equivalent of "default" meaning "granted"." or some such |
| 06:13 | <Hixie> | equivalent to, rather |
| 06:13 | <annevk> | thanks |
| 06:14 | <Hixie> | the origin stuff there seems right to me |
| 06:15 | <Hixie> | certainly i'd say it's no less tight than what i have for things like storage |
| 06:15 | <annevk> | sweet |
| 06:16 | <Hixie> | that reminds me, i had some question for you |
| 06:16 | Hixie | tries to recall what it was |
| 06:16 | <Hixie> | something abotu xhr |
| 06:17 | <Hixie> | oh, right |
| 06:17 | <Hixie> | what's the status of "chunked-text" and "chunked-arraybuffer"? |
| 06:18 | <annevk> | http://lists.w3.org/Archives/Public/public-webapps/2012AprJun/0859.html |
| 06:19 | <Hixie> | ah, thanks |
| 06:19 | <Hixie> | oh hey that was like mere days ago |
| 06:19 | <Hixie> | wonder how i missed that |
| 06:34 | <annevk> | MikeSmith: is there an option for DB-backed plus anyone who subscribes? |
| 06:34 | <annevk> | MikeSmith: I think that would be better for the Web Notifications WG |
| 06:38 | <MikeSmith> | annevk: isn't that the way I already have it set up? |
| 06:38 | MikeSmith | looks |
| 06:39 | <annevk> | MikeSmith: oh |
| 06:39 | <hsivonen> | annevk: how is the MS thing a "just have" thing compared to chunked-*? Isn't chunked-* much simpler? |
| 06:40 | <annevk> | another thing that bugs me is that it's public-web-notification / TR/notifications / hg/notifications |
| 06:40 | <annevk> | hsivonen: for whom? |
| 06:41 | <hsivonen> | annevk: for Gecko, WebKit and Presto |
| 06:41 | <annevk> | isn't it about developers? |
| 06:41 | <annevk> | and also, Stream seems likely to happen |
| 06:41 | <annevk> | I have not seen anyone oppose that |
| 06:41 | <annevk> | and having two APIs for the same thing... |
| 06:42 | <annevk> | MikeSmith: https://www.w3.org/services/list-audit/query?queryList=public-web-notification says no |
| 06:42 | <hsivonen> | annevk: doesn't the stream thing need buffering potentially tons of data? the whole point of chunked-* is that it's not buffered up |
| 06:42 | <MikeSmith> | annevk: I guess that naming inconsistency doesn't bug me nearly as much as the many other things that really bug me |
| 06:42 | <MikeSmith> | annevk: ok, checking now |
| 06:42 | <annevk> | MikeSmith: true enough |
| 06:43 | <hsivonen> | annevk: in the steam case, it seems script pulls from the stream. in the chunked-* case, XHR pushes data to the script |
| 06:43 | <Hixie> | is there a unix command line program that will just report a file's last modification time as a unix time_t to the console? |
| 06:43 | <MikeSmith> | cough fullscreen cough |
| 06:43 | <annevk> | haha |
| 06:43 | <annevk> | you mean glazman |
| 06:43 | <Hixie> | (i can do it in perl if necessary, but if there's one already...) |
| 06:43 | <annevk> | hsivonen: that's probably a point worth making on the list |
| 06:43 | <MikeSmith> | Hixie: there is one but I can't remember the name |
| 06:43 | MikeSmith | tries thinking harder |
| 06:48 | <hsivonen> | hmm. can the File API block the UI thread on reads? |
| 06:48 | hsivonen | mumbles about mount points that are actually backed by network shares |
| 06:49 | <Hixie> | i thought the file api was designed to be incredibly non-blocking |
| 06:49 | <hsivonen> | ok. then I'm misunderstanding something |
| 06:50 | <annevk> | hsivonen: are you going to make that point on the list? |
| 06:50 | <hsivonen> | annevk: yes. after breakfast |
| 06:50 | <annevk> | hsivonen: thanks; I guess with that the "other implementor" question still stands |
| 06:50 | <annevk> | but if true it does seem more justified |
| 06:54 | <MikeSmith> | annevk: I don't know why I set the list up to not be DB-backed but if you want I can ask to have it changed |
| 06:54 | <MikeSmith> | I can't change the config myself directly |
| 06:55 | <MikeSmith> | Hixie: isn't "stat -f %a FOO" what you want? |
| 06:55 | <Hixie> | aha, thanks! |
| 06:55 | <Hixie> | forgot about stat |
| 06:55 | <MikeSmith> | yeah, me too |
| 06:55 | <MikeSmith> | had to look at info coreutils |
| 06:59 | <annevk> | MikeSmith: maybe because the WG was not around when the list was setup; but yeah, lets change it |
| 07:00 | <MikeSmith> | OK |
| 07:08 | <MikeSmith> | annevk: OK, request sent |
| 07:16 | <annevk> | man |
| 07:16 | <annevk> | https://lists.w3.org/Archives/Team/team-webapps/2012Jun/0022.html is comedy gold |
| 07:16 | <annevk> | too bad nobody but the Team can read it |
| 07:17 | <hsivonen> | annevk: are you CCed or do chairs have Team access? |
| 07:17 | <annevk> | cc'd |
| 07:18 | <annevk> | only the Team has Team access afaik; not even AB |
| 07:22 | <annevk> | the 401 error for that seems bogus btw; suggests all you need is Member access |
| 07:28 | <MikeSmith> | hsivonen: about meta generator, i'm wondering what you think about the idea of minting a new meta name value that generator tools could emit instead, for the explicit purpose of indicating that they're not providing alternative text for images |
| 07:38 | <Hixie> | annevk: spill the beans man! |
| 07:54 | <Ms2ger> | Good morning, #whatwg |
| 08:01 | <MikeSmith> | Ms2ger: bonan posttagmezon |
| 08:01 | <MikeSmith> | wow, is the Tracking WG really saying that UAs can't turn DNT on by default? |
| 08:07 | <annevk> | that's so silly |
| 08:10 | <Ms2ger> | That makes a lot of sense |
| 08:11 | <Ms2ger> | If you turn it on by default, it's just going to be ignored |
| 08:11 | <annevk> | not with the legislation that's behind it |
| 08:11 | <annevk> | and if you don't turn it on by default, it's only 1% of the users that's going to bother |
| 08:12 | <annevk> | the people that prolly already use tor or some such |
| 08:12 | <Ms2ger> | I heard a figure of 10% with Firefox users |
| 08:16 | <jgraham> | In reality the problem is that the concept is silly |
| 08:16 | <jgraham> | Nobody *wants* to be tracked |
| 08:18 | <annevk> | MikeSmith: could it be that I'm hardcoded to be on the public-web-notification list too? |
| 08:18 | <annevk> | MikeSmith: with annevk⊙oc that is |
| 08:18 | <MikeSmith> | oh |
| 08:18 | <MikeSmith> | yeah man |
| 08:18 | <MikeSmith> | sorry |
| 08:18 | <MikeSmith> | will fix that now |
| 08:18 | <annevk> | no worries |
| 08:19 | <MikeSmith> | annevk: OK, removed you now |
| 08:20 | <annevk> | sweet |
| 08:20 | <annevk> | MikeSmith: so provided other people in the notifications WG agree, there's something we can publish now... |
| 08:21 | <MikeSmith> | yeah |
| 08:21 | <MikeSmith> | thanks for putting the time into |
| 08:21 | <MikeSmith> | *into it |
| 08:21 | <MikeSmith> | it will make it much easier to get the charter extended |
| 08:31 | <Ms2ger> | annevk, np (for the bug) |
| 08:40 | <annevk> | guess I should fix that now |
| 08:42 | <Ms2ger> | I have to say I was surprised how many bugs these tests caught |
| 08:44 | <MikeSmith> | speaking of tests, http://w3c-test.org/html/tests/submission/Opera/microdata/001.html looks great in Firefox Nightly |
| 08:44 | <Ms2ger> | Well, yes, David fixed the test :) |
| 08:45 | <MikeSmith> | Ms2ger: oh |
| 08:45 | <MikeSmith> | that makes a lot of them fail in Opera now I guess |
| 08:46 | <MikeSmith> | Opera is now 274 Pass / 63 Fail |
| 08:49 | Ms2ger | wants the framework to support multiple tests in one file already |
| 08:49 | <Ms2ger> | And preferably without me doing any work for it |
| 08:50 | <MikeSmith> | heh |
| 08:50 | <MikeSmith> | that's the hard part |
| 08:51 | <jgraham> | Ms2ger: The W3C framework? |
| 08:51 | <Ms2ger> | Yeah |
| 08:52 | <jgraham> | Why do you care? (serious question) |
| 08:54 | <hsivonen> | bizarre. Windows 8 Consumer Preview gets security updates but not an automatic update to Release Preview |
| 08:54 | <hsivonen> | why do they bother supporting Consumer Preview instead of upgrading it to Release Preview |
| 08:54 | <hsivonen> | ? |
| 08:56 | <MikeSmith> | hsivonen: in standalone context or as used in the the validator backend, if the vnu HTML parser can't otherwise determine a document's character encoding, does it always assume windows-1252 as the default encoding or does it user some other heuristics to try to choose a default? |
| 08:57 | <hsivonen> | MikeSmith: depends on the heuristic detector setting |
| 08:57 | hsivonen | looks up the API |
| 08:57 | <MikeSmith> | ah yeah |
| 08:58 | <MikeSmith> | hsivonen: I know in the validator backend, it uses both the chardet code and the ICU code |
| 08:58 | <hsivonen> | http://about.validator.nu/htmlparser/apidocs/nu/validator/htmlparser/sax/HtmlParser.html#setHeuristics%28nu.validator.htmlparser.common.Heuristics%29 |
| 08:59 | <MikeSmith> | hsivonen: thanks |
| 09:10 | <annevk> | Ms2ger: in our unreviewed spec algorithms? or in browsers? |
| 09:11 | <Ms2ger> | In browsers |
| 09:11 | <Ms2ger> | The spec bugs didn't really surprise me :) |
| 09:11 | <annevk> | I feel somewhat bad about them though |
| 09:15 | <Ms2ger> | Pff |
| 09:16 | <Ms2ger> | Look at parsing/serialization, you won't feel bad after that :) |
| 09:17 | <annevk> | not my work :p |
| 09:17 | <Ms2ger> | Exactly :) |
| 09:19 | <AryehGregor> | DNT is completely pointless anyway except from a political perspective. It's a way to pressure websites by saying "See, you're going against the explicit wishes of users!" even though everyone knows perfectly well that the large majority of users want that regardless of whether they say so in their browser preferences. |
| 09:20 | <AryehGregor> | It becomes a much weaker signal if it's opt-out instead of opt-in, because then you have to make the political argument "You should only be doing this if users explicitly consent!" |
| 09:20 | <AryehGregor> | But it's only a political move anyway. I believe someone in this channel once compared it to posting a sign on your car that says "Please do not break the windows." Well, no kidding. |
| 09:21 | <AryehGregor> | If users are asked in the abstract whether they want to be tracked, of course they'll say no. Per se, almost nobody wants to be tracked. The question is whether that cost is worth the benefit of greater ad revenue and therefore better free services. |
| 09:21 | <AryehGregor> | DNT trumpets the cost without paying any attention to the benefit. |
| 09:23 | <AryehGregor> | Very easy for organizations like Microsoft or Mozilla that don't see that benefit directly, and only see it accruing to Google, who's their rival or semi-rival. |
| 09:23 | <AryehGregor> | But from the perspective of the web as a whole, ad revenue is what keeps half of it propped up, and things that increase ad revenue are really important. |
| 09:23 | <AryehGregor> | But anyway. |
| 09:24 | <AryehGregor> | Ms2ger, annevk: You should never, ever be surprised at finding mounds of browser bugs when you write tests. |
| 09:24 | <Ms2ger> | Clearly |
| 09:24 | <AryehGregor> | This is why, ideally, you should write tests in conjunction with the spec. |
| 09:24 | <AryehGregor> | Preferably tests that are thorough to the point of being arguably pathological. |
| 09:24 | <Ms2ger> | I'm doing my best :) |
| 09:25 | <AryehGregor> | Link? |
| 09:25 | <Ms2ger> | http://w3c-test.org/webapps/DOMCore/tests/submissions/Ms2ger/Node-replaceChild.html / http://w3c-test.org/webapps/DOMCore/tests/submissions/Ms2ger/Node-insertBefore.html |
| 09:25 | <jgraham> | Given the choice just have the pathological tests and not the ones for other cases :) |
| 09:25 | <Ms2ger> | jgraham, exactly :) |
| 09:26 | <jgraham> | Although of course it is harder to think of pathological cases |
| 09:28 | <annevk> | AryehGregor: when I found out you were able to write much much much more comprehensive tests than I ever dreamed of I sort of gave up writing new tests |
| 09:30 | <jgraham> | So AryehGregor is actually having a negative effect on testing by discouraging others from doing it |
| 09:30 | <jgraham> | :) |
| 09:30 | <annevk> | I wouldn't quite put it that way, but I think that's what happened subconsciously for me |
| 09:30 | <annevk> | There's also enough spec bugs to fix |
| 09:37 | <jgraham> | I wonder if the range tests we unusually easy to automate or if there is something we should learn to make other testsuites more comprehensive |
| 09:37 | AryehGregor | should write more DOM tests at some point |
| 09:37 | <AryehGregor> | jgraham, there should be no big difference between Range and most other DOM features. |
| 09:37 | <AryehGregor> | There are other classes of features that can't be automated at all the same way, though. |
| 09:37 | <AryehGregor> | I wrote similar types of tests for Selection and HTML attribute reflection, FWIW. |
| 09:37 | <jgraham> | Yeah. I guess at the moment I am mostly not writing tests for DOM features per-se |
| 09:38 | <AryehGregor> | There are lots of requirements that are much harder to test. |
| 09:38 | <jgraham> | More like script scheduling, navigation, document loading, etc. |
| 09:38 | <AryehGregor> | Like, say, requirements about loading web pages require a basically different approach because the tests can't be self-contained. |
| 09:38 | <AryehGregor> | Yeah, those things are harder. |
| 09:38 | <jgraham> | I don't really know how to do better than "try to think of specific evil cases" there |
| 09:38 | <AryehGregor> | DOM stuff is easy because you can do it all in JS. |
| 09:39 | <jgraham> | Right |
| 09:39 | <AryehGregor> | Likewise, anything involving rendering is automatically harder. |
| 09:39 | <AryehGregor> | Although better reftesting frameworks could alleviate that. |
| 09:40 | <AryehGregor> | Mozilla's mochitests (test pages in JS) can do reftesting too. |
| 09:45 | <annevk> | Ms2ger: 1. doctype is or is following child 2. child is doctype or doctype is following child |
| 09:45 | <annevk> | I guess 2 |
| 09:45 | <annevk> | verbose requirements are verbose :( |
| 09:46 | <annevk> | hmm |
| 09:46 | <annevk> | the usage of either would not be correct either |
| 09:46 | <annevk> | man... |
| 09:49 | <AryehGregor> | "inclusively following"! |
| 09:50 | <annevk> | AryehGregor: should we add it? |
| 09:50 | <AryehGregor> | Eh. |
| 09:50 | <AryehGregor> | Not sure. |
| 09:51 | <annevk> | instead I'll add a note about it in the source |
| 09:51 | <annevk> | in case more of this comes up |
| 09:52 | <AryehGregor> | In math, the same kind of thing comes up with "less than". It can mean either "strictly less than" or "less than or equal to". People are usually lazy and don't specify. |
| 09:52 | <AryehGregor> | Because it's such a common phrase and it's awkward to make it longer. |
| 09:52 | <AryehGregor> | The "<" symbol is used ambiguously too. |
| 09:53 | <AryehGregor> | A lot of times people will use ⪇ if they really mean "and not equal to". |
| 09:53 | <AryehGregor> | (Unicode also has ≨, but I don't think I've seen that used.) |
| 09:53 | <annevk> | :) |
| 09:56 | <annevk> | aah fuck |
| 09:56 | <annevk> | Ms2ger: does this not apply to replace? |
| 09:56 | <annevk> | no because there the child is replaced |
| 09:56 | <annevk> | aah |
| 09:57 | <annevk> | so this was the result of copypasta most likely |
| 09:57 | <annevk> | and I just "fixed" the wrong set of steps |
| 10:21 | <AryehGregor> | Yay, it looks like sanity is finally prevailing vis-a-vis prefixing: http://blogs.msdn.com/b/ie/archive/2012/06/06/moving-the-stable-web-forward-in-ie10-release-preview.aspx |
| 10:22 | <AryehGregor> | That looks a lot like dbaron's recent proposal for Mozilla. |
| 10:30 | <jgraham> | AryehGregor: What are the requirements you had in mind for "better frameworks for reftesting" |
| 10:30 | <jgraham> | or what does Mochitest do? |
| 10:30 | <Ms2ger> | We have canvas.drawWindow |
| 10:31 | <jgraham> | That doesn't tell me much :) |
| 10:32 | <jgraham> | (I don't know all the implementation details of your reftest setup) |
| 10:33 | <AryehGregor> | jgraham, basically I just want a page to be able to take multiple snapshots that it can compare, instead of requiring one test per window load. |
| 10:33 | <AryehGregor> | I want one page that can do thousands of reftests per second. |
| 10:33 | <AryehGregor> | That's not doable if each one is a page load. |
| 10:36 | <jgraham> | Generating the ref and the test in realtime? I guess that could work |
| 10:38 | <jgraham> | I think in principle we could do that via watir, but it is a bit evil. And we were going to have a reftest type where the ref and the test were both elements in a single document, but we eventually ditched that idea (which I think was a very good move) |
| 11:02 | <hsivonen> | "Commercial video" seems to require all the bad things |
| 11:08 | <annevk> | it's like the fonts debacle, but worse |
| 11:09 | <AryehGregor> | Because normal people actually care about video, unlike fonts. |
| 11:10 | <jgraham> | Isn't that code for "because video is a much more profitable industry than fonts"? |
| 11:11 | <annevk> | prolly because all of their DRM :p |
| 11:12 | <AryehGregor> | jgraham, well, they're related, obviously, but not intrinsically so. There are unprofitable things that people are very concerned about, like privacy; and profitable things people don't care for at all, like lawyers. |
| 11:12 | <AryehGregor> | In this case they coincide, yes. |
| 11:16 | <AryehGregor> | Why do ranges use PRInt32 instead of PRUint32 for offsets? |
| 11:16 | <AryehGregor> | Argh! |
| 11:16 | <AryehGregor> | Wrong channel again. |
| 11:16 | AryehGregor | hides from Ms2ger |
| 11:16 | <hsivonen> | AryehGregor: my guess is that this MPEG-2 thing is about old terrestrial to cable relay regulations that prohibit recompression |
| 11:16 | <Ms2ger> | Going to blame hsivonen now? |
| 11:16 | <Ms2ger> | AryehGregor, DOM2 |
| 11:17 | <AryehGregor> | Hmm. |
| 11:19 | <hsivonen> | FWIW, all normal people who are aware of the relay regulations tend to think the regulations are dumb |
| 11:21 | <jgraham> | AryehGregor: /ignore Ms2ger should solve all your problems :) |
| 11:32 | <smaug____> | MikeSmith: how can I change my w3 bugzilla email address |
| 11:32 | <smaug____> | "Name and Password" is missing the normal bugzilla email field |
| 11:34 | <MikeSmith> | smaug____: I think you can't but I can |
| 11:34 | <MikeSmith> | if it's normally exposed to users but W3C bugzilla does not expose it, I don't know why it's not |
| 11:35 | <smaug____> | it is other bugzilla instances I use |
| 11:35 | <smaug____> | only W3C doesn't have it |
| 11:35 | <MikeSmith> | lemme see if there's some global admin setting I can flip |
| 11:36 | <MikeSmith> | bugzilla engrievens me |
| 11:37 | <MikeSmith> | smaug____: please try again from you preferences now |
| 11:37 | <MikeSmith> | I found the allowemailchange admin setting |
| 11:38 | <smaug____> | MikeSmith: ah, now it is there |
| 11:38 | <MikeSmith> | cool |
| 11:38 | <smaug____> | thanks |
| 11:38 | <MikeSmith> | np |
| 12:02 | <hsivonen> | there's clearly a world view difference between browser supporting X, Y and Z and publishers deal with it and publishers already having infrastructure for A, B and C and browser dealing with it |
| 12:03 | <jgraham> | Hmm, how are @defer and @async supposed to interact with createContextualFragment? |
| 12:04 | <hsivonen> | jgraham: IIRC, as if the nodes were created with createElement, but my recollection might fail me |
| 12:05 | <jgraham> | Seems to be waht gecko does, but I haven't found the spec-wise justification quite yet |
| 12:05 | <jgraham> | (haven't looked hard yet either) |
| 12:05 | <hsivonen> | jgraham: that was an area where Firefox had to go ahead of Hixie, so it's possible stuff got forgotten from spec |
| 12:07 | <hsivonen> | jgraham: based on another channel, spec-based justification will appear soon :-) |
| 12:07 | <jgraham> | There are other channels? |
| 12:07 | <jgraham> | ;) |
| 12:07 | <hsivonen> | #developrs on irc.mozilla.org |
| 12:07 | <hsivonen> | #developers even |
| 12:08 | <jgraham> | So I should assume the spec(s) are wrong here? |
| 12:08 | <hsivonen> | yes |
| 12:08 | <jgraham> | 'K |
| 12:08 | <jgraham> | Thanks |
| 12:08 | <Ms2ger> | Appeared |
| 12:09 | <hsivonen> | Ms2ger: thanks |
| 12:09 | <Ms2ger> | Np |
| 12:10 | <jgraham> | Takk |
| 12:35 | <jgraham> | Ms2ger: I seem to recall you had some comment about the timout patch for testharness.js, but I don't recall what it eas |
| 12:35 | <jgraham> | *was |
| 12:35 | <Ms2ger> | Yes |
| 12:35 | <Ms2ger> | Why you haven't landed it yet :) |
| 12:36 | <jgraham> | I guess landing what I already have works and if you did have another comment we can address it later |
| 12:36 | <Ms2ger> | If I had another comment, I can't remember what it was |
| 12:49 | <jgraham> | Ms2ger: Pushed |
| 12:49 | <Ms2ger> | Thanks |
| 12:49 | <jgraham> | Also, who thought that hg's merge conflict ui was acceptable |
| 12:49 | <jgraham> | hg resolve -m -> mark file as resolved |
| 12:50 | <AryehGregor> | jgraham, who thought that anything about hg was acceptable? |
| 12:50 | <jgraham> | hg resolve -> undo the merge you just did and go back to the unmerged state |
| 13:14 | <MikeSmith> | https://twitter.com/fantasai/status/210595248638922752 ah-hoo-ga |
| 13:18 | <MikeSmith> | twitter would be way more fun if you could mod other people's tweets up and down |
| 13:18 | <MikeSmith> | or if twitter had a poop button to let you poop on tweets |
| 13:24 | karlcow | read poo on tweets and thought it was already the essence of twitter |
| 13:42 | <hsivonen> | MikeSmith: RT is mod up |
| 13:42 | <hsivonen> | MikeSmith: "up" as in more visible that is |
| 13:42 | <MikeSmith> | yeah |
| 13:43 | <MikeSmith> | but would be great to have a down too |
| 13:44 | <hsivonen> | jgraham: does there exist an hg-compatible visual merge tool for Linux that doesn't depend on the whole of KDE yet? |
| 13:44 | <jgraham> | hsivonen: No idea, I mostly resolve mege conflicts by hand |
| 13:45 | <jgraham> | I have a feeling that this makes me A Bad Person, but merge tools generally confuse the hell out of me |
| 13:45 | <jgraham> | Whereas emacs + >>>> ==== <<<< is rather simple |
| 13:46 | <jgraham> | (does meld not work with hg?) |
| 13:46 | <hsivonen> | I don't know what meld is |
| 13:47 | <jgraham> | http://meldmerge.org/ |
| 13:47 | <hsivonen> | thanks |
| 13:48 | <hsivonen> | I have resolved merge conflicts from .rej even since it was discovered that hg pull --rebase corrupted the repo |
| 13:48 | <hsivonen> | before that I used kdiff3 |
| 13:49 | <jgraham> | The idea of rebase corrupting the repo is terrifying |
| 13:50 | <jgraham> | (rebasing local work seems like a fundamental operation in a dvcs to me) |
| 13:53 | <zewt> | i've avoided looking at hg; the sudden fragmentation in versioning tools (git, hg, bzr) makes me unwilling to spend time on it |
| 13:54 | <zewt> | also, that was a fascinating spambug |
| 13:54 | <annevk> | MikeSmith: I like wycats' reply to fantasai |
| 13:54 | <jgraham> | zewt: The situation is rather simple. bzr should be ignored unless you are working on gnome. hg is like git but with an initially shallower, but quite quickly steeper, learning curve. |
| 13:55 | <MikeSmith> | annevk: yeah |
| 13:57 | <MikeSmith> | annevk: so can we go straight to LCWD with the Notifications spec, or do you want to just do another normal WD first? |
| 13:57 | <zewt> | git sort of has the feel of cvs, in that it seems like five or ten years down the line there'll be enough experience with it to make something like it that isn't clumsy and annoying (eg. svn) |
| 13:58 | <annevk> | MikeSmith: prefer WD first |
| 13:58 | <MikeSmith> | annevk: are there any remaining issues unresolved now? (it seems like you solved the BIDI one) |
| 13:58 | <MikeSmith> | annevk: OK |
| 13:58 | <annevk> | MikeSmith: then couple of weeks later a LC unless people suddenly come up with issues (they usually do if something is published after such a long time with changes) |
| 13:58 | <MikeSmith> | ah yeah |
| 13:58 | <MikeSmith> | true that |
| 13:58 | <MikeSmith> | OK |
| 13:59 | <jgraham> | zewt: If you think svn isn't clumsy and annoying you have bigger problems than I can help you with :) |
| 13:59 | <zewt> | svn is very clean (especially compared to everything else available :) |
| 13:59 | <jgraham> | svn makes me want to kill kittens |
| 14:00 | <zewt> | the best thing about svn is how it killed cvs dead, and cvs needed killing badly |
| 14:01 | <jgraham> | Being an order of magnitude better than cvs doesn't make up for being an order of magnitude worse than any dvcs I have used |
| 14:01 | <zewt> | it's orders of magnitude cleaner than git, that's for sure |
| 14:01 | <zewt> | (i use git because it's what everyone else uses; that doesn't mean I particularly like it) |
| 14:02 | <zewt> | now if you want headaches, try git-svn :) |
| 14:03 | <zewt> | (which, surprisingly, does work when you need to bridge that gap ... but it's not a whole lot of fun) |
| 14:03 | <annevk> | hsivonen: heh, I think you found the email after which MIME types went to die |
| 14:03 | <jgraham> | I am, on the basis that local commits > impedance mismatch pain |
| 14:04 | <annevk> | hsivonen: back in the days when timbl was not lost to the semantic web |
| 14:29 | <annevk> | need more memified commit messages |
| 14:36 | <hsivonen> | annevk: either MS is willing to throw DNT under the bus for short-term feel-good press or they really calculate that Chrome won't ship with DNT defaulting to enabled so that they can really argue that the choice of product is a true proxy for setting the pref |
| 14:38 | <jgraham> | I though MS backed down on the DNT default |
| 14:40 | <annevk> | hsivonen: I think it's very strange they're trying this technical solution to a non-technical problem at all. It's false privacy. |
| 16:31 | <MikeSmith> | OK, HTML WG called completed |
| 16:31 | <MikeSmith> | end of a long day |
| 16:31 | MikeSmith | wanders off to ingest some bath salts |
| 17:12 | <TabAtkins> | hsivonen: Why wouldn't <template> work with the XHTML serialization? |
| 17:14 | <Ms2ger> | TabAtkins, if you make the children not end up in the DOM? |
| 17:15 | <TabAtkins> | But XHTML parses into a DOM. |
| 17:19 | <TabAtkins> | Ms2ger: Am I missing something? |
| 17:20 | <Ms2ger> | Either you or me |
| 17:20 | <TabAtkins> | Damn, that's unhelpful then. |
| 17:20 | <TabAtkins> | Is the problem that you can't write it in XHTML, that it won't serialize to XHTML, or that it won't parse into an infoset? |
| 18:15 | <karlcow> | TabAtkins: if a browser keeps the unprefixed version of a CSS property in its engine, we are back to step 1. Some authors will not bother and put the -webkit- version only as it is happening now. |
| 18:19 | <TabAtkins> | karlcow: ...and those authors' pages won't work on other browsers. That group very quickly becomes an extreme minority. |
| 18:22 | <karlcow> | well, then we respectfully disagree. |
| 18:23 | <TabAtkins> | There's not really anything to disagree about. This is a factual matter, because we've gone through the "add unprefixed version, keep prefixed version" dance several times already. New prefix usage drops to a trickle. |
| 18:23 | <TabAtkins> | I can't cite data showing this, though. |
| 18:25 | <karlcow> | We disagree, because a user doesn't care about minority. The site is working or not working and this is what matters. But you know the factual matter and I know it. We just don't agree on its importance. |
| 18:26 | <TabAtkins> | The user also doesn't care about politics if the page they visit stops working properly, because it's an unmaintained page written before unprefixing, and uses only the prefixed versions. |
| 18:44 | <jgraham> | Hmm, the only rule is that if something is needed by the platform everyone should be free to implement it |
| 18:44 | <jgraham> | If content requires -webkit- everyone should implement it until that is no longer the case, perhaps forever |
| 18:47 | <hsivonen> | jgraham: [citation needed] for MS backing down on DNT default |
| 18:48 | <hsivonen> | TabAtkins: I thought the template spec said XML to DOM mapping won't change |
| 18:58 | <jgraham> | hsivonen: Oh it seems I misunderstood and thought that something phrased as fact was based in more than speculation |
| 19:02 | <jgraham> | I'm not sure that there's a huge difference between them setting the default and setting the homepage to read "IE 10: Better privacy controls. [Click here] to tell advertisers not to track you on the internet" |
| 19:14 | <TabAtkins> | jgraham: I agree. I also think we should engineer the process towards a lesser chance of needing to implement prefixes forever. |
| 19:14 | <TabAtkins> | hsivonen: Pretend I'm dumb (because I am). What's your objection on those grounds? |
| 19:24 | <jgraham> | TabAtkins: We should realise that prefixes are a failed experiment and eliminate them from the process :) |
| 19:24 | <TabAtkins> | I'm down with dbaron's plan. |
| 19:26 | <jgraham> | The one where we get two interoperable implementations in testing branches before anything is turned on in stable? |
| 19:27 | <TabAtkins> | That's one of the paths, yes. |
| 20:03 | <Hixie> | prefixes aren't necessary if the spec editor commits to making sure the spec never specs something incompatible with anything shipped |
| 20:03 | <Hixie> | if the semantics really need to change, it's just a matter of also changing the names at the same time |
| 20:03 | <Ms2ger> | A spec editor? Where? |
| 20:10 | <Hixie> | Ms2ger: if there's no spec editor, prefix or no prefix doesn't matter |
| 20:41 | <TabAtkins> | Hixie: I would think that a minor difference in parsing SVG <script> over time is better than a permanent minor difference in parsing SVG <script> versus HTML <script>. |
| 20:41 | <shepazu> | +1 |
| 20:43 | <TabAtkins> | In terms of confusion to authors, at least. |
| 20:44 | <TabAtkins> | Especially since I don't even know what the difference between them is. |
| 20:44 | <TabAtkins> | Hasn't ever affected any scripts I've written in SVG. |
| 20:44 | <TabAtkins> | Nor styles, since I presume whatever the problem is is consistent for <style>. |
| 20:46 | <Hixie> | they're different |
| 20:46 | <TabAtkins> | Well that's just dumb. |
| 20:46 | <Hixie> | with <style> i think the only different is <![CDATA[ ]]> blocks |
| 20:46 | <Hixie> | with <script> the differences are more subtle and affect things like document.write() |
| 20:46 | <Hixie> | the model used by SVG <script> in HTML is better than the model used by HTML <script> in HTML |
| 20:46 | <Hixie> | (significantly simpler) |
| 20:46 | <Hixie> | (closer to what XML does) |
| 20:47 | <shepazu> | Hixie: but will HTML script developers know about the differences? will it trip them up to code script for SVG? |
| 20:48 | <TabAtkins> | Heh, then maybe we should just make all scripts inserted by document.parse() be svg scripts. ^_^ |
| 20:48 | <Hixie> | there are many disadvantages to the current model, that's why i was against it. but that river was crossed years ago. |
| 20:48 | <Hixie> | TabAtkins: we just shouldn't have document.parse() :-P |
| 20:48 | <Hixie> | (and certainly shouldn't let <script> blocks get executed by it) |
| 20:50 | <TabAtkins> | That doesn't help <template> with script in it, i suppose. |
| 20:50 | <Hixie> | <template> shouldn't execute script either |
| 20:50 | <Hixie> | not sure what should happen when you instantiate them |
| 20:50 | <Hixie> | but probably nothing either |
| 21:07 | <TabAtkins> | Dunno. If scripts dont' run, then it's a non-issue and we can just say they're all html script elements. |
| 21:07 | <TabAtkins> | But <style> is still relevant. |
| 21:20 | <Hixie> | seems weird to me that we'd want to allow <svg><![CDATA[...]]> but not <svg><style><![CDATA[...]]> |
| 21:21 | <Hixie> | given that it'd work everywhere else in svg |
| 21:26 | <TabAtkins> | It also seems weird to me that it actually matters which syntax we choose for <style> elements. Life is weird like that. |
| 21:52 | <Hixie> | TabAtkins: yeah well you'll notice i don't care much about the specifics, i just don't want the spec to churn :-) |
| 23:00 | <TabAtkins> | Hixie: What's your definition of "churn" here? If it's "change, at all", then I'm sad. |
| 23:01 | <Hixie> | by "churn" i mean "change from one workable solution to another workable solution", more than just any change at all |
| 23:01 | <Hixie> | i mean, i wouldn't call a clear bug fix "churn" |
| 23:01 | <Hixie> | if you see what i mean |
| 23:02 | <Hixie> | there's also the issue of implementations -- how many, how stable, etc |
| 23:02 | <tantek> | churn = change without noticeable improvement? |
| 23:02 | <Hixie> | "noticeable" is maybe too little an adjective |
| 23:02 | <Hixie> | "significant", maybe |
| 23:02 | <Hixie> | or "worthy" |
| 23:03 | <Hixie> | focusing on the word "churn" is unhelpful to describing my overall motivations here, i used the word maybe too loosely |
| 23:03 | <Hixie> | my core point was that change has a cost, and we should make sure to do better than break even |
| 23:03 | <Hixie> | (especially considering opportunity cost) |
| 23:05 | <hober> | Hixie: thanks for that email :) |
| 23:05 | <Hixie> | dude that thread was some level of special |
| 23:05 | <hober> | agreed |
| 23:05 | <Hixie> | your CP has a diff for kitten's sake |
| 23:06 | <hober> | :) |
| 23:06 | <tantek> | Hixie - you still pay attention to CPs? ;) |
| 23:06 | <Hixie> | no, i pay attention to hober :-) |
| 23:06 | <Hixie> | he cc'ed me |
| 23:11 | <jwalden> | for any Opera folk around: you seem to be implementing |new Date(new String("2012-01-31T00:00:00.000Z")).valueOf()| wrong, it should return 1327968000000 but instead returns NaN |
| 23:12 | <Hixie> | ok i just spent five minutes trying to understand why someone would want <a scoped> |
| 23:12 | <Hixie> | only to realise that i misread their e-mail |
| 23:12 | <Hixie> | they were saying <link rel=stylesheet scoped>, not "link scoped" |
| 23:12 | <gsnedders> | jwalden: Known bug |
| 23:14 | <TabAtkins> | Hixie: Were they asking for <link rel=stylesheet> outside of <head> too? |
| 23:15 | <Hixie> | yes |
| 23:15 | <Hixie> | though this e-mail is giving me a headhache |
| 23:15 | <Hixie> | (http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Mar/0002.html) |
| 23:15 | <jwalden> | gsnedders: cool; it is also known to Mozilla :-D but that's changing today \o/ |
| 23:15 | <jwalden> | ("This far and no further!") |
| 23:15 | <Hixie> | reading through it for like the fifth time it's starting to make sense |
| 23:16 | <Hixie> | (my fault, not theirs, i think) |
| 23:16 | <TabAtkins> | Still, that's just <style scoped>@import "foo.css";</style> |
| 23:16 | <Hixie> | yeah, you have an e-mail later in the thread on that |
| 23:16 | <gsnedders> | jwalden: Also, can we just get date parsing in some spec? >_> |
| 23:16 | <TabAtkins> | Heh, kk. |
| 23:16 | <jwalden> | gsnedders: :-) |
| 23:16 | <Hixie> | btw, the way people refer to attributes as @foo or element[foo] really confuses me |
| 23:17 | <Hixie> | e.g. i read element[foo] _as a selector_, not as <element foo> |
| 23:17 | <gsnedders> | jwalden: And work out what's happening with __proto__, etc., etc., etc. |
| 23:17 | <TabAtkins> | @ is pronounced "at", which is clearly short for "attribute". |
| 23:17 | <Hixie> | what is so hard about writing foo="" or <element foo>? |
| 23:17 | <Hixie> | @ is the address operator :-P |
| 23:17 | <jwalden> | gsnedders: the ISO subset microformat is the current solution to that; it's a longer-termish solution, but I think it's workable enough |
| 23:17 | <TabAtkins> | And using selectors as a shorthand for creating elements is common enough. |
| 23:17 | <Hixie> | i agree that it's common |
| 23:17 | <jwalden> | & is the address operator :-P |
| 23:18 | <gsnedders> | jwalden: And drop everything else? That's not web compatible. |
| 23:18 | <TabAtkins> | foo="" implies the empty-string value, which isn't always what you want. |
| 23:18 | <Hixie> | (@foo comes from xpath) |
| 23:18 | <Hixie> | foo="..." |
| 23:18 | <jwalden> | gsnedders: not drop everything, just have people stop using the old junk |
| 23:18 | <Hixie> | i think 'the foo="" attribute' is clear |
| 23:18 | <TabAtkins> | That's like, 5 more characters than @foo |
| 23:18 | <gsnedders> | jwalden: If we're not dropping it, we should spec it. |
| 23:18 | <tantek> | yeah Twitter took over "@" as a prefix. XPath loses. |
| 23:18 | <Hixie> | TabAtkins: well we wouldn't want to run out of _characters_ :-P |
| 23:18 | <jwalden> | gsnedders: disagree; but maybe it could be dropped in the longer term |
| 23:19 | <TabAtkins> | Hixie: Exactly. |
| 23:19 | <jwalden> | anyway |
| 23:19 | <jwalden> | fundamentally I don't think you spec ridiculous blatherskite |
| 23:19 | <jwalden> | we probably disagree on this point |
| 23:19 | <tantek> | Hixie, I think 'foo' attribute is fine |
| 23:19 | <TabAtkins> | The confusing part is when discussion of attributes is mixed with discussion of at-rules. |
| 23:19 | <tantek> | as is 'float' property |
| 23:19 | <gsnedders> | jwalden: Maybe I'm just tired of reverse-engineering others whenever we have yet another site compat. bug because of some weird date parsing edge-case. |
| 23:19 | <TabAtkins> | jwalden: You spec ridiculous blatherskite iff the web depends on it. |
| 23:20 | <jwalden> | TabAtkins: yeah, we disagree on this point, at the edges |
| 23:20 | <Hixie> | tantek: that works too (though i prefer to use that for css props and values) |
| 23:20 | <tantek> | TabAtkins - I had to specifically exclude @import @charset @media @font-face from my plain text auto-linker. |
| 23:20 | <TabAtkins> | jwalden: Do you mean that we disagree about how many sites constitute "the web depends on it"? Or something else? |
| 23:20 | <tantek> | Hixie, in general, single-quotes for standards terms seems to work pretty well, when followed up by what kind of term it is if not obv from context. |
| 23:21 | <tantek> | *single-quoting |
| 23:21 | <Hixie> | TabAtkins: in this particular e-mail, the guy uses link[scoped] about 15 lines above an actual attribute selector |
| 23:21 | <TabAtkins> | Hixie: Get a better context-aware parser. |
| 23:21 | <tantek> | Hixie, it's probably an XML/XPath/Java person I'm guessing |
| 23:21 | <tantek> | they've got odd habits |
| 23:22 | <Hixie> | TabAtkins: you mean take a break? no way! :-P |
| 23:22 | <Hixie> | tantek: nah xpath people don't use css selectors :-P |
| 23:23 | <tantek> | Hixie - good point :) |
| 23:23 | <jwalden> | TabAtkins: partly that truly awful stuff, if you can not-spec it long enough, can die if only you let it; that may not matter for date parsing, but I am as yet unconvinced that the ISO format is an unworkable way to give a format that will Just Work |
| 23:23 | <jwalden> | anyway |
| 23:23 | <jwalden> | this is probably not worth arguing about |
| 23:23 | <kennyluck> | foo="" is just always confusing. foo="…" might me interpreted as not including the empty string as a value. It itself is too lengthy as compared to @foo anyway. |
| 23:23 | <kennyluck> | s/me/be/ |
| 23:27 | <Hixie> | @foo is just wrong imho because there's no @ anywhere near the attribute either in HTML or the DOM :-) |
| 23:28 | <TabAtkins> | Silly CSS 2.1, your grammar has long-standing silly errors. |
| 23:28 | <kennyluck> | TabAtkins, and yet I have no idea why you want to borrow the never used <value> to css3-variables. |
| 23:29 | <TabAtkins> | kennyluck: I don't want to, but it's necessary right now. What I want to do is define <value> in Syntax and use that. |
| 23:30 | <TabAtkins> | Or do something similar, like saying that it's literally anything that successfully parses as a property value. |
| 23:30 | <TabAtkins> | With Syntax making that unambiguous. |