| 07:29 | <matjas> | JS guys: \c escapes for control characters in regular expressions are non-standard too, right? I can’t find anything about it in ES5.1. |
| 07:33 | <zcorpan> | you mean like "\1" ? |
| 07:37 | <matjas> | zcorpan: no, like `/\cA/.test('\x01'); // true` |
| 07:37 | <matjas> | `\cA` till `\cZ`, |
| 07:37 | <matjas> | so to speak |
| 07:40 | <matjas> | e.g. \cA sends Ctrl+A, which is U+0001 |
| 07:41 | <zcorpan> | i totally didn't know about this |
| 07:45 | <matjas> | if it’s so obscure even zcorpan had never heard of it, it must be non-standard |
| 07:48 | <zcorpan> | i don't see it in the syntax of regex literals in the spec and nothing in annex b |
| 07:48 | <matjas> | zcorpan: ok, thanks for confirming |
| 07:49 | <matjas> | not in ES3 either |
| 07:49 | matjas | specs |
| 08:17 | <matjas> | http://mathias.html5.org/specs/javascript/#control-character-escape-sequences |
| 08:21 | <zcorpan> | matjas: regular expression *literals* no? |
| 08:22 | <matjas> | zcorpan: fixed |
| 08:23 | <zcorpan> | matjas: saying "must be supported" doesn't really say what is supposed to happen. i think there needs to be something that extends the syntax or regular expression literals and then some prose that says what the semantic is of the added syntax |
| 08:25 | <zcorpan> | i guess add a line in RegularExpressionNonTerminator :: |
| 08:26 | <matjas> | zcorpan: right |
| 08:26 | <matjas> | zcorpan: i guess it should say more than just “literals” too, as RegExp('\\cA').test('\x01') should work too |
| 08:27 | matjas | ’s TODO list explodes |
| 08:27 | <zcorpan> | oh, ok, i thought it was a quirk for just literals |
| 08:32 | <zcorpan> | hey, hold on |
| 08:32 | <zcorpan> | c ControlLetter |
| 08:32 | <zcorpan> | http://ecma-international.org/ecma-262/5.1/#sec-A.7 |
| 08:33 | <matjas> | FFFFFUUUUU |
| 08:33 | <zcorpan> | LOL |
| 08:34 | <zcorpan> | http://ecma-international.org/ecma-262/5.1/#sec-15.10.2.10 has the semantic requirement |
| 08:35 | <hasather> | matjas: __lookupGetter__ says "If a getter for the prop property has been defined on the this object through the use of __defineGetter__, return the getter function; else, return undefined.". It should also return the getter if it was defined in the object literal. (Same for Setter). |
| 08:36 | <matjas> | hasather: defined in the object literal? how? |
| 08:37 | <hasather> | matjas: var o = {get p() { return 1; }} |
| 08:38 | <matjas> | woah, i thought that was Fx-only for some reason |
| 08:38 | <matjas> | this complicates things |
| 08:38 | <zcorpan> | odinho: the new graph looks better, but it's not really clear how the webapp makes a request to the UA. maybe the arrow should have an XHR code snippet to make it concrete (and more correct, since the app doesn't really make a HTTP request to the browser) |
| 08:38 | <hasather> | matjas: it's in http://es5.github.com/#x11.1.5 |
| 08:39 | <odinho> | zcorpan: Hmm. Okay. That might work and still be short enough. Like xhr.open('get', 'http://example.com/resource.txt';) xhr.send() |
| 08:39 | <odinho> | It's a bit longer. |
| 08:39 | <matjas> | hasather: thanks |
| 08:40 | <zcorpan> | odinho: yeah |
| 08:40 | <zcorpan> | odinho: dunno if the final arrow also should have a code snippet for symmetry |
| 08:41 | <zcorpan> | xhr.onload = function() { alert(xhr.response) } |
| 08:41 | <odinho> | zcorpan: Although it's conceptual the whole image, -- and CORS is really not tied to XHR. |
| 08:41 | <hasather> | matjas: isn't the name "Web ECMAScript" enough? This spec is not what people mean when they say "JavaScript". :) Plus, "JavaScript" is a registered trademark. |
| 08:41 | <matjas> | hasather: annevk suggested it, and i liked it |
| 08:42 | <matjas> | hasather: i’d argue this spec is what people mean when they say “javascript” |
| 08:42 | <zcorpan> | odinho: yeah but not everything matches the flow chart |
| 08:42 | <zcorpan> | odinho: e.g. <img> sans crossorigin doesn't use CORS |
| 08:43 | <matjas> | hasather: e.g. 'foo'.substr() is not ECMAScript, but it is JavaScript (who wouldn’t call it so?) |
| 08:43 | <hasather> | matjas: people say JavaScript and refer to ECMAScript usually, not the browser extensions |
| 08:43 | <odinho> | zcorpan: get ( lyrics.com/hello.txt ) looks cleaner, though. -- But can't find a way to codify the return. |
| 08:43 | <odinho> | The return has a different color tho'. Because it's supposed to be a body etc. |
| 08:44 | <odinho> | I'm not sure if any code will make it clearer, I think it makes it harder to visualize at least :P |
| 08:44 | <hasather> | matjas: s/not the browser extensions/not *only* the browser extensions |
| 08:44 | <matjas> | hasather: #whatwg regulars people might refer to ECMAScript more often, but I’ll bet the average web developer means “anything that looks like ECMAScript and works in all browsers” |
| 08:44 | <odinho> | zcorpan: "request lyrics.com/hello.txt"; then? Instead of GET |
| 08:44 | <zcorpan> | odinho: wfm |
| 08:45 | <matjas> | hasather: this spec requires an ES implementation + the extras, so it’s the whole package |
| 08:45 | <odinho> | Okay :D It looks better than the old. |
| 08:45 | <hasather> | matjas: yea, but this only specs a subset |
| 08:45 | <hasather> | matjas: ok then :) |
| 08:45 | <odinho> | zcorpan: Updated. |
| 08:47 | <zcorpan> | odinho: it should really also be GET /hello.txt HTTP/1.1 :-) |
| 08:48 | <odinho> | zcorpan: No. I put my foot down to your correctness :P |
| 08:48 | <odinho> | shortness > correctness for explanation picture :] |
| 08:48 | <zcorpan> | fine :-P |
| 08:49 | <zcorpan> | i'm still gonna grumble like an old fart |
| 08:49 | <odinho> | Well, technical non-relvevant detail correctness. |
| 08:49 | <odinho> | minus spelling errors. |
| 08:50 | <odinho> | Speaking of which, fixed matjas spelling fix also. Only waiting for anne now... |
| 08:58 | <matjas> | hasather: fixed — “If a getter for the prop property has been defined on the this object through the use of __defineGetter__ or the get syntax in the object initializer, return the getter function; else, return undefined.” + added examples |
| 10:34 | <jgraham> | http://software.hixie.ch/utilities/js/live-dom-viewer/saved/1647 |
| 10:34 | <jgraham> | Seems to be some disagreement about whether document.write causes load events |
| 10:35 | <jgraham> | In any case the spec is wrong (it's an infinite loop in the spec) |
| 10:35 | <jgraham> | (for some value of 'loop') |
| 10:39 | <jgraham> | matjas: __lookupGetter__ and friends probably want to be defined in terms of AccessorDescriptors as per ES5 |
| 10:41 | <jgraham> | Look at e.g. http://es5.github.com/#x8.7.1 for clues |
| 10:51 | <volkmar> | /win 18 |
| 11:14 | <matjas> | jgraham: thanks, added to TODO. I was trying to keep things simple :'[ |
| 11:19 | <annevk> | MikeSmith: can you add matjas' work to http://platform.html5.org/ please? |
| 11:20 | <MikeSmith> | sure |
| 11:20 | <MikeSmith> | what's the URL? |
| 11:20 | <matjas> | MikeSmith: http://mathias.html5.org/specs/javascript/ |
| 11:20 | <matjas> | (WIP) |
| 11:21 | <annevk> | everything is WIP :) |
| 11:24 | <MikeSmith> | OK added |
| 11:24 | <niloy> | does this mean IE will have to implement __proto__? |
| 11:24 | <MikeSmith> | did like this: "JavaScript (based on ECMAScript)" |
| 11:24 | <gsnedders> | niloy: No. Like all web standards it doesn't force anyone to do anything. |
| 11:25 | <niloy> | but they should right? |
| 11:25 | <gsnedders> | niloy: IE will (sadly, IMO) be implementing __proto__ fairly soon, when ES6 support starts to come along. |
| 11:26 | <gsnedders> | (It's simply not tenable to not support it on mobile where so much content relies upon WebKit behaviour.) |
| 11:26 | <niloy> | great! I was just wondering if exposing __proto__ is a good thing |
| 11:26 | <gsnedders> | Not really. Immutable prototype chains would be far nicer. |
| 11:27 | <gsnedders> | However, the web relies on it, so it's just another inelegant thing that's part of the web platform. |
| 11:28 | <niloy> | oh... sad |
| 11:28 | <annevk> | MikeSmith: nice |
| 11:28 | <MikeSmith> | seemed like the simplest way to handle it |
| 11:29 | <gsnedders> | niloy: As currently spec'd in ES6 it's really horrible, a magic data property with magic in [[Get]] and [[Put]]. Would be far nicer to have an accessor property. |
| 11:31 | <niloy> | yeh |
| 11:32 | <matjas> | niloy: if they want to be ES6-compliant, yeah |
| 11:33 | <gsnedders> | matjas: They're going to do it regardless of whether it's in ES6. |
| 11:33 | <matjas> | gsnedders: oh, cool |
| 11:33 | <gsnedders> | matjas: It's simply not viable on mobile anymore with the ubquity of WebKit-expecting content. |
| 11:33 | <niloy> | I always felt taht not exposing __proto__ was one of the good things IE has done, apart from ajax |
| 11:34 | <gsnedders> | I'd still like to see first trying Object.defineProperty(Object.prototype, "__proto__", {get: function(o){return Object.getPropertyOf(o);},configurable:true}); |
| 11:35 | <gsnedders> | (i.e., a read-only __proto__, which as such can be entirely described by ES5 semantics) |
| 11:35 | <gsnedders> | But apparently, in large part down to a couple of libraries, that isn't possible for the mobile web. |
| 11:41 | <benvie> | it seemed that part if it was because most __proto__ uses are in order to mutate the [[prototype]] of newly created objects, and a point of contention was the syntax that was to be introduced to cover that important use-case. At the end of the day, it was new, non-backward compatible syntax vs. __proto__ which works on mobile and works on now the majority of desktop environments by user percent. |
| 11:41 | <benvie> | Given the fact that using the new syntax is a syntax error in existing browsers, and that __proto__ is already in the wild and widely used, the discussion shifted toward formalizing what already exists |
| 11:43 | <gsnedders> | benvie: Certainly almost everyone would've rather have gotten rid of the setter if possible, even if that meant introducing new syntax. |
| 11:45 | <benvie> | that's where `<|` and `.{` came in and, I may have misinterpreted what I read, but those were what eventually fell by the wayside in favor of just using __proto__ |
| 11:52 | <jgraham> | http://play-ttd.com/ <-- don't tell Hixie |
| 11:56 | <benvie> | I don't know what the status of this is, but it'd be ideal http://wiki.ecmascript.org/doku.php?id=harmony:proto_operator |
| 12:05 | <annevk> | jgraham: sweet |
| 12:05 | <annevk> | jgraham: now someone make it happen for Dungeon Keeper 2 |
| 12:14 | <MikeSmith> | annevk: do we still want to publish the Notification LCWD this week? |
| 12:14 | <MikeSmith> | I see the message from Artur Ortega came in |
| 12:15 | <annevk> | MikeSmith: I guess we should address those comments first somehow |
| 12:15 | <MikeSmith> | OK |
| 12:15 | <annevk> | MikeSmith: need to find out what Apple/Google think |
| 12:15 | <MikeSmith> | annevk: I don't know how you plan to resolve the remaining i18n comments |
| 12:15 | <annevk> | MikeSmith: exposing direction seems sensible, language seems overkill |
| 12:16 | <MikeSmith> | annevk: OK, I'm planning to talk to Richard about that tonight |
| 12:16 | <jgraham> | annevk: Aren't you supposed to be depleting the crustacean population of western europe? |
| 12:16 | <annevk> | MikeSmith: at the end of the day, it's a lot of additional complexity to put into those systems and the benefit is small |
| 12:16 | <MikeSmith> | yeah |
| 12:16 | <annevk> | jgraham: we're about to go cycling :) |
| 12:17 | <jgraham> | Oh, fun :) |
| 12:42 | <MikeSmith> | jgraham: do you get notifications about testharness.js pull requests from github? |
| 12:43 | <jgraham> | MikeSmith: Yes |
| 12:43 | <MikeSmith> | k |
| 12:43 | <jgraham> | I got ones for the requests Lachy made anyway |
| 12:44 | <jgraham> | Kind of annoying that step 3 has to be "now commit using mercurial" |
| 12:44 | <MikeSmith> | yeah :( |
| 12:44 | <jgraham> | Well step 4 I guess |
| 12:44 | <MikeSmith> | the actually-important step |
| 12:44 | <jgraham> | 1) Make patch 2) Upload to github 3) Get review 4) commit using mercurial to dvcs.w3.org |
| 12:45 | <guestlald> | can anyone tell me what "whatwg" is? |
| 12:45 | <odinho> | MikeSmith, jgraham: I want notification as well. |
| 12:45 | <tanepiper> | Anyone know if Simon Pieters is in here and awake? |
| 12:45 | <odinho> | tanepiper: --> zcorpan: |
| 12:45 | <guestlald> | I got this error on w3c validator: Bad value rpuPostId for attribute name on element meta: Keyword rpupostid is not registered. |
| 12:46 | <MikeSmith> | odinho: I can add you to the github w3c account |
| 12:46 | <odinho> | MikeSmith: Ohyea! |
| 12:46 | <tanepiper> | odinho: cool, thanks |
| 12:46 | <guestlald> | how can I fix that? |
| 12:46 | <MikeSmith> | odinho: what is your user name? |
| 12:46 | <odinho> | MikeSmith: Velmont |
| 12:46 | <MikeSmith> | hai |
| 12:46 | <tanepiper> | (p.s. if anyone else might be interested, http://webcomponents.github.com/ :) |
| 12:46 | <jgraham> | guestlald: a mailing list on which people, including several major browser vendors, discuss proposals for changes to the web; principally the HTML spec |
| 12:46 | <MikeSmith> | guestlald: you need to read the full text of that error message |
| 12:46 | <tanepiper> | (x-tags ftw) |
| 12:47 | <guestlald> | full text? |
| 12:47 | <guestlald> | <meta name='rpuPostId' content='1914'><meta name='rpuPlugin' content='v2.7'/>… Syntax of metadata name: A metadata name listed in the HTML specification or listed in the WHATWG wiki. You can register metadata names on the WHATWG wiki yourself. |
| 12:48 | <jgraham> | guestlald: rpuPlugin is not a valid value for meta @name |
| 12:48 | <guestlald> | its a plugin I use on my blog |
| 12:48 | <tanepiper> | zcorpan: when you are awake can you ping me please :) |
| 12:48 | <guestlald> | I didn't put that in meta |
| 12:48 | <MikeSmith> | guestlald: it's not registered anywhere |
| 12:49 | jgraham | expects zcorpan is awake |
| 12:49 | <jgraham> | Unless he is taking an afternoon nap |
| 12:49 | <zcorpan> | tanepiper: i'm awake |
| 12:49 | odinho | expects he is busy writing CORS inline tests |
| 12:49 | <guestlald> | should I just remove the plugin? |
| 12:49 | <jgraham> | Which would noy be a bad idea! |
| 12:49 | <MikeSmith> | guestlald: you can safely ignore that message if you want |
| 12:49 | <guestlald> | or should I not worry about those errors? |
| 12:49 | <guestlald> | okay |
| 12:49 | <MikeSmith> | yeah, that |
| 12:49 | <tanepiper> | zcorpan: cool - Patrick Lauke said you are probably the person I need to talk to re: web components in Opera |
| 12:49 | <odinho> | guestlald: If you don't want that message, you can fix the plugin, remove it, or ignore the message. |
| 12:50 | <guestlald> | doesn't slow down my site if I ignore message? |
| 12:50 | <odinho> | guestlald: No. |
| 12:50 | <jgraham> | tanepiper: zcorpan or I are probably good to talk to. Maybe odinho also |
| 12:50 | <guestlald> | thank you :) |
| 12:50 | <guestlald> | anyone know if a w3c validation irc chatroom exists? |
| 12:50 | <zcorpan> | tanepiper: what jgraham said :-) |
| 12:51 | <MikeSmith> | guestlald: no there is not one. but you can always ask here |
| 12:51 | <guestlald> | A charset attribute on a meta element found after the first 512 bytes. …134593'></script> <meta charset="UTF-8"/><title>You Are Stronger | The Optimis… |
| 12:51 | <guestlald> | http://www.anthonysabilities.com/blog/yas/ |
| 12:51 | <odinho> | guestlald: You should put it at the top, right after <!doctype html> |
| 12:52 | <guestlald> | above head? |
| 12:52 | <odinho> | guestlald: You don't need head, but if you have <head> there do it right after <head> then. |
| 12:52 | <tanepiper> | jgraham: ah cool - yea, basically I;ve spoken to Daniel Buchner at Moz about this, and he's on board with getting the idea going - basically I'd like to do this 'not in a vacuum' but I've been tracking web components for a bit of time now, since Alex Russel talked about them - and after the GoogleIO talk and seeing the X-Tags implementation I've kicked off http://webcomponents.github.com/ |
| 12:52 | <guestlald> | its already like this <head> <meta charset="<?php bloginfo('charset'); ?>" /> <title><?php atom()->documentTitle(); ?></title> |
| 12:53 | <guestlald> | but my minify plugin adds more code before it |
| 12:53 | <odinho> | guestlald: So you have nasty plugins doing nasty things. |
| 12:53 | <guestlald> | <!DOCTYPE html><html dir="ltr" lang="en-US" xmlns:fb="http://www.facebook.com/2008/fbml"><head><link rel='stylesheet' href='http://www.anthonysabilities.com/blog/wp-content/plugins/wp-minify/min/?f=wp-content/plugins/custom-about-author/cab-style.css,wp-content/plugins/wp-single-post-navigation/css/single-post-navigation.css,wp-content/themes/mystique/css/core.css,wp-content/themes/mystique/css/style-blue.css,wp-content/themes/my |
| 12:54 | <tanepiper> | ideally i'd like to get a dev rel member on board from each of the browser vendors (sans Apple, because mehh) so we have people who can sanity check and make sure X-Tags, and moving on to proper web components, that are developer-proposed are sane :) |
| 12:54 | <guestlald> | ignore that code, didn't paste right lol |
| 12:54 | <MikeSmith> | odinho: added you https://github.com/w3c don't know if that means you will get the notifications or not (I don't understand how github handles the settings for that) |
| 12:54 | <zcorpan> | tanepiper: what's mehh about Apple? |
| 12:54 | <jgraham> | tanepiper: Oh well none of us are dev-rel |
| 12:54 | <guestlald> | but wpminify adds that link code |
| 12:55 | <guestlald> | before meta |
| 12:55 | <odinho> | MikeSmith: Cool, guess that should be enough. |
| 12:55 | <guestlald> | can I just put the meta before head? |
| 12:55 | <guestlald> | after <!DOCTYPE html> |
| 12:55 | <odinho> | tanepiper: ted is cool. |
| 12:55 | <tanepiper> | zcorpan: afaik they don't do much dev rel around Safari? I may be wrong, but that's the impression I get |
| 12:56 | <MikeSmith> | guestlald: I guess you could try omitting the head start tags and end tags completely. Though dunno that might make your plugin choke. |
| 12:57 | <guestlald> | <!DOCTYPE html> <html <?php language_attributes('html'); ?>> <head> <meta charset="<?php bloginfo('charset'); ?>" /> <title><?php atom()->documentTitle(); ?></title> |
| 12:57 | <zcorpan> | tanepiper: just so we understand each other, what do you mean with dev rel? |
| 12:57 | <guestlald> | change to |
| 12:57 | <guestlald> | <!DOCTYPE html> <meta charset="<?php bloginfo('charset'); ?>" /><html <?php language_attributes('html'); ?>> <head> <title><?php atom()->documentTitle(); ?></title> |
| 12:57 | <tanepiper> | The organisation exists around https://github.com/WebComponents - and i'm hoping to finaise the submission guidelines this week, get Moz's existing X-tags from http://mozilla.github.com/x-tag/ imported in as repos and get some discussion started on improving them |
| 12:57 | <guestlald> | ? |
| 12:57 | <odinho> | tanepiper: Edward O'Connor is apple and very responsive and cool. |
| 12:57 | <guestlald> | I need the head tags |
| 12:57 | <MikeSmith> | guestlald: that's not going to validate but it will if you drop the head start tag and end tag |
| 12:58 | <MikeSmith> | guestlald: why? |
| 12:58 | <tanepiper> | zcorpan: good question i suppose - really we want to make sure that proposed web components are sane for the browser vendors |
| 12:58 | <guestlald> | wordpress put them there |
| 12:58 | <zcorpan> | tanepiper: apple people can have good feedback, i wouldn't exclude them up front :-) |
| 12:58 | <MikeSmith> | guestlald: then you're probably better off asking in a wordpress forum |
| 12:59 | <guestlald> | okay |
| 13:00 | jgraham | doesn't really know what x-tags is, but web components in general is quite vendor driven |
| 13:00 | <odinho> | tanepiper: We're spec and web tech people in Opera. We have something called devrel too, they are more working with developers, w/ some specs on the side. |
| 13:00 | <tanepiper> | ideally at least one member from each will have full admin rights on the organisation to help keep things in check, potentially do merges on repos from incoming patch requests (the plan is to initially start with X-tags so we can have the likes of http://mozilla.github.com/x-tag/demo.html#tabbox or http://mozilla.github.com/x-tag/demo.html#modal - get these speced) |
| 13:00 | <jgraham> | tanepiper: You have seen http://dvcs.w3.org/hg/webcomponents/raw-file/tip/explainer/index.html ? |
| 13:01 | <tanepiper> | jgraham: X-Tag is based on the Custom Elements portion of the W3 Web Components spec. |
| 13:01 | <tanepiper> | i.e. a polyfill developers can use now :) |
| 13:01 | <tanepiper> | it's less to do with the implementation and more to do with what developers will actually do with this stuff |
| 13:02 | <tanepiper> | e.g. one tab compoenent to rule them all vs 50,000,000 different tab components |
| 13:03 | <tanepiper> | odinho: that's maybe who I should be speaking to then, but I was directed here via a question on twitter :) |
| 13:04 | <odinho> | tanepiper: Yea, you spoke to the devrel people, they sent you to us, who have our hands a bit more dirty and deeper into the specs etc. |
| 13:06 | <zcorpan> | tanepiper: it's probably my fault you ended up here :-) but at least now we know a bit more about what you're after |
| 13:07 | <tanepiper> | zcorpan: :) Cool, yea this is a project very much about defining standard <element>'s - not how you guys are implementing what we'll be using as devs |
| 13:12 | <zcorpan> | tanepiper: yeah, our devrel people seems more suitable for that kind of thing |
| 13:12 | <zcorpan> | assuming one of them can commit to it |
| 13:14 | <zcorpan> | maybe they'll just go "LOL I dunno nothing about web components, buy me a slab of beer and i'll *consider* it" |
| 13:17 | MikeSmith | thought Patrick Lauke was in dev rel |
| 13:17 | <odinho> | MikeSmith: He is. |
| 13:18 | <MikeSmith> | so you dudes should pass the hot potato back to him |
| 13:18 | <MikeSmith> | or karlcow |
| 13:20 | <tanepiper> | zcorpan: i just as a MS developer evangelist 'trying to make html5 work for everyone' - he also asked what are web components :) |
| 13:20 | <tanepiper> | *le sigh* |
| 13:20 | <odinho> | But well, I don't know... For my part, I feel normal spec/webtech people is better suited than devrel. Although, I don't really know what different stuff devrel do, -- they do more Twitter and less tests than the rest of us at least. |
| 13:20 | <odinho> | Less arguing on mailing lists. |
| 13:21 | <tanepiper> | hmm well testing will be a big part of this - we don't want x-tags (custom elements) going out that will break things badly :D |
| 13:22 | karlcow | is reading the backlog for the hot potato |
| 13:24 | <karlcow> | MikeSmith: in fact there is one for validation or more exactly two ;) question of guestald #validator on freenode, #validator on w3c irc |
| 13:26 | <karlcow> | "Web Components Organisation — We don't need no stinkin' standards bodies" … |
| 13:30 | <AryehGregor> | Wait, so for computed styles, what does "As specified, but with relative lengths converted into absolute lengths" actually mean? |
| 13:30 | <AryehGregor> | What unit should be used for the absolute length, for instance? |
| 13:30 | <karlcow> | I have read the http://webcomponents.github.com/ a few days ago… and not sure what the goal is, specifically with the inflammatory tone at the start. |
| 13:31 | <zcorpan> | AryehGregor: i think it means converted to px, but that's not what it says is it... |
| 13:31 | <AryehGregor> | No. |
| 13:31 | <AryehGregor> | Hmm, you know, I guess it makes no difference except for in the CSSOM. |
| 13:32 | <AryehGregor> | Because CSSOM aside, computed value is only used for inheritance, so units are irrelevant. |
| 13:33 | <AryehGregor> | Seems like "convert to px" is how all UAs handle getComputedStyle() for line-height, at least. |
| 13:43 | <karlcow> | tanepiper: not sure what do you want exactly |
| 14:02 | <MikeSmith> | oh wow http://darobin.github.com/test-harness-tutorial/docs/using-testharness.html is nice |
| 14:02 | <MikeSmith> | bravo Berjon |
| 14:02 | <matjas> | gsnedders, Ms2ger et al. is there any way to predefine the slugs instead of letting Anolis create them? |
| 14:03 | <Ms2ger> | Slugs? |
| 14:03 | <matjas> | Ms2ger: e.g. I’d like http://mathias.html5.org/specs/javascript/#array.prototype.splice(start,-deletecount-,-item1-,-item2-,-…-)) to just say http://mathias.html5.org/specs/javascript/#array.prototype.splice |
| 14:03 | <tanepiper> | hasn't every good distruptive project started by having a go at the old way :) And the goal is, browser vendors are finally giving developers the necessary tools to build our own tags and components, outwith defined specs, which means we'll start to see the likes of <x-modal>, <x-datepicker>, etc - but rather than have the current situation where you have 50 different date pickers to choose from - why not |
| 14:03 | <tanepiper> | instead have developers come together and try agree one to rule them all. Then as browser vendors scower the web post-html5 final spec, looking for new tags to add nativly (as per the suggestion in the GoogleIO talk) - then all these should be speced out rather well |
| 14:04 | <Ms2ger> | <h3 id=array.prototype.splice>... should work, I think |
| 14:04 | <matjas> | Ms2ger: hah, just like that huh :) |
| 14:05 | <Ms2ger> | All thanks to gsnedders, that :) |
| 14:05 | <gsnedders> | DON'T BLAME ME. |
| 14:06 | <AryehGregor> | Hmm. So why does the resolved value for transform-origin and perspective-origin resolve percentages to absolute lengths, but transform not? |
| 14:07 | <AryehGregor> | tanepiper, nobody has a problem with dev-written libraries, like jQuery or whatever. Specs still need to exist to define things that are better implemented in browsers directly, such as for reasons of efficiency or because scripts lack some capabilities or because not everyone wants to pull in a 100k library to get basic functionality. |
| 14:08 | <Ms2ger> | I have more than enough problems with jQuery :) |
| 14:08 | <AryehGregor> | Yeah, but things like it are going to exist, and that's fine. |
| 14:10 | <tanepiper> | well why can't these libraries, instead of creating their own markup and functionality over and over for the same thing (and making it almost impossible to mix-and-match libraries too) why can't they use agreed upon custom components? Isn't this what custom components are all about? |
| 14:12 | <jgraham> | Not really… I mean if you have two libraries that implement datepickers with different feature sets and expose different APIs, it will be quite hard to make them the same |
| 14:12 | <tanepiper> | By giving us the shadow DOM, etc, do you really want developers going out their way to write <mycustomvideo> tags? Or shouldn't you want them to use the pre-spec'ed <video> tag that's there - same with custom components. Why does the web need to be filled with <tanes-datepicker>, <joes-datepicker>, etc (i used those tag names as descriptive only) |
| 14:13 | <jgraham> | Well I sort of agree with Hixie that I don't want them writing their own tags at all |
| 14:13 | <tanepiper> | and how will google, scraping the web, know that both these are really the same thing and lots of people are using them |
| 14:13 | <tanepiper> | anyway, meeting |
| 14:19 | <karlcow> | tanepiper: any point of extensions will be used… in a way which is not consensual. This is the goal of extensions. I understand your goals but it seems a case of let create yet another thing on the pile of all other things. |
| 14:19 | <zcorpan> | MikeSmith: the first code snippet is wrong though, should use root-relative url |
| 14:20 | <karlcow> | tanepiper: more exactly it is a case of XKCD 927 http://xkcd.com/927/ |
| 14:20 | <MikeSmith> | zcorpan: oh. alert Berjon. But I think he's mostly away this week |
| 14:23 | <jgraham> | zcorpan: It is wrong for submissions to the W3C, but right for the text he gives there |
| 14:23 | <jgraham> | in that it is the easiest way to get started writing a test |
| 14:24 | <Ms2ger> | Oh yes, I should poke Lachy about using root-relative urls |
| 14:24 | <Lachy> | I did, didn't I? |
| 14:26 | <Lachy> | Ms2ger, which URLs did I use wrongly? |
| 14:27 | <Ms2ger> | Looks like you got it right |
| 14:27 | <Ms2ger> | Now I'm confused |
| 14:27 | <zcorpan> | jgraham: yeah, that's fair enough. i haven't finished reading it, but maybe it should have a note about submission to w3c since people who wanna write tests and submit to w3c might well read this as how to do it |
| 14:28 | <Ms2ger> | jgraham, also to get them imported into browser test suites, no? |
| 14:28 | <jgraham> | Ms2ger: Yes |
| 14:29 | <jgraham> | I am aware though that there is a tension between "how do I get going quickly" and "how do I write perfect tests" |
| 14:29 | <jgraham> | I think making step 1) "install a local web server" might be a bit off-putting |
| 14:29 | <zcorpan> | "assert_equals(actual, expected, description) checks that actual and expected have the same value (without necessarily being the same object)." seems wrong |
| 14:29 | <Lachy> | jgraham, depends. There are very easy ways to get set up with a local web server on some platforms |
| 14:30 | <jgraham> | Lachy: Sure. But as a prerequisite it increases the barrier to entry |
| 14:31 | <jgraham> | Although we should just make a node.js based server specifically for running the tests. People don't take projects seriously anymore unless step 1) is "install node.js and npm" |
| 14:32 | <Ms2ger> | Yeah, running V8, that sounds like a good idea :) |
| 14:32 | <jgraham> | (note: that was satire. If you think it is a serious suggestion, your doctor advises that you start monitoring your koolaid consumption) |
| 14:33 | <Ms2ger> | Btw, is Opera going to implement the Blob constructor at some point? |
| 14:35 | <jgraham> | Why wouldn';tt we? |
| 14:35 | <zcorpan> | Ms2ger: i think that's already done (might not be shipped yet) |
| 14:36 | <Ms2ger> | Doesn't look implemented in my opera-next :) |
| 14:37 | <Ms2ger> | Anyway, you may be interested in http://w3c-test.org/webapps/FileAPI/tests/submissions/Ms2ger/Blob-constructor.html |
| 14:38 | <zcorpan> | Ms2ger: nice, thanks |
| 14:38 | <jgraham> | Ooh cool |
| 14:39 | <Ms2ger> | (I wanted to write a test for passing null for dictionaries, but it got a bit out of hand) |
| 14:41 | <jgraham> | Ms2ger: (making a function called assert_blob that lives outside a test() is very weird. Rename it to test_blob?) |
| 14:44 | <Ms2ger> | Fair point, done |
| 14:45 | <jgraham> | Thanks |
| 14:54 | <tanepiper> | karlcow: you are the second person to link me to that (or maybe it was you on HN?) but the fact is, we're getting the tools to do this, it's happening - but lets not let idiots fuck it up for the rest of us - so what if there is 1 more competing spec, better than everyone coming up with their own individual snowflake spec :) |
| 14:54 | tanepiper | doesn't want the web to explode |
| 15:01 | <karlcow> | tanepiper: the Web will not explode. ☺ Not in that way at least. |
| 15:01 | <karlcow> | So you are targeting mainly the Web developers and encouraging a kind of best practices. Not sure how browsers devrel have any impacts or should have impacts on it. You were promoting Anarchy (let's say ala Proudhon and not Bakounine), it will then settle down by itself with the agreement of people participating to your project. |
| 15:15 | <tanepiper> | well a) devrel can help promote it beyond my efforts (as I mentioned the Moz guy I spoke to is keen) b) Despite the anarchy, there still needs to be final agreement on things that won't break browsers (and the anarchy is really more around the proposal stage, let devs go hog wild with suggestions, and through discussion the wheat and chaff can be seperated) |
| 15:22 | <karlcow> | ah not anarchy then |
| 15:23 | <Lachy> | Given a WebIDL dictionary, which defines a value like the following: |
| 15:23 | <Lachy> | dictionary X { |
| 15:23 | <Lachy> | RegExp foo; |
| 15:23 | <Lachy> | } |
| 15:24 | <Lachy> | Is that handled by the ECMAScript conversion algorithm for object http://dev.w3.org/2006/webapi/WebIDL/#es-object ? |
| 15:24 | <Ms2ger> | Invalid, there's no such thing as "RegExp" in WebIDL |
| 15:25 | <Lachy> | hmm. |
| 15:25 | <Lachy> | That's what I was afraid of. |
| 15:27 | <Lachy> | Ms2ger, so, then to handle such a case in a spec, it would have to be defined as { object foo; } and then use prose to check if it's a regular expression? |
| 15:28 | <Ms2ger> | Either that or change WebIDL |
| 15:29 | <tanepiper> | karlcow: Not anarchy in the sense of 'lets throw stuff through the bank window' - that would be silly. But also no situation where one person can say, decide a tag is no longer required despite the weight of developers disagreeing with that |
| 15:29 | <Lachy> | well, it's for an internal opera extensions feature that I'm doing QA for. So we could just accept it as being a willful violation too. |
| 15:29 | <tanepiper> | *cough* |
| 15:30 | <karlcow> | no no ☺ Anarchy has a precise meaning at least for me. Anarchy != mess |
| 15:30 | <karlcow> | https://en.wikipedia.org/wiki/Anarchism |
| 15:31 | <tanepiper> | Maybe Anarchy is wrong, but it's certainly not democratic (because Democracy is a suckers game) and no dictatorship because that never works |
| 15:32 | <tanepiper> | oh, and it's not against the 'state' here (despite my opening paragraph) - quite the opposite, it's working with the state :) |
| 15:33 | <tanepiper> | that'll get toned down once I actually sit down this week and finish some of the documentation around it |
| 15:45 | AryehGregor | can tell TabAtkins_ is the primary editor of a draft when it uses terms like "webapps" and "multicol" in spec prose |
| 15:46 | <AryehGregor> | You sure love your contractions. |
| 15:48 | <zcorpan> | Ms2ger: http://w3c-test.org/webapps/FileAPI/tests/submissions/Opera/ |
| 15:50 | <jgraham> | Hmm, so is it well/correctly defined how the load event in an iframe interacts with the parent document |
| 15:50 | <jgraham> | The spec says "When there is an active parser in the iframe, and when anything in the iframe is delaying the load event of the iframe's browsing context's active document, the iframe must delay the load event of its document" |
| 15:51 | <jgraham> | And it has an active parser whilst the parser is not stopped or aborted |
| 15:51 | <jgraham> | But "stopped" links to "the end" |
| 15:52 | <jgraham> | So it isn't clear if "has an active parser" becomes untrue at the start or at the end of that set of steps |
| 15:55 | <jgraham> | The text makes it sound like the end of those steps, but that can't be true or you would get the load event on the parent document before the load event on the iframe |
| 15:55 | <tantek> | annevk - congrats on Fullscreen being published as a FPWD |
| 15:57 | <tantek> | http://www.w3.org/TR/2012/WD-fullscreen-20120703/ |
| 15:58 | <zcorpan> | jgraham: maybe The end should have a step that says "now the document no longer *has an active parser*" that it can hook into, or so? |
| 16:00 | <jgraham> | zcorpan: Yeah, something like that |
| 16:02 | <tantek> | all links to terms like "browsing context" have been updated only in the static /TR/2012/ copy to link to http://www.w3.org/TR/2012/WD-html5-20120329/ instead of http://www.whatwg.org/specs/web-apps/current-work/multipage/browsers.html#browsing-context - no change in dvcs |
| 16:02 | <Ms2ger> | zcorpan, hmm, that wasn't there before :) |
| 16:02 | <tantek> | I wonder if that means that someone will do those (semi)automatically again next for the next TR snapshot, or if it doesn't matter that there's another TR snapshot. |
| 16:03 | <zcorpan> | Ms2ger: indeed |
| 16:04 | <tantek> | well at least the FPWD kicks off the call-for-exclusions |
| 16:04 | <TabAtkins_> | AryehGregor: Hehe. |
| 16:23 | <jwalden> | gsnedders: working on fixing one last issue with __proto__ as accessor, hopefully it'll be done today and I'll send mail |
| 16:23 | <jwalden> | thought I had it done yesterday, ran into a last-minute issue I didn't have time to debug before end of day |
| 16:32 | gsnedders | tries to find an empty workspace to try and finish his stuff off |
| 16:35 | <gsnedders> | jwalden: You going for origin-restricted? (i.e., the setter only works on same-global objects?) |
| 16:35 | <jwalden> | gsnedders: origin-restricted, or global-restricted? |
| 16:35 | <jwalden> | gsnedders: right now I'm going for no restrictions |
| 16:36 | <jwalden> | gsnedders: since there are no restrictions on __proto__ across globals right now, other than the ones enforced by the normal property lookup process |
| 16:37 | <jwalden> | I |
| 16:37 | <jwalden> | er |
| 16:44 | <gsnedders> | jwalden: I mean taking the __proto__ setter (through getOwnPropertyDescriptor) from another global. That's something you can't do today, because of the lack of getters. |
| 16:46 | <jwalden> | once the __proto__ setter escapes, it goes where it will |
| 16:50 | <gsnedders> | Right, so you're following the same route as JSC, against the wiki proposal and what's needed for SES. |
| 16:50 | <jwalden> | there's an actual wiki proposal for it right now? wasn't aware of that |
| 16:53 | <gsnedders> | http://wiki.ecmascript.org/doku.php?id=strawman:magic_proto_property#normative-optional_proposal_currently_in_es5_spec_language |
| 16:53 | <gsnedders> | "If O is not an object from this context, throw a TypeError exception." notably. |
| 16:54 | <gsnedders> | (which JSC doesn't implement, and I really don't want to for reasons I've said before) |
| 16:57 | gsnedders | was going to poison Object.getOwnPropertyDescriptor(Object.prototype, "__proto__").set instead |
| 16:59 | <gsnedders> | (But that requirement, or something else making the setter useless or unavailable is needed for SES) |
| 17:31 | <gsnedders> | jwalden: I know Brendan was especially worried about letting the setter out in the wild, even with the wiki proposal. Poisioning .set seems the simple way to do this. |
| 17:32 | <jwalden> | brendan is always worried about backwards-compatibility, with some frequency to the point of excess, I think |
| 17:32 | <gsnedders> | It's not the BC concern here, but the extra security surface risk. |
| 17:32 | <jwalden> | witness why we still have E4X, although thankfully that's dying very very soon now |
| 17:33 | <gsnedders> | (Hey, if I could convince others, I'd be all for dropping the setter and trying to evangelize it through) |
| 17:33 | <gsnedders> | (But that looks less and less likely :() |
| 17:33 | <jwalden> | also for security, too, although with somewhat more justification there |
| 17:33 | <jwalden> | the more we simplify our algorithms and code, the easier it is to make changes with less security-conscious hesitance |
| 17:34 | <jwalden> | and if there's one thing we are doing all the time now, it's simplifying |
| 17:39 | <gsnedders> | jwalden: I've got .set poisoned now, hopefully get that in (along with moving it to an accessor) really soon. |
| 17:40 | <gsnedders> | jwalden: Basically, the SES people want to make it impossible to mutate prototypes within a global context, so other global's setter functions can't work on it. |
| 17:41 | <jwalden> | if we want to make __proto__ setting not work across contexts, that should be fairly simple to bolt on after the initial patch for us |
| 17:41 | <gsnedders> | 1 file changed, 14 insertions(+), 1 deletion(-) |
| 17:41 | <gsnedders> | I think that counts as simple. :) |
| 17:50 | <AryehGregor> | gsnedders, you made me curious. Now I'm doing this on mozilla-central: hg log -I '**/*.cpp' -I '**/*.h' -p -u ayg | diffstat |
| 17:50 | <AryehGregor> | Have I made Gecko simpler or more complicated so far? :) |
| 17:54 | <gsnedders> | Heh. Will, given there are commits from CVS-days which makes git believe I've written code I haven't… |
| 17:54 | <gsnedders> | *Well |
| 17:57 | <AryehGregor> | 155 files changed, 6085 insertions(+), 6713 deletions(-) |
| 17:57 | <AryehGregor> | Not bad. |
| 17:58 | <AryehGregor> | Ms2ger is: 2430 files changed, 52892 insertions(+), 116678 deletions(-) |
| 18:03 | <jwalden> | AryehGregor: "yes" |
| 20:31 | <jgraham> | annevk: I'm not sure what "a camping full of hippies" is. Campsite, perhaps? |
| 20:32 | <Hixie> | camping site? |
| 20:32 | <Hixie> | in french, and maybe other non-english languages, there's a single noun for "camping site" that sounds like "camping" |
| 20:33 | <jgraham> | Yeah, and in english there's "campsite" :) |
| 20:33 | <Hixie> | oops, i read that as "composite" -_- |
| 20:35 | <jgraham> | Hixie: Did you see the question about delaying the load event in iframes earlier |
| 20:35 | <Hixie> | i did not |
| 20:35 | <jgraham> | http://krijnhoetmer.nl/irc-logs/whatwg/20120703#l-774 |
| 20:37 | <jgraham> | (except I think I might have said "end" and meant "start" but I'm not sure) |
| 20:37 | <jgraham> | (yes I did) |
| 20:39 | <Hixie> | jgraham: it doesn't link to "the end" it links to the definition of "stops parsing" |
| 20:39 | <Hixie> | jgraham: which is the condition that begins running the steps |
| 20:40 | <Hixie> | jgraham: the parser says when you "stop parsing" (typically in response to an EOF token) |
| 20:42 | <jgraham> | Hixie: But then the document would stop delaying the load event of the parent before those steps run, no? |
| 20:43 | <jgraham> | Whereas you have to have the load event on the child fire before the load event on the parent |
| 20:46 | <Hixie> | it's quite possible the spec has a bug :-) |
| 20:47 | <jgraham> | Well I can file a bug if you like :) I'm just checking first in case I am missing something subtle or indeed something blindingly obvious |
| 20:48 | <Hixie> | as specced, if the parser in a nested iframe is the only thing delaying the load event of the parent then the parent will likely fire 'load' before the child. |
| 20:48 | <Hixie> | as far as i can tell |
| 20:48 | <Hixie> | so if that's not compatible, yes, please send feedback |
| 20:48 | <Hixie> | (or file a bug) |
| 20:50 | <annevk> | jgraham: thanks will fix |
| 20:51 | <jgraham> | Hixie: OK. I'm pretty sure that frames always have to fire load events before their parents |
| 20:52 | <annevk> | jgraham: thought camping was pretty universal for some reason |
| 20:52 | <jgraham> | Filed bug 17680 |
| 20:53 | <jgraham> | annevk: Also I feel that "stinged" should probably be "stang" or "stung" |
| 20:53 | <jgraham> | Perhaps the latter? My native-speaker intuition fails me |
| 20:55 | <annevk> | anything wrong with clean-shaven or shaven? |
| 20:55 | <annevk> | spellchecker is marking them as incorrect... |
| 20:55 | <annevk> | (it's also not happy with Nirvana) |
| 20:58 | <Hixie> | jgraham: yeah, i doubt i tested that when writing that part of the spec to be honest |
| 20:59 | <jgraham> | annevk: I think [clean-]shaven is fine |
| 20:59 | <annevk> | cool cool |
| 21:06 | <TabAtkins_> | clean-shaven is definitely fine. |
| 21:06 | <TabAtkins_> | shaven by itself seems less common to my ears, but there's nothing wrong with it. I think it's usually conjugated as "shaved" when alone, though. |
| 21:14 | <guzzlefry> | Do many user-agents actually use the media attribute of the style tag? |
| 21:15 | <TabAtkins_> | Yes. |
| 21:15 | <guzzlefry> | How are they selected? Example: |
| 21:16 | <TabAtkins_> | Or wait, I don't know if <style media> is used. <link rel=stylesheet media> definitely does. |
| 21:16 | <guzzlefry> | that applies also, since I'd be using it instead of <style> |
| 21:17 | <guzzlefry> | <link rel="stylesheet" type="text/css" media="all" href="yada.css" /> <link rel="stylesheet" type="text/css" media="screen" href="yada_screen.css" /> |
| 21:17 | <TabAtkins_> | Media Queries just return a boolean - do they match or not? Then all the ones that match are used. |
| 21:17 | <guzzlefry> | ok |
| 21:18 | <guzzlefry> | TabAtkins_: so the regular cascade order applies, nothing fancy? |
| 21:18 | <TabAtkins_> | Yup. |
| 21:18 | <guzzlefry> | cool, thank you |
| 23:37 | <smokeyrat> | Do you think that HTTP 2.0 will be released soon in a Windows 95 style commercial jippo with new versions of all major browsers coming out within a week with full support for it and where the protocol supports native and standard and super-safe payments totally free from transaction fees and where any webpage (such as our HTML 5 games) may ask if the user wants to insta-pay $0.1 to play the game, |
| 23:37 | <smokeyrat> | or any other amount, and when they click yes, it's transferred instantly to our bank account? Because that would be a very, very, very welcome addition to HTML 5 + CSS 3 + modern JavaScript. |