| 00:00 | <jamesr_> | http://www.clipartbest.com/cliparts/RiA/yyX/RiAyyXeoT.jpeg mebbe? |
| 00:01 | <jamesr_> | i am shocked at how hard it is to find the happy anime face i want on the internet |
| 00:02 | <jamesr_> | http://keikakudoori.files.wordpress.com/2009/09/happy-face.jpg ? |
| 00:02 | <jamesr_> | even bing isn't helping here |
| 00:02 | <Hixie> | anime is weird |
| 00:02 | <zewt_> | window.is_mobile = (function (a) { |
| 00:02 | <zewt_> | return (/(android|bb\d+|meego).+mobile|avantgo|bada\/|blackberry|blazer|compal|elaine|fennec|hiptop|iemobile|ip(hone|od)|iris|kindle|lge |maemo|midp|mmp|mobile.+firefox|netfront|opera m(ob|in)i|palm( os)?|phone|p(ixi|re)\/|plucker|pocket|psp|series(4|6)0|symbian|treo|up\.(browser|link)|vodafone|wap|windows (ce|phone)|xda|xiino/i.test(a)||/1207|6310|6590|3gso|4thp|50[1-6]i|770s|802s|a wa|abac|ac(er |
| 00:02 | <Hixie> | these people look like something between being cross and being asleep |
| 00:02 | <zewt_> | |oo|s\-)|ai(ko|rn)|al(av|ca|co)|amoi|an(ex|ny|yw)|aptu|ar(ch|go)|as(te|us)|attw|au(di|\-m|r |s )| |
| 00:03 | <zewt_> | avan|be(ck|ll|nq)|bi(lb|rd)|bl(ac|az)|br(e|v)w|bumb|bw\-(n|u)|c55\/|capi|ccwa|cdm\-|cell|chtm|cldc|cmd\-|co(mp|nd)|craw|da(it|ll|ng)|dbte|dc\-s|devi|dica|dmob|do(c|p)o|ds(12|\-d)|el(49|ai)|em(l2|ul)|er(ic|k0)|esl8|ez([4-7]0|os|wa|ze)|fetc|fly(\-|_)|g1 u|g560|gene|gf\-5|g\-mo|go(\.w|od)|gr(ad|un)|haie|hcit|hd\-(m|p|t)|hei\-|hi(pt|ta)|hp( i|ip)|hs\-c|ht(c(\-| |_|a|g|p|s|t)|tp)|hu(aw|tc)|i\-(20|go|ma)|i230|iac( |\-|\/)|ibro|idea|ig01|iko |
| 00:03 | <zewt_> | ^ that being 50% of one line of code makes me sad for the internet |
| 00:04 | <TabAtkins> | =^_^= is a cat, due to the whiskers. |
| 00:04 | <TabAtkins> | zewt_: Looks like someone did some regex golfing on it? |
| 00:05 | <zewt_> | ψ(｀∇´)ψ is the double-bird |
| 00:05 | <TabAtkins> | It's a bird giving the double bird, making it a triple bird. |
| 00:05 | <zewt_> | which makes me wonder why it's an ios built-in |
| 00:06 | <zewt_> | for *･゜ﾟ･*:.｡..｡.:*･'(*ﾟ▽ﾟ*)'･*:.｡. .｡.:*･゜ﾟ･* you'll have to draw your own conclusions |
| 00:07 | <jamesr_> | zewt_: ¯\_(ツ)_/¯ |
| 00:09 | <Hixie> | surely >^_^< is more catlike than =^_^= |
| 00:09 | <TabAtkins> | Man, don't argue with idioms. |
| 00:09 | <Hixie> | >^o^< |
| 00:20 | <jamesr_> | /^_^\ |
| 00:21 | <astearns_> | ^ↀᴥↀ^ |
| 00:21 | <jamesr_> | woah, bustin' out the big codepoints |
| 00:22 | <TabAtkins> | ^̸̈́_̵̊^̷̀ |
| 00:23 | <Hixie> | ☺ |
| 01:04 | <MikeSmith> | Hixie: what's the status on landing the loading stuff in the HTML spec |
| 01:04 | <MikeSmith> | Hixie: blocked on TC39? |
| 01:12 | <Hixie> | MikeSmith: abandoned, as far as i'm aware. |
| 01:13 | <MikeSmith> | wha |
| 01:13 | <MikeSmith> | I guess I missed that memo |
| 01:14 | <Hixie> | nobody showed any interest :-( |
| 01:14 | <MikeSmith> | well that sucks |
| 01:14 | <Hixie> | i'm still up for speccing it if it's something people want |
| 02:45 | <MikeSmith> | for anybody here who might be interested, I just set up an TLS-enabled instance of the web-platform-tests runner, at https://w3c-test.org:9443 |
| 02:45 | <MikeSmith> | based on code from a pending PR from jgraham https://github.com/w3c/web-platform-tests/pull/1302 |
| 02:47 | <MikeSmith> | at this point the TLS support is intended just for tests that specifically require, not in general for the overall testsuite |
| 02:49 | <MikeSmith> | first thing I realize is that we if we were to want to TLS-enable the running of the whole testsuite, we've got tons of mixed-content cases in there we'd need to fix |
| 08:06 | <MikeSmith> | how come in gecko MessageChannel is still under a flag |
| 08:10 | <MikeSmith> | just blocked on getting it enabled in workers? |
| 08:10 | <MikeSmith> | https://bugzilla.mozilla.org/showdependencytree.cgi?id=952139&hide_resolved=1 |
| 08:19 | <foolip> | Hixie: pong |
| 08:24 | <foolip> | I saw https://www.w3.org/Bugs/Public/show_bug.cgi?id=27102 and will update WebVTT to match |
| 08:40 | <annevk_> | MikeSmith: hmm, BroadcastChannel is due to blobs |
| 08:42 | <MikeSmith> | annevk_: seems like smaug is on it |
| 08:42 | <MikeSmith> | (based on bugzilla comments) |
| 08:42 | <MikeSmith> | I mean just as far as knowing what the status isu |
| 08:44 | <MikeSmith> | fyi for anybody interested, I move the TLS-enabled instance of the web-platform-tests runner to port 443, so https://w3c-test.org works now (and https://w3c-test.org:9443 no longer does) |
| 08:47 | <annevk_> | Hmm |
| 08:48 | <annevk> | It seems when running https://w3c-test.org/encoding/single-byte-decoder.html online a bunch of tests timeout |
| 08:48 | <MikeSmith> | annevk: yeah |
| 08:48 | <MikeSmith> | but they also timeout at http://w3c-test.org/encoding/single-byte-decoder.html |
| 08:49 | <MikeSmith> | annevk: I was telling you this myself here yesterday :) |
| 08:49 | <annevk> | MikeSmith: apparently I can't actually read |
| 08:50 | <annevk> | MikeSmith: should we fix that somehow? |
| 08:50 | <MikeSmith> | sure |
| 08:50 | <MikeSmith> | question is, how |
| 08:51 | <MikeSmith> | I don't know why it's timing out |
| 08:51 | <MikeSmith> | haven't even looked at the console output yet |
| 08:53 | <annevk> | MikeSmith: I think all the fetches just take too long and the harness decides to call it a day |
| 08:53 | <MikeSmith> | annevk: nothing at all logged to console in firefox as far as I can see |
| 08:53 | <MikeSmith> | ah ok |
| 08:54 | <annevk> | MikeSmith: so we need to signal to the harness it takes longer I guess |
| 08:54 | <MikeSmith> | yeah the harness provides some option for doing exactly like that but I forget what it is |
| 08:55 | <annevk> | the downloading of those files btw violates mimesniff |
| 08:56 | <annevk> | I have no sympathy for that |
| 08:57 | <zcorpan_> | Hixie: i know some web developers want the "lazyload" aspect for images at least |
| 08:57 | <MikeSmith> | annevk: I have no sympathy or whatever engineer decided to make it do that |
| 08:59 | <zcorpan_> | MikeSmith: jgraham: about tls, do we have a way to indicate that a test should be run as https? |
| 09:02 | <MikeSmith> | zcorpan_: nope |
| 09:02 | <MikeSmith> | not as far as I know |
| 09:02 | <MikeSmith> | but I think we don't yet have many tests in that category, do we? |
| 09:05 | <zcorpan_> | some websocket tests at least iirc |
| 09:07 | <MikeSmith> | yeah |
| 09:07 | <MikeSmith> | those are the only ones I remember specifically |
| 09:10 | <MikeSmith> | zcorpan_: but I think we do probably have quite a few tests that are coded in way that assumes they're being served over normal http |
| 09:11 | <MikeSmith> | the webmessaging tests do at least |
| 09:11 | <foolip> | zcorpan_: do you have tools for grepping a large body of real Web content? |
| 09:12 | <zcorpan_> | foolip: 100,000 pages from last year not including external resources |
| 09:12 | <foolip> | zcorpan_: can you check how createCDATASection is typically used? |
| 09:13 | <zcorpan_> | sure |
| 09:14 | <foolip> | and can I get the data myself somehow? |
| 09:15 | <zcorpan_> | also see https://github.com/search?l=javascript&o=desc&q=createcdatasection&s=&type=Code&utf8=✓ |
| 09:15 | <zcorpan_> | yep, http://webdevdata.org (data set 2013-09-01 102,000 pages is the one i have) |
| 09:16 | <foolip> | GitHub search usually finds mostly WebKit/Blink test cases, but sometimes it works, sure |
| 09:16 | <Ms2ger> | And Gecko test cases |
| 09:16 | <zcorpan_> | httparchive+bigquery is supposedly kickass but i haven't tried to use that yet |
| 09:17 | <foolip> | I'm trying to figure out if httparchive actually has the response body |
| 09:18 | <zcorpan_> | it does somewhere, but i think you want to use bigquery to interact with it instead of downloading it |
| 09:18 | zcorpan_ | finds https://www.igvita.com/2013/06/20/http-archive-bigquery-web-performance-answers/ - not sure if it's still accurate |
| 09:19 | <foolip> | I've read that before, but the example looks like it's polling the URL only |
| 09:19 | <foolip> | "all you need to do is download and import ~400GB of raw SQL/CSV data" actually seems like not a problem, if I could just find where to download it :) |
| 09:19 | <zcorpan_> | ./4b/charter97.org_4bb84556534ed2034958e8fd4799058f.html.txt:targetNode.appendChild(document.createCDATASection(elementsObject[key])); |
| 09:19 | <zcorpan_> | ./57/awaytravel.ru_57db32e4f1d4a1b51b513efd9913fd14.c++:targetNode.appendChild(document.createCDATASection(elementsObject[key])); |
| 09:19 | <zcorpan_> | ./8f/16fan.com_8fe9894282996630af7e47dc04f1d27f.html.txt: targetNode.appendChild(document.createCDATASection(elementsObject[key])); |
| 09:19 | <zcorpan_> | ./cb/italia-ru.com_cb56b23a7ef834095755d9c071b7fd69.c++:targetNode.appendChild(document.createCDATASection(elementsObject[key])); |
| 09:19 | <zcorpan_> | ./d4/pegipegi.com_d43dca92b28b3ea685371ef18a89b7d6.html.txt:targetNode.appendChild(document.createCDATASection(elementsObject[key])); |
| 09:20 | <Ms2ger> | Looks like a library |
| 09:20 | <foolip> | yep, and that case would work fine if createCDATASection were aliased to createTextNode |
| 09:24 | <zcorpan_> | foolip: https://github.com/HTTPArchive/httparchive/issues/6#issuecomment-32502849 |
| 09:25 | <foolip> | zcorpan_: interesting! |
| 09:37 | <jgraham> | zcorpan_: The websockets tests don't rely on th etop level html file being served over https, do they? |
| 09:39 | <foolip> | zcorpan_: http://httparchive.webpagetest.org/habodies.php?run=20141015 is the most recent with complete data it seems |
| 09:41 | <jgraham> | annevk: <meta name=timeout content=long> or whatever <meta> syntax is |
| 09:41 | <jgraham> | (before the <script> elements) |
| 09:42 | <jgraham> | Running the whole testsuite over https seems like a non-goal |
| 09:45 | <annevk> | jgraham: will add |
| 09:45 | <MikeSmith> | jgraham: wouldbe nice at least if any new tests didn't be hardcoded with assumptions that they're being run over normal http |
| 09:46 | <MikeSmith> | plus, TLS is more fun |
| 09:46 | <foolip> | zcorpan_: well actually, I'm not finding the actualy bodies, just a large number of identical .har files in the end |
| 09:47 | <darobin> | foolip: it hid the bodies, looked at you, then went ".har .har .har!"? RUN! |
| 09:47 | <zcorpan_> | foolip: weird. ask in the bug |
| 09:47 | darobin | gets his coat |
| 09:50 | <annevk> | MikeSmith: jgraham: https://github.com/w3c/web-platform-tests/pull/1421 |
| 09:51 | <annevk> | jgraham: actually, running the test suite over TLS should be a goal |
| 09:51 | <annevk> | jgraham: e.g. if HTTP/2 ends up requiring HTTPS |
| 09:54 | <jgraham> | AFAICT the only effect of running the testsuite over TLS is that debugging gets harder because e.g. Wireshark no longer works |
| 09:55 | <jgraham> | This is a testsuite that is primarilly designed to be run on your local computer so there is no integrity concern |
| 09:56 | <jgraham> | And in cases where you *are* testing HTTPS/cross protocol forcing the top level file to be protocol agnostic makes writing tests much harder because you need to detect whether you're doing http->https or viceversa |
| 09:56 | <jgraham> | HTTP/2 is a whole different kettle of fish |
| 09:57 | <jgraham> | We will need a seperate HTTP/2 server and… I don't know what, exactly |
| 09:58 | <annevk> | It seems useful to run all these tests over HTTP/2, especially network-sensitive tests |
| 10:00 | <jgraham> | In practice it seems unlikely that we are going to run all 200,000 tests over two different protocols |
| 10:01 | <jgraham> | But this might be a thing to worry about when we actually have a HTTP/2 server |
| 10:02 | <MikeSmith> | annevk: nice, now 501 passes |
| 10:05 | <MikeSmith> | annevk: tested and reviewed and merged your PR all from Firefox Nightly running on my phone, on a train |
| 10:05 | <annevk> | heh |
| 10:06 | <MikeSmith> | I tried it in Chrome on my phone but here also it does the download thing |
| 10:11 | <zcorpan_> | MikeSmith: while you're at it, can you write a testsuite for dir="" rendering rules on your phone? |
| 10:11 | <jgraham> | MikeSmith: I think that's zcorpan_ for "Fuck You" |
| 10:12 | <jgraham> | ;) |
| 10:12 | <zcorpan_> | heh |
| 10:14 | <MikeSmith> | zcorpan_: in the words of my idol Doug Crockford, Don't harsh my mellow |
| 10:14 | <zcorpan_> | (i'm not looking forward to testing dir="" but i have it on my todo) |
| 10:17 | <annevk> | zcorpan_: can't you use some of Hixie's work? |
| 10:18 | <zcorpan_> | annevk: possibly, i'm not aware of his work |
| 10:21 | <Ms2ger> | annevk, btw, we should run all tests with application/xhtml+xml too |
| 10:21 | <annevk> | Ms2ger: why? |
| 10:23 | <jgraham> | Well some of them certainly depend on xhtmlness |
| 10:23 | <jgraham> | Or htmlness, rather |
| 10:24 | <jgraham> | So having all tests run in both document types ensures that you test those cases |
| 10:25 | <jgraham> | ofc having everything run in 2 document formats over 2 protocols starts to balloon your runtime enormously for relatively small benefit |
| 10:27 | <annevk> | It seems like a strange comparison |
| 10:28 | <jgraham> | Well it's actually a thing that CSS does today |
| 10:32 | <annevk> | They still do that? wow |
| 10:32 | <annevk> | When was the last time we found a bug that way? |
| 10:32 | <jgraham> | No idea |
| 10:38 | <zcorpan_> | also quirks mode, almost standards mode |
| 10:38 | <zcorpan_> | different encodings |
| 10:48 | <zcorpan_> | i think it makes more sense to use a single version of a test for the bulk of the tests, and have opt-in to several versions for specific tests somehow |
| 10:49 | <zcorpan_> | so far the opt-in is in the test itself or having several files for a test |
| 10:51 | <zcorpan_> | possibly the opt-in should be different for tests that should run over several protocols |
| 10:57 | <jgraham> | A long time ago the plan was to have per-directory manifest overrides mapping files to tests |
| 10:58 | <jgraham> | e.g. {foo.html: [foo.html?bar=baz]} |
| 10:58 | <jgraham> | You can imagine adapting that idea to get top-level files served over https or http/2, although it becomes cumbersome if that becomes the default |
| 10:59 | <jgraham> | Or s/default/very common/ |
| 11:02 | <zcorpan_> | i guess it's possible at some point in the future that http/2 is more interesting than http |
| 11:17 | <annevk> | That's certainly the goal |
| 11:17 | <annevk> | And unlike XHTML it has the incentives |
| 11:46 | <zcorpan_> | annevk: https://dom.spec.whatwg.org/#dom-document-characterset is there a reason to do it this way instead of making the right column the canonical case in the encoding spec? |
| 11:47 | <zcorpan_> | having different case for different APIs seems annoying |
| 11:49 | <gsnedders> | the ones in DOM are required for compat… I'd rather we just changed the canonical cases in the encoding spec to match what is used elsewhere… |
| 12:00 | <zcorpan_> | seems like there's big overlap between /dom/nodes/Document-characterSet-normalization.html and /encoding/single-byte-decoder.html |
| 12:02 | <gsnedders> | well yeah, annevk changed it all in the encoding spec to have a predictable case |
| 12:02 | <jgraham> | I think seitching the default to http/2 is more plausible than running everything over both, and can be dealt with once it becomes clear it's the right thing to do |
| 12:19 | <annevk> | zcorpan_: I don't want any new APIs to expose the weird legacy casing |
| 12:19 | <annevk> | zcorpan_: e.g. TextDecoder |
| 12:20 | <zcorpan_> | annevk: why? |
| 12:20 | <annevk> | zcorpan_: so you don't have to know the casing rules |
| 12:22 | <zcorpan_> | annevk: having the case be different between APIs means i can't compare the output without lowercasing or uppercasing both first |
| 12:22 | <annevk> | zcorpan_: there's no reason to use characterSet so I don't think that's a problem |
| 12:24 | <foolip> | how sure are we that making characterSet return lowercase isn't Web compatible? |
| 12:24 | <annevk> | foolip: hsivonen argued that Chrome + Safari + Firefox > IE |
| 12:24 | <annevk> | foolip: bz said that inputEncoding should return "UTF-8" |
| 12:25 | <zcorpan_> | does IE return lowercase? |
| 12:25 | <annevk> | foolip: I don't have actual data, only a lot of scars from things we thought we could change |
| 12:25 | <annevk> | zcorpan_: I'm not actually sure |
| 12:25 | <annevk> | zcorpan_: I have a vague recollection that IE and old Opera did that |
| 12:26 | <foolip> | IE11 returns lowercase "utf-8" for both characterSet and charset |
| 12:27 | <foolip> | but it sure seems like a change that would cause some breakage for whoever makes a change |
| 12:28 | <foolip> | honestly it seems like changing the canonical case in the Encoding Standard might be less weird long-term |
| 12:28 | <foolip> | but I don't plan to fiddle with this myself any time soon, so... yeah. |
| 12:29 | <Ms2ger> | zcorpan, you managed to fix the tests before I even got around to adding it to my todo list :) |
| 12:30 | <zcorpan_> | Ms2ger: :-) |
| 12:30 | <zcorpan_> | presto returns lowercase for window-1252 at least for characterSet (inputEncoding is undefined) |
| 12:42 | <annevk> | foolip: why put it in the Encoding Standard? I don't really want this to leak beyond characterSet & friends |
| 12:47 | <foolip> | annevk: it just that there's currently no big list of special-cased labels in the characterSet getter, and I expect some frowning if some other API is added where the capitalization must be different |
| 12:48 | <foolip> | unless those APIs only ever return lowercase strings, in which case one could have the characterSet-compatible labels as the canonical names internally, not bothering with the canonical names of the Encoding Standard |
| 12:51 | <foolip> | annevk: yep, I see that TextDecoder.encoding getter actually lowercases the returned string in Blink |
| 12:52 | <foolip> | so it's already the way I thought it would end up :) |
| 12:52 | <foolip> | I'm clairvoyant |
| 13:19 | <annevk> | foolip: yeah, makes sense for a legacy impl |
| 13:19 | <annevk> | foolip: I would expect a saner setup in say, Servo |
| 13:21 | <annevk> | rubys: when I run make I get a very different url.html from you again |
| 13:21 | <annevk> | rubys: e.g. mine removes bikeshed.css, but adds <script async src=//resources.whatwg.org/file-bug.js></script>; |
| 13:22 | <annevk> | rubys: mine adds title attributes all over |
| 13:22 | <annevk> | rubys: references www.whatwg.org over whatwg.org |
| 14:04 | <rubys> | annevk: did you update bikeshed? We might need TabAtkin's help |
| 14:09 | <zcorpan_> | what is the "context object" for things on Window? is it the Window or WindowProxy? |
| 14:12 | <annevk> | rubys: yes I ran bikeshed update |
| 14:13 | <zcorpan_> | hmm http://software.hixie.ch/utilities/js/live-dom-viewer/saved/3317 |
| 14:16 | <annevk> | rubys: I also updated the repository, apparently that doesn't go automatically |
| 14:16 | <annevk> | rubys: still minor differences |
| 14:16 | <rubys> | These are the commands I use: |
| 14:16 | <rubys> | cd ~/git/bikeshed |
| 14:16 | <rubys> | git checkout . |
| 14:16 | <rubys> | git pull --rebase |
| 14:16 | <rubys> | bikeshed update |
| 14:17 | <annevk> | yeah |
| 14:17 | <rubys> | annevk: you are on mac |
| 14:17 | <rubys> | ? |
| 14:18 | rubys | is down to 5 errors and 1 warning on the first-cut rough merge of my peg.js work and the url standard |
| 14:18 | <annevk> | rubys: yes |
| 14:18 | <rubys> | annevk: ok, I'll try on mac later today |
| 14:20 | <zcorpan_> | seems like blink associates the active document with the MediaQueryList while gecko associates the WindowProxy |
| 14:24 | <zcorpan_> | i think i prefer associating with the document so the object stops working while the frame is navigated to a different document |
| 14:52 | <annevk> | zcorpan_: WindowProxy most likely |
| 14:52 | <rubys> | darobin: I pushed to https://github.com/webspecs/url and https://specs.webplatform.org/url/webspecs/develop/ didn't update |
| 14:54 | <rubys> | darobin: just a guess, but bikeshed needed to make a fix for this to work |
| 15:01 | <darobin> | rubys: looking at the logs |
| 15:02 | <annevk> | "update several hundred billion users of Chrome" horse-blink-dev |
| 15:02 | <zcorpan_> | annevk: yeah that jumped out at me also :-) |
| 15:03 | <zcorpan_> | chrome must be really successful with so many users |
| 15:04 | <darobin> | rubys: ah, I found an interesting bug |
| 15:04 | darobin | slaps himself for supporting caching at this stage |
| 15:06 | <zcorpan_> | maybe some ants are using chrome? |
| 15:26 | <darobin> | rubys: should be updated now, lmk |
| 15:29 | <darobin> | rubys: also, about an hour ago it looks like you pull in a looooong list of commits from annevk |
| 15:30 | <darobin> | the resulting JSON payload from the hook is so large that it was rejected by the server's security policy :) |
| 15:30 | <darobin> | but I just retriggered more recent hook calls and they worked fine |
| 15:34 | <rubys> | darobin: indeed I did. Started the merge :-) |
| 15:36 | <darobin> | rubys: yeah, I figured :) So, just in case you do a megamerge again don't be surprised if it doesn't work (I don't want to remove the protection, we shouldn't be getting megabytes of JSON all the time), just trigger a small change afterwards and it'll just work |
| 15:36 | <darobin> | I'm eventually going to replace the clunky GH hooks with something simpler from Travis that just sends the repo and branch |
| 15:36 | <rubys> | there must have been another problem as I did trigger a small change afterwards |
| 15:36 | <darobin> | rubys: oh yes, the two issues are unrelated |
| 15:37 | <darobin> | the other one is fixed |
| 15:37 | <rubys> | I'm planning to use Travis for regression testing |
| 15:37 | <darobin> | I shot myself in the face with caching basically |
| 15:38 | <rubys> | in any case: thanks! And merges from here on out should be smaller |
| 19:18 | <zewt_> | heh well here's a nasty one: http://download.autodesk.com/us/support/report_a_bug.html?SelProduct=Maya autodesk's bug reporting form has ... no submit button in Chrome |
| 19:18 | <zewt_> | (it's outside of the iframe, for me at least) |
| 19:19 | <zewt_> | "i hope you didn't expect to be able to actually send that detailed bug report you just put together" |
| 19:38 | <caitp> | web development is hard zewt_ |
| 19:38 | <caitp> | why is it so hard |
| 20:11 | <Ms2ger> | Hixie, around? |
| 20:14 | <Hixie> | vaguely |
| 20:16 | <Hixie> | sup? |
| 20:19 | <Ms2ger> | Hixie, I found the bit of spec I was looking for myself, thanks anyway :) |
| 20:19 | <Hixie> | cool |
| 20:19 | <Ms2ger> | For future reference, the "all attributes are in no namespace" requirement is in the XML section |
| 20:22 | <Hixie> | which attributes? |
| 20:27 | <Ms2ger> | Content attributes |
| 20:27 | <Ms2ger> | I was looking at .dataset in this case |
| 20:34 | <Hixie> | k |
| 20:35 | <Hixie> | not really sure what you mean but whatever :-) |
| 20:35 | <Hixie> | so long as you're happy :-) |
