| 01:52 | AryehGregor | is annoyed at the new "ayg⊙an via gmail.com", although of course other mail clients would have been saying something like that forever |
| 01:54 | <AryehGregor> | Maybe I should just switch all my e-mail over to the ayg⊙an Google account from Simetrical⊙gc? Probably by setting up the former to read all the latter's contents via IMAP? |
| 01:54 | AryehGregor | wonders if that would be possible and how long it would take, or if there's a better way |
| 02:23 | <MikeSmith> | heycam: where you moving to? |
| 02:26 | <MikeSmith> | oh, Melbourne, I gues |
| 02:51 | <heycam> | MikeSmith, yep |
| 02:51 | <MikeSmith> | cool |
| 02:51 | <MikeSmith> | I just got back yesterday from a visit to Perth |
| 02:52 | <MikeSmith> | surprised how expensive things are there |
| 02:52 | <heycam> | oh yeah, all the increased wealth over there from the mining boom |
| 03:54 | <bga_> | anybody from Mozilla? |
| 03:54 | <bga_> | i have bug |
| 03:55 | <bga_> | also miketaylr |
| 03:55 | <bga_> | in last opera window.onerror is fake event |
| 03:55 | <miketaylr> | bga_: orly |
| 03:55 | <bga_> | never fires |
| 03:56 | <miketaylr> | i thought we didn't support window.onerror |
| 03:56 | <bga_> | but |
| 03:56 | <bga_> | 'onerror' in window // true! |
| 03:56 | <bga_> | plz remove |
| 03:56 | <miketaylr> | oh, hmm |
| 03:56 | <bga_> | if not support |
| 03:56 | <miketaylr> | ok, i'll file a bug if that's the case |
| 03:56 | <bga_> | thx :) |
| 03:57 | <miketaylr> | np |
| 04:07 | <bga_> | miketaylr and opera is one browser which correctly parse { if(foo) _a() else _b() } :) |
| 04:07 | <bga_> | other wants ; |
| 04:07 | <bga_> | not bug, feature! |
| 04:09 | <miketaylr> | :) |
| 04:22 | <roc> | bga_: what's your Mozilla bug? |
| 04:23 | <bga_> | roc window.addEventListener('error', #(e){ _log(e.message, e.fileName, e.lineNumber) }) |
| 04:24 | <bga_> | or .filename .lineno as in webkit |
| 04:24 | <bga_> | but in Gecko both - null |
| 04:25 | <roc> | file a bug I guess |
| 04:25 | <roc> | I don't know |
| 04:25 | <bga_> | a can get lineNumber only if i attach event via window.onerror = #(message, fileName, lineNumber){} |
| 04:26 | <roc> | those are very different |
| 04:31 | <roc> | I see that for error events we pass the message, filename and line number as direct parameters to the handler |
| 04:31 | <roc> | instead of passing the event object |
| 04:31 | <roc> | I don't know why we do that |
| 04:32 | <roc> | addEventListener("error", function f(msg, filename, lineno) { ... }, false) should work |
| 04:36 | <bga_> | typeof(msg) == 'object' because its event object |
| 04:37 | <bga_> | both filename and lineno are undefined |
| 04:37 | <bga_> | in 8a1 |
| 04:37 | <heycam> | the spec says that window.onerror, as well as registering a listener for the error event, is also called for script errors -- and script errors invocations of window.oenrror get called with the three arguments |
| 04:58 | <roc> | weird |
| 06:06 | <zcorpan> | hi |
| 06:09 | <MikeSmith> | zcorpan: hello |
| 06:09 | <zcorpan> | hello MikeSmith |
| 06:10 | <zcorpan> | what happened last month? |
| 06:59 | <hsivonen> | someone filed a bug report as a Word document? |
| 07:58 | <zcorpan> | Hixie: i don't mind dropping <datalist>-fallback-to-<select>. most authors use script to implement fallback instead of clever markup |
| 09:59 | <mhausenblas> | hey foolip - a new toy to publish HTML5+Schema.org from CSV files https://github.com/mhausenblas/web.instata - in case you wanna play around w/ it ;) |
| 10:01 | foolip | looks |
| 10:01 | <foolip> | I don't have any POTD I'm afraid :) |
| 10:03 | <mhausenblas> | he he, fair enough |
| 10:04 | <mhausenblas> | I just found the templating stuff fun, so I thought I give it a try |
| 10:04 | <mhausenblas> | Bottle rocks! |
| 10:05 | <mhausenblas> | and, btw, thanks for microdata-live - helped me to debug stuff |
| 10:05 | <mhausenblas> | as well as thanks to hsivonen for validator.nu - same applies here |
| 10:06 | <foolip> | mhausenblas, do you think vocabulary-specific validation would be useful for validator.nu, or a waste of time? |
| 10:06 | <mhausenblas> | hmm |
| 10:06 | <mhausenblas> | didn't think about it, tbh |
| 10:07 | <mhausenblas> | I guess for widely used vocabs, vCard, iCal, etc. yes |
| 10:07 | <mhausenblas> | maybe :) |
| 10:07 | <mhausenblas> | how would you do that, foolip? |
| 10:07 | <mhausenblas> | ah, you're contributing to validator.nu, right? is it on github? |
| 10:07 | <foolip> | mhausenblas, http://bugzilla.validator.nu/show_bug.cgi?id=851 |
| 10:08 | <foolip> | mhausenblas, I wrote a few patches, but don't expect to be a long-term contributor |
| 10:08 | <mhausenblas> | right |
| 10:09 | <foolip> | mhausenblas, to validate a vocabulary you "just" check if the properties values follow the syntax required by the vocabulary |
| 10:09 | <mhausenblas> | so, let's put it this way: for a couple of common vocabs (that are used throughout microformats, microdata an RDFa) such as license, vCard, etc it would make sense, yes |
| 10:09 | <mhausenblas> | makes sense |
| 10:10 | <foolip> | are there any vocabularies at all that are used for all 3 syntaxes? |
| 10:10 | <mhausenblas> | maybe the first step is to compile a list of vocabs (see above for seeds), including, obviously Schema.org terms |
| 10:10 | <mhausenblas> | I guess so, yes - lemme see |
| 10:11 | <mhausenblas> | vCard - check, iCal - check, license - check |
| 10:11 | <mhausenblas> | Schema.org both for microdata and RDFa or whatever we will have in 3 months time :D |
| 10:12 | <foolip> | I think vCard and vEvent are way to complicated and will fail to get adopted, I don't plan to do anything with them |
| 10:12 | <mhausenblas> | I agree that they are not that simple, but I think widely used and needed |
| 10:12 | <mhausenblas> | but, again, Schema.org to the rescue ;) |
| 10:13 | <mhausenblas> | (that's why I'm focusing on Schema.org) |
| 10:13 | <foolip> | they're not used in microdata, which is all that I'd be checking |
| 10:13 | <mhausenblas> | right |
| 10:13 | <mhausenblas> | anyways, I guess a Schema.org validator would be the most interesting thing to have |
| 10:13 | <mhausenblas> | I'm about to do it anyway (for web.instata and other projects) |
| 10:14 | <mhausenblas> | in which language is validator.nu written? |
| 10:14 | <foolip> | Java |
| 10:14 | <mhausenblas> | ouch |
| 10:14 | <foolip> | the main reason I decided to not do it independently is because it already has all the framework for pointing to the source code location where something was wrong |
| 10:15 | mhausenblas | is chuckling at html5lib/ihatexml.py |
| 10:15 | <foolip> | without that, a validator would be useless for all but trivial cases |
| 10:15 | <mhausenblas> | roger that |
| 10:16 | mhausenblas | used to do Java ... some 8y ago ... now really only Python and JS |
| 10:16 | <mhausenblas> | anyways, guess back to work (though, formally it's a bank holiday here today, I think ;) |
| 10:17 | <mhausenblas> | good talking to you foolip - KUTGW! |
| 10:17 | <foolip> | mhausenblas, likewise! |
| 11:24 | <MikeSmith> | hsivonen: I notice that Hixie's "microsyntaxes-dates" folder is empty but the v.nu behavior for checking "valid date or time string" and "global date and time string" is still not conformant |
| 11:25 | <MikeSmith> | specifically, I notice that for date-or-time, v.nu allows, e.g., 1996-01-01T12:05:25 (a date and time with no time-zone information) and 12:05:25Z (a time with no date but with time-zone information) |
| 11:25 | <MikeSmith> | but the spec prohibits both of those |
| 11:26 | <MikeSmith> | and for global-date-and-time, the spec allows 1996-01-01T12:05Z (a date and time string with no seconds specified), but v.nu prohibits it |
| 11:37 | <zcorpan> | i thought v.nu didn't implement the spec but just used an off-the-shelf library for validating dates and times |
| 11:41 | <MikeSmith> | zcorpan: from what I can see in the code, it's currently just using regexes |
| 11:41 | <zcorpan> | oh |
| 11:42 | <zcorpan> | https://bitbucket.org/ms2ger/dom-core/changeset/f92a4bdbb5e6 - how is QName equal to Name? annevk? |
| 11:43 | <MikeSmith> | zcorpan: btw, about what happened last month, I have a hard time remembering details about anything further back than two weeks, and I was away most of last week, so my recollections are pretty hazy |
| 11:43 | <zcorpan> | k |
| 11:43 | <Ms2ger> | https://bitbucket.org/ms2ger/dom-core/changeset/6caa468281a4 |
| 11:43 | <Ms2ger> | zcorpan, ^ |
| 11:44 | <MikeSmith> | hsivonen: I don't know if either of those differences are ones that you had sent feedback on, but if so, it seems that Hixie must have already responded |
| 11:44 | <zcorpan> | Ms2ger: thanks |
| 11:58 | <hsivonen> | MikeSmith: it's quite possible that I've missed Hixie's response(s) or spec edits on that topic |
| 11:58 | <MikeSmith> | ok |
| 12:00 | <MikeSmith> | hsivonen: btw, I also noticed today that for cases of a time element that has a pubdate attribute, the spec now requires the datetime value can't be just a time |
| 12:00 | <MikeSmith> | that is, it must either be a date with a time, or just a date |
| 12:01 | <MikeSmith> | so I checked in a change for that today |
| 12:01 | <MikeSmith> | but the spec also makes the same requirement for the text content of the time element, if no datetime attribute is specified |
| 12:02 | <MikeSmith> | so I can make a change for that too, but I'm wondering if it's worth it, especially given that there seems to be some chance of the time element just being dropped altogether |
| 12:40 | <annevk> | What is the latest on mutation listeners? |
| 13:02 | <zcorpan> | annevk: grattis |
| 13:03 | <annevk> | takk |
| 13:14 | <Ms2ger> | annevk, congratulations |
| 13:18 | <annevk> | thanks! |
| 13:26 | <brucel> | zcorpan "Hixie: i don't mind dropping <datalist>-fallback-to-<select>. most authors use script to implement fallback instead of clever markup" - surely too early to tell? datalist so far has ben implemented in Opera for a while, Chrome recently. So a bit premature to declare the fallback mechanism dead? |
| 13:27 | <Ms2ger> | And Firefox for a while |
| 13:27 | <Ms2ger> | Don't forget the best implementation in the world ;) |
| 13:27 | jgraham | thinks the fallback is a good idea still. Was there some evidence it isn't |
| 13:28 | <annevk> | The fallback mechanism was mostly designed for a time when browsers were not updated |
| 13:28 | <jgraham> | ? |
| 13:28 | <annevk> | Well, IE was not updated |
| 13:28 | <jgraham> | That's not evidence it isn't |
| 13:28 | <annevk> | That changed and scripts became more prevalent to handle fallback in better ways |
| 13:28 | <annevk> | So these days introducing somewhat cleaner design is feasible |
| 13:29 | <jgraham> | That sounds a bit like "backwards compatibility is hard. Let's not bother" |
| 13:29 | <jgraham> | Or "graceful degradation" if you like |
| 13:29 | <annevk> | It's more that backwards compatibility is solved in a different way that allows new features to be designed without clutter |
| 13:33 | <jgraham> | What is the clutter in this case? And who does it help if it is already implemented everywhere? |
| 13:34 | <annevk> | new implementors, people trying to grasp the platform |
| 13:34 | <annevk> | i value those more than legacy implementations |
| 13:35 | <jgraham> | Is there any evidence that this is actually hard to implement? |
| 13:37 | <annevk> | it's pretty clear it's more complex |
| 13:37 | <brucel> | It seems to me that "everything inside datalist is invisible, except the <options>" is beautifully simple, annevk |
| 13:38 | <brucel> | (even I understand it) |
| 13:38 | <annevk> | brucel, except that doesn't tell you if you need to traverse children or descendants, whether scripts are executed, whether other descendants are submitted, etc. |
| 13:39 | <zcorpan> | brucel: maybe, although i base my judgement on other features where i see most authors use script to implement the fallback behavior |
| 13:40 | <zcorpan> | brucel: which makes sense since it's dead simple if somebody else writes the script, e.g. modernizr |
| 13:41 | <zcorpan> | jgraham: i recall bratell whining about datalist having to consider all descendants and not just the children |
| 13:42 | <zcorpan> | it complicates teh implementation |
| 13:42 | <brucel> | zcorpan and that's legit - but how big is the amount of evidence at the moment? Basing it on the decisions of a small group of highly-motivated script-savvy early adopters isn't indicative of the majority of authors who, let's face it, won't be figuring this stuff out until IE10 |
| 13:43 | <zcorpan> | brucel: the fallback is *for* early adopters. when it's mainstream, you don't bother with fallback at all |
| 13:44 | <zcorpan> | if the early adopters don't use the declarative fallback mechanism, it isn't going to do anyone any good |
| 13:47 | <brucel> | zcorpan I don't understand you, sorry. The fallback, surely, is so IE6,7,8,9 users get an input mechanism more helpful than a plain text input. |
| 13:48 | <zcorpan> | i'm saying that pages that use datalist will use a scripted dropdown if datalist is not supported |
| 13:48 | <zcorpan> | if (!input.list) { use jquery dropdown and be done with it } |
| 13:51 | <brucel> | feels to me like losing a useful declarative fallback mechanism in order to make it easier for implementors, because in the short time that it's been supported by majority of browsers, not everyone is using it |
| 13:54 | <zcorpan> | yeah |
| 13:55 | <zcorpan> | i've been disappointed several times where new features have useful fallback mechanisms but people feature check for the feature instead and fallback to jquery or something with script |
| 13:55 | <Rik`> | brucel: is it really implemented in Chrome ? |
| 13:57 | <brucel> | Rik Not sure - I meant to type Firefox (and made Ms2ger mad by getting it wrong) |
| 13:57 | <Rik`> | last time I checked, it was broken because the default CSS had "datalist{ display: none;}" |
| 13:57 | <brucel> | ah, think they removed that |
| 13:58 | <zcorpan> | without implementing the feature? |
| 13:58 | <brucel> | and it's implemented in IE10 although the fallback mechanism is mangled; I reported it to them and was told they were de-mangling that |
| 13:59 | <Rik`> | brucel: I removed that ;) |
| 13:59 | <zcorpan> | brucel: mangled how? |
| 13:59 | <Rik`> | zcorpan: yeah, they had flags for <datalist> implementation but not in the CSS |
| 13:59 | <zcorpan> | k |
| 13:59 | <brucel> | zcorpan - just let me dig out my tests |
| 14:05 | <brucel> | zcorpan <input list=cheese> |
| 14:05 | <brucel> | <datalist id=cheese> |
| 14:05 | <brucel> | <option>Wensleydale</option> |
| 14:05 | <brucel> | <option>Gouda</option> |
| 14:05 | <brucel> | </datalist> |
| 14:05 | <brucel> | .. works fine in IE10 pp1 |
| 14:06 | <brucel> | .. but Jeremy's example with <select> fallback always goes back to the fallback, even though datalist is supported |
| 14:07 | <zcorpan> | you mean the select is rendered? |
| 14:07 | <brucel> | yes |
| 14:07 | <zcorpan> | so chrome stole ie's CSS! |
| 14:08 | <Rik`> | brucel: well it's PP1, report it and it should be fixed |
| 14:08 | <brucel> | have done, a couple of weeks ago |
| 14:10 | <brucel> | but my point is that until we see datalist usable in the Web's Favourite Browser most devs aren't going to be aware of it, so it's too early to call the degrade-to-select pattern a failure |
| 14:12 | <zcorpan> | and when we know for sure it'll be too late to change it :) |
| 14:29 | <annevk> | so what is left |
| 14:29 | <annevk> | * mutations |
| 14:29 | <annevk> | * range |
| 14:30 | <annevk> | * event handlers |
| 14:30 | <annevk> | and evaluation of what can be removed and what needs to be added back in |
| 14:31 | <annevk> | some of which depend on either Acid3 changing or browsers giving up on Acid3 |
| 14:51 | <hsivonen> | I didn't want to think about mutation events today, but I ended up thinking about them anyway. |
| 14:51 | <annevk> | sorry |
| 14:52 | <Ms2ger> | And it's not even annevk's fault |
| 14:52 | <hsivonen> | annevk: oh, not your fault. I blame sicking's patch |
| 14:54 | <zcorpan> | so that's the latest on mutation listeners |
| 15:16 | <atrigent> | when using HTML5 drag and drop, is it possible to obtain the dom node of the element being dragged on drop? |
| 15:48 | <gsnedders> | http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%20%0A%20%3Cstyle%3E%20%0A%20%20%20div%20%7B%20background-color%3A%20green%3B%20color%3A%20lime%3B%20%7D%20%0A%20%20%20div%3Afirst-line%20%7B%20background-color%3A%20red%3B%20color%3A%20blue%3B%20%7D%20%0A%20%20%20span.one%20%7B%20background-color%3A%20inherit%3B%20color%3A%20inherit%3B%20%7D%20%0A%20%3C%2Fstyle%3E%20%0A%20%3Cdiv%3E%3Cspan%20class%3D%22one%22%3EGreen%3F%3C%2Fs |
| 15:50 | <Michael> | That's a cool tool |
| 16:08 | <annevk> | gsnedders, should be I think |
| 16:09 | <annevk> | gsnedders, the real fun is when you put a break in the <span> |
| 16:18 | <gsnedders> | annevk: Why? Why does background-color inherit from one place and color from another? |
| 16:20 | <erlehmann> | oh my. google+ javascript routing breaks links containing fragments |
| 16:20 | <erlehmann> | or so it seems |
| 16:20 | <erlehmann> | srsly. |
| 16:20 | <erlehmann> | ._. |
| 16:24 | <gsnedders> | When is Fx8 release? |
| 16:25 | <gsnedders> | 14 weeks time? |
| 16:25 | <smaug____> | https://wiki.mozilla.org/RapidRelease/Calendar |
| 16:25 | <AryehGregor> | gsnedders, your URL was cut off at: Green%3F%3C%2F |
| 16:27 | <gsnedders> | http://software.hixie.ch/utilities/js/live-dom-viewer/saved/1090 |
| 16:27 | <gsnedders> | is somewhat amusing in Firefox was the comment with it |
| 16:27 | <gsnedders> | AryehGregor: so you didn't really miss anything |
| 16:27 | <AryehGregor> | Yeah, seems not. |
| 16:31 | <erlehmann> | ohne thing is that the release version number stuff seems to work |
| 16:32 | <erlehmann> | i fell bad about not having ff $next yet ;) |
| 16:47 | <zewt> | gar i need to figure out how to make firefox stop pasting html as html |
| 16:47 | <zewt> | it's never ever wanted and i always have to paste text into a text editor and copy it back out to make it stop, heh |
| 16:48 | <Philip`> | You should use an OS on which copy-and-paste almost never works reliably so it's bound to degrade to plain text, like Linux |
| 16:48 | <zewt> | this feels like one of those things that somebody designed and implemented without really thinking about how annoying and unwanted it is in practice |
| 16:49 | <zewt> | eg. pasting text into email and having it end up in a giant font |
| 16:50 | <gsnedders> | zewt: It's one of the most common feature requests for Opera, though. |
| 16:56 | <erlehmann> | Philip`, sadly, even linux desktops do that right nowadays. bugs me as well. |
| 17:18 | <annevk> | gsnedders, that's the current thinking |
| 17:20 | <gsnedders> | annevk: citation? |
| 17:21 | <annevk> | don't have anything handy |
| 17:21 | <annevk> | but see discussion from some years ago |
| 17:21 | <annevk> | involved bz |
| 17:25 | <gsnedders> | annevk: CSS 2.1 doesn't seem to match that, though |
| 17:28 | <gsnedders> | annevk: inherit has a single dfn that is used for everything, which implies constant behaviour |
| 17:38 | <annevk> | gsnedders, CSS is a mess |
| 17:39 | <Ms2ger> | News at 12 |
| 17:43 | <gsnedders> | annevk: That doesn't mean we should go against fairly unambiguous parts of the spec. :P |
| 18:22 | <gsnedders> | annevk: Also: Happy birthday! |
| 18:29 | <dglazkov> | good morning, Whatwg! |
| 18:30 | <dglazkov> | annevk: Happy Birthday! |
| 18:53 | <Hixie> | hsivonen: it wasn't on my radar, but in general i recommend people send feedback ot the list rather than to a limited-availability social network :-) |
| 18:54 | <Hixie> | for those whe were talking about the <datalist>/<select> thing -- as far as i can tell, none of the implementations match the spec or are interoperable with each other, so we don't have enough data to know if the fallback can be used by authors or not |
| 19:28 | <AryehGregor> | Okay, so I changed the address in my W3C profile thing to ayg⊙an, but public-html thinks I'm not subscribed? |
| 19:29 | <AryehGregor> | Any further magic I need to do? |
| 19:29 | AryehGregor | inquires of MikeSmith |
| 19:30 | <AryehGregor> | Also, MikeSmith, can I get a Bugzilla component for my editing spec? Specifically, are there going to be any political problems based on the fact that the spec isn't hosted at the W3C that might lead people to agitate that it should be shut down after I've come to start relying on it? |
| 19:30 | <AryehGregor> | (DOM Range already has one, it's been pointed out) |
| 19:31 | <AryehGregor> | (did anyone get my public-html message yet? does it have to be approved by moderators or something in addition to me giving permission to post it?) |
| 19:45 | AryehGregor | wonders why mailing list archives are not conventionally updated in real time |
| 19:58 | <Hixie> | annevk: can we get an overload for appendChild() that takes a DOMString and creates a text node for you? |
| 19:58 | <AryehGregor> | That would be cool. |
| 19:58 | <Ms2ger> | Hixie, I suggest you try to convince implementors directly :) |
| 19:59 | <AryehGregor> | Although frankly, if we're going to add shortcuts to the DOM methods, we need to go a heck of a lot further than that. |
| 19:59 | <AryehGregor> | They're a massive headache to use. |
| 20:00 | <AryehGregor> | As it stands at least they're predictable, so adding a few random shortcuts doesn't seem like it would be a big win. |
| 20:29 | <TabAtkins> | Agreed with Aryeh on the "let's just sit down and make the entire DOM less sucky". ^_^ |
| 20:30 | <AryehGregor> | Do you have a concrete proposal? Maybe "clone the most commonly used parts of jQuery"? :) |
| 20:30 | <TabAtkins> | That would be a good start, certainly. |
| 20:30 | <TabAtkins> | SVG wants to make a less sucky SVG DOM, so we can coordinate and get everyone together. |
| 20:31 | <AryehGregor> | SVG has totally different needs. |
| 20:31 | <AryehGregor> | They need some kind of entirely non-DOM API that translates to DOM stuff. |
| 20:32 | <TabAtkins> | Likely, yes. |
| 20:32 | <TabAtkins> | But some things could be fixed, like automatically handling the namespacing hell. |
| 20:32 | <AryehGregor> | SVG is vector graphics shoehorned into XML, HTML is actually a natural fit for the DOM. |
| 20:32 | <Michael> | Have you guys seen Adobe Edge? |
| 20:33 | <Michael> | It finally became public today |
| 20:33 | <TabAtkins> | AryehGregor: Vector graphics are naturally layer-based, which seems like an acceptable fit for a tree-based language. |
| 20:33 | <smaug____> | huh, please, no jQuery |
| 20:34 | <jgraham> | Hopefully not the sucky magic bits of jQuery |
| 20:34 | <TabAtkins> | Depends on your defintion of "sucky magic". |
| 20:34 | <AryehGregor> | I was thinking of just looking at things that take five lines of DOM vs. one line of jQuery. |
| 20:34 | <jgraham> | Like "oh you entered a string that matched (some regexp) so you probably meant x" |
| 20:34 | <AryehGregor> | Not actually trying to copy it. |
| 20:34 | <jgraham> | In function parameters |
| 20:34 | <smaug____> | though, perhaps I'm against jQuery just because the implementation is ... less-than-perfect |
| 20:34 | <AryehGregor> | Heh, probably. |
| 20:35 | <miketaylr> | much like the DOM |
| 20:35 | <miketaylr> | ;) |
| 20:35 | <Michael> | smaug____, Have you told the jQuery devs? |
| 20:35 | <jgraham> | smaug____: By that token is there any software you ar for ? :) |
| 20:35 | <AryehGregor> | Did anyone get my last post to public-html, in the thread about innerText? |
| 20:35 | <AryehGregor> | I haven't been able to figure out whether sending from ayg⊙an worked or not. |
| 20:35 | <smaug____> | to jresig yes |
| 20:36 | <Michael> | What'd he say? |
| 20:36 | <smaug____> | not much |
| 20:36 | <Michael> | I mean... Did you say "jQuery sucks" or did you pin point areas for improvement? |
| 20:36 | <smaug____> | I just CC'ed him to some bugs to show that jQuery causes mem usage to go high |
| 20:36 | <smaug____> | very high in some cases |
| 20:36 | <Michael> | hmm |
| 20:37 | <Michael> | Do other libs like prototype, mootools etc? |
| 20:37 | <smaug____> | and jQuery used to have code which slowed down unload of pages a lot, but I think they did fix that |
| 20:37 | <smaug____> | don't know about other libs |
| 20:38 | <smaug____> | because when profiling, if some slow down has been caused by a js lib, it has usually been jQuery |
| 20:38 | <smaug____> | perhaps because it is used so often |
| 20:39 | <Michael> | I'd be curious to see the performance benchmarks for jQuery vs prototype etc |
| 20:39 | <Michael> | Just because JS itself is a single threaded bottleneck |
| 20:40 | <smaug____> | *IIRC*, jQuery also uses some constructs which tend to be hard to optimize in JS JITs (at least in some forms of jits). |
| 20:42 | <AryehGregor> | jQuery is an abstraction layer, it aims more for ease of use than performance. |
| 20:44 | AryehGregor | says this as someone who just found that in his own code, he was repeatedly doing getDescendants(document) on a huge document, which recursed through all nodes in the document at a stack depth of like twenty, when he could have written it imperatively in a few more lines and iterated over like twenty nodes instead |
| 20:44 | AryehGregor | just rewrote that and noticed a significant speedup, but there don't seem to be good JS profiling tools last he checked . . . |
| 20:49 | <jgraham> | "JS itself is a single-threaded bottleneck" - not really |
| 20:49 | <jgraham> | Some concurrency is avaliable via workers |
| 20:50 | <jgraham> | and the idea of making the DOM threadsafe or letting random webdevs loose with threads in the browser is... not appealing |
| 20:51 | <jgraham> | Also, javascript is generally pretty fast these days. Surprisingly so, even |
| 20:51 | <Hixie> | yet in some cases still lacking in what seed like obvious optimisations to me |
| 20:51 | <Hixie> | seem |
| 20:52 | <Hixie> | i recently optimised a for loop by a factor of two by factoring out some common computation with variables that were not assigned to in the loop |
| 20:52 | <Hixie> | the loop had no side-effects, called no user methods |
| 20:52 | <jamesr> | it's hard to tell that in JS |
| 20:53 | <Hixie> | so are all the other optimisations |
| 20:53 | <Hixie> | i was surprised that this one hadn't been done yet |
| 20:53 | <Moo--> | AryehGregor: google chrome comes with good performance monitoring tools nowadays |
| 20:54 | <AryehGregor> | Moo--, its JS profiler tends to give me useless results. |
| 20:54 | <AryehGregor> | I've tried it pretty recently. |
| 20:54 | <AryehGregor> | IIRC, IE10 was the only browser that had usable profiling when I tested it out, although I think at the time Firebug wasn't working with my Firefox version. |
| 20:55 | <Ms2ger> | Hixie, were you calling into the DOM? |
| 20:55 | <Hixie> | no |
| 20:55 | <Hixie> | it was a loop on a CanvasPixelARra |
| 20:55 | <Hixie> | CanvasPixelArray even |
| 20:55 | <Ms2ger> | Same thing, really |
| 20:55 | <Hixie> | who is that the same thing? |
| 20:55 | Ms2ger | has a wide definition of "DOM" |
| 20:56 | <Ms2ger> | I should have said "native code" |
| 20:56 | <Hixie> | CanvasPixelArray shouldn't be any more native than String |
| 20:57 | <Ms2ger> | Not sure why it'd be any less native than Node per spec |
| 20:57 | <Hixie> | Node has to interact with complicated machinery |
| 20:57 | <Hixie> | CanvasPixelArray does not |
| 20:58 | <Hixie> | (e.g. what you do to a Node could involve HTTP, CSS, image decoding, memory allocation, mutation events, etc etc etc) |
| 20:58 | <Ms2ger> | And people still expect that to be fast :) |
| 20:59 | <Hixie> | that doesn't affect my point |
| 20:59 | <Hixie> | which is that in the case i was talking about, i don't see why it should be that hard to optimise |
| 21:00 | <Hixie> | compared to other optimisations that have already been done |
| 21:01 | <Ms2ger> | Yeah, in this case it should |
| 21:06 | <jgraham> | Hixie: On all browsers? It's not like everyone has the same optimisations |
| 21:07 | <Hixie> | i do not recall on what browsers i tested |
| 21:08 | <Ms2ger> | Firefox might be better there, because we implement it as an ArrayBuffer |
| 21:21 | <gsnedders> | Hixie: Loop invariant code motion is actually not that easy to do with JS, because such a small amount can actually be proven to be loop-invariant |
| 21:28 | <Hixie> | what makes it hard to prove loop-invariancy? |
| 21:30 | <AryehGregor> | "But rather than actually calculating the dimensions of that hypothetical box, user agents are free to make a guess at its probable position." |
| 21:30 | <AryehGregor> | <3 CSS |
| 21:34 | <gsnedders> | Hixie: Doing static analysis of entire lexical scopes is expensive (so any function call becomes expensive), and the fact that objects can change their value in random places. |
| 21:38 | <Hixie> | gsnedders: sure but in this case there were no such problems :-) |
| 21:38 | <Hixie> | gsnedders: it was just math |
| 21:38 | <Hixie> | anyway |
| 21:42 | <Philip`> | Rather than proving hard optimisations are perfectly safe and coping with obscure edge cases, browsers ought to run an aggressive optimiser that's safe 99% of the time, and also run a completely independent clone of the page in parallel with a slow but perfectly safe JS engine |
| 21:43 | <Philip`> | then if the first one happens to go wrong, the divergence will be detected soon when the second one catches up with it, and the browser can switch to displaying the output of the second one |
| 21:43 | <TabAtkins> | And then stay on the slow one forever? |
| 21:43 | <Philip`> | so you'll eventually end up with the correct result but in most cases you'll get the result displayed much sooner |
| 21:44 | <Philip`> | It's a foolproof plan |
| 21:44 | <Hixie> | there's one pretty fatal flaw with this plan |
| 21:45 | <Hixie> | no wait, two. |
| 21:45 | <Hixie> | though i guess the second one is the same as the first. |
| 21:45 | <Hixie> | so one. |
| 21:45 | <Hixie> | (namely, that script can have side-effects) |
| 21:46 | <Hixie> | (the second one is that the script's side-effects include "taking time" which can be detected from script, but i guess you cuold make new Date() in the second script always return whatever it returned on that occurrence in the first script.) |
| 21:52 | <gsnedders> | Hixie: Firefox should do a lot if you're on a traced path. If you're in method JIT, not so much. |
| 21:53 | <jarek> | Hi |
| 21:53 | <jarek> | why iframe is allowed by default to navigate the parent window? |
| 21:53 | <jarek> | isn't this potentialy dangerous? |
| 21:53 | <TabAtkins> | It's only allowed to do so when it's same-origin as the parent, right? |
| 21:54 | <jarek> | TabAtkins: I'm afraid not |
| 21:54 | <jarek> | no… wait, I have same origin policy disabled in browser |
| 21:55 | <jarek> | let me check |
| 21:55 | <AryehGregor> | Navigating the parent is how things break out of frames, no? |
| 21:55 | <jarek> | http://en.wikipedia.org/wiki/Framekiller |
| 21:55 | <AryehGregor> | Isn't that one of the things <iframe sandbox> explicitly prevents? |
| 21:55 | <AryehGregor> | Basically, if you include an <iframe> you're letting it take over the page, yes. |
| 21:56 | <AryehGregor> | sandbox is designed to prevent that. |
| 21:56 | <jarek> | it looks like any iframe (even from different origin) can overwrite parent's top.location value |
| 21:56 | <AryehGregor> | Sounds right. |
| 21:56 | <Hixie> | overriding top.location isn't a security problem |
| 21:58 | <jarek> | this permission could be used to redirect user to malicious website |
| 21:59 | <TabAtkins> | Only if you're already embedding the malicious website. |
| 22:03 | <Hixie> | jarek: yeah but the user could tell that he was going to a malicious website. |
| 22:03 | <Hixie> | jarek: because it would change the location bar |
| 22:04 | <Hixie> | jarek: the web's security model assumes that the user is aware of the origin of the current page and can determine if it's safe or not. |
| 22:04 | <Hixie> | whether that's a safe assumption or not is open to debate, but if it's not, we have much bigger problems than top.location being settable |
| 23:00 | <AryehGregor> | I have a box that's absolutely positioned to the right of the page, then another box inside it. The inner box is wide and I want it to overflow outside the outer box, but to the left, not the right. |
| 23:00 | <AryehGregor> | In LTR. |
| 23:00 | <AryehGregor> | Any way to do that? |
| 23:00 | AryehGregor | pings TabAtkins, as for all his n00b CSS questions |
| 23:01 | <AryehGregor> | Actually, maybe I don't want that after all . . . |
| 23:01 | <TabAtkins> | Yo. |
| 23:01 | AryehGregor | settles for overflow: auto for now |
| 23:02 | <TabAtkins> | Is the inner box positioned? |
| 23:02 | <AryehGregor> | TabAtkins, click the first "Comments" button on the right: http://aryeh.name/tmp/editing/editing.html#the-forecolor-command |
| 23:02 | <AryehGregor> | See the giant table with color values? |
| 23:02 | <AryehGregor> | I'd prefer if that somehow stuck out to the left and extended the background or something. |
| 23:03 | <TabAtkins> | Ah, I see. |
| 23:03 | <TabAtkins> | If it's positioned, you can just position it relative to the right edge. Since it's not, the only way to influence overflow behavior is through changing the @dir. |
| 23:03 | <TabAtkins> | (Or the CSS 'direction', with the same effect.) |
| 23:03 | <AryehGregor> | Which will have undesirable side effects, no? |
| 23:04 | <TabAtkins> | Yes, definitely. Horrible side effects. |
| 23:04 | <AryehGregor> | Oh well. |
| 23:04 | <AryehGregor> | Scroll bar it is. |
| 23:04 | <TabAtkins> | Unless you wrap the rest of your content into another element with @dir set correctly. |
| 23:04 | <TabAtkins> | Or, wait, float:right will do it too. |
| 23:05 | <AryehGregor> | Hmm, interesting thought. |
| 23:06 | <AryehGregor> | That looks promising, thanks. |
| 23:06 | AryehGregor | fidgets |
| 23:08 | <AryehGregor> | Now if only I could suppress the border where it's on top of the outer box's background. |
| 23:08 | TabAtkins | wishes fervently again for vw and vh units, so you can say "max-width:100vw" in that situation and force scrollbars. |
| 23:08 | <TabAtkins> | Put a background color on the float? |
| 23:09 | <AryehGregor> | Already did. |
| 23:09 | <TabAtkins> | Is the change live? |
| 23:09 | <AryehGregor> | Yes. |
| 23:09 | <TabAtkins> | Oh! I see what you mean. |
| 23:09 | <TabAtkins> | Misread your comment previously. |
| 23:10 | <TabAtkins> | You'd like a border around the "final shape" of the box. |
| 23:10 | <AryehGregor> | Yeah. |
| 23:10 | <TabAtkins> | Yeah, that'd be cool. |
| 23:10 | <AryehGregor> | But it strikes me as probably impossible. |
| 23:10 | <TabAtkins> | Well, without diving into a full graphics language, probably. (SVG will be able to do it with shape-combining and then stroking.) |
| 23:11 | <AryehGregor> | Hmm, it might be doable. |
| 23:11 | AryehGregor | adds a couple of extra divs and tries carefully positioning them |
| 23:12 | <TabAtkins> | Ah, clever. Dunno if you can get it done currently, but you'd be able to after Positioning gets done, by attaching the floating div's edges to different box edges. |
| 23:12 | <TabAtkins> | Or, wait! |
| 23:12 | <TabAtkins> | Another div, positioned on top, with a left:0;right:0;margin-right:100%; |
| 23:13 | <TabAtkins> | Or, hm. |
| 23:13 | <TabAtkins> | You may need a wrapper div around the float that's a normal block and a positioning root. |
| 23:13 | <TabAtkins> | So the margin will resolve its percentage propertly. |
| 23:21 | <AryehGregor> | Cool observation by Peter Beverloo: over 50% of web browsers by market share are now open-source (if you count Chrome as open-source). |
| 23:21 | <AryehGregor> | Yay. |
| 23:21 | <AryehGregor> | Argh. |
| 23:21 | <AryehGregor> | My post to public-html has not appeared. |
| 23:21 | AryehGregor | stabs it viciously |
| 23:22 | <smaug____> | well, Chrome isn't open source :p |
| 23:22 | <AryehGregor> | Pfft, trivial details. |
| 23:34 | <annevk> | maybe not appendChild(string), but there's something to say for new Text(...) |
| 23:35 | <annevk> | and maybe new Element(localNameWithNamespaceautomaticallyresolvingtoSVGMathOrHTML) |
| 23:38 | <TabAtkins> | annevk: Indeed! |
| 23:39 | <TabAtkins> | I still wonder if there's any way we could kick everything into a single namespace if we got SVG and MathML to agree to it. |
| 23:40 | <annevk> | there is |
| 23:40 | <annevk> | by breaking all existing SVG and Math content |
| 23:40 | <annevk> | or at least most of it |
| 23:40 | <TabAtkins> | I meant "reasonably". |
| 23:40 | <TabAtkins> | We *could* do anything if we ignore compat. |
| 23:41 | <annevk> | changing XML would be the other path |
| 23:41 | <annevk> | seems that would be kind of hard |
| 23:42 | <annevk> | apart from the local name clashes |
| 23:42 | <TabAtkins> | Are there localname clashes? |
| 23:42 | TabAtkins | didn't think SVG clashed with HTML at all, but isn't sure about MathML. |
| 23:43 | <heycam> | annevk, oh, great idea. I did worry that createElement(dosomethingwithnamespacesautomatically) wouldn't be compatible, but doing it for `new Element(...)` only might be a good place to have it |
| 23:44 | <TabAtkins> | And I guess it takes the script's current document as the element's document? |
| 23:44 | <heycam> | yeah |
| 23:44 | <heycam> | I imagine |
| 23:44 | <heycam> | I think someone ought to look at how we could resolve the differences between the similar elements of HTML and SVG (like <script>, <a>) |
| 23:44 | <TabAtkins> | While we're at it, BAG OF ATTRIBUTES OMG |
| 23:45 | <heycam> | :) |
| 23:45 | <annevk> | TabAtkins, video, audio, textArea |
| 23:45 | <annevk> | TabAtkins, style, script |
| 23:45 | <TabAtkins> | annevk: Those are Tiny, right? |
| 23:45 | <annevk> | TabAtkins, some are I guess |
| 23:45 | <annevk> | TabAtkins, dunno what's implemented in most browsers |
| 23:45 | <TabAtkins> | video/audio/textArea are. |
| 23:45 | <TabAtkins> | Browsers don't implement Tiny at all. |
| 23:45 | <heycam> | Opera does some |
| 23:46 | <TabAtkins> | style/script/a are shared, but I suspect are similar enough to unify. |
| 23:46 | <heycam> | but yes, we should move away from textArea and towards just CSS boxes full of text |
| 23:46 | <TabAtkins> | (And we should unify them anyway, for author understanding.) |
| 23:46 | <heycam> | should we add defer/async to svg script, for example? dunno. |
| 23:46 | <TabAtkins> | Yes, definitely. |
| 23:47 | <TabAtkins> | Any differences between SVG <script> and HTML <script> are platform bugs, imo. |
| 23:50 | <annevk> | I do think that would be a good idea |
| 23:50 | <annevk> | Someone should probably write up a more coherent plan |
| 23:51 | <TabAtkins> | I wrote it on my whiteboard as a todo. Does that count? |
| 23:52 | <heycam> | TODO: Fix the Web platform |
| 23:52 | <annevk> | TabAtkins, sorry |
| 23:53 | <annevk> | heycam, that's like bug #1 now plugins are "destroyed" |