| 00:09 | <gsnedders> | AryehGregor: Really, seems to be exactly that. |
| 00:12 | <gsnedders> | AryehGregor: (like, it is exactly that it's running before first-draw) |
| 00:13 | <Hixie> | so right now the cue start time is defined as the time at which a cue becomes relevant |
| 00:13 | <Hixie> | this works ok (though not great) for subtitle cues |
| 00:13 | <Hixie> | but for chapter cues it's a bit weirder, since chapter titles aren't only "relevant" when you're watching the chapter |
| 00:14 | <Hixie> | anyone got a better definition? other than the redundant "the cue start time is the time at which the cue starts" |
| 00:14 | <Hixie> | (the latter seems a little too tautological) |
| 00:30 | <TabAtkins> | That seems fine to me,a ctually. |
| 00:31 | <mkanat> | Is the timeline position at which the cue starts? |
| 00:46 | <Hixie> | foolip: yt? |
| 01:10 | <AryehGregor> | Hixie, you can just say "every cue has a start time" or something and treat its definition as self-evident. I mean, that's really equivalent to saying "the cue start time is the time at which the cue start", but it doesn't sound silly. |
| 01:10 | <Hixie> | i went with something similar to that |
| 01:32 | <jarek> | Hi |
| 01:32 | <annevk> | roc, hey, I wondered how likely it is Full Screen will drastically change |
| 01:32 | <jarek> | is there any point in using SVGZ instead of SVG? |
| 01:32 | <jarek> | it looks like even Chrome does not support it (at least not when used from CSS) |
| 01:32 | <annevk> | roc, e.g. the suggested change of not having a pseudo-class but instead just rendering the specified element and descendants |
| 01:33 | <annevk> | jarek, what is SVGZ? |
| 01:33 | <jarek> | annevk: it's a file format |
| 01:34 | <jarek> | annevk: a gzipped SVG file |
| 01:34 | <jarek> | at least this is how Inkscape calls it |
| 01:34 | <annevk> | it seems browsers should be able to handle compression of SVG just as well as they should handle compression of HTML |
| 01:35 | <annevk> | if you configure the headers right and such |
| 01:37 | <jarek> | when I send SVG files with proper mime type I'm getting a lot of errors like this one: |
| 01:38 | <jarek> | "Resource interpreted as Document but transferred with MIME type image/svg+xml" |
| 01:38 | <jarek> | though they render perfectly fine (unlike SVGZ files) |
| 01:41 | <annevk> | no idea what that means |
| 01:43 | <jarek> | it's actually a warning, not error (it shows up in yellow in console) |
| 01:43 | <jarek> | I tried googling it but there are few results |
| 01:44 | <jarek> | seems like SVG is not that popular on the web yet |
| 01:45 | <shepazu> | jarek: from what I understand, depending on your server settings, you don't need to use .svgz |
| 01:45 | <shepazu> | typically (IIUIC) the server will compress it for transmission anyway |
| 01:46 | <jarek> | shepazu: so if I send SVG files and my server is configured to use gzip compression then there would be no benefits in using SVGZ? |
| 01:46 | <shepazu> | jarek: that is my understanding, yes |
| 01:47 | <shepazu> | in fact, I've heard that it can even increase the number of transferred bytes |
| 01:47 | <shepazu> | but I won't swear to that |
| 01:47 | <shepazu> | it does save file size on the server itself, of course, if that's an issue |
| 01:47 | <roc> | annevk: I don't think that's likely, since we've implemented that proposal |
| 01:47 | <roc> | more or less as it is in the wiki |
| 01:47 | <jarek> | is it a good idea to use SVG file as a sprite? |
| 01:47 | <zewt> | well, runtime compression is more expensive, but most production webservers can cache compressed files, i think |
| 01:47 | <TabAtkins> | As good an idea as any other image format. |
| 01:48 | <TabAtkins> | Relying on your server to do runtime gzip is completely fine and standard and simple. |
| 01:48 | <jarek> | I mean if I had embedded 100 PNG images inside single SVG then it would load much faster, right? |
| 01:48 | <zewt> | and you want it doing that anyway; it makes a huge difference for HTML |
| 01:49 | <TabAtkins> | jarek: You mean like, 100 <image>s? |
| 01:49 | <annevk> | roc, okay, it did seem like a nice idea to me |
| 01:49 | <TabAtkins> | No, that would be even slower (by a single request) than just using the 100 PNGs directly. |
| 01:49 | <roc> | which idea? |
| 01:49 | <jarek> | TabAtkins: yeah, I mean embedding, not linking |
| 01:49 | <TabAtkins> | jarek: How are you embedding a PNG inside an SVG? |
| 01:50 | <jarek> | TabAtkins: uhm... I click "Embed all images" in Inkscape... |
| 01:50 | <jarek> | TabAtkins: I have to investigate this more |
| 01:50 | <shepazu> | base64 encoding, I think |
| 01:50 | <zewt> | ew |
| 01:50 | <TabAtkins> | Ew indeed. ^_^ |
| 01:50 | <zewt> | i wonder how efficient deflate is at compressing base64 |
| 01:50 | <jarek> | yeah, I suspect it inserts the binary data directly into SVG file |
| 01:51 | <TabAtkins> | Well, using a single SVG with 100 base64-encoded images will almost certainly be faster than 100 individual images. |
| 01:51 | <shepazu> | useful if you want a single file |
| 01:51 | <jarek> | I remember reading somewhere that you can use base64 even inside CSS |
| 01:51 | <TabAtkins> | jarek: Yup, data: urls are just fine in pure CSS too. |
| 01:51 | <zewt> | heh it's pretty good |
| 01:51 | <zewt> | 1048576 /dev/urandom -> 1416501 base64 -> 1076454 base64.gz |
| 01:51 | <shepazu> | TabAtkins: I'm going to be in the valley tomorrow night through saturday, if you have time to hang out |
| 01:52 | <jarek> | TabAtkins: but there won't be any image rendered on the screen until the whole file with 100 images is downloaded, right? |
| 01:52 | <jarek> | or would the images show progressively? |
| 01:52 | <TabAtkins> | jarek: All-at-once. But a single slightly-larger download is usually *significantly* faster than 100 individual downloads. |
| 01:55 | <annevk> | roc, of just laying out the element and its descendants and not worrying about ancestors |
| 01:55 | <annevk> | roc, it would make any animations easier I imagine |
| 01:56 | <annevk> | roc, I had another question, why does the parent browsing context Document need to be full screen if one of its child browsing context Documents is full screen? |
| 01:56 | <roc> | that's a fairly violent change to CSS |
| 01:56 | <roc> | and the layout engine |
| 01:56 | <roc> | and creates various issues for the CSSOM etc |
| 01:57 | <annevk> | okay |
| 01:58 | <roc> | annevk: if the parent Document is not fullscreen, I'm not sure how the child could be fullscreen |
| 01:58 | <roc> | unless you have magic to rip the child document out and display it apart from the parent document |
| 01:59 | <roc> | that has similar problems to "just laying out the element and its descendants and not worrying about ancestors" |
| 01:59 | <roc> | such magic is not necessary |
| 02:02 | <annevk> | so if you invoke fullscreen on some iframe descendant element |
| 02:02 | <annevk> | does that also set styles for the iframe element itself when you go full screen? |
| 02:02 | <roc> | yes |
| 02:02 | <roc> | the iframe element is the fullscreen element in its document |
| 02:03 | <annevk> | including all its ancestor iframes? |
| 02:03 | <roc> | right, all the way up |
| 02:03 | <annevk> | ah okay, that works |
| 02:14 | <dbaron> | annevk, should I reserve constants for SUPPORTS_RULE and DOCUMENT_RULE in http://wiki.csswg.org/spec/cssom-constants or should I wait? |
| 02:14 | <annevk> | dbaron, please go ahead |
| 02:14 | <annevk> | dbaron, and thanks for the update! |
| 02:14 | <dbaron> | (and see http://lists.w3.org/Archives/Public/www-style/2011Oct/0388.html for a bit of a mess we'll need to fix) |
| 02:15 | <dbaron> | annevk, WebKit uses different constants for KEYFRAMES and KEYFRAME than what they wrote in the spec |
| 02:15 | <dbaron> | I just followed the spec |
| 02:15 | <erlehmann> | jarek, i use data uris in css. |
| 02:15 | <dbaron> | annevk, your wiki actually followed webkit rather than the spec, but I just changed it to follow the spec |
| 02:15 | <annevk> | dbaron, I noticed, wfm |
| 02:16 | <jarek> | erlehmann: but isn't this an overkill? |
| 02:16 | <annevk> | dbaron, if WebKit wants to change that around they better speak up I guess |
| 02:16 | <jarek> | erlehmann: how can you find anything in CSS file if there huge chunks of binary data? |
| 02:16 | <TabAtkins> | jarek: Tell your editor not to wrap lines in CSS files. |
| 02:16 | <erlehmann> | jarek, i am in the process of optimizing a page that had about 100 http requests for small decorative stuff. no, it is not. |
| 02:17 | <erlehmann> | TabAtkins, jarek, last one i used was data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAQAAAAABCAYAAAAxWXB3AAAAAXNSR0IArs4c6QAAADdJREFUOMvt00ENACAMBMGtATThjJzAmil/Dg08SfoYCRO2D+DW2ieqYIynt0my2Z7MI8FaGCkupysHEkVP6dUAAAAASUVORK5CYII= |
| 02:17 | <erlehmann> | that is not much. |
| 02:17 | <erlehmann> | (background gradient png) |
| 02:17 | <TabAtkins> | Oh man, you really do mean "small". |
| 02:18 | <dbaron> | hmmm, should I give jdaggett 13 for css3-fonts? :-) |
| 02:18 | <erlehmann> | indeed. and the requests held up the page. |
| 02:18 | <erlehmann> | dbaron, what does “13” mean here? |
| 02:18 | <dbaron> | just a number |
| 02:18 | <TabAtkins> | erlehmann: Constants for CSSRule. |
| 02:20 | <dbaron> | oh, wait, he already put 11 in the spec |
| 02:20 | <dbaron> | I can fix this |
| 02:23 | <dbaron> | wait, two different specs took 11 |
| 02:24 | <annevk> | anarchy |
| 02:25 | <TabAtkins> | I blame tyou, annevk. |
| 02:27 | <erlehmann> | wat |
| 02:28 | <TabAtkins> | dbaron: Oh, my usage is completely unimportant. |
| 02:28 | <TabAtkins> | IGNORE ME. |
| 02:28 | annevk | wonders if TabAtkins has seen the series "Ideal" |
| 02:29 | <TabAtkins> | annevk: Never heard of it. |
| 02:29 | <annevk> | there's a charater there that uses that phrase |
| 02:29 | <TabAtkins> | I usually think of the Observer from Venture Brothers when I say it. |
| 02:29 | <erlehmann> | dbaron, how can two different specs have the same number? |
| 02:29 | <erlehmann> | do constants work that way? |
| 02:30 | <dbaron> | erlehmann, by mistake |
| 02:30 | <erlehmann> | yeah, but how does it … err, work? |
| 02:30 | <dbaron> | TabAtkins, could you reply to the email I just sent, then? |
| 02:30 | <erlehmann> | or did you notice it right away? |
| 02:30 | <dbaron> | erlehmann, neither has been implemented yet |
| 02:30 | <erlehmann> | oh, okay |
| 02:30 | <erlehmann> | that i understand |
| 02:30 | <TabAtkins> | dbaron: Already did! Woo! |
| 02:31 | <dbaron> | TabAtkins, I think jdaggett might have beaten you |
| 02:31 | <dbaron> | TabAtkins, don't end up both using 14 now! |
| 02:31 | <TabAtkins> | We shall continue politely vacating each integer until infinity. |
| 02:32 | <TabAtkins> | At which point I will use infinity and he will use infinity+1. |
| 02:33 | <erlehmann> | then “hark! a vagrant” will make a story out of it |
| 02:33 | <erlehmann> | or wait, let me shoop something together |
| 02:33 | <erlehmann> | before going to sleep |
| 03:00 | <annevk> | kind of odd how the HTML WG references WHATWG revision numbers |
| 03:00 | <annevk> | no trust in CVS?! |
| 03:28 | <erlehmann> | TabAtkins, history will remember you fondly http://daten.dieweltistgarnichtso.net/pics/zeichnungen/cssconstants.png |
| 03:29 | <annevk> | haha |
| 03:29 | <annevk> | more comics please! |
| 03:31 | <MikeSmith> | heh |
| 03:32 | <MikeSmith> | great depiction of Tab |
| 03:32 | <annevk> | so I booked in that Avatar hotel and tried getting W3C rate |
| 03:32 | <MikeSmith> | looks exactly like him |
| 03:32 | <heycam> | haha, awesome |
| 03:32 | <annevk> | initially I was just "Anne van Kesteren" and had to pay $1,007.43, now it's "ms. Anne van Kesteren" and $985.52 |
| 03:33 | <annevk> | is the W3C discount really 20 bucks? |
| 03:33 | <annevk> | because that's a pretty sad negotiated discount, if any |
| 03:33 | <erlehmann> | annevk „ms“ ? |
| 03:34 | <annevk> | erlehmann, rest of the world has a hard time understanding the Netherlands |
| 03:34 | <erlehmann> | i do not know a language in which that is shorthand for discount |
| 03:35 | <annevk> | oh no, it's just that when they made an update to my reservation they set my gender as well |
| 03:35 | <erlehmann> | but anne is a male name. and a female name. |
| 03:35 | <erlehmann> | i see. |
| 03:36 | <erlehmann> | though i wonder why they store gender at all. |
| 03:36 | <annevk> | oh I see what happened |
| 03:36 | <annevk> | initially I had a night for 80 bucks |
| 03:36 | <annevk> | now they made that 150 bucks |
| 03:36 | <annevk> | and lowered some other nights with a few bucks |
| 03:37 | <erlehmann> | wat |
| 03:37 | <annevk> | awesome |
| 03:38 | <erlehmann> | i do not understand a thing |
| 03:39 | <erlehmann> | annevk, have fun stories about gender confusion? or do people just accept their error when they get the different pronounciation? |
| 03:40 | <erlehmann> | i knew an anne who wrote it änne, with diacritical marks. to make sure everyone knew how to pronounce it. |
| 03:45 | <erlehmann> | night |
| 03:47 | <dbaron> | is it really pronunced änne? |
| 03:47 | <Hixie> | annevk: don't encourage them to use cvs, i'll never be able to work out what's going on then :-P |
| 04:22 | <jacobolus> | thanks all for the talk slides at http://fronteers.nl/blog/2011/10/fronteers-2011-awesome |
| 04:22 | <jacobolus> | bruce wins for best title |
| 04:23 | <paul_irish> | hahaha |
| 04:31 | <jacobolus> | also, I like http://infrequently.org/11/fronteers/fronteers.html#6 :p |
| 04:45 | <paul_irish> | superfluous quotes |
| 04:49 | <annevk> | dbaron, depends on how you pronounce "än" I guess :) |
| 04:49 | <dbaron> | annevk, like Händel or länder in German? |
| 04:50 | <annevk> | ah, no |
| 04:51 | <annevk> | it's more like the "a" in "ah" |
| 04:51 | <annevk> | an-ne |
| 04:51 | <dbaron> | that's what I thought |
| 04:55 | <jacobolus> | TabAtkins: http://www.xanthir.com/talks/2011-10-06/ is not rendering very well here |
| 04:56 | <jacobolus> | either in chrome or safari |
| 05:57 | <annevk> | Hixie, so if we want bindings declarative and we don't want XML syntax anymore, do we want changes to the HTML parser? |
| 06:40 | <Hixie> | annevk: maybe |
| 06:41 | <annevk> | seems like if you have a separate document for your bindings you don't really want <body> and <head> there and such |
| 06:44 | <annevk> | http://blog.whatwg.org/weekly-binding-components |
| 09:10 | <foolip> | Hixie, I'm here, but I assume you are not. |
| 09:12 | <annevk> | TabAtkins, could have a per-property default type for attr() |
| 09:12 | <annevk> | TabAtkins, but then I'm not sure having attr() is really that useful |
| 09:12 | <annevk> | mixing markup & style = bad |
| 09:40 | <hsivonen> | annevk: major apps have moved on from mixing markup and style to generating both with script so that they mix all three |
| 09:42 | <annevk> | point being? |
| 09:44 | <hsivonen> | annevk: that "mixing markup & style = bad" focuses on mixing that has been superceded by even more mixing |
| 09:47 | <annevk> | not universally |
| 09:47 | <hsivonen> | true |
| 09:48 | <hsivonen> | speaking of markup and style, epub readers are an interesting time warp |
| 09:49 | <hsivonen> | epub readers are like from the time when Lynx and Mosaic roamed on earth |
| 09:49 | <hsivonen> | as far as markup and style go |
| 11:47 | <hsivonen> | gsnedders: it turns out that it's audio that sucks in Firefox on Android--not VP8 perf: https://bugzilla.mozilla.org/show_bug.cgi?id=693905 |
| 15:32 | <bga_> | http://colinm.org/language_checklist.html |
| 15:45 | <jgraham> | Fun fact: Opera has it's own special dark matter from Unite applications |
| 15:46 | <Ms2ger> | Ah, finally :) |
| 15:48 | <Ms2ger> | Anyone have opinions on isElementContentWhitespace, btw? Kill it? Keep it? Meh? |
| 15:52 | <jgraham> | My opinion is somewhere on the "meh" part of the spectrum |
| 16:50 | <dglazkov> | good morning, Whatwg! |
| 16:51 | <timeless> | hsivonen: cute |
| 16:51 | <timeless> | grr |
| 16:51 | <timeless> | NoScript shows an Opera icon for hsivonen 's WebM video |
| 16:52 | <timeless> | which clearly means that Opera conquered the webm type on this computer.. |
| 16:57 | <zewt> | opera took a bunch of media extension associations when i installed it recently |
| 16:57 | <zewt> | bizarre and quicktime-esque |
| 17:09 | <timeless> | yeah, i think i saw you complaining |
| 17:28 | <zcorpan> | 's' and 'd' are next to each other on a qwerty keyboard. that would theoretically make it pretty easy to typo 'id' as 'is' and vice versa. however, i didn't find a lot of instances of is= with google code search. |
| 17:32 | <zewt> | random musings? :) |
| 17:42 | <Ms2ger> | Assumed related to the xbl thread |
| 18:11 | <smaug____> | so, does anyone here actually like Dart? |
| 18:11 | <smaug____> | and if so, why? |
| 18:12 | <Ms2ger> | Of course! |
| 18:12 | <Ms2ger> | Google knows what's good for you, even if you don't! |
| 18:14 | <smaug____> | huh, DOM bindings for Dart are silly |
| 18:15 | smaug____ | decides not to care about Dart and moves on |
| 18:59 | <jgraham> | smaug____: Oh, I thought their plan was to replace DOM with Some Other API |
| 19:00 | <bga_> | smaug____ aeveryone have rights to make your own wrapper |
| 19:01 | <smaug____> | so? |
| 19:01 | <jgraham> | bga_: It sucks to be Not Google if they make a wrapper that they don't test in other browsers and implement natively in Chrome |
| 19:01 | <jgraham> | That hasn't happened yet ofc |
| 19:02 | <bga_> | oh |
| 19:02 | <bga_> | but Google want remove js too, replace to Dart + NaCl |
| 19:02 | <bga_> | new standards! |
| 19:03 | <Ms2ger> | bga_, interesting definition of "standard" |
| 19:04 | <bga_> | jgraham may be they wants to make Chrome as browser for intranet |
| 19:04 | <timeless> | Ms2ger: the wonderful thing about standards... |
| 19:04 | <bga_> | and will go away from internet |
| 19:04 | <timeless> | > . The wonderful thing about standards is that there are so many of them to choose from. |
| 19:08 | <bga_> | Ms2ger btw my view of ideal dom api is var div = doc.Div(){id: 'foo', style: doc.Style(){position: eStylePos.ABSOLUTE, left: 10, top: 10} } |
| 19:08 | <bga_> | no new |
| 19:08 | <Ms2ger> | Not mine, obviously |
| 19:09 | <bga_> | Ms2ger and el.beforeClick._add(_fn) el.beforeClick._del(_fn) |
| 19:17 | <Hixie> | foolip: i cced you on the relevant bug |
| 19:26 | <TabAtkins> | jacobolus: You have to give it like 10 seconds, because I wait for onload before hooking up the JS, and some of the iframes take a little while. |
| 19:28 | <TabAtkins> | annevk5: Yeah, I mentioned that possibility in the telcon this morning. Seems like a lot of overhead for little benefit. |
| 19:28 | <jacobolus> | TabAtkins: okay, in safari I waited minutes, and now it's at this state: http://imgur.com/JJ6E8 |
| 19:29 | <TabAtkins> | That should not take minutes. It should take maybe 10 seconds. |
| 19:29 | <TabAtkins> | That is the correct "loading" appearance, though. |
| 19:30 | <jacobolus> | TabAtkins: in chrome, it loads and turns blue, but then as I arrow through, each slide disappears halfway through trying to appear, so I get to read a nice blank blue screen |
| 19:30 | <jacobolus> | there's clearly stuff moving around, etc., but I can't really read it |
| 19:30 | <TabAtkins> | Um, blue? |
| 19:33 | <jacobolus> | oh, hmm |
| 19:33 | <jacobolus> | https://raw.github.com/LeaVerou/Incrementable/master/incrementable.js 405s |
| 19:35 | <TabAtkins> | Yeah, something's wrong with your connection. That loads <1s for me. |
| 19:36 | <jacobolus> | it loads fine in a separate page |
| 19:37 | <jacobolus> | I guess it loaded in chrome too. not sure what's wrong there |
| 19:37 | <jacobolus> | I've got a "Unsafe JavaScript attempt to access frame with URL http://www.xanthir.com/talks/2011-10-06/ from frame with URL http://hacks.mozilla.org/2010/08/mozelement/. Domains, protocols and ports must match." |
| 19:37 | <TabAtkins> | That should be irrelevant. |
| 19:38 | <jacobolus> | http://i.imgur.com/AJX1P.png |
| 19:39 | <TabAtkins> | That's all kinds of crazy. I don't have that color anywhere in my document. |
| 19:39 | <jacobolus> | in firefox the first page loads, and then the rest are just blank gray |
| 19:43 | <TabAtkins> | Oh, hm, you're right. Somehow the scroll position isn't being set correctly. |
| 19:45 | <jacobolus> | TabAtkins: in firefox, trying to load that incrementable.js file, I get an error that <!DOCTYPE html> isn't valid javascript after the server returns 301 and sends https://github.com/LeaVerou/Incrementable instead |
| 19:47 | <bga_> | oh. github has becomed much faster |
| 19:47 | <bga_> | nice |
| 19:49 | <jacobolus> | hm, actually maybe that's not what it sends, dunno. in any event, all the javascript ends up broken somewhere along the line, and then the slides stop working :) |
| 19:56 | <Hixie> | Ms2ger: why http://www.w3.org/Bugs/Public/show_bug.cgi?id=13877 ? |
| 19:57 | <Ms2ger> | Why not? :) |
| 19:57 | <Hixie> | well because we're not the text/plain spec |
| 19:58 | <Hixie> | so really if a UA wants to, i dunno, embed notepad to handle text files, who are we to disagree? |
| 19:58 | <Ms2ger> | Is that the one part of the web you aren't speccing? ;) |
| 19:58 | <Ms2ger> | I don't think embedding notepad without creating a document as described would be web-compatible |
| 19:59 | <Hixie> | yeah, that's probably true |
| 19:59 | <Hixie> | i guess this stuff only applies to html uas anyway |
| 19:59 | <Hixie> | but then again, there's not any real difference to saying "must" or "should" |
| 19:59 | <Hixie> | since a UA could just pretend it's not an HTML UA when it comes across a text/plain file |
| 20:00 | <Hixie> | then again, it couldn't do that _and_ handle it in iframes... |
| 20:00 | <Hixie> | so i guess it makes sense to have must |
| 20:00 | <Hixie> | ok |
| 20:02 | <Ms2ger> | And then I don't have to argue about the tests |
| 20:26 | <Ms2ger> | An extra word, a missing word... Same thing, really :) |
| 20:26 | <Hixie> | :-) |
| 20:47 | <TabAtkins> | annevk5: You around? What "other specifications" could make the extension requirements? |
| 20:53 | <Ms2ger> | TabAtkins, the ones that define the @-rule |
| 20:54 | <Ms2ger> | partial interface CSSWhatever { const MY_AT_RULE = 11; } |
| 20:54 | <TabAtkins> | I don't understand how they can define the wiki as being the required extensibility mechanism. |
| 20:54 | <Ms2ger> | The wiki is just a list of pointers to specs that define extensions |
| 20:57 | <TabAtkins> | Shrug. Seems easier to just define the wiki as normative. |
| 20:58 | <Ms2ger> | But then you've got a normative wiki page |
| 20:58 | <TabAtkins> | Yes? |
| 20:58 | <TabAtkins> | HTML has several already. |
| 20:59 | <Ms2ger> | If that's the fight you want to fight, sure :) |
| 21:00 | <Ms2ger> | Also, how high on your todo list is the scary messages on obsolete specs? :) |
| 21:00 | <TabAtkins> | I need to do that sometime soon. |
| 21:03 | <TabAtkins> | Ms2ger: Why do you ask? |
| 21:03 | <Ms2ger> | Just that I want it to happen :) |
| 21:03 | <TabAtkins> | Ah. Well, the WG resolved to do it, so it's completely up to me at this point. |
| 21:11 | <annevk> | TabAtkins, a normative wiki page doesn't really have the same effect as the partial interface construct afaict |
| 21:12 | <annevk> | though I guess it's "clear enough" |
| 21:13 | <bga_> | hm. plz ppl say me why UA dont add unknown properties to cssom and many ppl are forced to make own css parser |
| 21:13 | <bga_> | some CSSUnknownRule will be nice |
| 21:14 | <bga_> | w/ string contains not parsed rule |
| 21:14 | <TabAtkins> | bga_: There was discussion about this not long ago on www-style. |
| 21:14 | <Ms2ger> | bga_, use glazou's |
| 21:15 | <bga_> | TabAtkins and result? |
| 21:15 | <TabAtkins> | It's not a good idea. |
| 21:15 | <bga_> | :( |
| 21:16 | <annevk> | still might be nice to have something akin data-* for CSS properties |
| 21:16 | <TabAtkins> | Yes. |
| 21:16 | <TabAtkins> | I think we should use exactly that name: data-* |
| 21:16 | <annevk> | but given how the CSS parser is defined it seems rather tricky to get the details correct |
| 21:17 | <TabAtkins> | Hmm? I wouldn't think so. You'd still have to obey the generic grammar, but that's really loose. |
| 21:18 | <TabAtkins> | Basically you can take anything that's a space, comma, or slash separated list of numbers, dimensions, keywords, strings, or functions. |
| 21:19 | <erlehmann> | what exactly would you want? |
| 21:19 | <TabAtkins> | erlehmann: ? |
| 21:20 | <erlehmann> | i do not understand how „data-“ and CSS would come together. |
| 21:20 | <annevk> | e.g. data-t: x tralolol /**/ whatev ; |
| 21:20 | <annevk> | what is its string value? |
| 21:20 | <erlehmann> | so how would that be used? |
| 21:20 | <annevk> | and how does that follow from the CSS parser? |
| 21:20 | <TabAtkins> | The idea is that selectors + the cascade is a pretty useful model for assigning data to elements, so we could define an author-extensible set of properties that can take anything and mean nothing. |
| 21:21 | <erlehmann> | like with fonts, only more general? |
| 21:21 | <erlehmann> | like assigning the name of a font is? |
| 21:21 | <TabAtkins> | annevk: cssText is defined generically (as much as it's defined at all). |
| 21:21 | <bga_> | annevk just get all string between : and ; |
| 21:21 | <bga_> | or : and } |
| 21:21 | <annevk> | TabAtkins, well yeah, that's a bug |
| 21:21 | <TabAtkins> | annevk: Really? Why? |
| 21:21 | <annevk> | TabAtkins, defining cssText however is easy for properties with normal values |
| 21:21 | <annevk> | because you just serialize those values |
| 21:22 | <TabAtkins> | I mean, your example is just three keywords and a comment. |
| 21:22 | <annevk> | but if you don't know the value, you cannot serialize it |
| 21:22 | <bga_> | annevk serialize as-ai |
| 21:22 | <annevk> | bga_, CSS doesn't work that way |
| 21:22 | <bga_> | *is |
| 21:22 | <TabAtkins> | If you restrict it to specifically the five data types I mentioned, it's easy and still extremely useful. |
| 21:22 | <bga_> | ++ |
| 21:23 | <annevk> | TabAtkins, yeah that might work |
| 21:23 | <bga_> | TabAtkins and custom bnf grammar |
| 21:23 | <TabAtkins> | Hmm. I wonder if it would be possible to do calc() under that regime. |
| 21:23 | <annevk> | TabAtkins, though we don't have functions currently |
| 21:24 | <bga_> | for your own rules |
| 21:24 | <bga_> | it will be like edsl :) |
| 21:24 | <bga_> | in css |
| 21:24 | <TabAtkins> | annevk: Hm? FUNCTION is a token in the core grammar. |
| 21:25 | <TabAtkins> | {ident}(<any>), plus whitespace, once you combine the token and the grammar. |
| 21:25 | <bga_> | hm |
| 21:26 | <bga_> | TabAtkins => we can make interface CSSUnknownRule { CSSAst cssAst } |
| 21:26 | <bga_> | not cssText |
| 21:27 | <TabAtkins> | It's not bad just for technical reasons. It's also bad for practical reasons. |
| 21:27 | <dbaron> | hmmm, if an edit Hixie just made for a w3.org bug is wrong, should I reopen the bug or reply on the whatwg mailing list...? |
| 21:27 | <TabAtkins> | It's a good thing for it to be painful to invent your own syntax. |
| 21:27 | <TabAtkins> | dbaron: Either works. |
| 21:32 | <dbaron> | ok, reopened http://www.w3.org/Bugs/Public/show_bug.cgi?id=13915 |
| 21:32 | <annevk> | yeah, data-* would be kind of last resort |
| 21:33 | <TabAtkins> | I don't think data-* is bad. Inventing your own properties, though, interferes with our ability to mint new properties in the future. |
| 21:33 | <TabAtkins> | Similarly, inventing your own values for existing properties. |
| 21:33 | <annevk> | I never really considered that a viable option |
| 21:34 | <bga_> | TabAtkins its will gives right for authors to extents css standards, make css flexible and extendsible |
| 21:34 | <TabAtkins> | bga_: That is *very explicitly* something we do *not* want to give to authors. |
| 21:35 | <TabAtkins> | annevk: That's the end result of directly exposing "invalid" properties, which is why I mention it. |
| 21:35 | <bga_> | ok. not standards |
| 21:36 | <TabAtkins> | bga_: We do not want to make CSS author-extensible in a way that makes it hard for the WG to extend it in the future. |
| 21:36 | <TabAtkins> | If there are safe ways to make it extensible, like data-* properties, that's fine. |
| 21:36 | <TabAtkins> | This is similar to how HTML defines the data-* attributes rather than allowing authors to mint whatever new attributes they want. |
| 21:36 | <bga_> | TabAtkins ok. force authors to use data- prefix |
| 21:37 | <TabAtkins> | And how the component model is proposing that components must start with x-, rather than being some arbitrary element name. |
| 21:37 | <bga_> | but i must have right to inject own subparser in css parser and own rule in cssom |
| 21:38 | <TabAtkins> | I don't see how that follows. |
| 21:38 | <TabAtkins> | That would be a nightmare, actually. |
| 21:38 | <bga_> | TabAtkins it will true extensible browser |
| 21:38 | <bga_> | TabAtkins i can patch dom prototypes |
| 21:39 | <bga_> | i can register new protocols |
| 21:39 | <bga_> | can create new html elements |
| 21:39 | <bga_> | next - new css rules |
| 21:39 | <RobbertAtWork> | haha, the CSSRule.register() suggestion was inevitable |
| 21:39 | <bga_> | :) |
| 21:40 | <TabAtkins> | Minting your own data-* properties is fine. You can then read them from script and do what you want. There's no need for anything further (and I don't think it even makes sense to go further). |
| 21:48 | <annevk> | https://raw.github.com/gist/933cc4f7df97d553ed89/24386c6a79bb4b31fb818b70b34c5eab7f12e1ff/gistfile1.txt is quite a fun read |
| 21:50 | <Peter-> | https://plus.google.com/112678702228711889851/posts/eVeouesvaVX |
| 21:50 | <Peter-> | same message, got some comments as well |
| 21:51 | <jgraham> | The way CSS people always talk about "The WG" makes it sound very sinister |
| 21:51 | <TabAtkins> | At least we're not a cabal. |
| 21:52 | <jgraham> | You're way more of an actual cabal than whatwg every has been |
| 21:52 | <jgraham> | *ever |
| 21:52 | <TabAtkins> | But we're not *called* a cabal. |
| 21:54 | <jgraham> | Well it is apparently legitimate to be one if you brand it with the W3C logo, so no one complains |
| 21:55 | <TabAtkins> | Now you've got it. |
| 22:33 | <annevk> | "What we really need is Strict Mode for the DOM: The possibility to completely re-invent all of the DOM from scratch." |
| 22:33 | <annevk> | I wonder when we stopped thinking that quirks mode was a bad idea |
| 22:33 | <annevk> | Also, from http://www.dartlang.org/articles/improving-the-dom/ it does not seem like Dart is re-inventing the DOM |
| 22:34 | <annevk> | It just introduces some different names for the same concepts |
| 22:35 | <TabAtkins> | annevk: Quirks mode is bad for different reasons than "let's rename the DOM!" is. |
| 22:35 | <TabAtkins> | It involves parsing differences, CSS layout differences, etc. |
| 22:35 | <annevk> | It's bad because mode switching like that is bad |
| 22:36 | <annevk> | With the epitome being the IE versioning model |
| 22:36 | <TabAtkins> | No. Mode switching is expensive. Quirks mode is bad for more reasons than just mode switching. |
| 22:36 | <TabAtkins> | Javascript strict mode is a mode switch that we're okay with. |
| 22:37 | <annevk> | You might be, I think it's quite silly |
| 22:37 | <TabAtkins> | A mode switch is, eventually, the only answer to "shit sucks forever". |
| 22:37 | <bga_> | annevk ++ |
| 22:38 | <TabAtkins> | Either you mode switch, or you have duplicate functionality that can be used at the same time, or you just stick with the sucky stuff forever. |
| 22:38 | <TabAtkins> | I think those are the only three choices. |
| 22:39 | <annevk> | Mode switch is duplicate functionality too |
| 22:39 | <TabAtkins> | Yes, but the old functionality is hidden and in the unicorn future can be eventually removed. |
| 22:39 | <annevk> | that sounds like crock |
| 22:40 | <annevk> | I'm not sure why we would start believing that now |
| 22:40 | <TabAtkins> | Even if we cant' remove it ever, having everyone opt-in to the new stuff makes newer code easier to understand, at least. |
| 22:40 | <annevk> | what Google seems to be advocating is pretty much XHTML2 |
| 22:40 | <TabAtkins> | Where eventually the definition of "newer" is "everything that anyone cares about". |
| 22:40 | <annevk> | minor improvement with major cost |
| 22:40 | <TabAtkins> | I haven't mentioned Dart at all, and am not talking about it. |
| 22:40 | <TabAtkins> | It's irrelevant. |
| 22:41 | <annevk> | I was not talking about that either |
| 22:41 | <TabAtkins> | My mistake, then. Anytime someone mentions Google at the moment, they're talking about Dart. |
| 22:42 | <jgraham> | TabAtkins: "Dart ... it's irrelevant" - is that the official position ;) |
| 22:42 | <TabAtkins> | Google has no official position. Ever. |
| 22:42 | <jgraham> | Uh huh |
| 22:43 | <paul_irish> | haha |
| 22:43 | <Philip`> | Is the official position that it has no official position? |
| 22:43 | <annevk> | paul_irish, the jQuery thing was a joke right? I wasn't sure |
| 22:43 | <TabAtkins> | We don't have an official position on that. |
| 22:43 | <TabAtkins> | annevk: Yes, it was. |
| 22:43 | <jgraham> | annevk: That looks quite like reinventing the DOM to me |
| 22:43 | <jgraham> | I mean sure it has the same concepts |
| 22:43 | <paul_irish> | annevk: yea |
| 22:44 | <jgraham> | But a totally different API |
| 22:44 | <annevk> | if you rename a few things, but you keep the event, node, range, exception model around you are not reinventing anything |
| 22:44 | <annevk> | you are just making things more confusing for authors |
| 22:45 | <annevk> | oh, right, in Dart I use .elements, not .children |
| 22:45 | <annevk> | such a win! |
| 22:45 | <TabAtkins> | annevk: You're completely ignoring the fact that even just the *naming* of the DOM is horribad and confusing for authors. |
| 22:45 | <bga_> | longer :( |
| 22:45 | <jgraham> | Well it also makes things worse for implementors that they don't bother to test with |
| 22:45 | <smaug____> | and Dart+DOM seems to manage to make naming even worse |
| 22:46 | <TabAtkins> | Having unique names for DOM collections different from the rest of the platform is bad. Making them all collections is good. |
| 22:46 | <TabAtkins> | Having nearly a dozen DOM searching methods is bad. Having one, which we know from experience people love to use, is good. |
| 22:46 | <TabAtkins> | Etc. |
| 22:46 | Philip` | thought Strict Mode wasn't about adding any features or syntax or renaming anything or reinventing anything, it was just about enforcing that you don't use certain dodgy features |
| 22:47 | <TabAtkins> | Philip`: Yeah, but it helps pave the way for new features less painfully. |
| 22:47 | <jgraham> | Just dealing with the language as JS is likely to be bearable because JS engines are relatively small and not that buggy. Having it also layer new stuff on top of DOM practically means that there will have to be lots of spcial casing for different browsers in the generated JS which means lots of breakage |
| 22:48 | <annevk> | TabAtkins, sure, simplicity is good, but it's not groundbreaking enough to do away with the old |
| 22:48 | <TabAtkins> | annevk: I disagree. The pain of millions of authors struggling with the old mistakes is significant. |
| 22:49 | <annevk> | most authors hardly deal with the DOM so that seems somewhat overstated |
| 22:49 | <TabAtkins> | Yeah, because it's so sucky that everyone uses libraries. |
| 22:49 | <TabAtkins> | Are you using that as an argument that we don't need to fix the DOM? |
| 22:50 | <annevk> | I'm saying that what you are saying is not true |
| 22:50 | <TabAtkins> | How, precisely, is it not true? |
| 22:50 | <annevk> | I do think we should simplify certain constructs as should be evident from my www-dom emails |
| 22:51 | <bga_> | looks like wine that implemets bugs oа win32 too |
| 22:51 | <TabAtkins> | Authors *do* use the DOM *all the time*. They just don't use the W3C DOM, because it blows. |
| 22:51 | <jgraham> | I don't understand why you think tying this to a new language is a sensible idea |
| 22:51 | <TabAtkins> | jgraham: I didn't say anything about that. See my above comments about how I'm not talking about Dart. |
| 22:52 | <jgraham> | TabAtkins: In what way? The discussion is precisely about the DOM replacement in Dart |
| 22:52 | <jgraham> | If you're not talking about it, you are the only one |
| 22:52 | <TabAtkins> | jgraham: Not at all. Dart happens to be provoking the discussion, but I don't give a crap about Dart. I care about better DOM. |
| 22:52 | <TabAtkins> | jgraham: Um, Anne's not talking about Dart either. By his own direct admission. |
| 22:53 | <smaug____> | TabAtkins: isn't the DOM4 work exactly about fixing the problems of old DOM API |
| 22:53 | <jgraham> | TabAtkins: So propose the better DOM APIs |
| 22:53 | <TabAtkins> | smaug____: In general, yes. I think annevk is too conservative, though. ^_^ |
| 22:53 | <jgraham> | I haven't really seen people do that |
| 22:53 | <jgraham> | Apart from all the hand-wringing about what new HTMLFooElement should do |
| 22:53 | <TabAtkins> | jgraham: The Dart APIs are, roughly, what several of us Google engineers working on JS would like to see in DOM. |
| 22:53 | <bga_> | TabAtkins sometimes any even very good software is needed to be completely rewritten |
| 22:54 | <smaug____> | TabAtkins: propose better DOM APIS ;) |
| 22:54 | <TabAtkins> | Me, Alex Russell, Erik Arvidsson, etc. |
| 22:54 | <jgraham> | TabAtkins: So propose them then... |
| 22:54 | <smaug____> | APIs |
| 22:54 | <krijn> | Don't fight kids! |
| 22:54 | <annevk> | TabAtkins, conservative how? I just think mode switching is bad idea |
| 22:54 | <TabAtkins> | annevk: You underestimate the aggregate pain that the sucky DOM causes to authors, and assert that nobody uses the DOM, so it's all right. |
| 22:55 | <jgraham> | krijn: In England we fight kids: http://www.guardian.co.uk/uk/2011/sep/21/eight-year-old-children-cage-fight-preston |
| 22:55 | <annevk> | I didn't say the DOM is all right |
| 22:55 | <krijn> | o_O |
| 22:56 | <jgraham> | TabAtkins: But there's no one trying to fix it. So far we have the Element.create suggestion (which I like) and the new HTMLElement suggestion (which doesn't work at all) |
| 22:56 | <jgraham> | That's it |
| 22:56 | <jgraham> | krijn: Indeed |
| 22:56 | <bga_> | TabAtkins how many times you deprecate oк remove some ability during dom0-dom4? |
| 22:57 | <annevk> | TabAtkins, anyway, what I think does not really matter, what matters so far is that there is a lot of noise, but not so much signal, about a better DOM |
| 22:57 | <TabAtkins> | jgraham: No one trying to fix it? Alex and Arv have been pushing forever on making NodeList be an array, for example. |
| 22:57 | <bga_> | i never heard that some feature was removes |
| 22:57 | smaug____ | is having hard time to find good things in the (dart) DOM API |
| 22:57 | <TabAtkins> | smaug____: I... I don't understand how that is possible. |
| 22:57 | <jgraham> | TabAtkins: iirc that doesn't work either |
| 22:57 | <annevk> | I guess tied to Dart there is some signal now, but I am personally hoping for it to be on www-dom |
| 22:58 | <jgraham> | It is easy to come up with unworkable ideas of course |
| 22:58 | <TabAtkins> | smaug____: Or pehraps you're not looking at the negative space, the fact that the Element interface is, like, a dozen methods/attributes now. |
| 22:58 | <krijn> | I want Element.nyanCatify() |
| 22:59 | <TabAtkins> | annevk: Dart is useful as a "hey look at this!", since individual feature suggestions are often shot down with "the DOM isn't really that painful" by you and others. ^_^ |
| 22:59 | <krijn> | annevk: btw, did we meet on Wednesday? |
| 23:00 | <annevk> | krijn, last week, briefly? |
| 23:00 | <krijn> | Hm |
| 23:00 | <krijn> | Don't know what was in the beer on that boat, but I'm missing some parts |
| 23:01 | <smaug____> | "(For mysterious reasons, these are named allinlowercase unlike the rest of the DOM.)" ? |
| 23:01 | <TabAtkins> | elem.onclick="..." |
| 23:01 | <smaug____> | what is mysterious about onfoo handlers |
| 23:01 | <TabAtkins> | As opposed to elem.onClick="..." |
| 23:02 | <smaug____> | they are all lowercase because the content attributes in HTML are lowercase |
| 23:02 | <TabAtkins> | We usually camelcase in JS. |
| 23:02 | <smaug____> | nothing mysterious there |
| 23:02 | <TabAtkins> | smaug____: That's not a general pattern. |
| 23:02 | <bga_> | TabAtkins dom isnt painful because we can completely change it api via dom prototypes. s/length/size/ for example |
| 23:02 | <TabAtkins> | We camelcase some things that are uncased in the content attributes. |
| 23:03 | <TabAtkins> | bga_: That's not a valid argument. Libraries *can* fix anything. They shouldn't be required, though. |
| 23:03 | <smaug____> | the new event registration mechanism looks also broken |
| 23:03 | <smaug____> | what if I want to add listener for event "foo" |
| 23:04 | <smaug____> | would it be then elem.on.foo.add (...) |
| 23:04 | <smaug____> | and that foo property would magically appear in the 'on' object |
| 23:04 | <bga_> | smaug____ el.onFoo.add is better |
| 23:05 | <smaug____> | ah, it says "we also put a subscript operator on NodeEvents." |
| 23:05 | <TabAtkins> | smaug____: Yes, though I think you have to use the subscript operator. |
| 23:05 | <TabAtkins> | elem.on['foo'].add() |
| 23:06 | <smaug____> | anyway, don't understand why to change onclick = value to on.click.add(value); |
| 23:06 | <bga_> | because its not add |
| 23:06 | <bga_> | its assign |
| 23:07 | <annevk> | smaug____, the latter allows for multiple |
| 23:08 | <smaug____> | I wonder where <element onclick="adlfkm"> handler appears |
| 23:08 | <smaug____> | ah, it does allow multiple |
| 23:08 | <smaug____> | but it breaks onfoo idl vs content attribute mapping |
| 23:08 | <smaug____> | ah, well |
| 23:08 | <smaug____> | I just don't care this |
| 23:08 | <smaug____> | won't implement any of this stuff anyway |
| 23:08 | <bga_> | smaug____ my friend made small monkey patch which replace on* properties to setters which calls addEventLisneters |
| 23:09 | <smaug____> | bga_: how does that work? |
| 23:09 | <smaug____> | er |
| 23:10 | <smaug____> | ah, yes, defineProperty or some such |
| 23:10 | <bga_> | yes |
| 23:10 | <smaug____> | replacing Element.property.onclick by assigning a new value wouldn't ofc work |
| 23:10 | <bga_> | smaug____ but its points vector |
| 23:10 | <arv> | One of the goals with the on property was to unify the onfoo and the addEventListener("foo") mess |
| 23:11 | <smaug____> | what is the mess with onfoo and addEventListener? |
| 23:12 | <TabAtkins> | onfoo is annoying because it can only accept a single listener. However, it's short, while addEventListener is super-verbose and painful. |
| 23:12 | <arv> | I assume you think it is good to have 2 different ways? I know there are minor differences but who cares? |
| 23:12 | <TabAtkins> | You want short and easy for such a common thing. You also want a single way to do it if possible. |
| 23:12 | <smaug____> | how is addEventListener painful? |
| 23:13 | <smaug____> | ok, it is a bit long method name, but that is all |
| 23:13 | <arv> | and having strings as type sucks because it does not catch typos |
| 23:13 | <TabAtkins> | "That is all"? That's the whole problem. The DOM is stuffed full of painfully long names for no reason. |
| 23:13 | <TabAtkins> | That just makes your code huge and hard to both type and read. |
| 23:13 | <smaug____> | you elem.on['foo'] doesn't catch typos either |
| 23:13 | <smaug____> | yuor |
| 23:13 | <smaug____> | your |
| 23:14 | <smaug____> | :) |
| 23:14 | <dominicc|home> | and boolean parameters make understanding call sites harder |
| 23:14 | <TabAtkins> | It's impossible to catch typos in arbitrary user-creted events, obviously. |
| 23:14 | <arv> | That is all? Seriously. You don't think it is flawed in any other way than the length? |
| 23:14 | <TabAtkins> | Oh god, I completely forgot abotu the boolean parameter in aEL. >_< |
| 23:14 | <smaug____> | dominicc|home: you don't need to use boolean parameters with add/removeEventListener |
| 23:14 | <bga_> | 1st what you can do is make Element.prototype.on = Element.prototype.addEventListener |
| 23:14 | <TabAtkins> | ...yes you do. |
| 23:14 | <TabAtkins> | If you don't use it, it's a violation, and makes FF angry. |
| 23:14 | <smaug____> | there is no need to use boolean parameter |
| 23:14 | <smaug____> | no |
| 23:15 | <arv> | ff was fixed so, it is a step in the right direction |
| 23:15 | <arv> | but |
| 23:15 | <arv> | still |
| 23:15 | <TabAtkins> | Ah, wasn't aware it was fixed. |
| 23:15 | <arv> | reading a true or false at the end is still painful for the cases where it does matter |
| 23:15 | <annevk> | wait are we looking at DOM4 or Firefox? |
| 23:15 | <smaug____> | spec was fixed (and then gecko started to follow the spec) |
| 23:15 | <dominicc|home> | They’re optional I think. But still there… MDN says Mozilla has a second optional bool now. |
| 23:15 | <TabAtkins> | Still, seeing "someMethod(foo, bar, true)" kills me. |
| 23:15 | <annevk> | because that's been optional since forever |
| 23:16 | <TabAtkins> | dominicc|home: Oh jeezus. |
| 23:16 | <smaug____> | they were may optional actually because it was a bug in webkit that it allowed to leave out the last parameter :) |
| 23:16 | <smaug____> | s/may// |
| 23:17 | <dominicc|home> | So addEventListener has many infelicities. |
| 23:17 | <arv> | WebKit just followed common js practice. Makes me smile every time when that happens |
| 23:17 | <arv> | (but it does not happen often enough) |
| 23:17 | <smaug____> | and not following the spec? |
| 23:17 | <smaug____> | and not even filing spec bug |
| 23:17 | <arv> | The specs should follow reality, not the other way around |
| 23:18 | <annevk> | it's nice to tell the spec list if you think reality has shifted though |
| 23:18 | <smaug____> | is webkit the reality ? |
| 23:18 | <annevk> | also |
| 23:18 | <annevk> | webkit is changing their practice |
| 23:18 | <annevk> | and making arguments required |
| 23:19 | <annevk> | so it's not as simple as you say |
| 23:19 | <arv> | nothing is as simple as I say |
| 23:19 | <annevk> | that fourth addEventListener argument is something Mozilla did not propose anywhere btw smaug____ |
| 23:19 | <TabAtkins> | Not even the DOM. |
| 23:21 | <smaug____> | annevk: very true. But if I do something wrong doesn't make it ok for others to do wrong ;) |
| 23:21 | <smaug____> | and unfortunately 4th parameter was added long ago |
| 23:21 | <arv> | annevk: I'm well aware that it is hard work to spec these things and I appreciate all the good work you (and others) are doing |
| 23:22 | <arv> | One of the reasons why we chose to experiment with this in the Dart DOM was because we could do this without the risk of not breaking anything since there is no Dart code out there |
| 23:23 | <dominicc|home> | arv: And since Dart is "developer preview" you expect to be able to make breaking changes for a while, right? |
| 23:24 | <arv> | and we were tired of doing another blind webidl to dart conversion which would fit dart as badly as webidl fits js today |
| 23:24 | <arv> | do |
| 23:24 | <arv> | m |
| 23:24 | <arv> | |
| 23:24 | <arv> | dominicc|home: yes |
| 23:24 | <smaug____> | what is wrong with webidl <-> js? |
| 23:25 | <TabAtkins> | smaug____: WebIDL still encourages horrifyingly bad impedance mismatch with what good JS APIs should be. |
| 23:26 | <smaug____> | really? |
| 23:26 | <annevk> | I don't really mind Dart that much. What I mind is all the screaming that the DOM is broken and then either not proposing anything or coming up with proposals that are unworkable when you look at the details. |
| 23:26 | <annevk> | And of course there are some more constructive proposals too, e.g. from Ojan, so it's not all bad. |
| 23:26 | <arv> | annevk: I totally agree with that point. There are too many haters out there |
| 23:27 | <arv> | Also Ojan is awesome =D |
| 23:27 | <annevk> | TabAtkins, yeah, I hear that all the time, "omgwtfbbq Web IDL is terrible" |
| 23:28 | <annevk> | please do propose a workable alternative or just appreciate the fact it's so much vastly better than what we had before |
| 23:28 | <TabAtkins> | annevk: I know it's vastly better than what we had before. |
| 23:28 | <TabAtkins> | It's not perfect, though, dammit! |
| 23:31 | <smaug____> | TabAtkins: but really, what is bad in WebIDL? |
| 23:31 | <TabAtkins> | arv would be able to answer better than I, but in general it's still relatively hard to design properly idiomatic APIs in WebIDL. |
| 23:31 | <smaug____> | (I apparently just don't know why people are complaining about WebIDL) |
| 23:33 | <arv> | One of the problem with WebIDL is that it is language neutral which leads to impedance mismatch. For example, webidl attributes almost always have side effects and as such needs to be done as getters and setters to follow JS semantics. Some of these things are hidden in prose in webidl |
| 23:34 | <arv> | other things include interceptors which cannot be done in JS without ES6 proxies |
| 23:35 | <dominicc|home> | arv: And your contention is that, because the attribute setters have side effects, it would be more idiomatic in JS if they were functions? |
| 23:35 | <arv> | dominicc|home: JS has setters and getters (unlike java which uses getFoo and setFoo) |
| 23:36 | <dominicc|home> | arv: Right. So… what is the problem with mapping attributes to getters and setters? |
| 23:36 | <rniwa> | Hixie: ping |
| 23:36 | <Hixie> | pong |
| 23:36 | <arv> | yes, and this is being taken care of in the latest webidl spec |
| 23:37 | <rniwa> | Hixie: i'm confused about your comment on https://bugs.webkit.org/show_bug.cgi?id=68610 |
| 23:37 | <rniwa> | Hixie: are you saying that itemtype is a space-separated list of types? |
| 23:37 | <rniwa> | Hixie: or are you saying it is not |
| 23:37 | <Hixie> | it is now a space-separated list of types |
| 23:37 | <Hixie> | as of about 24 hours ago |
| 23:37 | <rniwa> | :( |
| 23:39 | <annevk> | arv, do you mean in Web IDL the specification or in the language it defines? |
| 23:39 | <rniwa> | Hixie: ok, but I'm more inclined to prefix all attributes now |
| 23:39 | <Hixie> | heh |
| 23:39 | <rniwa> | I thought the spec was relatively stable but apparently not |
| 23:40 | <Hixie> | it should be a backwards-compatible change for any existing content |
| 23:40 | <arv> | annevk: I'm not fully sure. Can you clarify that question? |
| 23:40 | <rniwa> | that seems to indicate that there's a chance we'll have incompatible changes in the future |
| 23:40 | <rniwa> | or that we might end up wanting to make incompat. changes but can't due to backward compat. |
| 23:40 | <Hixie> | rniwa: we make changes to things that have been "stable" for 15 years sometimes |
| 23:40 | <Hixie> | rniwa: doesn't mean it won't change |
| 23:40 | <rniwa> | Hixie: does any other vendor besides WebKit implement this? |
| 23:40 | <Hixie> | rniwa: what i try to ensure is that changes don't break shipped code |
| 23:41 | <Hixie> | rniwa: opera may, not sure (foolip?) |
| 23:41 | <annevk> | arv, is it a problem that specifications need to use "attribute DOMString x;" for what is essentially a getter/setter? Or is it a problem with how Web IDL defines "attribute"? |
| 23:42 | <arv> | annevk: I would have been happier if the specification was done in ES5 code |
| 23:42 | <arv> | annevk: I think the part that explains how to map Web IDL to ES5 already says that they should be implemented as getters and setters on the prototype. |
| 23:42 | <smaug____> | rniwa: microdata? |
| 23:43 | <smaug____> | rniwa: there is a patch for gecko, but it needs to be updated ... |
| 23:43 | <rniwa> | smaug____: ok. are you prefixing attributes? |
| 23:43 | <rniwa> | smaug____: or new methods on Document/Element? |
| 23:43 | <annevk> | how would you enforce any kind of consistency if specifications need to define all the ES details themselves? |
| 23:43 | smaug____ | is looking at the patch |
| 23:44 | <Hixie> | rniwa: prefixing attributes doesn't solve this, btw |
| 23:44 | <Hixie> | rniwa: it just adds even more trouble, with authors having to use multiple apis |
| 23:44 | <annevk> | Opera is unprefixed fwiw |
| 23:44 | <rniwa> | Hixie: yeah but it'll at least discourage ppl from widely deploying it until we remove prefixing |
| 23:44 | <smaug____> | optional_argc] nsIDOMNodeList getItems([optional] in DOMString types); |
| 23:44 | <Hixie> | rniwa: we don't _want_ to discourage people |
| 23:45 | <Hixie> | smaug____: it's itemType that's changed, not getItems() |
| 23:45 | <rniwa> | Hixie: well, I'd like to discourage until API is stable |
| 23:45 | <Hixie> | rniwa: the API won't be stable for decades |
| 23:45 | <rniwa> | smaug____: no prefixes then? |
| 23:45 | <Hixie> | rniwa: and then it'll be obsolete |
| 23:45 | <rniwa> | Hixie: I disagree. |
| 23:45 | <Hixie> | rniwa: what do you mean by "Stable"? |
| 23:45 | <rniwa> | Hixie: by stable, I mean that it won't have radial changes like WebSocket did |
| 23:45 | <smaug____> | rniwa: in the patch I don't see prefixes |
| 23:46 | <rniwa> | smaug____: ok, I guess we can follow the same suite then |
| 23:46 | <rniwa> | smaug____: btw, would you mind giving me the bugzilla url |
| 23:46 | <TabAtkins> | rniwa: "radical" meaning what? The sensible definition is "not backwards-compatible". |
| 23:46 | <smaug____> | rniwa: https://bugzilla.mozilla.org/show_bug.cgi?id=591467 |
| 23:46 | <Hixie> | rniwa: i will never make radical changes like websocket. that was a travesty. |
| 23:46 | <rniwa> | smaug____: so that I can post it on WebKit's bugzilla |
| 23:46 | <Hixie> | rniwa: and the ietf can be entirely blamed for that |
| 23:46 | <TabAtkins> | By that definition, this change is not radical. |
| 23:46 | <rniwa> | TabAtkins: this was not |
| 23:46 | <Hixie> | we should never have moved websocket to ietf |
| 23:47 | <Hixie> | it literally delayed us by a year |
| 23:47 | <rniwa> | smaug____: wow! you're implementing all of it in one patch? |
| 23:47 | <Hixie> | we'd have compression and multiplexing by now if we'd stayed at whatwg |
| 23:47 | <Hixie> | but anyway |
| 23:47 | <smaug____> | rniwa: I don't know much about it |
| 23:47 | <Hixie> | water under the bridge |
| 23:47 | <smaug____> | hsivonen would know |
| 23:47 | <smaug____> | but I guess it is late for him |
| 23:48 | <smaug____> | (for some reason it is not that late for me although I live in the same city as hsivonen ) |
| 23:49 | <Hixie> | heh |
| 23:57 | <annevk> | arv, basically, IDL handles a whole bunch of details that specifications do not need to take care of now and because of IDL they are taken care of consistently; is your idea that we should replace all that by just having "raw" ECMAScript definitions for each method in specifications? |
| 23:57 | <annevk> | arv, because to me such an idea sounds like it will lead to a hell of a lot more prose and less consistency across specifications |
| 23:59 | <arv> | annevk: I can see that. Since Web IDL has type annotations and JS does not. |
