| 04:29 | <zcorpan> | jgraham: why isn't it logical to have attributes on the prototype? |
| 07:50 | <jgraham> | zcorpan: Attributes are properties of instances. Putting them on the prototype and using getter magic to return the value seems like a very muddy model that depends on implementation details |
| 07:50 | <JonathanNeal> | hiya |
| 07:54 | <zcorpan> | jgraham: but it makes feature detection simpler for authors |
| 07:56 | <jgraham> | Well not if 3/4 browsers don't use the model |
| 07:56 | <jgraham> | Since you will have to feature detect different things in different places |
| 07:57 | <jgraham> | Although I would agree in principle if that wasn't the case |
| 08:22 | <zcorpan> | so with authors > implementors, shouldn't we be moving to that model? |
| 08:24 | <hsivonen> | I wonder what kind of evil situations I should test with HTML in sync XHR that can be tested relatively deterministically in an automated test... |
| 08:25 | <hsivonen> | I'm now mainly testing charset stuff and that scripts don't run |
| 08:34 | <annevk> | <img> not loading? |
| 08:40 | <hsivonen> | annevk: oh yeah, I'm testing img, iframe, style sheet, video, object and script not loading |
| 08:41 | <hsivonen> | and the onload attribute in the loaded file doing nothing |
| 08:41 | <hsivonen> | my sync XHR testing is now on the level "seems to work. good." |
| 08:57 | <jgraham> | zcorpan: The point is that in the short term it makes things worse for authors. And in the long term it makes the mental model more confusing, although it will improve feature detection once we don't have to care about IE<11 (say) |
| 09:45 | <annevk> | sicking seems very confused with the proposal |
| 10:31 | <hsivonen> | annevk: which proposal? |
| 10:35 | <annevk> | oh sorry |
| 10:35 | <annevk> | the proposal for easier element creation |
| 10:49 | <hsivonen> | sigh. the reference maturity level issue just won't go away (now DAP and DOM4) |
| 10:50 | <annevk> | also see the geolocation list |
| 10:50 | <jgraham> | hsivonen: Making that issue go away would be admitting that the process is broken. Which it is. But there are still heads in the sand. |
| 10:50 | <annevk> | someone suggested referencing HTML4 for event handler attributes |
| 10:51 | <annevk> | trololol |
| 10:53 | <hsivonen> | Referencing HTML4 is even more sad than referencing DOM < 4 |
| 10:56 | smaug____ | hasn't even started to look at all the append/element creation proposals yet |
| 11:21 | hsivonen | finds <!DOCTYPE NETSCAPE-Bookmark-file-1> |
| 11:26 | <zcorpan> | hsivonen: does firefox use the html5 parser for importing bookmarks these days? |
| 11:34 | <hsivonen> | zcorpan: not yet |
| 11:35 | <hsivonen> | zcorpan: that's why I'm looking at a file that has a doctype like that |
| 11:37 | <zcorpan> | ok |
| 11:37 | <jgraham> | In unrelated news http://my.opera.com/desktopteam/blog/2011/10/07/ragnarok-css3-radial-gradients |
| 11:39 | <annevk> | yay for stig james arne et al |
| 11:39 | <hsivonen> | jgraham: cool |
| 11:40 | <annevk> | hmm |
| 11:40 | <annevk> | Opera Next says I'm using the latest snapshot |
| 11:40 | <annevk> | but I'm clearly not |
| 11:41 | <hsivonen> | annevk: the Ubuntu/Debian repo is also out of date |
| 11:41 | <jgraham> | annevk: They don't release the snapshots to autoupdate straight away |
| 11:41 | <smaug____> | hsivonen: still about parsing. Does the spec say that some elements can be moved in the DOM during parsing |
| 11:42 | <hsivonen> | smaug____: yes |
| 11:42 | <jgraham> | smaug____: s/can/must/ |
| 11:42 | <smaug____> | hsivonen: I mean, are some elements really inserted to DOM and then moved to some other place? |
| 11:42 | <hsivonen> | smaug____: yes |
| 11:43 | <hsivonen> | smaug____: however, in the innerHTML case, per spec, that happens in the fragment that gets inserted but our optimization optimizes away the fragment so that it happens in the tree in that case |
| 11:43 | <smaug____> | right |
| 11:43 | <smaug____> | I |
| 11:43 | <hsivonen> | smaug____: which is why I suggested turning off the mechanism that turns notifications into MutationRecords when the fragment parser is running |
| 11:43 | <smaug____> | I'm thinking about mutations while parsing the page |
| 11:43 | <hsivonen> | and then faking the MutationRecord right after |
| 11:43 | <jgraham> | hsivonen: Thanks btw |
| 11:44 | <hsivonen> | smaug____: while parsing the page from the network, stuff can get moved around per spec |
| 11:44 | <smaug____> | though, that all happens per spec... |
| 11:44 | <smaug____> | so if someone listens for mutations before the page is loaded, surprises are ok, I guess |
| 11:47 | <hsivonen> | smaug____: is the new mechanism so lightweight that reporting parser-made mutations is OK for perf? |
| 11:47 | <hsivonen> | jgraham: thanks about what? |
| 11:47 | <smaug____> | hsivonen: well, it is up to the web app to decide whether to use it or not |
| 11:48 | <jgraham> | hsivonen: 05:42 < hsivonen> jgraham: cool |
| 11:50 | <annevk> | smaug____, should we really have mutations for the parser inserted elements? |
| 11:51 | <hsivonen> | jgraham: ah. you're welcome |
| 11:51 | <smaug____> | annevk: I'm not sure |
| 11:51 | <hsivonen> | jgraham: are you no longer in Sweden or is just your IRC not in Sweden? |
| 11:51 | <smaug____> | annevk: that is something I'm trying to figure out |
| 11:51 | <jgraham> | hsivonen: Just my IRC |
| 11:51 | <hsivonen> | smaug____: will the Skype extensions be able to use it on every page? |
| 11:52 | <smaug____> | I sure hope Skype isn't using mutation events anymore |
| 11:52 | <smaug____> | I somehow thought they moved to our internal mutationobserver thingie |
| 11:52 | <smaug____> | since skype extension is anyway a binary extension |
| 11:53 | <jgraham> | hsivonen: I am balancing out the fact that Hixie's IRC is in Norway :) |
| 11:58 | <hsivonen> | smaug____: ok. my main point is that parse-time perf can be affected for all pages if an extension can request to see the MutationRecords for all pages |
| 11:59 | <annevk> | smaug____, doesn't sound like a good idea |
| 11:59 | <smaug____> | annevk: any particular reason why |
| 12:00 | <annevk> | cause you can already get to the result easily enough |
| 12:00 | <smaug____> | how ? |
| 12:00 | <annevk> | just wait until the parser is done |
| 12:01 | Cradam | likes the version-less html idea |
| 12:01 | <smaug____> | (again, I don't really have opinion whether it should be possible get mutationrecords during parsing) |
| 12:02 | <smaug____> | annevk: well, if you have a huge page, like HTML spec, some script might want to decorate elements while the page is still loading |
| 12:02 | <smaug____> | basically initialize widgets or such during the page load |
| 12:03 | <annevk> | I think for those you should get mutations |
| 12:03 | <annevk> | I would expect the parser to use DOM methods that do not affect mutation observers |
| 12:04 | <annevk> | internal stuff |
| 12:04 | <smaug____> | I don't understand |
| 12:04 | <smaug____> | " I think for those you should get mutations" ... "use DOM methods that do not affect mutation observers" |
| 12:04 | <annevk> | everything the parser does uses internal methods that do not affect mutation observers |
| 12:05 | <smaug____> | for what should you get mutations ? |
| 12:05 | <annevk> | but if you have a script that while parsing does a call to insertBefore or some such that would affect them |
| 12:05 | <smaug____> | so it is not possible to initialize widgets during parsing |
| 12:06 | <smaug____> | I'm talking about widgets like <div foobar="element_with_foobar_attribute_is_a_widget"> |
| 12:07 | <Cradam> | eugh i hate those wierd attributes people use |
| 12:07 | <annevk> | for that we are going to introduce a dedicated mechanism |
| 12:08 | <annevk> | <div is=something> or some such, see the component model discussion |
| 12:08 | <annevk> | it seems bad if you need all the overhead of mutation observers just for that |
| 12:08 | <Cradam> | i also find it wierd how people use "" when they arent needed |
| 12:09 | <bga_> | Cradam ++ |
| 12:09 | <bga_> | and close <td> |
| 12:10 | <annevk> | </td> being optional was a great idea |
| 12:10 | <bga_> | yes |
| 12:11 | <Cradam> | tables... who uses them other than for ecommerce |
| 12:12 | <annevk> | me |
| 12:13 | <Cradam> | annevk: seriously? |
| 12:13 | <bga_> | Cradam table layout is easy than div layout |
| 12:13 | <Cradam> | bga_: :O |
| 12:13 | <annevk> | Cradam, http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html#concept-throw |
| 12:13 | <Cradam> | NEVER USE TABLES FOR LAYOUT! |
| 12:14 | <bga_> | :) |
| 12:14 | <smaug____> | tables are useful |
| 12:14 | <annevk> | or e.g. http://annevankesteren.nl/2010/07/matterhorn-tour |
| 12:14 | <annevk> | yeah, they're just annoying to author |
| 12:14 | <smaug____> | annevk: yes, I can see reasons to not fire create mutation records |
| 12:14 | <Cradam> | smaug____: yes for tabular data |
| 12:14 | <smaug____> | but for consistency they should be there... |
| 12:14 | <smaug____> | but I don't care too much |
| 12:15 | <smaug____> | I'm trying to get innerHTML + mutationrecords to work better first |
| 12:15 | <smaug____> | (in the implementation) |
| 12:16 | <Cradam> | annevk: why do i need that |
| 12:16 | bga_ | crying each time when write {document.createEvent() ...} |
| 12:17 | smaug____ | needs to find time to implement event ctors |
| 12:17 | <Cradam> | i repeat the NEVER part of my comment about not using tables for layout! |
| 12:17 | <annevk> | Cradam, what? |
| 12:18 | <Cradam> | annevk: why do i need that link about DOM |
| 12:18 | <annevk> | because you asked whether I used tables for something other than ecommerce and I said yes and then you asked if I was serious so I decided to give some examples |
| 12:18 | <hsivonen> | annevk: why can't I set responseType on XHR before the state is OPENED? |
| 12:19 | <Cradam> | ahh yes |
| 12:19 | <Cradam> | tables... who uses them other than for ecommerce and tabular data |
| 12:19 | <annevk> | hsivonen, because open() resets a bunch of things |
| 12:19 | <Cradam> | tables... who uses them other than for ecommerce and tabular data (other than newbs who don't know better) |
| 12:19 | <hsivonen> | annevk: hmmkay. failed my intuition |
| 12:20 | <annevk> | hsivonen, we could make it work I suppose, it kind of depends on how people want this to work |
| 12:20 | <annevk> | other than extensions there's not much love for XMLHttpRequest from people other than me |
| 12:21 | <hsivonen> | annevk: hey, I'm giving XHR some text/html love |
| 12:21 | <annevk> | technically that's an extension, but it's still great and appreciated :) |
| 13:58 | <hsivonen> | hrm. ES5 String.prototype.trim() affects more than space, tab, CR and LF |
| 13:58 | <hsivonen> | boo |
| 13:59 | <jgraham> | hsivonen: You won't liek any of the string stuff in ECMAScript |
| 14:00 | <jgraham> | It all depends on ever changing unicode standards |
| 14:00 | <hsivonen> | :-( |
| 14:02 | <Ms2ger> | hsivonen, and of course we should make HTML number parsing depend on it as well! |
| 14:03 | <hsivonen> | Can ES5 or Mozilla-specific JS do 64-bit ints these days? |
| 14:04 | <hsivonen> | maybe I should pass 64-bit ints as stringified in JS |
| 14:05 | <Ms2ger> | { hi: ..., low: ... }? |
| 14:06 | <smaug____> | I don't recall 64 bit |
| 14:06 | <smaug____> | isn't Number 53 bits or something strange like that |
| 14:07 | <bga_> | Ms2ger i have choosed to have internal charset w/ EOL, a-z, a-Z, 0-9 and $#... its just look like stantdard ascii but i dont trust standards :) and i have abstract class for external charset which can convert string to internal charset and back, have 'isClass' fn like isLowerChar for transforming/parsing w/o convert to internal charset |
| 14:07 | <bga_> | i'll show you later |
| 14:07 | <Ms2ger> | Wasn't 53 bits how much SM allows pointers to use? |
| 14:08 | <hsivonen> | smaug____: Number is a 64-bit IEEE 754 value per spec |
| 14:08 | <bga_> | hsivonen https://developer.mozilla.org/en/js-ctypes/js-ctypes_reference |
| 14:09 | <Cradam> | a[href="./"],a:link[href="./"] {} FTW |
| 14:10 | <smaug____> | hsivonen: yeah, but you can't express all the 64bit values using JS Number |
| 14:10 | <smaug____> | I mean 64bit int |
| 14:12 | <hsivonen> | bga_: thanks |
| 14:14 | <Cradam> | bored and poor = not a good combo |
| 14:14 | <Ms2ger> | You could write specs |
| 14:18 | <Cradam> | Ms2ger: ... |
| 14:18 | <Cradam> | why would anyone respect specs that i write, its not like i have 10 years of experience or a phd |
| 14:18 | <Ms2ger> | Me neither |
| 14:19 | <bga_> | Cradam write spec and its will die in draft state :) |
| 14:21 | <Ms2ger> | There's a lot of stuff that still needs specifications |
| 14:28 | <Philip`> | Ms2ger: Pointers are 47 bits, I think |
| 14:29 | <jgraham> | I wonder how many people writing specs *do* have 10 years of experince and a PhD |
| 14:29 | <Philip`> | (64-bit doubles can store 53-bit integers losslessly) |
| 14:30 | <Ms2ger> | jgraham, all the people who got us DOM3? :) |
| 14:30 | <Philip`> | If spec writers had PhDs, surely they'd be more likely to write specs in LaTeX than in HTML |
| 14:31 | <Cradam> | also how will writing specs relieve boredom of poverty |
| 14:31 | <Ms2ger> | You have something to do, and Google might end up hiring you |
| 14:31 | <smaug____> | Ms2ger: not D3E |
| 14:31 | <Ms2ger> | Don't talk to me about d3e ;) |
| 14:32 | <smaug____> | Google, or Mozilla or Opera might hire you, perhaps even Microsoft |
| 14:32 | <Cradam> | *or |
| 14:32 | <Cradam> | baha google would never hire me |
| 14:32 | <jgraham> | smaug____: That's just mean |
| 14:32 | <Cradam> | smaug____: i would NEVER work for MS |
| 14:33 | <Ms2ger> | Apple? |
| 14:33 | <bga_> | Oracle :P |
| 14:34 | <Cradam> | Apple is also not high on my willing to have a job with them |
| 14:36 | <hsivonen> | when will epoch time as JS Number lose millisecond precision? |
| 14:36 | <hober> | Cradam: :( |
| 14:37 | <Cradam> | hober: why? |
| 14:37 | <Ms2ger> | hober is an Apple employee |
| 14:38 | <Philip`> | hsivonen: 2^53 msecs = 2^43 secs = quarter of a million years |
| 14:38 | <hsivonen> | Philip`: ok. good |
| 14:39 | <Cradam> | hober: i only mean that they sound like they have a very corporate environment, i would rather work for google or mozilla |
| 14:41 | <gsnedders> | In other news, the HbbTV and OIPF specs are scary. |
| 14:41 | hsivonen | looks up OIPF |
| 14:41 | <gsnedders> | hsivonen: No 64-bit ints, just 64-bit doubles. |
| 14:41 | <hsivonen> | Wikipedia doesn't know what OIPF is |
| 14:42 | <gsnedders> | Open IPTV Forum |
| 14:42 | <hsivonen> | Oh Open IPTV Forum |
| 14:42 | <hsivonen> | gsnedders: who is implementing those specs besides Opera? |
| 14:42 | <hsivonen> | a dozen WebKit ports? |
| 14:43 | <gsnedders> | http://www.mediatvcom.com/content.php?page=hbbtv&preview=true&lg=en |
| 14:43 | <gsnedders> | A lot of them are custom CE-HTML impls |
| 14:43 | <Cradam> | i think i have upset hober |
| 14:44 | <hsivonen> | gsnedders: custom CE-HTML impls as in not using a pre-existing Web engine? |
| 14:44 | <gsnedders> | Yeah. |
| 14:45 | <hsivonen> | gsnedders: the only browser vendors there that I've heard about are Opera, Access and ANT |
| 14:45 | <hsivonen> | I wonder how Web-compatible the non-Opera engines are |
| 14:46 | <gsnedders> | They aren't, pretty much. |
| 14:46 | <hsivonen> | gsnedders: who provides the content that these engines ingest? cable company extranets? |
| 14:46 | <gsnedders> | hsivonen: Pretty much. Sometimes widgets as well. |
| 14:47 | <hsivonen> | I wonder what the sales pitch for the non-Opera vendors is |
| 14:47 | <gsnedders> | These things do rather help our > 70% marketshare on TVs… |
| 14:47 | <hsivonen> | oh. the Comedia thing is said to be WebKit |
| 14:48 | <gsnedders> | I believe there are other WebKit based impls too. |
| 14:48 | <Cradam> | ie6 usage at 9% FTW |
| 14:48 | <gsnedders> | But certainly not with any large amount of development resources to practically have a good enough product to sell. |
| 14:49 | <hsivonen> | Recently, Poland joined Finland, Sweden, Norway and Denmark as a contry with < 1% IE6 usage share |
| 14:49 | hsivonen | wonders how security patches work with TVs |
| 14:49 | hsivonen | guesses they don't |
| 14:49 | <gsnedders> | Depends on the TV. |
| 14:50 | <gsnedders> | Some TVs have browsers in ROM, so they don't, at al. |
| 14:50 | <hsivonen> | Since our TV works, I've figured that there wouldn't be much of an upside to connecting it to the Internet and trying a software update |
| 14:51 | <hsivonen> | though I believe our TV doesn't have a browser |
| 14:51 | <hsivonen> | IIRC, it came with legal stuff that suggested it has some Mozilla software in it. NSS probably |
| 14:52 | <gsnedders> | In general Opera-based TVs updates are entirely up to the vendor. |
| 14:52 | <gsnedders> | Because for a lot of them we merely ship an SDK to the vendor. |
| 14:52 | <hsivonen> | It would suck to start relying on a browser, find out that it has an XSS-enabling hole and not get a fix |
| 14:53 | hsivonen | uses Firefox for TV browsing (Firefox running on a Mac Mini) |
| 14:54 | <Cradam> | hober: i am sorry |
| 15:07 | <zewt> | i don't think i've ever seen Android update its browser either, except during a full OS update |
| 15:09 | <Cradam> | i don't understand the use of TV's |
| 15:09 | <Cradam> | in modern cyber space |
| 15:12 | <gsnedders> | zewt: Heck, my Android phone has known security bugs in it, because the vendor (HTC) didn't want to support a year old phone. :\ |
| 15:12 | gsnedders | gets tempted to get involved in web TV standards again, but doesn't really want to inflict that pain on himself |
| 15:12 | <gsnedders> | But they are such a mess. :\ |
| 15:12 | <Ms2ger> | You could get involved with the IETF instead |
| 15:13 | <gsnedders> | Ms2ger: Considerably less painful. |
| 15:13 | <zewt> | the browser, at least, should be updated by market like every other google-provided app--but I've never once seen that happen |
| 15:13 | <gsnedders> | zewt: Probably not because WebKit is a system library, and that's where the interesting bits lies. |
| 15:13 | <gsnedders> | *lie |
| 15:14 | <gsnedders> | Like, the browser itself is fairly uninteresting, and unlikely to be where any security issues are. |
| 15:15 | <zewt> | it's pretty astounding that Google didn't set up their mobile OS to allow updating the browser easily, and ship with a solid browser (android's browser is very ... not) |
| 15:15 | <zewt> | (tried developing simple touchscreen webapps supporting it; not fun at all) |
| 15:17 | <hsivonen> | zewt: Firefox and Opera Mobile to rescue |
| 15:18 | <zewt> | google should not be creating new old, unupdated, buggy browsers that almost everyone on a platform uses; we're just getting rid of one of those D: |
| 15:19 | <hsivonen> | gsnedders: what kind of holes? |
| 15:20 | <zewt> | i still havn't found a really reliable way to make a webapp go fullscreen on androidbrowser (eg. without the gigantic address bar) |
| 15:20 | <zewt> | google images seems to do it but I don't think I figured otu how |
| 15:21 | <hsivonen> | zewt: Google employees could start giving presentations where they call the Android default browser a "boat anchor browser" :-) |
| 15:44 | <gsnedders> | hsivonen: http://www.dailytech.com/88+Serious+Security+Bugs+Identified+in+Android+22+Froyo/article20060.htm |
| 15:50 | <smaug____> | <meta http-equiv="X-UA-Compatible" content="IE=8" /> mean that the web site requires IE8 mode, right? |
| 15:50 | <Ms2ger> | Looks like it |
| 15:53 | <Cradam> | smaug____: and why would you use it rather than just getting IE8 portable |
| 15:53 | <smaug____> | I'm not using it |
| 15:53 | <smaug____> | a web page is using it, and it would apparently actually break without it |
| 15:54 | <Cradam> | smaug____: check what it looks like with it turned off with your dev tools |
| 15:54 | <Cradam> | and report whether it breaks |
| 15:57 | <hsivonen> | smaug____: well, if you see that, you don't really know if it really requires the IE8 mode or if would work in IE9 mode, too |
| 15:57 | <Cradam> | hsivonen: or you can press f12 and turn it off |
| 15:59 | <smaug____> | hsivonen: well, in this case I assume it would break in IE9 mode. The problem is what HTMLElement.prototype.onmouseenter = function() {} does |
| 15:59 | <smaug____> | Gecko and IE9 throws exception per spec |
| 16:00 | <smaug____> | but the web page doesn't expect that |
| 16:12 | <hsivonen> | unsuprisingly, the Netscape bookmark format doesn't adhere to HTML vocabulary design patterns |
| 16:13 | <hsivonen> | there's a boolean attribute that takes the value "true" |
| 16:13 | <hsivonen> | there are also attribute names with underscores in them |
| 16:16 | <timeless> | hsivonen: Cable boxes are more exciting for Updates than TVs :) |
| 16:16 | <timeless> | at least TVs have a UI |
| 16:16 | <timeless> | but in general, security updates on embedded devices are a disaster |
| 16:16 | <timeless> | odds generally are that they don't secure the transport |
| 16:16 | <timeless> | and do a bad job of validating the update package |
| 16:17 | <timeless> | and yes, it's like Windows 9x, where you probably will have a better chance of being rooted before you can get your box updated :) |
| 16:42 | <JonathanNeal> | mornin' |
| 16:49 | <JonathanNeal> | Would anyone be interested in helping me edit diveintohtml5 for accuracy with present technologies? |
| 17:00 | <timeless> | define edit? |
| 17:00 | <timeless> | i'm slightly willing to review documents that are less than 3 screens tall |
| 17:00 | <timeless> | (roughly under 2 printed pages?) |
| 17:03 | <JonathanNeal> | Well, if you could review some of the wording at http://diveinto.org/html5/ anywhere you please as little or as much as you please, it would be greatly appreciated. |
| 17:03 | <timeless> | it's easier for me to review in response to a specific request |
| 17:04 | <timeless> | so, i'll review the literal page you linked, you poke me on Tuesday for another page |
| 17:04 | <timeless> | ok? :) |
| 17:06 | <timeless> | actually, that page is too bland :) |
| 17:06 | <timeless> | http://www.diveinto.org/html5/introduction.html |
| 17:06 | <timeless> | > But you can detect support for individual features, like canvas, video, or geolocation. |
| 17:06 | <timeless> | offhand, i think you /might/ want s/or/and/ |
| 17:06 | <timeless> | > That’s an important part of it, but it’s not the whole story. |
| 17:06 | <timeless> | I personally do s/it's not/it isn't/g |
| 17:07 | <timeless> | > The HTML5 specification also defines how those angle brackets interact with JavaScript, through the Document Object Model (DOM). |
| 17:07 | <timeless> | i'm not sure about the <comma> there, i believe it's valid both ways, but i wonder if it's better without it |
| 17:08 | <timeless> | > Even Microsoft — rarely known for blazing the trail of standards support — will be supporting most HTML5 features in the upcoming Internet Explorer 9. |
| 17:08 | <timeless> | IE9 shipped, so that `will be` needs to be redone |
| 17:09 | <AryehGregor> | What happened to diveintohtml5.org? |
| 17:09 | <timeless> | Mark disappeared from the face of the earth iiuc |
| 17:09 | <timeless> | > HTML5 features like geolocation (Chapter 6) and video (Chapter 5) were first provided by browser plugins like Gears or Flash. |
| 17:09 | <timeless> | s/or/and/ |
| 17:09 | <AryehGregor> | Really? Does anyone know the circumstances? |
| 17:10 | <timeless> | i don't, but there are some places that talked about it |
| 17:10 | <timeless> | i didn't spend the time reading it, i just filed it away as "i should remember that" |
| 17:10 | <timeless> | i'm not sure if it was the earth or the digital earth fwiw |
| 17:11 | <AryehGregor> | http://meyerweb.com/eric/thoughts/2011/10/04/searching-for-mark-pilgrim/ |
| 17:12 | <Cradam> | timeless: mind making your speech easier to read |
| 17:12 | <annevk> | is he no longer working at Google? |
| 17:13 | <timeless> | Cradam: sorry, please clarify? |
| 17:13 | <timeless> | (suggestions welcome) |
| 17:13 | <timeless> | ... i tend to write using w3 style scribe regexps (s///), which actually mean something to a scribe.pl script |
| 17:14 | <timeless> | they tend to be easier than diff -u output :) |
| 17:14 | <timeless> | AryehGregor: ok, thanks for making me read that :) |
| 17:15 | <timeless> | JonathanNeal: anyway, that's as much time as i can allocate today |
| 17:15 | <timeless> | poke me Tuesday w/ another page |
| 17:18 | <JonathanNeal> | thanks timeless |
| 17:22 | <Cradam> | timeless: yes well we kinda don't want to read regexps |
| 17:23 | <AryehGregor> | Cradam, some of us are accustomed to it. |
| 17:24 | <timeless> | i have a couple of editing styles, i can switch to one of the others |
| 17:24 | <JonathanNeal> | So, is it "HTML 4" and "HTML5"? What's with the sometimes space? |
| 17:24 | <timeless> | i believe so |
| 17:24 | <timeless> | google: HTML4 yields About 9,800,000 results (0.17 seconds) |
| 17:25 | <timeless> | google: "HTML 4" yields About 15,000,000 results (0.19 seconds) |
| 17:25 | <timeless> | I'm not sure where blame lies for the change |
| 17:25 | <miketaylr> | are we on "H:TML" or "HTML LS™" now? |
| 17:25 | <timeless> | it's possible that it's the Media |
| 17:25 | <timeless> | miketaylr: *sigh*, i'm sure i should recognize those references, but i don't |
| 17:25 | <Cradam> | i type HTML5 because it is more of a name than a version |
| 17:26 | <miketaylr> | timeless: oh latter is living standard, former is... i may have just made it up |
| 17:26 | <timeless> | yeah, i think part of it is that "HTML 4" really referenced the "HTML 4" specification |
| 17:26 | <Cradam> | HTML LS sounds cool |
| 17:26 | timeless | has seen : notation *somewhere* |
| 17:27 | miketaylr | recalls something as well but forgets |
| 17:28 | <JonathanNeal> | timeless: that was great, I made all the changes you mentioned |
| 17:28 | <JonathanNeal> | minus the or/and for around "browsers already support" where there wasn't an "or" to replace. |
| 17:29 | <timeless> | sorry, what's "browsers already support"? which line of context failed? |
| 17:31 | <AryehGregor> | Is there some way to get the time when the page has been fully laid out and is actually interactive? |
| 17:31 | <AryehGregor> | Programmatically. |
| 17:31 | timeless | thought gecko had an event for that |
| 17:31 | <JonathanNeal> | timeless: nevermind, I found the "or" you were referring to. |
| 17:31 | <timeless> | do you want an event or a timestamp? |
| 17:31 | <timeless> | JonathanNeal: cool |
| 17:32 | <AryehGregor> | Either would do. |
| 17:32 | <timeless> | please feel free to respond like that indicating a failure, but preferably indicating which line i quoted and the regexp i specified |
| 17:32 | <JonathanNeal> | Is it wrong to say "HTML4". Should it be "HTML 4" ? |
| 17:32 | <timeless> | JonathanNeal: it's 3:2 in favor of the latter |
| 17:32 | <timeless> | since the spec is called the latter, i believe it really should be |
| 17:33 | <timeless> | probably a page explaining the names for HTML 3.2 / HTML 4 / HTML5 would be useful |
| 17:33 | <JonathanNeal> | timeless: but it's "HTML5" all together, yes? |
| 17:33 | <timeless> | you can stick it in an appendix |
| 17:33 | <timeless> | yeah |
| 17:33 | <JonathanNeal> | Yea. |
| 17:33 | <JonathanNeal> | Okay, cool. |
| 17:36 | <Ms2ger> | HTML LS makes me think of DOM LS |
| 17:36 | <timeless> | indeed |
| 17:36 | <timeless> | did you cry or tear your hair out? |
| 17:37 | <Ms2ger> | I'm used to worse than that ;) |
| 17:40 | <miketaylr> | oh right, i remember. wasn't there a H:TML for HTML: The Markup Language at some point? |
| 17:41 | <miketaylr> | oh this guy, http://www.w3.org/TR/html-markup/ |
| 17:43 | <sicking> | jgraham: i probably misunderstood the proposal |
| 17:43 | <sicking> | jgraham: will look at your library |
| 17:43 | <Ms2ger> | Don't, unless you want to poke your eyes out :) |
| 17:58 | <Hixie> | JonathanNeal: it's just "HTML" :-) |
| 17:58 | <JonathanNeal> | Right. |
| 17:59 | <JonathanNeal> | Well, I was meticulous. |
| 17:59 | <timeless> | HTML5 is just the Media's Brand Name |
| 18:31 | <Cradam> | its called a buzz word timeless |
| 18:32 | <timeless> | s/its/it's/ ;-), sure... |
| 18:34 | <JonathanNeal> | :) |
| 18:36 | timeless | leaves |
| 18:36 | <timeless> | גמר חתימה טובה |
| 18:36 | <AryehGregor> | timeless, same to you. |
| 18:37 | <AryehGregor> | jgraham, so if I use innerHTML with escaping in that one place, instead of textContent 75,000 times, it drops the time until the load event from about 35s to about 7s. |
| 18:37 | <AryehGregor> | (in Chrome 15 dev) |
| 18:37 | <AryehGregor> | In Firefox 8.0a2, it drops it from around 78s to 45s. |
| 18:41 | <AryehGregor> | jgraham, while I agree that in general it's better to use textContent instead of doing escaping manually, it's justifiable to use less-safe techniques in cases where they provide a large enough performance increase. |
| 18:41 | <AryehGregor> | FWIW, if I comment out your test suite and do function test(f) {try{f()}catch(e){}} and define assert_* as no-ops, it takes like one second to run the tests. |
| 18:42 | <AryehGregor> | So the time it's taking is basically all the test suite, not the tests. |
| 18:44 | <JonathanNeal> | http://www.diveinto.org/html51/ is what I'm putting together thus far. It's juuuuust beginning. |
| 19:00 | <AryehGregor> | jgraham, diff: http://pastebin.com/wbAazWRk |
| 19:24 | <AryehGregor> | jgraham, additional proposed change: hide results by default if there are > 1000 rows. This reduces my real-world test-case to about 7 seconds in Chrome from 25 or so, from starting to load it until the page is usable. |
| 19:24 | <AryehGregor> | http://pastebin.com/YKdPRTem |
| 19:24 | <AryehGregor> | Of course, checking either of the boxes will freeze the tab for ten seconds or more. |
| 19:39 | <AryehGregor> | jgraham, I pushed another performance change that should hopefully be unobjectionable. I'll wait for your feedback before pushing the other two. |
| 19:59 | <Cradam> | one thing i love, PDF |
| 19:59 | <Cradam> | i love read-only files :P |
| 19:59 | <Ms2ger> | Philip`, so your PhD is done by now? |
| 20:00 | <smaug____> | AryehGregor: what is taking 35s in Chrome but 78s in FF ? |
| 20:00 | smaug____ | would like to profile that |
| 20:00 | <Ms2ger> | The editcommands tests, I presume |
| 20:03 | <smaug____> | hmm, that might involve editor. /me leaves testing to ehsan |
| 20:03 | <Ms2ger> | Very much so |
| 20:25 | <Philip`> | Ms2ger: Yep |
| 20:25 | <Ms2ger> | Good, then you can start looking at my bugs :) |
| 20:25 | <AryehGregor> | smaug____, running 26,000ish tests in jgraham's test harness. I don't think it has anything to do with the tests themselves, it's all test harness overhead AFAICT. |
| 20:25 | AryehGregor | goes to dig up a stable URL for an example |
| 20:26 | <smaug____> | ah, it would be interesting to know what in the testharness causes that difference |
| 20:26 | <AryehGregor> | The exact URLs I'm using are works-in-progress, not useful for me to hand them out to anyone. |
| 20:26 | <smaug____> | I think I haven't profiled textContent |
| 20:27 | <AryehGregor> | smaug____, e.g., this takes over twice as long for me in Firefox as Chrome (will freeze Firefox briefly): http://dvcs.w3.org/hg/editing/raw-file/98671dcd5b1f/selecttest/Selection-collapse.html |
| 20:28 | <AryehGregor> | In that case it's less drastic, since it's only 4-5s in Chrome to start with, 9-10s in Firefox. |
| 20:28 | <AryehGregor> | Beware, the version of testharness.js included with that will change. I'm in the middle of optimizing it. |
| 20:29 | <AryehGregor> | So if you want to profile properly, I suggest saving the page and all includes. |
| 20:30 | <Philip`> | Ms2ger: Hopefully :-) |
| 20:31 | Philip` | needs to work through a backlog of things |
| 20:31 | <Ms2ger> | Yeah, I believe you do ;) |
| 20:32 | <smaug____> | AryehGregor: well, very briefly |
| 20:32 | <AryehGregor> | ? |
| 20:33 | <smaug____> | AryehGregor: that test takes like 5s here |
| 20:33 | <smaug____> | and the freeze is very short |
| 20:33 | <AryehGregor> | smaug____, I've discovered my CPUs are older and cheaper than most people around here. :) |
| 20:33 | <AryehGregor> | Freezes for more like 10 seconds for me. |
| 20:33 | <smaug____> | my macbook is ancient |
| 20:33 | <AryehGregor> | Well over a minute for longer test-cases. |
| 20:33 | <AryehGregor> | What CPU does it have? |
| 20:34 | <smaug____> | (I use macbook only for profiling. For other things I want reasonable UI) |
| 20:34 | <smaug____> | dunno what cpu |
| 20:35 | <AryehGregor> | Anyway, obviously, Chrome doesn't freeze at all, except that one tab. One of the biggest reasons I use Chrome right now. |
| 20:35 | <smaug____> | 2Ghz core 2 duo |
| 20:36 | <AryehGregor> | I'm using a 2.6 GHz AMD 64 X2. So it's unsurprising that a Core 2 Duo is faster even at a slower clock speed, but a factor of two seems excessive. |
| 20:36 | <AryehGregor> | Oh well. |
| 20:38 | <smaug____> | bah, Shark doesn't work |
| 20:38 | <AryehGregor> | What's Shark? |
| 20:39 | <smaug____> | the profiler on OSX |
| 20:42 | <AryehGregor> | Ah |
| 20:42 | <AryehGregor> | . |
| 21:27 | <AryehGregor> | jgraham, so with my additional two patches applied, Chrome seems to be spending most of its time on a) actually running the test content and b) doing hard-to-optimize-further things like doing the giant innerHTML set, and make_message/format_value. |
| 21:28 | <AryehGregor> | (I could probably optimize make_message/format_value some, but it's only like 10% of the profile at this point, so it's not really worth it.) |
| 21:28 | <AryehGregor> | I.e., I don't see any really low-hanging optimizations at that point. |
| 21:28 | <AryehGregor> | Firefox is similar, but seems to do a bit worse -- it takes much longer on ancestor_windows for whatever reason, and maybe some others. Firebug's profiling is worse than Web Inspector's, though, so not sure. |
| 21:30 | <AryehGregor> | Well, let me correct that: I bet I could still massively optimize layout. But I don't have good tools for that. |
| 21:36 | <AryehGregor> | Hmm . . . it looks like if I defer layout, it takes much longer than if I do it right away. |
| 21:37 | <AryehGregor> | Probably the "add a bunch of consecutive visible nodes to DOM" case is much more optimized than the "remove display: none from a bunch of existing nodes". |
| 21:37 | <AryehGregor> | So perhaps we don't want that patch. |
| 21:38 | AryehGregor | tries to think what could possibly speed up layout here, but has no idea, since he doesn't know how layout works at all |
| 21:38 | <AryehGregor> | Other than having fewer things to lay out, naturally. |
| 21:54 | <AryehGregor> | jgraham, consider my second patch (hide results by default if there are >1000 tests) retracted. It seems to do more harm than good. |
| 21:55 | <AryehGregor> | The innerHTML one still stands, though. |
| 22:19 | <annevk> | http://lists.w3.org/Archives/Public/public-webapps/2011OctDec/0131.html |
| 22:19 | annevk | is somewhat surprised |
| 22:36 | AryehGregor | is only moderately surprised |
| 22:36 | <AryehGregor> | mpilgrim is a perennially surprising person. |
| 22:37 | <AryehGregor> | So it tends to dull over time. |
| 22:44 | <jgraham> | AryehGregor: Sigh. If we must have innerHTML stuff can we at least have a single escaping function |
| 22:50 | <annevk> | Hixie, you are not defining what happens when you set an event handler that is already non-null? |
| 22:51 | <annevk> | Hixie, or for that matter, what happens when you set a non-null event handler to null |
| 22:51 | <Hixie> | nothing happens (other than it gettings its new value) |
| 22:51 | <Hixie> | getting |
| 22:52 | <Hixie> | i can say that if you like |
| 22:52 | <annevk> | the event listeners associated with the EventTarget surely change in some way? |
| 22:53 | <Hixie> | no |
| 22:54 | <Hixie> | all that changes is the value of the event handler |
| 22:54 | <Hixie> | (which i think is already defined) |
| 22:54 | <Hixie> | (but i can check in a sec) |
| 22:54 | <Hixie> | the event listener itself is just a small anonymous function that calls the event handler if it's not null |
| 22:54 | <Hixie> | all event listeners that have ever been set to a non-null value have the same one |
| 22:54 | <Hixie> | the same anonymous function, i mean |
| 22:55 | <annevk> | oh interesting |
| 22:56 | <annevk> | I wonder if that's exposed in any way |
| 22:56 | <Hixie> | if it wasn't done that way "return false" wouldn't work |
| 23:09 | <Hixie> | annevk: what does "a Function object" mean in DOM Core? |
| 23:09 | <Hixie> | a JS Function object? |
| 23:09 | <Hixie> | or an object implementing the HTML spec's Function interface? |
| 23:11 | <Hixie> | and is the callback this value for addEventListener() really the target, not the currentTarget? |
| 23:11 | <Hixie> | for event handlers it's the currentTarget, right? |
| 23:12 | <annevk> | yeah, ECMAScript |
| 23:12 | <smaug____> | callback this value must be currentTarget |
| 23:15 | <smaug____> | (well, of course not if callback is actually an object, not a function) |
| 23:16 | <annevk> | smaug____, thanks fixed |
| 23:16 | <annevk> | Hixie, I wasn't sure how to mark up Function |
| 23:16 | <Hixie> | yeah |
| 23:17 | <annevk> | Hixie, it's currentTarget for both apparently, didn't test properly :( |
| 23:17 | <Hixie> | k |
| 23:17 | <annevk> | but the spec is fixed now |
| 23:19 | <annevk> | oops, bedtime, ttyl |
| 23:21 | <michaelw> | if a script element which has async or defer set is removed from the document tree *before* the script actually run, should it still run eventually? |
| 23:22 | <Hixie> | i believe the answer is no |
| 23:22 | <Hixie> | wait |
| 23:22 | <michaelw> | anything else would've raised more questions :) |
| 23:22 | <Hixie> | it depends on whether the element was inserted by the parser or not |
| 23:23 | <Hixie> | see a Function object |
| 23:23 | <Hixie> | er |
| 23:23 | <Hixie> | see http://www.whatwg.org/specs/web-apps/current-work/#execute-the-script-block |
| 23:23 | michaelw | looks |
| 23:25 | <Hixie> | annevk: dom core doesn't pass the Event object to the listener! |
| 23:37 | <michaelw> | Hixie: hmm, I don't see it in the section you referenced, but in the section directly above (in particular, step 15), I could read it that way, because the defer scripts go to the "list of scripts that will execute when the document has finished parsing" (and async scripts to the "set of scripts that will execute ASAP") |
| 23:39 | <michaelw> | however, fun starts if a defer script is in that lists, and the document is blown away and a new one is created (which I understand is possible)... |
| 23:54 | <Hixie> | michaelw: if the document is blown away, the list is never used, is it? |
| 23:54 | <Hixie> | i don't recall exactly where the list is used |
| 23:54 | <Hixie> | in the parser is one place |
| 23:54 | <Hixie> | i think in the script section is the other, there's some text somewhere that talks about it |
| 23:54 | <Hixie> | this particular part of hte spec is one of the most complicated aspects of the web platform, fwiw |
| 23:58 | <michaelw> | Hixie: even for the case that a script wants to remove everything from a document, there is no way to avoid executing the (then potentially unneeded) async and defer scripts |
| 23:58 | <michaelw> | (by everything I mean all nodes) |